Subject: RE: [Diffserv] shaper in the diffserv MIB

From: "Iliff, Tina" <[email-masked]>
Date: Tue, 13 Feb 2001 15:51:19 +0000

The thoughts I have are as follows:

 If Meters for certain DSCPs are synonymous within PEPs for a domain, then
the Meters Fail and Succeed should point to appropriate Queues, Schedulers,
and parameters.  In other words if certain traffic is out of profile, then
it should be shaped in such a way which places it back in profile.  The
Meter should "lead" to appropriate Queues and Schedulers in order to
implement this shaping.  The same holds true if the traffic is in profile,
the shaping must keep it in profile.

Tina Iliff

-----Original Message-----
From: Fred Baker [mailto:[email-masked]]
Sent: Tuesday, February 13, 2001 1:05 AM
To: [email-masked]
Subject: [Diffserv] shaper in the diffserv MIB

Andrew notes a concern he has below, and then points out that he's a busy 
boy and we'd better make progress any way we can. Kwok has one approach in 
mind, Andrew doesn't see it the same way, and I'm not quite sure I agree 
with either of them. Due to the fact that Wednesday is a tad over 24 hours 
from now, I am taking the liberty of taking this discussion, framed among 
the author team, to the list for other inputs.

I would very much like to hear what other folks are thinking, and get 
direction from the chairs.

>Fred Baker wrote:
>
>A diffmk version of the proposed new draft may be found at
>ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-08.txt
>The changes are as requested on the list:
>  - revert the maximum random drop rate to tenths of a percent rather
>    than 1/integer
>  - change StaticRowPointer to RowPointer
>  - make it all run through smicng

At 08:53 PM 2/12/2001 -0800, Andrew Smith wrote:
>As I noted in a previous message, I'm still quite unhappy about this talk 
>of a "Shaper" thingy in the MIB e.g. page 81 of 
>ftp://ftpeng.cisco.com/fred/diffserv/marked.draft-ietf-diffserv-mib-08.txt.

 > This entity is not described in the Model draft and I'm not sure I know 
>what a "multi-color shaper" looks like. So I don't see that this OID 
>belongs here:
>
>"diffServSchedulerShaper OBJECT-IDENTITY
>     STATUS       current
>     DESCRIPTION
>        "For use with diffServSchedulerMethod to indicate the
>        diffServSchedulerEntry is being used to describe a Shaper.  The
>        diffServSchedulerSpecific attribute for a Shaper will point to an
>        entry in the diffServTBParamTable for the shaper's Leaky Bucket
>        parameters.  Notice multi-rate, multi-color shapers can be
>        parameterized by use of diffServSchedulerSucceedNext and
>        diffServSchedulerFailNext the same way multi-rate, multi-color
>        meters are parameterized with diffServMeterSucceedNext and
>        diffServMeterFailNext parameters."
>     REFERENCE
>         "[MODEL] section 7.1.2"
>     ::= { diffServScheduler 8 }"
>
>
>The referenced section of Model-06 contains the following text which is of 
>relevance:
>
>"Possible service disciplines fall into a number of categories, including
>(but not limited to) first come, first served (FCFS), strict priority,
>weighted fair bandwidth sharing (e.g. WFQ), rate-limited strict priority
>and rate-based. Service disciplines can be further distinguished by
>whether they are work-conserving or non-work-conserving (see Glossary).
>Non-work-conserving schedulers can be used to shape traffic streams to
>match some profile by delaying packets that might be deemed non-
>conforming by some downstream node: a packet is delayed until such time
>as it would conform to a downstream meter using the same profile.
>
>[DSARCH] defines PHBs without specifying required scheduling algorithms.
>However, PHBs such as  the class selectors [DSFIELD], EF [EF-PHB] and AF
>[AF-PHB] have descriptions or configuration parameters which strongly
>suggest the sort of scheduling discipline needed to implement them. This
>document discusses a minimal set of queue parameters to enable
>realization of these PHBs. It does not attempt to specify an all-
>embracing set of parameters to cover all possible implementation models.
>A mimimal set includes:
>
>a)   a minimum service rate profile which allows rate guarantees for
>      each traffic stream as required by EF and AF without specifying the
>      details of how excess bandwidth between these traffic streams is
>      shared. Additional parameters to control this behavior should be
>      made available, but are dependent on the particular scheduling
>      algorithm implemented.
>
>b)   a service priority, used only after the minimum rate profiles of
>      all inputs have been satisfied, to decide how to allocate any
>      remaining bandwidth.
>
>c)   a maximum service rate profile, for use only with a non-work-
>      conserving service discipline."
>
>So it seems like we don't have the right set (or at least a set consistent 
>with the Model-06 draft - but it's possible *that* draft neeeds to change 
>to reflect reality - please advise if so) of enumerations for scheduling 
>methods (right now the proto-MIB-08 has diffServSchedulerPriority, 
>diffServSchedulerWRR, diffServSchedulerWFQ and diffServSchedulerShaper): 
>in particular I wasn't aware that WFQ and "shaping" were mutually 
>exclusive things.
>I don't know exactly how to fix this - I think maybe I'm missing some of 
>the context of the discussion that lead to the 4 enumerations present in 
>this proto-MIB-08 (I thought everything looked OK in -06 but maybe I 
>blinked). I wonder if a separate "BOOLEAN diffServSchedulerWorkConserving" 
>parameter is what's intended by the addition of the "Shaping" enumeration.
>
>This issue also spills over into some of the other descriptive text for 
>e.g. diffServSchedulerSucceedNext and diffServSchedulerFailNext: I don't 
>think is is right to talk of a "scheduler acting as a shaper". In my mind 
>at least and, not coincidentally, in the definition in Model-06:
>
>"  Shaping       The process of delaying packets within a traffic stream
>                  to cause it to conform to some defined temporal profile.
>                  Shaping can be implemented using a queue serviced by a
>                  non-work-conserving scheduling algorithm."
>
>- shaping is an externally-observable behaviour that needs multiple of our 
>defined datapath elements to implement it. So any discussion of it in the 
>MIB ought to be in terms of its component elements, not a "Shaper" entity.
>
>In fact, the more I try to parse/understand the DESCRIPTION clauses for 
>these two (new) objects, the more uncomfortable I am - does anyone else 
>share this discomfort (I'll shut up now if not)?
>
>Please let me know if you want me to raise this point on the mailing list.
>
>I've also got some editorial nits e.g.
>- a DESCRIPTION clause that doesn't parse and/or scan.
>- a style issue with numbering the diffServSchedulerXXX OIDs: typically 
>these are numbered 1....n under their own arc of the MIB tree, rather than 
>being appended 5...m after some tables. This makes potential future IANA 
>administration much easier.
>
>I'll work on these nits some more if/when I can find time (busy week 
>travelling ahead - very spotty email access from tomorrow pm onwards, so 
>go ahead in my absence in whatever way y'all see fit e.g. 
>ignore/file/delete/delete-without-reading).
>
>Andrew

At 10:51 PM 2/12/2001 -0800, Andrew Smith wrote:
>At 08:53 PM 2/12/2001 -0800, Andrew Smith wrote:
>>This entity is not described in the Model draft and I'm not sure I know 
>>what a "multi-color shaper" looks like.
>
>You might look at RFC 2963, "A Rate Adaptive Shaper for Differentiated 
>Services". O. Bonaventure, S. De Cnodder. October 2000. (Format: TXT=39895 
>bytes) (Status: INFORMATIONAL)
>
>It is certainly possible to shape to multiple (at least two) rates. In 
>Frame Relay, one generally is supposed to shape to (Bc+Be)/interval 
>(CIR+EIR) under normal circumstances, and to Bc/interval (e.g. what the 
>Frame relay specs call "throughput" and the market calls "CIR"). More 
>clever algorithms step between those values. In ATM, a VBR service has a 
>peak rate and a mean rate.
>
>Kwok, correct me if I get this incorrect...
>
>I think Kwok was thinking about a case where one might have N classes of 
>traffic with a work-conserving discipline (and therefore a scheduler among 
>them) feeding into a second scheduler which used priority to arbitrate 
>between them and one or more queues. In TCB-speak, it becomes
>
>         --->classifier -+->||-> S
>                        |       c
>                        +->||-> h
>                        |       e
>                        +->||-> d
>                        |       u
>                        +->||-> l
>                        |       e------------> P
>                        +->||-> r              r
>                          |                      i
>                        +---------------->||-> o
>                          |                      r--> output
>                        +---------------->||-> i
>                          |                      t
>                        +---------------->||-> y
>
>One could certainly (and easily) describe this as two TCBs with a queue 
>between the two schedulers. But having the queue sort of implies that it 
>has some depth - that it has one or more messages in it - when in fact you 
>probably want to have it be little more than a presence semaphore and keep 
>the actual messages in the first column of queues. If one *had* to 
>describe it as two TCBs, that might therefore be a little odd. So Kwok 
>wanted to insert the concept of a scheduler feeding a scheduler.
>
>If one then wanted (also hierarchically) to have the total output rate of 
>the class of work-conserving queues to follow a non-work-conserving 
>discipline, he argues that he needs to have the output of the first 
>scheduler shaped. I think that is Kwok's argument. He in this case has a 
>shaper which has no internal storage - the storage is in the queues.
>
>My concern with this is not based on the idea that the model doesn't 
>describe it; I personally think the model is a lot heavier than it needs 
>to be. If we can describe the world as having classifiers, meters, some 
>set of actions, queues, and schedulers (either work-conserving or not, and 
>quite possibly with a mix of work-conserving and non-work-conserving 
>inputs), and can decide that it is OK to connect those components like 
>tinkertoys, we have a pretty good model. Making it try to explicitly 
>describe every possible combination, or to force the world into TCBs... I 
>think that has been a bit heavy a ball chained to our collective legs.
>
>That said, what I thought we described at one point was simply a minimum 
>and maximum output rate on a queue, and the same on a scheduler. If we 
>have those, we can accomplish the above. I'm not sure we need more than
that.

