Subject: Re: [Diffserv] Diffserv MIB - droppers

From: "Nabil Seddigh" <[email-masked]>
Date: Tue, 30 May 2000 01:34:20 -0400

On May 26, 2000 "Fred Baker" wrote:
> >Instead of 1 set of RED parameters
> >per physical queue, we would have 3 sets of 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.
> 

Agreed. I guess this is also good for backwards
compatibility in the case of pre-Diffserv products
that used more than 3 thresholds of RED parameters
within a single Q.

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

Not exactly sure what "externalize the means" refers to.
I was arguing that we should allow for multiple 
averages to be maintained within a single Q - not 
necessarily per DSCP though. More on this further
down. 

I'm not proposing we allow the admin to configure
a device to use single or multiple Q averages. 
Rather, for monitoring purposes, *if* a device
uses multiple Q averages in its calculations, it
should allow the multiple averages to be read. 

BTW, I had a look at the MIB's diffservQEntry fields 
and didn't find any field that returned the current Q size -
did I miss it or is this not included? 

> 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. [.SNIP..] RIO is another algorithm, and 
> keeps a separate mean depth for each DSCP - the number 
> of packets of that DSCP in the queue. 
> 

RIO and WRED are 2 of the MRED schemes I was thinking 
of. We have experimented with a decoupled-RIO scheme
as well. Our comparison of the 3 algorithms
reveals different behaviour depending on the traffic type...
but this is probably beyond the scope of the WG or
the MIB. 

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

Can I add another twist :) The common case is to 
have a set of RED thresholds (Qmin, Qmax, Pmax)
per DSCP within the AF class queue. 
However, it is also possible to have N DSCPs in
queue and only M levels of drop precedence supported
by that device. E.g. upstream nodes mark pkts with
AF11, AF12 and AF13 but a downstream router 
supports only 2 levels of drop precedence. In this
case, for the downstream device, though we have N DSCPs, 
we only need M thresholds where M < N. I suggest that 
we need to ensure that the MIB design handles this case
as well.

There are probably a number of ways to handle
the above scenario. Currently, the diffservActionEntry 
allows mapping of DSCPs to a particular Q. This 
could be extended to allow mapping to 
a diffservAlgDropEntry. Conceptually, this is
similar to the idea of "virtual queues"
that has appeared in some recent Diffserv
publications. I'm assuming that multiple RED 
thresholds per Q will be handled by multiple
entries of diffservAlgDropEntry. 

On a side note, is there a particular reason why
diffservAlgDropTable points to the QTable instead
of the other way around?

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

Agreed. I think if we allow either one average or M it
would handle majority of the popular MRED algorithms.

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

To use MIB terminology (pg 7) is this:
Qmin, Qmax, Pmax and a 4th parameter from which
the averaging "weight" can be derived?

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

Not sure what you mean by the above. Are you suggesting
for the "N"-average case, we hang the fields off the
diffservActionEntry? Can't we just have multiple
entries of diffservAlgDropEntry with each entry 
representing a set of threholds. We then add a field
to diffservActionEntry that points to the particular
diffservAlgDropEntry. This should allow DSCP to drop
precedence level mapping. 

Also not sure re: reference to min-threshold? I thought
we would allow the admin to specify all the RED 
parameters per level of drop precedence supported by
the device.

BTW, a general comment for the MIB authors. Section
2.5.3 provides a visual view of the MIB Q table.
I think that's a great idea! Have you considered 
similar examples for other MIB tables? 

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: Mon, 29 May 2000 23:56:53 -0700

At 01:34 AM 5/30/00 -0400, Nabil Seddigh wrote:
>I had a look at the MIB's diffservQEntry fields

The ifEntry used to contain a variable called ifQDepth, which was the queue
depth in packets. This was obsoleted, as some equipment chose to not support
it (it can be tricky, when part of a queue is on one card and part is on
another, and there is a bus or fabric in between), and it was ephemeral - by
the time you read it, the value you're looking at is not current and may not
be relevant. Seeing as this was in MIB-I and MIB-II but was removed by the
Interface MIB people for a principled reason, it didn't seem to make sense
to re-introduce here in the form of "ifMeanQDepth".

I'll ask our erstwhile NM AD to comment, though - Bert, do you think we
should externalize mean queue depths in a random drop MIB? Why or why not?