Subject: Re: [Diffserv] draft-kanada-diffserv-qospifmib-00.txt

From: Yasusi Kanada <[email-masked]>
Date: Mon, 12 Jun 2000 23:23:54 -0700

Thank you for so many responses.

Brian wrote:
>As has been mentioned before, it's much easier to add things to a MIB than
>to remove them later.

I agree the MIB should not be so complicated.  However, the MIB should
support enough functionality.

In my understanding, the major features that were dropped from Diffserv
MIB (-03) are:

1. Hierarchical queuing/shaping
  I guess the scheduler can be cascaded in DiffservMIB-03.  However, 
bandwidth or priority cannot be specified for schedulers.  In DiffservMIB-02,
they can be specified for each level of hierarchical queues.  This allowed
description of hierarchical queuing and/or shaping function, such as CBQ.  
We, Hitachi, will support such function soon, so we will need this 
functionality.

2. WRED (algorithmic dropper) parameters and ...
  The WRED parameters in DiffsrvMIB-03 were too restricted.  However,
I am almost satisfied with the result of recent discussions on Diffserv ML
(although Kwok is probably not satisfied).  So, I will not discuss this
issure more.  But, I want to ask about the unit of ratio.  In the previous
version, the unit of ratios such as Pmax was 1/1000000 (Kwok called this
"per micro age").  I am not sure about the final version of Fred's MIB,
but I remember he used something different from "per micro age" for Pmax,
and 1/10000 is used for diffservQMinRateRel or diffservQMaxRateRel in 
DiffservMIB-03.  Why did you change the unit?

I want to add one more issue.  As a result of recent discussions, a
classifier is going to be introduced before the algorithmic dropper.
In the current design of Diffserv MIB, you may need a BA classifier
there, but I think there should not be a MF classifier.  In Diffserv 
MIB, a classifier can be inserted anywhere in nature, because the tables 
are connected by RowPointers.  However, I think this is too flexible.
For example, if two or more MF classifiers are specified in a Diffserv 
MIB usage and the router support only one MF classifier, there will be 
a serious semantic problem.  I experience this problem now because our
hardware router is not so flexible as Cisco's software routers (7200,
7500, ...).

A BA classifier may be too restrictive.  I think a better solution is 
to use virtual flow labels (VFL) that I introduced in my MIB 
(draft-kanada-diffserv-qospifmib-00.txt).  In this architecture, a
classifier appears only once, but VFL makes configuration flexible.
However, introduction of VFL into Diffserv MIB would take us too far
from the current point.  I think a moderate solution is to restrict 
the dropper classifier to BA.

I am sorry for my late response to Brian's call.  I wanted to write
earlier, but my job did not allow me to do so.
# Even today, Brian and I stay in the same place (iBAND4), but his
# response was much more rapid...

---
Yasusi Kanada, Ph.D,  WWW: http://www.kanadas.com/
Email: [email-masked] (day), [email-masked] (night)
Network Systems Research Dept., Central Research Lab., Hitachi Ltd.
---

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: Fred Baker <[email-masked]>
Date: Tue, 13 Jun 2000 11:35:10 -0700

At 11:23 PM 6/12/00 -0700, Yasusi Kanada wrote:
>bandwidth or priority cannot be specified for schedulers.

So you are arguing for a priority and a bandwidth function for each 
scheduler as well as each queue. Would you be happy with cloning the 
existing definitions for queues?

>DiffservMIB-03.  Why did you change the unit?

Well, to begin with, I was modeling the RED-93 paper as a baseline, and it 
doesn't talk about microages or rates, it talks about depths. So I used the 
definitions suggested by the paper.

It is my belief that a consensus has gelled around my second proposal, 
apart from the maximum drop rate parameter; there was a suggestion, I think 
a good one, that we make that be a percentage or a drops per thousand.

There was also a suggestion that we allow two different min and max 
thresholds - one for packets and one for octets. I am not strongly of 
either opinion, there are good arguments either way (Van tends to make one 
and Sally the other). I would like to minimize the number of objects, but I 
can see having four instead of two along with some information to the 
effect that one would only configure one and not the other in each pair.

If the working group chairs would comment on this consensus, I think we're 
about done there.

>classifier is going to be introduced before the algorithmic dropper.

I'm not convinced of that. It was suggested, but I'm not convinced I hear a 
consensus, and if there is a consensus and that's it, I am not a part of 
that consensus. IMHO, this is unnecessary complexity.

Maybe the chairs can comment on that consensus.

Regarding BA vs MF in that place, if we do put a classifier there, it needs 
to be able to identify any packet the first classifier would have done, so 
I think it winds up being of the same granularity.

---

From: "Ricardo Cadime" <[email-masked]>
Date: Tue, 13 Jun 2000 22:35:12 +0100

> existing definitions for queues?

Now I am getting confused. Can someone explain me how is CBQ mapped into
both Diffserv v2 MIB and Diffserv v3 MIB?? Is there any info available on
this subject??

Thanks in advance,
Ricardo Cadime

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Jun 2000 23:38:03 -0500

Fred Baker wrote:
...
> a good one, that we make that be a percentage or a drops per thousand.

I think that is a fair summary. Drops per thousand would be my choice.

   Brian

---

From: Yasusi Kanada <[email-masked]>
Date: Tue, 13 Jun 2000 23:25:18 -0700

Fred,

On Tue, Jun 13, 2000, Fred Baker <[email-masked]> wrote:
>scheduler as well as each queue. 

Yes.

>Would you be happy with cloning the 

Yes.  If a priority and a bandwidth are specified for the schedulers, 
I will be happy.

>>2. WRED (algorithmic dropper) parameters and ...
..
>>But, I want to ask about the unit of ratio.  In the previous

I do not mean the queue depth, but I wrote about the drop rate.
Theoretically the range of probability is 0 to 1.  But it must be
expressed using an integral value in a MIB, Kwok and I thought "per
micro age" was good.

BTW, Kwok allowed "kB" for the unit of queue depth, but you want to
restrict this to "packets".  I think this is OK.

>a good one, that we make that be a percentage or a drops per thousand.

As for drop rate, a percentage or a drops per thousand (permil) would
be sufficient.  However, to specify rates precisely and uniformly,
(Kwok and?) I thought "per micro age" was good, because rates MAY often
occur in (a future version of) this MIB.

---