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

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

Fred, 

Comments follow:

"Fred Baker" <[email-masked]> writes:
>>
>>Can we extend the above with:
>>
>>DiffServRandomDropEntry ::= SEQUENCE  {
>>      ....
>>      diffServRandomDropSpecific OBJECT IDENTIFIER,
>>      ....
>>}
>
>I'm not fundamentally opposed, but I do find myself 
>wondering: why not just define:
>
>vendorRandomDropEntry OBJECT-TYPE
>      SYNTAX       VendorRandomDropEntry
>      MAX-ACCESS   not-accessible
>      STATUS       current
>      DESCRIPTION
>         "An entry describes a process that drops packets
>          according to a random Algorithm."
>      INDEX { ifIndex, diffServAlgDropIfDirection,
>              diffServAlgDropId }
>      ::= { diffServRandomDropTable 1 }
>
>VendorRandomDropEntry ::= SEQUENCE  {
>      whatever
>  }
>
>and identify that whenever your favorite vendor's 
>equipment generates a diffServRandomDropEntry, it will 
>also generate a vendorRandomDropEntry with 
>the same index parameters? The vendor definition then 
>becomes in some sense 
>an extension of the standard parameters.
>

I think we're pretty much in agreement where to
hang the entry off of - it's mostly a naming
convention issue :)

I suggested use of RandomDropSpecific instead of 
vendorRandomDrop to be consistent with the rest of
the MIB. e.g. In diffServAlgDropEntry
we have the field diffServDropSpecific to 
allow support for other algorithmic drop schemes.
Same is true for diffServMeterSpecific.

>> > diffServRandomDropMinThreshold OBJECT-TYPE
>>
>>Suggest rewording the above description along following lines:
>>
>>DESCRIPTION
>>    "The average queue depth beyond which traffic has a
>>     non-zero probability of being dropped or marked"
>>
>> Can we get away with the simplification?
>
>Almost, except I am concerned about two things.
>
>First, is Walter OK with this? As I understand it, his favorite algorithm 
>isn't as well described. If he buys off, I'll fold.
>
>Second, actually min-threshold is in effect a target queue 
>depth. I'd like you to take a quick gander at three studies:
>
>Can we compromise on:
>
>DESCRIPTION
>   "The target queue depth, beyond which traffic has a
>    non-zero probability of being dropped or marked"
>

Thanks to the pointers on detailed RED studies. My key 
concern is that recent studies show (and personal 
experience leads me to agree) that RED-93 does
not necessarily cause the queue size to hover around
min-th. Can we compromise on your compromise:

DESCRIPTION
   "The average queue depth, beyond which traffic has a
    non-zero probability of being dropped or marked.
    In some implementations this may be viewed as
    the target queue depth"

>> > 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.

Agreed. Andrew had asked the question why the statement
about "faster rate". Why not just "100%" of the pkts?
Earlier, there was some discussion of a 2-step RED function.
I was trying to keep those folks happy. Otherwise, 
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

Sorry. Unclear terminology on my part. Actually, 
in some implementations, the weight is not factor
of 2^(1/n) but rather allows more accurate setting
of the value. Can we address those implementations 
as well with the following modification of your definition:

     DESCRIPTION
        "The weighting of past history in affecting the 
	 calculation of the current queue average.
	 This value is the inverse of the weight
	 assigned to the present sample in calculating
	 the average queue size. Past history samples are
	 weighted with (1-[1/diffservRandomDropWeight]) while
	 present samples are weighted with 
	 1/diffservRandomDropWeight."

I hope the above:

1. Addresses Andrew's concerns about EWMA specifics 
   being removed

2. Is suitable enough for implementations that 
   have to translate diffServRandomDropWeight
   to 2^n. I'm assuming devices are able to tranlsate
   the MIB value into the required "n" and 
   store it in the appropriate router variables.

Are the above reasonable assumptions?
   
>>DESCRIPTION:
>>"An inverse of the drop probability when the average
>>  queue size approaches diffServRandomDropMaxThreshold.
>
>That statement is very specific to RED93, which has a 
>defined slope. How about "The inverse of the worst 
>case drop probability."?

Just a concern with use of "worst case drop prob":
In RED-93 it's not really the worst case. Worst case
is drop prob of 1

>
>>  This value is a reflected estimate of the number
>>  of packets forwarded between successive dropping
>>  or marking events. The number zero implies
>>  that all packets are subject to drop; the number 99 indicates
>>  that when the average queue size approaches
>>  diffServRandomDropMaxThreshold roughly 1% of the
>>  packets are dropped, as between any two dropped packets
>>  99 packets are forwarded."
>
>This (and my text that it came from) could be argued as being 
>implementation specific. Maybe we should just drop it? 
>That does modify the algorithm suggested slightly, 
>but perhaps it is a good thing anyway.
>

The above text is mostly yours. I'm happy with keeping
it in.  But if you strongly feel it should be removed
then that's ok.

>Are we precessing in a useful direction?
>

I think so!

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: Fred Baker <[email-masked]>
Date: Fri, 02 Jun 2000 09:49:10 -0700

At 01:50 AM 6/2/00 -0400, Nabil Seddigh wrote:
>the MIB.

we're talking past each other. When I said "vendorRandomDrop", I was 
referring to the table you build in your vendor MIB. What I'm saying is - 
why not have it have the same index variables as the Random Drop Entry we 
create, and use it as an extension of the table. That is done when a vendor 
extends any other table - they put their own extension features into their 
private table and use the two tables together.