Subject: Re: [Diffserv] Diffserv MIB - droppers

From: "Nabil Seddigh" <[email-masked]>
Date: Thu, 25 May 2000 21:51:48 -0400 (EDT)

I have 3 main thoughts (see square brackets)
in response to Andrew's request for comments 
on the need for RED parameters in the MIB. My 
comments are interspersed with what 
Fred wrote below:

>
>I see great utility in describing a rudimentary RED dropper, 
>as the IETF recommends the deployment of RED to improve 
> handling of TCP traffic, and because we have an instance 
>of a PHB that uses that kind of dropper. More in
>a moment.
>

I tend to agree with this. Given that the AF PHB
requires AQM and given that we have an IETF RFC
recommending RED for wide-spread deployment, I 
would think that the DS MIB should contain the 
necessary parameters  to support RED and MRED 
(Multi-Level RED) - see below.

>Some quick observations:
>
>The min-threshold could be characterized as the target 
>mean queue depth. My observations of RED in deployment 
>tests is that the effect of the algorithm is to make the mean 
>queue depth hover close to that value. If we describe it
>in those terms, it probably generalizes a little better to the
>algorithms that Walter has described.
>
>The max-threshold, the so-called "upper bound", is 
>something that Van has argued and I think I have heard 
>Kathy agree is non-essential. It may be that
>we could agree to drop it as a control.
>

There has been a lot of work by different folks in the area 
of RED-variants and RED parameter setting recently. 
Until these different endeavours gather sufficient momentum
in academia and industry, I would suggest that we
focus the MIB efforts on specifying parameters for
RED-93. 

I would suggest that the MIB contain at least the 
3 key parameters traditionally associated with configuring 
RED-93 (minth, maxth and maxp). It would also be good if the
MIB contained the weight (wq) since it seems to be
a key parameter in governing RED's performance. [1]

I use the term MRED (Multi-Level RED) as the generic term
to describe Multiple-levels of RED - this is one possible
way of achieving AF. Various MRED algorithms have been
proposed and are being used - all the algorithms require a 
set of RED parameters per drop precedence level or AF 
DSCP. So I would suggest  that the MIB should provide 
support for this. Instead of 1 set of RED parameters 
per physical queue, we would have 3 sets of parameters
for queues used for the AF classes - I thought the MIB
already supported this but I haven't looked at the recent
versions. [2]

The MRED algorithms differ in the number
of queue average calculations that they base their 
drop decision on. Some algorithms use a single queue
average to make drop decisions for all packets of
an AF class while other algorithms track and use 
multiple queue averages to make their drop decisions.

Given, that we don't want to force vendors AF implementations
to a specific algorithm, I would suggest that the MIB 
allows a configurable number of Qaverages to be
calculated and returned for monitoring purposes.
This leaves it to the vendor to decide which type 
of MRED algorithm to use to achieve AF. [3]

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, 26 May 2000 12:43:30 -0700

>a key parameter in governing RED's performance. [1]

I'll buy that

>Instead of 1 set of RED parameters
>for queues used for the AF classes

This needs to be generalized, as AF defines but is not limited to 3 
classes. We need it to be indexed in such a way that it is clear what 
parameters apply to which class of traffic.

>  - I thought the MIB already supported this but I haven't looked at the 
> recent versions. [2]

The most recent version of the MIB leaves this as an open issue.

>I would suggest that the MIB allows a configurable number of Qaverages to 
>be calculated and returned for monitoring purposes. This leaves it to the 
>vendor to decide which type

not sure what you mean by that. If you mean we should externalize the 
various means, I'll argue that the information is ephemeral, and we have 
been removing ephemeral information from public MIBs over the past few 
years (and as a design guideline have generally not included it in the 
first place) as its utility was suspect. If you mean that we should allow 
separate averages to be maintained, I don't see anything in having a 
configuration block per DSCP per queue, or equivalently per action that 
applies to a queue, to negate that. Unfortunately, though, the way you 
*use* them could be very different.

For example, Cisco's WRED (one of the MRED's you mention) uses a single 
average, and it is the mean depth of the queue. we start dropping from a 
DSCP when its target queue depth (minth) is less than or equal to the mean 
queue depth associated with it. The effect of usual configurations is to 
drop most to all of AFx3 if we have to drop any of AFx2, and and most or 
all of AFx2 if we have to drop any of AFx1. RIO is another algorithm, and 
keeps a separate mean depth for each DSCP - the number of packets of that 
DSCP in the queue. Depending on how that is configured, it could keep some 
of each DSCP in the queue, or might similarly exhaust one before dropping 
from the next. So you would wind up configuring the thresholds quite 
differently.

SO now the next question might be whether there are implementations which 
use a different number - If you have N DSCPs in the same queue, do you have 
one mean, N means, or some other number? If you have some other number, 
then I submit that the problem gets even more interesting - how do you 
correlate thresholds with averages? Do you want to configure that as well? 
If such exist, that would very much need to reshape our thinking. But if it 
doesn't, then the only question is "do you have one average or N", and a 
vendor could provide instructions for the configuration of his equipment.

So I think I am arguing toward min-threshold and max-threshold, as Kathy 
suggested, an exponent to manage the exponential averaging (minp), and if 
you like an upper bound on the drop rate (the weight), and a counter per 
action so that we can measure the effect of the configuration. I am arguing 
to not externalize the current mean depth, as it is ephemeral, and if we 
did, I would argue that we want one mean (an attribute of the queue) or N 
(an attribute of the action, in the same table entry with the min-threshold 
is gets compared to).

Is that acceptable to you? Does that represent a list consensus?