Subject: [Diffserv] MIB-07 comments on Shapers

From: Andrew Smith <[email-masked]>
Date: Mon, 12 Feb 2001 23:02:54 -0800

I'm still unhappy about this talk of a "Shaper" thingy in the MIB e.g. page 82 
of http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-07.txt. This 
entity is not described in the current 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 
http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-06.txt 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) of enumerations for scheduling methods (right now the MIB-07 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 MIB-07 
(I thought it looked reasonably OK in MIB-06 but maybe I blinked). I wonder if a 
separate "BOOLEAN diffServSchedulerWorkConserving" parameter is what's intended 
by the addition of the "Shaping" enumeration? Maybe someone could explain the 
rationale for this change.

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

i.e. 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 confused I become - does anyone else share this 
discomfort (I'll shut up now if not)?

Andrew Smith

_______________________________________________
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: "Kwok-Ho Chan" <[email-masked]>
Date: Tue, 13 Feb 2001 12:56:20 -0500

The shaping functionality of the Scheduler (if I don't call it the

Shaper, maybe people will be happier?) in DiffServ MIB-07 is

based on the following:

In the Model draft-06

------------------------------

http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-06.txt

Section 7 first paragraph and
Section 7.1.1 first paragraph on usage

of dropper before a queue, including for shaping purpose.

Section 7.1.2 Second paragraph (after the a,b,c,d) on Non-work-conserving

schedulers for shaping purpose. Notice the sentence "a packet is
delayed

until such time as it would conform to a downstream meter using the

same profile" at the end of the paragraph.

Section 7.2 Third paragraph. "Some implementation may elect to have

queues whose sole purpose is shaping, while others may integrate the

shaping function with other buffering, discarding and sheduling
associated

with access to a resource."

Section A.4 on usage of [SRTCM] and [TRTCM] for shaping profile.

In San Diego's WG Minutes:

----------------------------------------

Minutes of Diffserv WG meetings, San Diego, December 2000

=========================================================

WG Chairs: Brian Carpenter, Kathie Nichols

Area Director: Scott Bradner

Monday December 11

------------------

...

New MIB issues:

...

*** Issue - hierarchical schedulers for excess BW

Current MIB does not address this.

One view - too immature to be included into a draft trying for last

call - ignore for now.

Other view - can be done in current framework by augmenting certain

parameters.

It was noted that a scheduler can have a failed-to-schedule outcome.

Can create hierarchy by having such failure point to another

level of scheduler. But may need both success and failure
hierarchies.

Kwok: proposes additional attribute in a SCHEDULER - two nexts - one for

success, one for failure.

Resolution - Even if the model describes mixed-action schedulers

(i.e., different treatment for different queues), the MIB will support

only single-action schedulers. However, the MIB will be changed to

allow a hierarchy of single-action scehdulers, as above.

The changes in the Shaping functionality part is to support the

above, with minimum changes to MIB-06.

Having a Shaping Scheduler (as defined by the new OID) does

NOT mean a device can not do WRR before or after the Shaping

functionality.  Since the Scheduler in the MIB is
single-action

hierarchical scheduler.  The multi-action (mixed-action)
scheduler

can be realized by using multiple different action hierarchical

scheduler table entries.

There are different ways to do this, what is in MIB-07 is just one
way.

I have considered adding a Shaping Table, but didn't do that
because

I think what is in MIB-07 is better.

I THINK THIS IS A JUDGEMENT CALL BY THE WG.

I WOULD LIKE TO CALL ON THE WORKING GROUP TO CONSIDER

IF THE MIB-07 (MIB-08) BREAKS ANY FUNCTIONALITIES IN MODEL-06

DRAFT.

I WOULD ALSO LIKE TO ASK THE WORKING GROUP TO LEAVE THE

MODELING OUT OF THE MIB, LET IT BE HANDLED BY THE MODEL DRAFT.

HENCE THE MIB SUPPORTS THE MODEL DRAFT BUT DOES NOT NEED

TO HANDLE EVERYTHING THE MODEL DRAFT WANTS TO MODEL.

AT THE SAME TIME, LEAVE THE IMPLEMENTATION TO THE MIB, LET THE

MIB ADDRESS THE CONFIGURATION AND MONITORING ISSUES FOR

THE IMPLEMENTATIONS.

Thank you for your attention.

PLEASE LET THE CO-AUTHORS KNOW WHAT DO YOU WANT TO IMPLEMENT!

THESE DOCUMENTS ARE CREATED FOR THE PUBLIC TO CREATE A BETTER

INTERNET.  IF THAT IS NOT TRUE, SPEAK UP!

-- Kwok Ho Chan --

>of
http://www.ietf.org/internet-drafts/draft-ietf-diffserv-mib-07.txt.
This

>Archive:
http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

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

> Shaper, maybe people will be happier?) in DiffServ MIB-07 is
[snip]

> Section A.4 on usage of [SRTCM] and [TRTCM] for shaping profile.

I think you are mis-reading the text in A.4.  It reads:

  The strict token bucket conformance behavior defined in [SRTCM] and    
  [TRTCM] is not mandatory for compliance with any current Diffserv
  standards, but we give here a mathematical definition of two-parameter
  token bucket operation which is consistent with those documents and
  which can also be used to define a shaping profile.

  ...

Notice that the text is careful not to claim that it is defining the
behavior of [SRTCM] or [TRTCM] (which are defined in the respective
documents).  The subsequent text defines *a* single-rate, two-color
token bucket (the two-parameter simple token bucket in [MODEL], not
necessarily the only possible one.

I don't understand how the concept of "color" would relate to a shaper;
a shaped packet should be released only if it would be "green"; i.e.,
simultaneously satisfies all constraints.   Therefore I don't see
how SRTCM or TRTCM are suitable as models for shaping behavior.

I would suggest that you add the two-stage, three-parameter token bucket
meter [MODEL, sec. 5.1.4] to the MIB, and restrict the shaper to taking
its parameters only from a diffServTBParamSimpleTokenBucket and this
new meter (e.g., call it diffServTBParamSimpleTokenBucket2).

Also, the section references to [MODEL] on pg. 51 and 52 are incorrect;
there is no longer a section 5.2 in [MODEL]. 

Regards,

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

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Tue, 13 Feb 2001 15:59:35 -0500

Steve:
Thank you for your reply.  Please see below for my interpretation.
-- Kwok --

>necessarily the only possible one.

I was interpreting the text in the Model-06 to mean [SRTCM] and [TRTCM]
can be used but not mandatory for defining a shaping profile.  I think the
interpretation hinges on the meaning of "and which can also".  What does
"which" refering to?  [SRTCM] and [TRTCM]?  Or just "two-parameter token
bucket operation"?

Since [SRTCM] and [TRTCM] are used for Metering functionality.
And
>schedulers for shaping purpose. Notice the sentence "a packet is delayed 

Would you have considering using the [SRTCM] and/or [TRTCM] parameters
to setup your shaping functionality so the Metering functionality of the next
router/device will be satisfied?  With the "Yellow" color possibly meaning
send only if excess resource is available.  Notice these additions started
with hierarchical schedulers for excess BW issue raised in the meeting.

I minimumly want to preserved the ability for hierarchical schedulers for
excess BW be augmented to the MIB in later time when that is better
understood.  May be I went too far with it.  In that case I would agree on
removing the reference to [SRTCM] and [TRTCM] for shaping functionality.

And someone will have to answer how does one CONFIGURE the shaping
functionality using the DiffServ MIB that feeds into a device using
[SRTCM] and [TRTCM] to Meter the same flow.
I think we should concentrate on HOW TO CONFIGURE for the MIB.
 
>how SRTCM or TRTCM are suitable as models for shaping behavior.

Please see the tail end of above reply.

>new meter (e.g., call it diffServTBParamSimpleTokenBucket2).

Hence you want to change the way the Meter is built?  Not using the
cascaded multiple TBParam entries?  But each Meter can have only
one TBParamXX, and creating new (possibly more complex) TBParamXX
when needed?

>there is no longer a section 5.2 in [MODEL]. 

Thanks!

>Regards,
http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h
tml

---

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

Kwok, I think that not calling it a shaper is *important* for
the reasons that Tina gave - it is just a variant of scheduler.

Another question is how many schedulers we include now before
we stop and leave it for future extensions. As you say, the MIB
doesn't have to implement everything that is allowed by the model.
So, assuming the thing currently called a shaper is renamed as a
foobar scheduler, do we include it, or skip it for now?

  Brian

Kwok-Ho Chan wrote:
> Section 7 first paragraph and Section 7.1.1 first paragraph on usage
> shaping function with other buffering, discarding and sheduling associated
> level of scheduler. But may need both success and failure hierarchies.
> functionality.  Since the Scheduler in the MIB is single-action
> hierarchical scheduler.  The multi-action (mixed-action) scheduler
> There are different ways to do this, what is in MIB-07 is just one way.
> I have considered adding a Shaping Table, but didn't do that because
> _______________________________________________ diffserv mailing list [email-masked]
> http://www1.ietf.org/mailman/listinfo/diffserv Archive: