Subject: RE: [Diffserv] MIB-07 comments on Shapers

From: "Weiss, Walter" <[email-masked]>
Date: Wed, 14 Feb 2001 10:51:27 -0500

Brian,

If you want to go down that path, then I would object equally to a WFQ
scheduler. The usage of the term is greatly abused and the semantics of the
scheduler varies greatly. Some usages claim it is work conserving (a
relative bandwidth weight) and others claim it is non-work conserving (a
bounded bandwidth allocation). Irrespective of which you choose, some of the
scheduling parameters are no longer appropriate.

Rather than eliminate the shaping scheduler, I would prefer my earlier
suggesting of desribing two generic bandwidth schedulers. One describes a
work conserving proportion. The other describes a bounded bandwidth
allocation. All the scheduling parameters are still applicable and the names
for the schedulers are more agnostic than the current names.

regards,

-Walter

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Wednesday, February 14, 2001 8:16 AM
> To: Juha Heinanen
> Cc: Fred Baker; diffserv
> Subject: Re: [Diffserv] MIB-07 comments on Shapers
> 
> 
> Well, we are chartered to produce a MIB, so a MIB will be sent to the
> IESG. But Juha's comment reassures me that I am on the right track:
> when in doubt, cut it out. I don't detect any support on the list
> for including the shaper/scheduler. Vendors can always add bells
> and whistles, just as they can ignore unwanted features that the
> MIB happens to support.
> 
>   Brian
> 
> Juha Heinanen wrote:
> > 
> > Fred Baker writes:
> > 
> >  > >if that is not acceptable, then the mib should be
> >  > >much more abstract and contain pointers to other (in 
> many cases vendor
> >  > >specific) mibs that define the actual details of the 
> various diffserv
> >  > >mechanims.
> >  >
> >  > um, you haven't noticed the RowPointers? It can point to 
> about anything.
> > 
> > i was refering to the discussion regarding the meters, markers,
> > policers, etc. where the mib already seems to have made up 
> its mind by
> > suggesting how the mechanisms look like.  those kind of 
> things should be
> > defined in conjunction with separate rfcs that describe a 
> given meter,
> > marker, policer, shaper, red algorithm, etc. otherwise 
> there is a big
> > danger that the mib defines one particular implementation 
> of a diffserv
> > box.
> > 
> > -- juha
> >
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: 
http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h
tml

---

From: Dan Grossman <[email-masked]>
Date: Wed, 14 Feb 2001 11:46:02 -0500

We seem to be getting to a point of having lost track of what the objective 
was in the first place.  A rhetorical question: What exactly was the intent in 
standardizing a MIB?  A checklist item for the WG?  Or something usable for 
managing DS-nodes?

Can anybody explain the point in having a standardized MIB if it's useless 
without lots of enterprise MIB objects?  

In any event, whatever the answers to these meta-questions, they need to be 
captured and put in the text, so that they can be read and understood by 
implementors.

Dan

_______________________________________________
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: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Feb 2001 13:26:18 -0600

Walter,

Please send precise proposed MIB text so that we can see if the WG prefers this
approach.

   Brian

> "Weiss, Walter" wrote:
> 
> Brian,
> 
> If you want to go down that path, then I would object equally to a WFQ scheduler. The usage of the term is greatly abused and
> the semantics of the scheduler varies greatly. Some usages claim it is work conserving (a relative bandwidth weight) and
> others claim it is non-work conserving (a bounded bandwidth allocation). Irrespective of which you choose, some of the
> Rather than eliminate the shaping scheduler, I would prefer my earlier suggesting of desribing two generic bandwidth
> schedulers. One describes a work conserving proportion. The other describes a bounded bandwidth allocation. All the scheduling
> parameters are still applicable and the names for the schedulers are more agnostic than the current names.
> 
> regards,
> 
> -Walter
> 
> http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Feb 2001 13:29:53 -0600

Dan,

