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

From: "Weiss, Walter" <[email-masked]>
Date: Thu, 15 Feb 2001 11:27:16 -0500

Fred,

My impression is that you have expressed concern for the purpose of
DiffServSchedulerFailNext on several occasions. I brought up the FailNext at
the last meeting based on some recent observations I had made. The purpose
of scheduler chaining is to allow schedulers further up on the hierarchy to
override the decision of the previous scheduler. The scenario we have all
grown comfortable with is one where a bandwidth scheduler allows a
conforming packet through but a subsequent priority scheduler rejects the
packet. In this scenario, the first scheduler succeeded, but the second
schduler failed.

Now, let's consider two situations where the reverse happens. Suppose you
have a hierarchical CBQ scheduler which "borrows" unutilized bandwidth from
peer queues (queues aggregating to the same scheduler at a specific point in
the hierarchy). The borrowing function only occurs at the next level up in
the hierarchy because the previous level "failed" to provide sufficient
resources. In another scenario, there may be bandwidth limiting scheduler
that allows a subset of queues to leak bandwidth if there is excess capacity
available. Again, this is a scenario where the bandwidth scheduler may
prevent a packet departure while a subsequent scheduler which manages
arbitrates these failures based on some independent scheduling criteria.
This was the rational for distinguishing between a failnext and a
succeednext. If this is unclear or you have a better mechanism in mind,
please let us know.

Per Brian's request, I will work on a more concrete proposal.

regards,

-Walter

> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]]
> Sent: Wednesday, February 14, 2001 8:27 PM
> To: diffserv
> Subject: Re: [Diffserv] MIB-07 comments on Shapers
> 
> 
> 
> >3. Continue to use the cascading scheduler for multi-rate shaping.
> >     Acceptable complexity?
> 
> I consider the complexity unacceptable. I am thinking, 
> however that we are 
> trying too hard somehow. Let's step back a bit and rethink this.
> 
> Leaving meters (RFC 2697/2698) aside, which measure the rate 
> of arriving 
> traffic, let's look at the way a scheduler can select traffic 
> from a set of 
> queues and present it for transmission. What we want to 
> achieve, I think, 
> is a combination of things.
> 
> 1) we want to be able to say that some set of queues each get some
>     specified percentage of the line - "the queue containing 
> AF1 gets at
>     least 1/2 the line", "the queue containing AF2 gets at 
> least 1/4 the
>     line", and so on.
> 2) we want to be able to give absolute rates as well: "The queue
>     containing AF4 gets at least 10 MBPS".
> 3) we want to be able to say that some set of queues gets 
> priority over
>     some other set of queues - "the queue containing EF gets simple
>     priority over everything else"
> 4) we want to be able to limit the rate of some set of queues to a
>     selection of rates: "AF3 is being used for video; give it 
> the sum of
>     the mean rates unless the queue gets too deep, and then 
> give it the sum
>     of the peak rates, but shape it to those rates."
> 5) we want to be able to do things hierarchically: "give these fives
>     classes up to these rates if bandwidth is available, but under no
>     circumstances give their composite more than some other 
> rate less than
>     the sum of those rates."
> 
> We obviously want to be able to get more complex in a specific 
> configuration, but these are the kinds of statements we want 
> to be able to 
> make. Correct me if I'm missing some of them.
> 
> So we want to be able to give
>   - a scheduler any combination of queues and schedulers as inputs
>   - the input to a *rate-based* (WRR/WFQ) scheduler a 
> percentage of the line
>     or a minimum rate (which gets translated internally to a 
> percentage of
>     the line). This could be expressed as the minimum output 
> rate of a queue
>     or a scheduler.
>   - the input to a *priority* scheduler a priority. This 
> could be expressed
>     as the priority of a queue or of the output of a scheduler.
>   - the output of a queue or the output of a scheduler a list 
> of maximum
>     rates or a list of maximum rate/override threshold pairs. 
> I don't see these
>     being expressed as percentages of a line, although I'm 
> willing to be told
>     otherwise. This is RFC 2963, and RFC 2212 page 10.
> 
> Now, the way things are currently described in the MIB, it 
> seems to me that 
> we don't really have a definition of "inputs", we have a 
> definition of 
> "outputs". We have pulled the priority and minimum rate 
> (expressed either 
> as a rate or hundredths of a percent) aside into the 
> diffServSchdParamEntry, and that seems to work.
> 
> What I think is being asked for is to move the maximum rates 
> out into a 
> separate table LIKE diffServSchdParamEntry, but indexed by 
> two parameters: 
> the diffServSchdParamId and a maximum rate order. This 
> shaping rate table 
> contains two variables: the RFC 2963 rate and threshold. 
> Essentially, if 
> the instantaneous queue depth is less than the indicated 
> threshold, the 
> shaper will shape to that rate; if the instantaneous queue 
> depth is deeper, 
> it will go to the next entry and shape to that rate. The 
> threshold in one 
> of the entries is not used; we're going to have to define 
> that carefully, 
> as at least I find the text in 2963 ambiguous; in some cases, 
> it says that 
> the "maximum rate" is used when the queue depth exceeds the maximum 
> threshold, and in other cases it seems to say that one 
> entry's threshold is 
> the trigger to move to the next.
> 
> Would folks be happy if I define such a table and apply it using a 
> RowPointer in parallel with the diffServQSchdParam and 
> diffServSchedulerSpecific RowPointers?
> 
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: 
> http://www2.ietf.org/mail-archive/working-groups/diffserv/curr
ent/maillist.html