_______________________________________________
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

_______________________________________________
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: Andrew Smith <[email-masked]>
Date: Tue, 13 Feb 2001 09:40:37 -0800

Tina,

The Model, and the MIB that is supposed to be consistent with it, treats these 
Queue, Scheduler, Meter entities as independent things. It makes no statement 
about whether stuff that has been metered then needs to be shaped (there are 
various appropriate policies for what to do with out-of-profile traffic: one of 
those might be to re-shape it but there are plenty of other valid policies). But 
that sort of treatment is defined by a "black-box" approach i.e. the PHB and PDB 
definitions will dictate the policy. The Model and MIB (and other 
representations/models too) then may be used to describe the individual 
components that a specific device might use to implement the policy - therefore, 
the Model has to be flexible enough to decouple the individual components.

I'd note also what I wrote in an earlier message, that "shaping" is a black-box, 
externally-observable kind of term - it can be implemented by various assorted 
combinations of the abovementioned datapath entities, not only by Schedulers.

Hope that helps,

Andrew

---

From: Steve Blake <[email-masked]>
Date: Tue, 13 Feb 2001 14:06:02 -0500

Andrew Smith wrote:

> I'd note also what I wrote in an earlier message, that "shaping" is a 
> black-box, externally-observable kind of term - it can be implemented by
> various assorted combinations of the abovementioned datapath entities, not
> only by Schedulers.

RFC 2745 has a confusing description of a shaper decomposed into multiple
elements that I don't think is helpful to propagate.  The bottom line
is that most shapers look externally like a FIFO that is serviced by
a non-work-conserving scheduling policy.  The latest mib's description
needs some tweaks but I think it is on the right track.

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake               <[email-masked]>
Ericsson IP Infrastructure                  (919)472-9913

---

From: Fred Baker <[email-masked]>
Date: Tue, 13 Feb 2001 15:49:02 -0800

Andrew: I told you I would look at what it took to make the minimum and 
maximum rates an attribute of the input of a scheduler rather than an 
attribute of the outs of a queue or of a scheduler. What I have come up 
with is that this is fine *if* a scheduler always comes last - that the 
maximum *output* rate of the scheduler is always determined by something 
else such as an output interface.

The problem I come up with is "what if you are shaping your worst case 
input rate" and "what if you are shaping your worst case output rate". To 
do this, having the rates be on the input to the scheduler means that I 
have to configure a second scheduler as final. In other words, if I'm 
willing to have (say) up to rate M of one queue and up to rate N of another 
queue, but no more than P < N+M rate over-all, I have to configure the 
queues as inputs to one scheduler and then configure a second scheduler 
with a maximum input rate of P. I don't think I have gained anything in 
that over having the maximum and minimum rates apply to the outputs of a 
queue or of a scheduler respectively.

---