"managing" diffserv nodes doesn't (in the case of this MIB) mean *configuring*
them - that is either the PIB or SNMPCONF. So the mandate is a MIB that
provides meaningful generic info about what a node is doing diffserv-wise.
If that can't be achieved we will so inform the ADs, but we are actually
very close right now so I don't think we should give up just yet.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org
Non-IBM email: [email-masked]

---

From: Dan Grossman <[email-masked]>
Date: Wed, 14 Feb 2001 15:07:55 -0500

> them - that is either the PIB or SNMPCONF.
Did I say anything about configuration?
  
> So the mandate is a MIB that
So if config management is out of scope (does the MIB say that?), it must be 
doing fault management, event management, performance management and/or 
security management.  Is there enough generic information in this MIB to do 
any of those things?

> very close right now so I don't think we should give up just yet.
I'm not proposing we give up.  I'm not even sure that I care whether shapers 
are in or out, or which flavors of scheduler are in (well, actually, I agree 
with Walter, but that's besides the point).  The complaint is that we don't 
have a common understanding of exactly what the MIB is (and is not) supposed 
to manage.  Which is why we don't have a  set of architectural principles for 
deciding what's in or out.  And, more important, none of this is written in 
the draft.  Which means that anybody who reads it in a year won't know what's 
going on.

(Advice to the authors:  join the federal witness protection program as soon 
as the RFC is published. :-)  Or budget big chunks of time for answering 
questions).

---

From: Fred Baker <[email-masked]>
Date: Wed, 14 Feb 2001 15:16:19 -0800

Brian:

I am about to throw my hands into the air.

Do you, or do you not, want this scheduler/shaper thing? If you do, how 
much time are you willing to assign to properly designing it? I'm not going 
to get it done in the next 3.5 hours. There are some serious misconceptions 
here.

First, WRR vs WFQ vs Priority are a question of "when I decide to send a 
packet, which queue shall I draw it from". That is significantly different 
from work-conserving vs non-work-conserving, which is a question of "when 
may I send the next packet?" A work-conserving scheduler sends if the link 
is idle and it has data to send; a non-work-conserving scheduler (such as a 
shaper) sends if the link is idle, it has data to send, and some other 
condition (such as "a certain time has arrived") is also true. I can build 
a non-work-conserving scheduler that uses priority to select a queue, and I 
can build a work-conserving one. I can build a non-work-conserving 
scheduler that assigns a rate to each queue and mixes and matches packets 
to achieve it (WFQ by any other name), and I can build a work-conserving 
one. I can build a non-work-conserving scheduler that runs round robin on a 
set of queues and sends varying size bursts of packets (WRR), and I can 
build a work-conserving one. These two topics are disjoint.

I can also build a mixed system. Let me give you two models. In one model, 
I have a set of work-conserving queues in one scheduler, and that scheduler 
feeds into a second scheduler which has a set of shaping queues. If the 
second is a priority scheduler, I might take any ready packet from a 
non-work-conserving queue, and send from the work-conserving ones if and 
only if I have no other data to send. If the second scheduler is a WRR 
scheduler, we will search all the non-work-conserving queues and the output 
of the first scheduler in round-robin-order. In the other model, I am 
running some number of work-conserving and non-work-conserving queues in 
the same scheduler, but only the subset which have traffic and whose time 
has arrived are eligible to transmit at any given time. Again, when asking 
which to send from among those which are eligible, I might consider 
priority, rate, or whatever.

Second, a shaper assigns transmission times to packets. That is an 
arithmetic calculation. As a result, there is no concept of "succeeding" or 
"failing" - the shaper calculates times according to some algorithm, end of 
discussion. That is different than a meter, which determines whether a 
shaper on the other side of a network worked properly, and somehow 
penalizes traffic which is out of contract.

We can build a multi-rate shaper fairly easily. RFC 2963 describes one 
implementation in these terms:

