Subject: Re: [Diffserv] Diffserv MIB - droppers

From: jamal <[email-masked]>
Date: Sat, 27 May 2000 22:22:56 -0400 (EDT)

For a quick overview of the architecture we have:
http://www.davin.ottawa.on.ca/ols/img9.htm

We are fully conformant to the model draft except for some implementation
specifics.

cheers,
jamal

_______________________________________________
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: Tue, 30 May 2000 11:38:28 -0400 (EDT)

In message "[Diffserv] Diffserv MIB - droppers", Fred Baker writes:
>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. 

If taken in isolation, the transient value of the queue size
may not have relevance. However, a periodically sampled 
queue size value is a useful parameter for offline 
traffic engineering and network management tools -
this is particularly true as we develop Diffserv services.
I would suggest that the MIB include not just the
N or 1 average queue sizes but also the instantaneous
value of the physical queue. 

Most devices will explicitly track this information 
so the MIB is not imposing any new "feature"
requirements.

--
Nabil Seddigh
[email-masked]

---

From: Andrew Smith <[email-masked]>
Date: Tue, 30 May 2000 09:59:37 -0700

Nabil,

> -----Original Message-----
> From: Nabil Seddigh [mailto:[email-masked]]
> Sent: Tuesday, May 30, 2000 8:38 AM
> To: Fred Baker
> Cc: [email-masked]; Bert Wijnen
> Subject: Re: [Diffserv] Diffserv MIB - droppers

...
> so the MIB is not imposing any new "feature"

That's quite a leap - just because a device uses this deep down in the
implementation doesn't mean that it is easy to extract and report back,
particularly for a silicon implementation. 

The criteria to use on evaluating a MIB variable for inclusion in a
standards'-track MIB must be primarily based on the utility to a SNMP
manager for the management of commonly-agreed functionality. If it passes
that test, then we can look at whether it is too "expensive" to implement
generally.

Andrew

****************************************************************
Andrew Smith                              tel: +1 (408) 579-2821
Extreme Networks                          fax: +1 (408) 579-3000
3585 Monroe St.                   http://www.extremenetworks.com
Santa Clara CA 95051-1450        em:  [email-masked]
****************************************************************

---

From: Andrew Smith <[email-masked]>
Date: Tue, 30 May 2000 11:00:08 -0700

See [Andrew] below.

> Sent: Monday, May 29, 2000 10:34 PM
> To: [email-masked]; [email-masked]
> Cc: Nabil Seddigh
...
> > 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? 

[Andrew] Externalize == "make visible in a read-only variable in the MIB".
The current assumption (MIB draft -03) is that such a variable should not be
externalised (see Fred's response), even if it is maintained internally in
the implementation. For what purpose would you want an SNMP manager to read
these averages?
...
> 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.

[Andrew] We had a long discussion between the authors over whether an
algorithmic dropper has multiple "inputs" (one per "classified stream") or
has a single "input" with an implied internal classifier. We chose the
latter. I place "input" in quotes because these are not really inputs and
outputs in the data plane - they show relationships in the management plane,
not packet flows. So there's really no problem in having multiple "inputs"
to such a dropper - the data plane issues (e.g. no re-ordering) have to be
handled by the data plane. The Conceptual Model draft discusses this point:

"The Algorithmic Dropper is modelled as having a single input. However,
it is likely that packets which were classified differently by a
Classifier in this TCB will end up passing through the same dropper. The
dropper's algorithm may need to apply different calculations based on
characteristics of the incoming packet e.g. its DSCP. So there is a
need, in implementations of this model, to be able to relate information
about which classifier element was matched by a packet from a Classifier
to an Algorithmic Dropper.  This is modelled here as a reverse pointer
from one of the drop probability calculation algorithms inside the
dropper to the classifier element that selects this algorithm."

> 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. 
 
[Andrew] If we add to this MIB support for a RED-like algorithm to handle
AF, I expect that we will define a MIB structure that contains a
back-pointer to the classifier filter element that selects the
drop-probability function.

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

[Andrew] I assume you mean diffServAlgDropQMeasure - this points to the
queue whose characteristics the algorithm is measuring. diffServAlgDropNext
points to the queue to which this dropper's traffic next goes (this may or
may not be the same queue as that which is being measured). In addition,
diffServAlgDropSpecific points to more specific detail of the algorithm -
this -03 version of the draft considers further specification of this
algorithm out of scope, but see issue 22. To quote from the MIB preamble:

