Subject: RE: [Diffserv] Re: Proposal for Diffserv MIB - droppers

From: "Nabil Seddigh" <[email-masked]>
Date: Fri, 2 Jun 2000 01:49:22 -0400 (EDT)

"Fred Baker" <[email-masked]> writes:
>At 04:36 PM 6/1/00 -0700, Andrew Smith wrote:
>>How about RED-lite? How about WalteRED? How about NabilRED? VJ-RED?
>
>RED-Lite and RED93 both qualify as VJ-RED - he wrote both 
>of them. I can't say for Walter or Nabil, they will have 
>to speak for themselves, but Nabil suggested the weight 
>and I was quibbling on the wording of the DESCRIPTION. 
>

No such thing as a NabilRED :) I'm primarily concerned with
ensuring RED doesn't get left out of the MIB and just as 
importantly, avoid having the MIB become a restriction 
on certain MRED-related features that are deemed valuable.

The parameter set we have been discussing the last few
days seems to satisfy the requirements to configure
RED93 at least and possibly other RED variants.
Are we getting somewhere? What is outstanding?

I think it would have been a travesty to keep RED params
out of the MIB just because of lack of agreement on 
improvements to RED93.

Best,
---
Nabil Seddigh
[email-masked]

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

---

From: "Nabil Seddigh" <[email-masked]>
Date: Fri, 2 Jun 2000 00:05:45 -0400 (EDT)

"Fred Baker" <[email-masked]> writes:
>At 06:39 AM 6/1/00 -0400, Nabil Seddigh wrote:
>>Without the connection between the classifier (actually
>>the action arising out of the classifier match) and
>>the AlgDropEntry, we have to make a hidden device-specific
>>assumption as to which DSCPs the AlgDropEntry applies
>>against. Much better to make this configurable - IMHO.
>
>One of us is missing something; maybe it's me. Tell me 
>what I'm missing, please?

You're too generous :) I'm' willing to consider that
I may be the dense one ;)

