Subject: [Diffserv] Re: DSMIB-09 dated

From: Andrew Smith <[email-masked]>
Date: Fri, 02 Mar 2001 17:36:57 -0800

Fred,

Taking this to the list as requested ...

Fred Baker wrote:

> At 12:06 PM 3/2/2001 -0800, Andrew Smith wrote:
> 
>> it is the whole TCB that provides shaping functionality
> 
> 
> no, it is not. The shaper is a specific piece of functionality, 
> essentially a potentially-variable maximum output rate on a queue. The 
> MIB doesn't have a TCB anywhere in it, apart from some text in the 
> introduction that talks about how to use the MIB to build TCBs.

I don't see how to reconcile this view of a "shaper" with what's in the Model 
draft, or with what I thought was in the MIB, as explained by you and Kwok in 
private messages over the last few weeks. "Queues" do not have output rates, 
they just contain data. "Schedulers" do have input rates (rates at which they 
pull data from whatever happens to be at their input). "TCB" is a shorthand for 
"collection of datapath elements that together implement some traffic 
conditioning functionality": it seems reasonable to use this shorthand for the 
queues-feeding-into-schedulers thing which is what is used, at least in the 
Model draft, to build something with traffic shaping functionality. It seems as 
if you are arguing that a "shaper" needs to be an independent element in the 
Model - if so, you need to argue the case for that on the list.

> How can the RFC 2963 shaper be built using the MIB? How do you ask the 
> question "is the instantaneous queue depth deeper than this threshold, 
> triggering me to use the faster rather than the slower rate", using the 
> meter as specified? You can do it if the shaper is an algorithm that the 
> queue scheduler will use in selecting which packet goes next, which the 
> MIB gives parameters to, but you can't make that decision using the 
> meters as specified.

I don't think anyone was arguing that Meters were a part of such a shaper (they 
can certainly be part of different types of shapers which may or may not make 
commercial sense).

> I think you're both [Andrew, Kwok] going to have to make your comments be last call 
> comments, because although you had quite a bit of time to make them, you 
> didn't make them until after I had submitted the draft, and you didn't 
> copy the working group in order to build a working group consensus 
> behind your viewpoints.

I assume you're talking about things that didn't make it into -09 draft: will do 
so. In the last week or so, I have been attempting to decipher the scheduler 
part of the MIB since the changes that you and Kwok made last time around - I 
don't recall much publication or consensus-building on those changes on the list 
though: as far as I can tell, your consensus for those changes was based on 2 
opinions and a whole bunch of deafening silence (that's OK, that's how we work 
here). I think we've made some good progress with -09 (many thanks to Fred for 
lightning fast editing turnarounds) in the last week although there's still more 
work to be done.

Andrew

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Fred Baker <[email-masked]>
Date: Fri, 02 Mar 2001 17:59:30 -0800

At 05:36 PM 3/2/2001 -0800, Andrew Smith wrote:
>I don't think anyone was arguing that Meters were a part of such a shaper 
>(they can certainly be part of different types of shapers which may or may 
>not make commercial sense).

Well, if it takes a TCB to implement a shaper (your statement to which I 
was responding), a meter is going to have to be part of it. Maybe I'm not 
understanding your definition of a shaper.

To me, a shaper is a queue with a maximum output rate. A simple shaper is 
exactly that, and a multi-rate shaper is a queue with more than one maximum 
output rate and a reason to choose among them. For a well-described 
example, read RFC 2963; it talks a whole lot about a queue, some number of 
rates, and some number of thresholds that say when each rate might be 
chosen. It also goes into great depth on how the parameters to such a thing 
should be specified - some number of {threshold, rate} pairs. That is 
literally what I implemented in the diffServShapingRateTable:

         DiffServShapingRateEntry ::= SEQUENCE  {
             diffServShapingRateId              Unsigned32,
             diffServShapingRateLevel           Unsigned32,
             diffServShapingRateAbs             Unsigned32,
             diffServShapingRateRel             Unsigned32,
             diffServShapingRateThreshold       BurstSize,
             diffServShapingRateStatus          RowStatus
         }

It doesn't take a classifier, a meter, a set of actions, and a queue to 
implement that, and when you say "a shaper is a TCB", I start looking for a 
classifier, a meter, and a set of actions, as well as a queue. So I'm 
missing something. Fill me in?

---

From: Andrew Smith <[email-masked]>
Date: Sat, 03 Mar 2001 08:36:10 -0800

Fred Baker wrote:

...
> implement that, and when you say "a shaper is a TCB", I start looking 
> for a classifier, a meter, and a set of actions, as well as a queue. So 
> I'm missing something. Fill me in?

Those are certainly some of the things that can be contained in a TCB. Nowhere 
does the Model say that they must all be present. As I wrote before, it's just a 
useful shorthand for "a collection of datapath elements".

Andrew

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 05 Mar 2001 05:12:29 -0600

Sure. A TCB is just a descriptive tool; I don't think we
expect to see it manifested in an implementation.

  Brian