"2.5.1.  Algorithmic Dropper Table

Algorithmic Droppers have a close relationship with queueing: they are
represented in this MIB by entries in an Algorithmic Dropper Table.
Entries contain a "next" attribute which indicates to which queue they
sink their traffic. They may also contain a pointer to specific detail
of the drop algorithm. This MIB only defines the detail for one drop
algorithm, Tail Drop; other algorithms are outside the scope of this MIB
but the general framework is intended to allow for their inclusion in
other modules.

One generally-applicable parameter of a dropper is the specification of
a queue-depth threshold at which some drop action is to start. This is
represented in this MIB, as a base attribute of the Algorithmic Dropper
entry, by pointing to the queue for which depth is to be compared and
the threshold, in bytes, to compare against.

<ed: if we need to represent a dropper as depending on multiple queues
then this single-queue pointer and threshold is not adequate: should we
leave them here or not? they will be useful for many, but not all,
dropper algorithms.>"

Anyhow, to answer your question: it is the algorithm that needs to refer to
the queue that it is measuring: that's why it points at the queue, not
vice-versa.

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

[Andrew] I'm still not understanding what is the exact set of parameters
proposed and what they mean. Everyone so far seems to have difficulty in
expressing (without referring to a particular algorithm/paper) what they
mean by this mysterious "weight" thing. To me that indicates that there is
no single DESCRIPTION that could possibly make everyone happy and still be
meaningful - but I'm willing to listen to concrete proposals.

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

[Andrew] I think Fred's terminology has confused you: I agree with Fred that
we should not have a "current queue depth" parameter in the MIB. The Model
figure 5 shows how there can be one or more (what Fred calls N) "smoothing
functions" per queue - these may use different parameter sets to do their
calculations. These may feed into one or more (T) "trigger" or "drop
probability calculation" functions. N may or may not be equal to T.

I haven't yet worked out an actual MIB representation of this (was waiting
to get consensus on what to include, if anything, first of all). But it
would be connected with diffServAlgDropTable and diffServAlgDropSpecific and
nothing to do with diffServActionTable - the Model considers algorithmic
droppers to be queueing elements, not actions (yes, it's an arbitrary choice
but it seems to fit better this way).

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

[Andrew] Not sure what you mean here.
 
> 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? 

[Andrew] Any ASCII drawings gratefully received (do you know how long it
takes to do those diagrams without a 6-week course in nroff macro-coding?).

Andrew

---

From: Andrew Smith <[email-masked]>
Date: Tue, 30 May 2000 12:06:24 -0700

Sounds like a circular argument to me - it's useful because it's useful. Can
you try to be a little more forthcoming in your uses?

Andrew

> Sent: Tuesday, May 30, 2000 11:30 AM
> To: Andrew Smith
> Cc: [email-masked]
> Subject: RE: [Diffserv] Diffserv MIB - droppers
...
> I would suggest that having a measure of
> the instantaneous and avg Q sizes is most definitely 
> useful in a Diffserv-world.

---

From: Andrew Smith <[email-masked]>
Date: Tue, 30 May 2000 14:55:00 -0700

I'm still slightly confused as to what is being requested here - is it
visibility into the *averaged* queue length or the *instantaneous* queue
length? In an earlier message you seemed to be arguing for the latter but
here you are arguing for the former. It seems to me that you've got to be
particularly careful if you sample on some already-averaged value. Please
clarify.

Andrew

> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Tuesday, May 30, 2000 2:47 PM
> To: Nabil Seddigh
> Cc: Andrew Smith; [email-masked]
> I have to say that I still don't understand. I can see how percentiles
> might be useful (95th percentile of queue length for example) 
> but I don't
> see what diagnostic information the mean queue length conveys.
> 
>   Brian
> 
> Nabil Seddigh wrote:
> > 
> > >Sounds like a circular argument to me - it's useful because
> > >it's useful. Can you try to be a little more forthcoming
> > > in your uses?
> > >
> > 
> > Circular? I guess I thought the reasons for having
> > average Q sizes was obvious. My apologies!!
> > 
> > We have done extensive work with the AF PHB as
> > incarnated by various MRED schemes: WRED, RIO
> > & RIO-decoupled. In all cases, access to the queue
> > averages greatly assisted in trouble shooting and "traffic
> > engineering".
> > 
> > Without this information, in many cases we would
> > have been unable to tell whether end-customer achieved
> > traffic characteristics was due to faulty configuration or
> > algorithm specifics.
> > 
> > Another reason for exporting the avg Q sizes are
> > the emergence of Diffserv tools for network management.
> > Offline traffic engineering and SLA tools
> > require access to algorithm specific information.
> > For the MRED algorithms, avg Q size is key
> > to achieved performance - not only delay but
> > also achieved bandwidth.
> > 
> > Best,
> > ---
> > Nabil Seddigh

---

From: "Weiss, Walter" <[email-masked]>
Date: Tue, 30 May 2000 18:10:23 -0400

Fred,

I agree that this is a reasonable starting point.

regards,

-Walter

> From: Fred Baker [mailto:[email-masked]]
> Sent: Friday, May 26, 2000 3:44 PM
> To: Nabil Seddigh
> Cc: Diffserv (E-mail)
> At 09:51 PM 5/25/00 -0400, Nabil Seddigh wrote:
> >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'll buy that
> 
> >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.
> 
> >  - 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
> >of MRED algorithm to use to achieve AF. [3]
> 
> 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.
> 
> 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?
> 
>

---

From: "Nabil Seddigh" <[email-masked]>
Date: Wed, 31 May 2000 14:03:19 -0400 (EDT)

The average queue length (whether multiple or single per 
queue) is the primary item of interest since that is 
what the MRED algorithms utilize to make their drop 
decisions. As my previous email stated, this information 
will assist with network management, trouble-shooting, 
SLA tools, traffic engineering and probably to provide 
observability into the operation of the MRED algorithms.

The instantaneous queue length is of lesser interest....
but why preclude it from the MIB? If certain products
are unable to provide such information why 
constrain other products? Again, I believe most 
products should easily be able to report this information.
Should we limit the "many" because of the exception
cases? If a product is unable to report this information,
maybe it can simply zero it out. 

Best,
Nabil

---

From: "Nabil Seddigh" <[email-masked]>
Date: Wed, 31 May 2000 15:18:34 -0400 (EDT)

In message "[Diffserv] Diffserv MIB - droppers", Andrew Smith writes:

>"The Algorithmic Dropper is modelled as having a 
>single input. However, it is likely that packets which were 
>classified differently by a Classifier in this TCB will end up 
>passing through the same dropper. The dropper's algorithm 
>may need to apply different calculations based on 
>characteristics of the incoming packet e.g. its DSCP. 
>So there is a need, in implementations of this model, 
>to be able to relate information about which classifier element 
>was matched by a packet from a Classifier to an Algorithmic 
>Dropper.  This is modelled here as a reverse pointer from 
>one of the drop probability calculation algorithms inside the

I am confused. The above is quoted from sec 7.1.3 of
the Model Draft and says there's a reverse pointer
from the dropper to the classifer. I looked at the MIB's
diffServAlgDropEntry and its associated fields.
The only pointers I found were diffServDropNext and
diffservDropQMeasure - the former points to the
next datapath element (Q) and the latter to the 
diffServQueueTable. Where's the reverse pointer to the
Classifier? Did I miss it?

In addition, I would have thought that the pointer should 
be from the classifier to the dropper and not the 
other way around. 

>[Andrew] I assume you mean diffServAlgDropQMeasure - 
>this points to the queue whose characteristics the 
>algorithm is measuring. diffServAlgDropNext
>points to the queue to which this dropper's traffic 
>next goes (this may or may not be the same queue as 
>that which is being measured). 
>

I'm not sure I understand how you can measure solely
on one queue yet drop solely on another queue.

>
><ed: if we need to represent a dropper as depending 
>on multiple queues then this single-queue pointer and 
>threshold is not adequate: should we

Do we need to represent a dropper as being dependent on 
multiple physical queues or just multiple "virtual queues" within
a physical queue?

>Anyhow, to answer your question: it is the algorithm that 
>needs to refer to the queue that it is measuring: that's why 
>it points at the queue, not vice-versa.
>