From: Fred Baker <[email-masked]>
Date: Tue, 13 Feb 2001 15:47:35 -0800

At 02:06 PM 2/13/2001 -0500, Steve Blake wrote:
>The latest mib's description

Time to elaborate on the tweaks you want. Really.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Feb 2001 21:54:49 -0600

Indeed. No words sent means no tweaks will occur.

   Brian

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Wed, 14 Feb 2001 16:16:56 -0500

Fred:
Please see response embedded.
-- Kwok --

>else such as an output interface.

Do you anticipate anything with a sheduler or queue feeding into something
with unlimited physcial resources??
Some form of maximum *output* rate will always be there, correct?

>queue or of a scheduler respectively.

What you said above applies to Shaping functionality only, not Scheduling
functionality, correct?  (Scheduling is still view as parameters used by the
Scheduler at its input?)

In the current MIB-07 and MIB-08(02/12/2001), because each scheduler can
either 'schedule' or 'shape' but not both at the same time by the same
diffServSchedulerEntry, to do what you indicated, one will need to have
Q1withRateM feeds into Scheduler11,  Q2withRateN feeds into Scheduler12.
Both Scheduler11 and Scheduler12 are there to perform shaping functionality.
The output of Scheduler11 and Scheduler12 will both feed into Scheduler21
that performs scheduling functionality between the 2 streams.
The output of Scheduler21 will feed into Scheduler31 that performs shaping
functionality.
Scheduler11 shapes to rate M, Scheduler12 shapes to rate N, Scheduler21
schedules amongst output og Scheduler11 and Scheduler12.
Scheduler31 shaps to rate P.

If you say diffServSchdParam is associated with the Output of queue/scheduler,
you can say when the diffServSchdParamMaxRateAbs/Rel parameters are used,
the Queue/Scheduler limits its output to such MaxRate (Note: Only single rate
can be used by the Queue in the current MIB unless multirate, burst size are
added to diffServSchdParamEntry).
When the diffServSchdParamMinRateAbs/Rel parameters are used, they are
used by the 

If you say diffServSchdParam is associated with the Input of the Scheduler the
queue/scheduler is feeding into, and using the extra Scheduler Entry are not
of concerns, than the multirate, burst size are represented by multiple
diffServTBParamEntry's.

The diffServSchdParamEntry are associated with each Queue and Scheduler
right now.  You can view them as used by the Qeueu/Scheduler at their output
or by the Scheduler at their input.
Whichever method get choosen, most of the changes are in the text and
description.
Not in the MIB Tables attributes.

-- Kwok --

---

From: Andrew Smith <[email-masked]>
Date: Mon, 19 Feb 2001 14:41:46 -0800

Fred,

I think I understand what you're saying although it's taken me a few days to 
figure out how to answer.

> else such as an output interface.

[Andrew] i.e. a transmission line of finite bandwidth can be modelled as a 
scheduler followed by a transmission line of infinite bandwidth.

> input rate" and "what if you are shaping your worst case output rate". 
> To do this, having the rates be on the input to the scheduler means that 
> I have to configure a second scheduler as final. In other words, if I'm 
> willing to have (say) up to rate M of one queue and up to rate N of 
> another queue, but no more than P < N+M rate over-all, I have to 
> configure the queues as inputs to one scheduler and then configure a 
> second scheduler with a maximum input rate of P. 

[Andrew] I'm slightly confused: in your notation are "up to" and "no more than" 
equivalent? Or, by "up to", did you mean "guarantee a rate" (what I would call a 
"min rate") and, by "no more than", did you mean "limit to a rate" (what I would 
call a "max rate")?

> I don't think I have 
> gained anything in that over having the maximum and minimum rates apply 
> to the outputs of a queue or of a scheduler respectively.

[Andrew] If I read you correctly, I agree that this implies 2 concatenated 
schedulers to model this example: this is a functionally accurate model 
although, I agree, it may not be optimal in terms of complexity of 
representation. But I'm not sure how your example would look if the rates are 
always on the output of the scheduler: if you agree that a Scheduler can look 
like, for example:

             +-----+
    in A --->|     |
    in B --->|     |-----> output line
             +-----+

then I'm not sure I see "where" in the picture you are putting the parameters 
(bad choice of words I know - trying to draw a spacial picture to representa 
di-graph-like set of spaghetti). Are you saying that, for your example, N goes 
with input A, M goes with input B and P goes with the output line?

