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

From: "Iliff, Tina" <[email-masked]>
Date: Tue, 13 Feb 2001 16:59:18 +0000

Let me add a little clarification to my thought below...I do not agree with
the SchedulerShaper and with having multiple-rate, multiple-color
Schedulers.  That is the job of the Meter.

Tina Iliff

-----Original Message-----
From: Iliff, Tina 
Sent: Tuesday, February 13, 2001 9:51 AM
To: 'Fred Baker'; [email-masked]
Subject: RE: [Diffserv] shaper in the diffserv MIB

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.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: "Iliff, Tina" <[email-masked]>
Date: Tue, 13 Feb 2001 17:44:59 +0000

Andrew,

Exactly, the Meter to Queue to Scheduler is just one example of how one can
shape traffic or re-shape traffic (specifically, it is an example of
policing and re-shaping...one can classify and shape or one can classify,
mark and shape, etc).  Well, if you want the MIB to be totally flexible in
allowing all components to be used for many different purposes, then one can
say that an Action type of shape can be added.  There needs to be very
definitive and exact definitions in the model for each datapath functional
element.  These definitions should explicitly call out the purpose of each
functional element.  The model should dictate the structure of the MIB.

Shaping is not a scheduling method it is an outcome of scheduling.  The
scheduler is not a policer.

Tina Iliff

-----Original Message-----
From: Andrew Smith [mailto:[email-masked]]
Sent: Tuesday, February 13, 2001 11:41 AM
To: Iliff, Tina
Cc: [email-masked]
Subject: Re: [Diffserv] shaper in the diffserv MIB

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: Fred Baker <[email-masked]>
Date: Tue, 13 Feb 2001 13:51:13 -0800

>Schedulers.  That is the job of the Meter.

Actually, no. A shaper and a meter do two very different things. A shaper 
assures that traffic leaving a device goes at a certain average rate or 
range of rates, while a meter measures whether another device has correctly 
imposed a level of shaping.

The difference between the two is that in a shaper, the router 
deterministically places a message into the (short) transmission queue at 
specific times that result in a smooth transmission behavior. That message, 
however, gets jostled in time by competing traffic. This is most simply 
explained in an ATM world, so let me give you an ATM example: suppose you 
have two CBR data streams which transmit their data at one cell every N and 
one cell every M respectively. In this case, 1 cell every N*M, they are 
both scheduled into the same slot, and one of them will be jostled an 
instant later. The same behavior happens in the IP world, but the 
competition is not only with packets that want to be scheduled for 
simultaneous transmission out the same interface, but with the packet sent 
just previously which happens to be long enough to jostle the message.

In other words, the shaper ensures that the *intention* is to send data at 
a perfect rate, but reality intrudes.

The meter, in its concept of a burst size, accounts for the impacts of 
reality. It tests the arriving traffic for rate, and explicitly allows the 
arriving packets to be a tad earlier or later than ideal under the rubic of 
the burst.