The MIB is only intended to provide config and monitoring
info. It is not intended to model implementation.
Each queue will have a bunch of config info associated
with it. Why not have the queue point to the config info? 

>[Andrew] I'm still not understanding what is the 
>exact set of parameters proposed and what they mean. 
>Everyone so far seems to have difficulty in
>expressing (without referring to a particular algorithm/paper)
>what they mean by this mysterious "weight" thing. To me that 
>indicates that there is no single DESCRIPTION that could 
>possibly make everyone happy and still be

I think there's agreement on at least 3 parameters:
(Qmin, Qmax and Pmax). As for the weight, different products
might use the weight differently but that is implementation
specific. Can't we just agree that there's a weight that
needs to be used? I wouldn't mind seeing the weight as a float
but I suspect that's a hard-sell :) The option 
of having an exponent that translates into a weight is
an acceptable compromise. The MIB doesn't need to nail down
exactly how this weight is used does it?

I believe Page 28 of the Model draft has an example
of suitable RED/MRED parameters instantiated as RIO 
parameters.

>[Andrew] I think Fred's terminology has confused you: I agree 
>with Fred that we should not have a "current queue depth" 
>parameter in the MIB. The Model figure 5 shows how there 
>can be one or more (what Fred calls N) "smoothing
>functions" per queue - these may use different parameter 
>sets to do their calculations. These may feed into one or 
>more (T) "trigger" or "drop probability calculation" functions. 
>N may or may not be equal to T.
>
>I haven't yet worked out an actual MIB representation 
>of this (was waiting to get consensus on what to include, 
>if anything, first of all). But it would be connected with 
>diffServAlgDropTable and diffServAlgDropSpecific and
>nothing to do with diffServActionTable - the Model 
>considers algorithmic droppers to be queueing elements, 
>not actions (yes, it's an arbitrary choice

Agreed! 

I think you can easily achieve the above with a 
new dropType in diffservAlgDropEntry. I think you would
also need to connect the output of the classifier-action with 
the structure that contains the specific thresholds on 
which the packet is to be compared.

Best
----
Nabil Seddigh

---

From: Andrew Smith <[email-masked]>
Date: Wed, 31 May 2000 14:19:26 -0700

See below.

> Sent: Wednesday, May 31, 2000 12:19 PM
> To: Andrew Smith
> Cc: [email-masked]

That text is from the Model draft which is designed to cover all algorithms
in a generic way but not the specifics of any one algorithm. 

The MIB does not (currently) handle specific drop algorithms. I would expect
that a MIB that included e.g. RED support, would have a RED structure which
contained appropriate pointer(s) back to the classifier(s) that are
appropriate for that algorithm. There is no sensible way to do this using
SMIv2 in a general-enough way to include such pointer(s) in the generic
diffServAlgDropEntry.

> be from the classifier to the dropper and not the 

If you have a "from" and a "to" then the choice is arbitrary from a plumbing
point of view - it just depends from whose point of view you are describing
the thing. that said, it does not make sense to add the pointer field to
every classifier element - it is more efficient to add it just to those drop
algorithm elements that need to know something about classification. Are you
arguing for bi-directional pointers then?

> on one queue yet drop solely on another queue.

Do you mean "how" or "why"? I don't see any reason *how* this would not be
feasible. I cannot think of a very good reason *why* you might want to do
this though. A contrived example might be that you use congestion
backpressure from a low-priority queue to also throttle down a high-priority
stream.

> multiple physical queues or just multiple "virtual queues" within

Not sure what you mean by a "virtual queue". We don't currently have such a
concept in the Model.

> with it. Why not have the queue point to the config info? 

Be more precise.

> (Qmin, Qmax and Pmax). 

Please provide definitions.

> As for the weight, different products
> needs to be used? 

Please provide a definition of "weight".

> I wouldn't mind seeing the weight as a float

Yes it does, for some definition of consensus on the definition.

> which the packet is to be compared.

Let me try the following to see if I understand these 2 points: I think you
are saying that diffServAlgDropType needs a new "randomDrop" enumeration -
agreed. And I think you are saying that you need a pointer between the
classifier element and the drop-algorithm-element - agreed. But there's more
than that needed, along the lines of what Fred proposed yesterday.

Andrew