Subject: [Diffserv] shaper in the diffserv MIB

From: Fred Baker <[email-masked]>
Date: Mon, 12 Feb 2001 23:05:13 -0800

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.html

---

From: Fred Baker <[email-masked]>
Date: Tue, 13 Feb 2001 00:03:57 -0800

At 11:05 PM 2/12/2001 -0800, Fred Baker wrote:
>Andrew notes a concern he has below

he beat me to it :^)

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Feb 2001 09:32:17 -0600

The chairs aren't MIB experts and they get confused when they see
MIB experts disagreeing. 

I do understand the current version of the model draft, and absent
other input, I will suggest that the shaper part of the MIB needs
to be consistent with the model - unless we see a rapid consensus
to change the model. Kwok, please speak up!

   Brian
   confused co-chair