If so, then, I guess, you've created a new set of "output parameters" for each 
scheduler, as well as one or more per-input parameter sets - it is arguable 
whether this is simpler or more complex than forcing use of the 2-stage model 
(for such examples). Reasonable people might differ - I'll have to think this 
through some more to think how this would look in the MIB (is that what's 
already there in MIB -08? If so, that could be why I've found the scheduler 
stuff confusing since about -05 version).

If not, then please clarify.

Andrew

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Tue, 20 Feb 2001 15:56:39 -0500

Andrew:
Please see notes embedded.
-- Kwok --

>stuff confusing since about -05 version).

[Kwok]
The Scheduler in MIB-07 (the revisions after Pittsburgh):
                +----------+
   Q_A ||--->| Schdr |
   Q_B ||--->|     S    |-----> output line
                +----------+

N is in SchdParam_A pointed to by Q_A used by Schdr_S
M is in SchdParam_B pointed to by Q_B used by Schdr_S
P is in SchdParam_S pointed to by Schdr_S used by ...
(in this case used by the "output line", as you have indicated above,
with the "output line" being modelled with infinite bandwidth).

Note that N is kept with Q_A but used by Schdr_S.  This may ease
the arguement with regard to is this really "output of Q_A" or
"input of Schdr_S", which I am seeing is more of a modeling issue
then a parameterization issue.  Note that I would like to stress the
MIB should be used to CONFIGURE and MANAGE a device.
And lets solve the Modelling issues with the Model draft.
Some of these discussions may cause changes to the Model draft??

The MIB-07 did not indicate one must specify P this way, P can
be the real restriction of the "output line" indicated by the
"output line" MIB and not specify by SchdParam_S.
Should more restrictions on how the MIB may be used be specified??
 
Hope this clears up (at least some of) "the confusing scheduler stuff in
the MIB".

-- Kwok --

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Feb 2001 15:42:37 -0600

I will be attempting to go through the recent threads to pull
out a list of issues that remain in the MIB. For now:

Kwok-Ho Chan wrote:
...
> Some of these discussions may cause changes to the Model draft??

For the general reader, the Model is a lot easier to understand than the
MIB, and we have an appearance of consensus on the model right now (although
we haven't had a WG last call). I'd be reluctant to change the model
on the basis of details of a MIB that apparently only about 6 WG members
have actually looked at enough to comment.

  Brian

---

From: Fred Baker <[email-masked]>
Date: Tue, 20 Feb 2001 18:25:54 -0800

At 02:41 PM 2/19/2001 -0800, Andrew Smith wrote:
>another queue, but no more than P < N+M rate over-all, I have to configure 
>the queues as inputs to one scheduler and then configure a second 
>scheduler with a maximum input rate of P.
>
>[Andrew] I'm slightly confused: in your notation are "up to" and "no more 
>than" equivalent? Or, by "up to", did you mean "guarantee a rate" (what I 
>would call a "min rate") and, by "no more than", did you mean "limit to a 
>rate" (what I would call a "max rate")?

well, "up to" is "<" and "no more than" is "<=", but that's a nit. My point 
is that if I have two queues whose potential arrival rates are larger than 
M and N respectively, and I implement a shaper to limit them to M and N 
respectively, I can represent the maximum rate as the maximum output rate 
of the queue (the scheduler applies it, just as the scheduler applies the 
weight or the priority of a queue), or I can represent it as the input rate 
to the scheduler. If I want to limit the combination of the two data 
streams to some value P which is strictly less than M+N, I can represent 
that as the maximum output rate of a scheduler, the maximum output rate of 
a queue which manages to hold no data at any time, the maximum output rate 
of a queue which does hold some amount of data, or the maximum input rate 
of a subsequent scheduler.

It seems to me that talking about the maximum rate of a queue is comparable 
to talking about the priority of a queue, or the weight of a queue, or the 
deficit round robin gulp of a queue, etc - they are attributes applied by 
the scheduler, not the queue, but such language is certainly commonly used. 
I have a stack of very fine books on the subject that use that terminology.

We can also talk about the maximum output rate of a scheduler, and I don't 
see a strong reason not to. To him who has to implement it, of course that 
implies some sort of scheduler, but I don't think the average person thinks 
very hard about that fact.