>2.2. Configuration of the srRAS
>
>    The srRAS is configured by specifying four parameters: the Committed
>    Information Rate (CIR), the Maximum Information Rate (MIR) and two
>    buffer thresholds: CIR_th (Committed Information Rate threshold) and
>    MIR_th (Maximum Information Rate threshold).  The CIR shall be
>    specified in bytes per second and MUST be configurable.  The MIR
>    shall be specified in the same unit as the CIR and SHOULD be
>    configurable.  To achieve a good performance, the CIR of a srRAS will
>    usually be set to the same value as the CIR of the downstream srTCM.
>    A typical value for the MIR would be the line rate of the output link
>    of the shaper.  When the CIR and optionally the MIR are configured,
>    the srRAS MUST ensure that the following relation is verified:
>
>                CIR <= MIR <= line rate
>
>    The two buffer thresholds, CIR_th and MIR_th shall be specified in
>    bytes and SHOULD be configurable.  If these thresholds are
>    configured, then the srRAS MUST ensure that the following relation
>    holds:
>
>                CIR_th <= MIR_th <= buffer size of the shaper
>
>    The chosen values for CIR_th and MIR_th will usually depend on the
>    values chosen for CBS and PBS in the downstream srTCM.  However, this
>    dependency does not need to be standardized.

In other words, the shaper in RFC 2963 sends traffic at the lower 
"committed" rate until its internal queue becomes deeper than a threshold, 
and then it sends at the faster "peak" rate until the queue comes below the 
threshold. There is no question of a burst size in this model, only of two 
rates and a discrimination threshold (not obvious to me what it does with 
the second threshold they mention, maybe it discards data that point, I 
don't know).

The shaper defined in the Frame Relay specifications does the opposite. 
According to one interpretations, it is willing to send data in short 
bursts at a higher rate, but as soon as anything resembling a steady state 
is achieved, it slows down to the CIR. In this way, the network operator 
can provision his network assuming CIR behavior and feel that he 
understands his network. According to another interpretation, it always 
sends at the peak rate unless the network reports congestion; then it slows 
down to the committed rate for a while.

So what we need for a multi-rate shaper, as near as I can tell, is N rates 
and N-1 queue-depth thresholds, and something that tells us what algorithm 
we are applying.

So what do you want me to do, and how long are you willing to give me to do 
it? I'm glad we're finally getting comments, but I see very few of the form 
"change this text to that text". I see comments of the form "it's all wrong 
and I don't like the way this is written and I'm afeared that we're 
designing a router."

I'm sending in what I have at 6:00 PM, but I'm not yet convinced it is 
correct. From tomorrow until the end of next week, I will be fitting 
editing tasks in around a slew of other tasks including day-long meetings 
and a legal deposition. I want to get this done, but you need to manage the 
conversation to a set of editing instructions that I can execute and which 
results in the right thing.

---

From: Fred Baker <[email-masked]>
Date: Wed, 14 Feb 2001 15:20:20 -0800

> > them - that is either the PIB or SNMPCONF.

that certainly doesn't conform to my view of the universe. If MIBs can't 
configure, we should pull all the read-write and read-create variables out, 
and remove the concept of a "SET" from SNMP. PIBs and SNMPCONF are 
interesting approaches to playing with Policy, but Policy is not yet a 
proven thing. We've been configuring equipment with SNMP for a lot longer 
than anybody has even thought about policy.

Even if the statement that "configuration means PIB or SNMPCONF" is true, 
the MIB will need to reflect what they set values to.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Feb 2001 20:52:17 -0600

As previously stated, I stand corrected.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Feb 2001 21:05:00 -0600

I'm not happy that we have a consensus to include the shaper/scheduler
and I'm not happy that we have a consensus on how to describe it. Also I
am on travel all week and not in a position to analyse either the mail
thread or the MIB in enough detail before the weekend. In fact it is now 
after 6 p.m. your time and so I assume you have sent in a -08 version. 
I suspect it isn't in fact ready for last call, despite all the effort, 
so, sigh, maybe we have to go round again.

Fred, let me thank you very much for the work on this.

Everybody, **please** either indicate your preference to remove things
from the MIB (e.g. the shaper/scehduler), or to leave them as they are,
or send specific text amendments. Arguments don't help at this stage;
we need MIB text so that, assuming we have to make a -09 version,
Fred has unambiguous input at the end of next week.

   Brian