---

From: John Schnizlein <[email-masked]>
Date: Thu, 15 Feb 2001 12:53:40 -0500

At 11:27 AM 02/15/2001 -0500, Weiss, Walter wrote:
>... The scenario we have all grown comfortable with is one where 
>a bandwidth scheduler allows a conforming packet through but a 
>subsequent priority scheduler rejects the packet. 
>In this scenario, the first scheduler succeeded, but the second 
>schduler failed.

We are not all comfortable with this concept of the scheduler.
Cascading schedulers without queues between, in contrast to schedulers
that might implement hierarchical scheduling directly, does not make
sense to me.

I agree with Fred that there is confusion between policing and scheduling
lurking in these discussions. Only MIB variables that do not depend on
complex models of the mechanisms underlying diffserv operations should
be included.

"Subsequent priority scheduler rejects the packet" makes no sense.

John

_______________________________________________
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: Thu, 15 Feb 2001 13:44:45 -0600

John, can you turn that into specific recommendations for deletions
from the MIB text? I can put the question to the WG if we know
precisely what is in debate.

  Brian

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Thu, 15 Feb 2001 16:21:29 -0500

John:
Who do you mean by "we"??
Please elaborate on:
"Cascading schedulers without queues between, in contrast to schedulers
that might implement hierarchical scheduling directly, does not make
sense to me."

I would like to understand your concerns and would like to address it if
possible.

For some history, much of the scheduling ideas in the MIB came from the PIB,
which Keith is a major co-author of.  Some form of weighted scheduling feeding
into a priority scheduling was in the PIB and MIB for awhile now.  We have
people
wanting to do InterOp BakeOffs of the PIB, with the MIB and PIB so much alike
now, we may want to do them together, after we finish these drafts first. :)

I can understand that people may not agree with the Shaping functionality,
but the Scheduling functionality should be pretty solid, if not, the issues
should
have been raised a long time ago.
-- Kwok --

>"Subsequent priority scheduler rejects the packet" makes no sense.
http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h
tml

---

From: John Schnizlein <[email-masked]>
Date: Fri, 16 Feb 2001 08:01:28 -0500

The question is putting DiffServSchedulerFailNext into the MIB.
My arguments have been against this change.
Until proven necessary, an arbitrarily long chain of cascading
schedulers, with the complexity of some signalling between them,
should not be included in the MIB.

Answers to your specific questions follow:

>Who do you mean by "we"??

I was disputing the claim that "we have all grown comfortable".
Just a single person's discomfort falsifies the universal claim.
Tina Iliff and Fred Baker have also indicated some lack of comfort
with the notion of "failing" in a scheduler. Without an explicit
evaluation of the potential existence of consensus, it should not
be claimed, and should not add speculative implications for the
implementation of cascading schedulers to the MIB.

>Please elaborate on:
>"Cascading schedulers without queues between, in contrast to 
>schedulers that might implement hierarchical scheduling directly, 
>does not make sense to me."
>
>I would like to understand your concerns and would like to address 
>it if possible.

The way to address this concern is to not incorporate the implication 
of cascading schedulers in the MIB. There are different ways to do this.
Fred described one that seems much simpler.

>For some history, much of the scheduling ideas in the MIB came from 
>the PIB, which Keith is a major co-author of.  Some form of weighted 
>scheduling feeding into a priority scheduling was in the PIB and MIB 
>for awhile now.  We have people wanting to do InterOp BakeOffs of the 
>PIB, with the MIB and PIB so much alike now, we may want to do them 
>together, after we finish these drafts first. :)

Thank you for that history lesson. Having discussed the PIB with Keith
myself occasionally ;-) I see no error in it. The trend toward including
the complexity of the PIB concepts into the MIB is not a good one. The
original idea of a MIB reflecting the blocks in the diffserv architecure
was better. My preference would have been that the model move toward the
MIB rather than the other way during the process of convergence.

I agree with completing the MIB ASAP. I am skeptical of the value of
tying this to the PIB and the whole policy conceptual superstructure.
Remember that the original point of diffserv has been to compose a
small set of simple functional blocks with static (at first) configuration.

>but the Scheduling functionality should be pretty solid, if not, the 
>issues should have been raised a long time ago.

It remains unclear to me how Shaping can be separated from Scheduling.
Whenever representations of these functions have attempted that, they
have raised questions. Fred's e-mail this week summarized the way these
are essentially different aspects of the process of choosing which packet
goes when.