We can put it all on the input rate/pririty/whatever to a scheduler. It is 
elegant, I suppose, in the the stuff occurs exactly once. However, I rarely 
see people discuss this configuration, or talk about having "a class of 
traffic which contains these things, and which is treated by the scheduler 
as having this scheduling priority or input rate." I hear them talk about 
"a class of traffic which contains these things and has this priority or 
rate." I think you'll find putting the attribute on the input to the 
scheduler is counter-intuitive to people for that reason. And having to 
configure two schedulers simply to limit the rate of the output of one will 
be seen as counter-intuitive. Intuitively, we talk about the rates and 
weights of classes of traffic, not of inputs to schedulers.

>But I'm not sure how your example would look if the rates are always on 
>the output of the scheduler:

I didn't put them *always* on the outputs of the scheduler. I put them on 
the outputs of the queues or the schedulers.

You tried to draw this, and apologized, and asked where I was putting 
parameters.

>    in B --->|     |-----> output line

Functionally, we have this situation:

                      M  +-----------+   M+N  +--------+ P < M+N
     {class m}---->||--->+ scheduler +------->+ shaper +------>
     {class n)---->||--->+           |        +--------+
                      N  +-----------+

note that I have punted on how the shaper is implemented; that is not key 
to the argument at this point. Bottom line it exists, and we are trying to 
decide how to represent it.

so the arrival rate of class m is something, but the departure rate of the 
queue that class m is going into is at most M. In all likelihood, some of 
class m is getting dropped as a result. In an information modeling sense, 
one would probably argue that the maximum output rate is an attribute 
neither of the queue nor of the scheduler, but of the ["inputs to"] 
relationship between the queue and the scheduler. We can represent it as an 
attribute of the queue, an attribute of the scheduler, or an attribute of 
that relationship. I am arguing that it is incorrect to consider it an 
attribute of the scheduler itself, and it is probably very correct to view 
it as an attribute of the input relationship, but it is very usual to 
consider it an attribute of the queue.

The output of the scheduler is again potentially N+M, and if the shaper is 
implemented as a queue and a scheduler, one has essentially the same 
situation - the queue overflows and the output rate is an attribute of the 
queue, the scheduler, or the relationship between them.

But one could also implement the shaper as some kind of a push back scheme 
such that the queues for classes m and n each get m/(m+n) or n/(m+n) out of 
P, so there is no need for storage in the latter shaper. In such a case,the 
shaper is simply a second scheduler, and the rate P is correctly an 
attribute of the output of the first scheduler, an attribute of the second 
scheduler, or an attribute of the [input] relationship between them. I will 
argue by analogy that this is intuitively the output rate of the first 
scheduler.

One is *correct* either way. I'm arguing from common language and practice. 
We rarely talk about the priority or rate of the relationship between a 
queue and a scheduler. We talk about the priority or rate of a queue when 
acted on by the scheduler.

>If so, then, I guess, you've created a new set of "output parameters" for 
>each scheduler, as well as one or more per-input parameter sets - it is 
>arguable whether this is simpler or more complex than forcing use of the 
>2-stage model (for such examples). Reasonable people might differ - I'll 
>have to think this through some more to think how this would look in the 
>MIB (is that what's already there in MIB -08? If so, that could be why 
>I've found the scheduler stuff confusing since about -05 version).

I think what I have just described is similar to what Kwok put into draft 
-07, the Scheduler Parameters. He applies those to the output rate of a 
queue or of a scheduler. You basically want the same parameters, I think, 
but want to apply them to the input to a scheduler.

I am further proposing that if we want multi-rate shapers, we can divide 
the parameters into two parts. One has a priority, minimum rate or weight, 
and so on. The other is a set of maximum rates and thresholds at least 
conceptually corresponding to RFC 2963. A single rate scheduler is simply 
one of those rates, and an N-rate scheduler is N rates and N-1 thresholds. 
(RFC 2963 calls for an Nth threshold as well, but I'm not convinced I know 
what to do with it).

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Wed, 21 Feb 2001 09:06:02 -0500

Fred, Andrew, DiffServ WG participants:
Please see comments embedded near the bottom of this msg.
-- Kwok --

>but want to apply them to the input to a scheduler.

[Kwok]
Yes, this is what is in MIB-07, with diffServSchdParamTable/Entry usage.
Also indicated by my earlier response to Andrew.