>
>The MIB describes a TCB, which is a classifier, a 
>potential meter, a potential set of actions of which 
>this is one, and a queue number. You may 
>think of it conceptually as:
>
>         switch (ip_header->dscp) {
>         case AF11:
>                 if (traffic within table->meter1) {
>                         update table->meter1
>                         update table->counters
>                         randomly drop(table->dropParameters1, 
>queue[table->queue])
>                         otherwise enqueue in queue[table->queue]
>                         break;
>                 }

The above makes an assumption that AF11 maps to dropParameters1,
AF12 maps to dropParameters2 and AF13 maps to dropParameters3.
This is what I meant earlier when I talked about "implicit
mapping". Let me try to give an example of specific product
requirements. What if I have pkts marked with AF11, AF12 and AF13 and
yet only support 2 levels of drop precedence within
the device? In this case, one choice is to say if the pkt
is AF12 or AF13, use the dropParameters2 otherwise
if it is AF11 use dropParameters1. Thus, there's a M:N
mapping where M is the # of different DSCPs within a single
AF class and N is the the levels of drop precedence 
supported within that class and its associated queue.
In the above example, M is 3 and N is 2.

In the absence of a configurable M:N mapping, hard-coded
assumptions need to be made. Now imagine the case 
where a device allows you to configure (not through the MIB)
the # of drop predence levels supported per AF class.
If through a simple config option, I changed the # of 
predence levels supported from 2 to 3 or
even 4 or 5 (as you had mentioned in an earlier email, 
we should not restrict the # of drop precedence levels
supported to just 3 as in the AF RFC), in the absence 
of the mapping, it would
require software changes for the specific product. Thus,
the MIB, by not having this mapping is imposing a
restriction.

How about we include the connection between the action
and the RED parameters? If devices don't want to use
this pointer and seek to make hard-coded assumptions
(which is another perfectly valid approach that will
satisfy a different set of requirements) then the pointer
can be set to "null".

Andrew had some further comments re: having the classifier
and meters also point to the RED params. I'll find
his email and continue this line of thought in the 
context of his comments.

>
>So now you're telling me that you can't "randomly 
>drop(table->dropParameters1, queue[table->queue])" 
>unless those parameters contain something that says 
>"these parameters apply to the case AF13"? Why? 

See above. Did that clarify or muddy the issue?

Best,
---
Nabil Seddigh

---

From: "Nabil Seddigh" <[email-masked]>
Date: Fri, 2 Jun 2000 01:51:31 -0400 (EDT)

"Andrew Smith" <[email-masked] writes:
>Nabil (and a picture for Fred too),
>
>> I think this can be done easily enough. Currently, the
>> diffServActionEntry has a field with diffservActionNext
>> that points to the next datapath element. e.g. the Queue.
>> With this info, we can map DSCPs to specific Queues.
>> Why not have another entry in this structure that points
>> to the RED params. See below: 
>
>With this approach we would also have to add the forward 
>pointer to the RED parameters to Action, Meter *and* 
>Classifier entries: any of these elements
>can reflect the path through the TCB followed 
>by packets of particular DSCP "colouring(s)". 
>As I wrote earlier to Fred, a single 6-tuple classifier
>filter is not adequate to describe "AF11 OR AF12" 
> even though these 2 DSCPs might be fed through the 
>same meter and/or marker and/or counter to the same
>algorithmic dropper.
>
>Maybe the following diagram helps:
>
>  ---> AF11 ---+---> Meter1 ---> Marker1 --+--> AlgDropper1 --->
>               |          |                |
>  ---> AF12 ---+          +----> Marker2 --+
>                                           |
>  ---> AF13 -------> Meter2 ---------------+
>
>The problem is that AlgDropper1 needs to know what 
>the (possibly re-marked)DSCP is as the packet stream enters 
>it: it wants to apply different drop probability depending 
>on the DSCP. The fact that the stream
>has been classified once already is good: it means that 
>there is already an existing element to represent each 
>pattern. But "the fact that we know via which path through the 
>diagram it got to the dropper" (to paraphrase Fred)

Andrew, do I understand correctly that you're suggesting
we add the pointer to RED params to classifier, meter and action?

Maybe I'm just making implicit assumptions again but
I would have thought that instead of adding pointers
to classifer, meter *AND* actions, we just add them
to actions. Reason is that I assumed all traffic streams
have to be chained to an action prior to 
buffer management and enqueuing. I agree that it is 
cumbersome for the net admin to config pointers to
RED params per classifier. Thus, instead, if we
limit the pointer reference to being done only in 
the action and all traffic streams have an action, we have a way
of mapping all traffic to appropriate RED parameters.

BTW, I assumed that the MIB includes a "Forward
with marking or dropping action". I think this is
what is referred to as "no action" in sec 2.4.
However, I don't actually see such an action defined
in the MIB details. Is it missing?

>
>> I am assuming that if we seek to maintain multiple
>> RED parameters per Q (a la MRED) then we would
>> have multiple entries of diffServRandomDropEntry 
>> as opposed to multiple entries of diffServAlgDropEntry.
>> If it is the latter then we can modify the action
>> to point to the AlgDropEntry instead.
>
>I am assuming that diffServAlgDropEntrys exist 
>one-to-one with diffServRandomDropEntrys. RandomDrop is a 
>class that is "derived from" the more general AlgDrop in 
>OO terminology. If there are multiple drop
>algorithms in effect then I assume you would chain 
>together the diffServAlgDropEntrys with their Next pointers 
>in this incarnation of the model.

Agree that diffServAlgDropEntrys:diffServRandomDropEntrys should
have 1:1 mapping. Not sure about 
the chaining of diffServAlgDropEntrys. I guess we 
should discuss this later if we agree to include
pointers from the action (or classifier/meter) to the
RED parameters.

Best,
---
Nabil Seddigh

---

From: "Nabil Seddigh" <[email-masked]>
Date: Fri, 2 Jun 2000 01:32:43 -0400 (EDT)

Andrew,

"Andrew Smith" <[email-masked] writes:
>See below - a couple of things that I don't quite understand.
>
>
>> > > diffServRandomDropMaxThreshold OBJECT-TYPE
>> >Another rewording suggestion for the DESCRIPTION:
>> >
>> >DESCRIPTION:
>> >    "The threshold that provides primary notification of
>> >     a severe congestion level. If the average queue depth
>> >     exceeds this amount, the current rate of random dropping
>> >     has not been successful in reducing congestion.
>> >     Beyond this threshold, either 100% of packets are
>> >     dropped or the packet drop probability is increased
>> >     at a faster rate"
>> 
>> s/. Beyond this threshold/; therefore/
>> 
>> otherwise, fine.
>
>[Andrew] Not sure about the "either" here: that raises a red flag in my
>mind. The second option is somewhat vague - can we not just say "100%"? What
>does it mean to "increase the probability at a faster rate"? Rate w.r.t.
>what?
>

I included the "faster rate" bit for folks who want
to implement a 2-step function. I'm happy with the
100% limit.

>> 
>> >diffServRandomDropWeight OBJECT-TYPE
>> >     SYNTAX       Unsigned32
>> >     MAX-ACCESS   read-create
>> >     STATUS       current
>> >     DESCRIPTION
>> >        "The weighting of past history in affecting the
>> >         calculation of the current queue average. This
>> >         value is an exponent, the inverse of which can
>> >         be used to calculate the actual weighting factor"
>> >     ::= { diffServRandomDropEntry ? }
>> 
>> is it the inverse of the exponent, or the inverse of the 
>> exponentiated 
>> exponent? I think it would be better to read
>> 
>> "The weighting of past history in affecting the calculation 
>> of the current 
>> queue average using  an exponentially weighted moving 
>> average. This value 
>> is an exponent of two; the factor for the new information is 
>> 1/(2^diffServRandomDropWeight), and the factor for the 
>> history term is 
>> 1-1/(2^diffServRandomDropWeight)."
>> 
>> Does that work?
>
>[Andrew] Is it a valid assumption that the averaging is an EWMA function?
>We've been careful not to mention the specifics of the smoothing algorithm
>up to now - this would be the first time in the {Model/MIB} set that this
>were mentioned as "the" way to do it.

See previous email to Fred. I tried to remove 
the reference to EWMA.

Best,

---
Nabil Seddigh

---

From: Andrew Smith <[email-masked]>
Date: Fri, 2 Jun 2000 11:07:50 -0700

Nabil,

> -----Original Message-----
> From: Nabil Seddigh [mailto:[email-masked]]
> Sent: Thursday, June 01, 2000 10:52 PM
> To: Andrew Smith
> Cc: [email-masked]
> Subject: RE: [Diffserv] Proposal for Diffserv MIB - droppers 
...
> Reason is that I assumed all traffic streams
> buffer management and enqueuing. 

I'm not sure that is a valid assumption - I don't think we (currently) have
a requirement that there always be one or more Meter elements or one or more
Action elements.

The Model draft currently says that any element may be not present and it
includes an example (figure 6) where there are no Action elements between a
Meter and an Algorithmic Dropper.

The MIB draft currently says explicitly that a "null" action is to be
represented by using a RowPointer to skip to the following element.

But we could change this.

> in the MIB details. Is it missing?

Yes, so far we have not needed one.

Andrew

---

From: Fred Baker <[email-masked]>
Date: Fri, 02 Jun 2000 11:15:37 -0700

>AF12 maps to dropParameters2 and AF13 maps to dropParameters3.

you're implying that it would not? The structure of the MIB is oriented 
around that assumption. I tried to make that real clear both in the talk I 
gave in Washington and in the text in the document.

>assumptions need to be made.

It seems like, in the case, you would want the device to enforce some 
policy to the effect that there are a grand total of two sets of 
parameters, and so either the values in AF11 and AF12 must be equal, or the 
parameters for AF12 and AF13 must be equal. Alternatively, you want to have 
some other way to configure them (have a MIB that sets the registers 
specifically, and implement this MIB to be read-only in this case). I don't 
see any reason that they couldn't reply with those values separately in the 
SNMP objects.

But that seems a pretty different problem than we're looking at with 
respect to classification. How would knowing the classifier solve this? 
Remember that the classifier is completely general - it's not just DSCPs, 
but six-tuples, IPX addresses, BGP communities, MAC Addresses on other 
interfaces, interface identifiers, whatever bizarre thing comes into 
someone's head to classify on. What has the fact that the message came from 
a certain neighboring router on some other interface got to do with the 
parameters for the queue dropper on this interface, other than that it 
happened to be relevant to the fact that I decided to put it into this queue?

>his email and continue this line of thought in the

I still see a pretty strong layer violation or object boundary violation in 
having the protocol-independent queue manager know something about the 
protocol-dependent classifier, and it seems pretty strange for the 
classifier (which is looking at protocol values in messages) to know 
anything about the outbound queues.

---

From: "Nabil Seddigh" <[email-masked]>
Date: Mon, 5 Jun 2000 01:25:04 -0400 (EDT)

"Andrew Smith" <[email-masked] writes:
>I'm not sure that is a valid assumption - I don't think 
>we (currently) have a requirement that there always be 
>one or more Meter elements or one or more Action elements.
>
>The Model draft currently says that any element may 
>be not present and it includes an example (figure 6) 
>where there are no Action elements between a

It makes sense that Meters need not be present.
However, if we view the simple "forward without dropping
or marking" as an action then we could say that all traffic
streams have to be chained to an action prior to buffer 
management & enqueuing.

>But we could change this.

For a pkt to be forwarded, eventually one of the blocks has
to point to a Q element. All the blks (Classifier, Meter & Action)
currently allow a Q to be pointed to via a Next ptr. If
we seek to do something similar with pointing to
the diffServAlgDropEntry for this stream of pkts,
then the choice is simple. In one case, we add a new field
to each of the 3 blks and allow them to indicate
which diffServAlgDropEntry to use. Alternatively,
we force Classifiers & Meters to explicitly chain
to an action and enhance only the diffservActionEntry
to allow a ptr to the diffServAlgDropEntry.

My preference is the latter but think that the former
is also acceptable. .... as long as we can get the 
TC blks to point to a diffServAlgDropEntry (or the 
corresponding diffServRandomDropEntry), it's fine :)

Best,
---
Nabil Seddigh

---

From: "Nabil Seddigh" <[email-masked]>
Date: Mon, 5 Jun 2000 01:25:37 -0400 (EDT)

"Fred Baker" <[email-masked]> writes:

>you're implying that it would not? The structure of the MIB 
>is oriented around that assumption. I tried to make that real 
>clear both in the talk I gave in Washington and in the 
>text in the document.

I'm actually trying to do more than imply :) I hoped I was
being clear and direct enough.

With the aid of the current MIB, the router software
doesn't make the hard-coded assumption that AF11 maps to Queue 0, 
AF12 maps to Queue 0, AF21 maps to Queue 1, AF32 maps to Queue2 
etc. Why not? Quite simply, we have deemed it beneficial
to allow the net admin to configure which queues to
direct streams of packets emerging from the classifier
meter & action blocks. This is clearly valuable!

In the same way, it is useful for the same
blocks (classifier, meter & action) to allow indication
of which dropParameter[i] to use for making 
the drop decision prior to enqueuing of the
different AFij packets. Again my suggestion is to
add a simple pointer to do this. Implmentations that 
choose to hard-code as in your previous email,
can be free to do so and can NULL this pointer.

>But that seems a pretty different problem than we're looking 
>at with respect to classification. How would knowing the classifier 
>solve this? Remember that the classifier is completely general 
>- it's not just DSCPs, but six-tuples, IPX addresses, BGP 
>communities, MAC Addresses on other interfaces, interface 
>identifiers, whatever bizarre thing comes into 
>someone's head to classify on. What has the fact that the message 
>came from a certain neighboring router on some other interface 
>got to do with the parameters for the queue dropper on this 
>interface, other than that it happened to be relevant to the 
>fact that I decided to put it into this queue?

I think your last line hits it on the head. *Somewhere* you have
decided to put the pkt on the queue. Currently in the MIB, this
is specified thru a linkage between the TCBs and the queuing element.
This linkage is configurable and not hard-coded.
Then *somewhere* you need to make a decision as to which packets
to apply against which RED parameters. You have chosen to 
make that decision thru a mapping that is hard-coded.
That's fine. However, others would like the ability to make
that mapping explicit so that changes in the mapping don't
require new software loads. Seems pretty reasonable to me.

>I still see a pretty strong layer violation or object 
>boundary violation in having the protocol-independent 
>queue manager know something about the protocol-dependent 
>classifier, and it seems pretty strange for the 
>classifier (which is looking at protocol values in 
>messages) to know anything about the outbound queues.
>

Why strange? Routers cannot get away without the mapping. 
If the mapping is not via configurable MIB parameters then 
it has to be hard-coded. 

In any case, am I reading that you are opposed to the
MIB allowing a TCB blk to explicitly point to a Q?
Or are you opposed to having the TCBs point to
a set of dropper parameters? Or are you opposed to
both?

Best,
---
Nabil Seddigh