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

From: Steve Blake <[email-masked]>
Date: Tue, 13 Feb 2001 16:22:38 -0500

Kwok-Ho Chan wrote:

> At 02:23 PM 2/13/01 -0500, Steve Blake wrote:
> >Kwok-Ho Chan wrote:
> >
> >
> >> 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
> >> ------------------------------
> >[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 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"?

The latter.  Probably this sentence should be rewritten, perhaps as:

  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.  This
  two-parameter token bucket can also be used to define a shaping profile.

> Since [SRTCM] and [TRTCM] are used for Metering functionality.
> And
> >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.
> 
> 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 think I missed this meeting.  The shaper I described previously would
automatically satisfy a SRTCM/TRTCM meter directly downstream; every
packet would be green.

I now see what you are trying to do.  I think to avoid confusion there
should be some more indication about when the link scheduler is work-
conserving vs. non-work-conserving. 

> 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.
>  
> >
> >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.
> 
> Please see the tail end of above reply.
> 
> >
> >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).
> 
> 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?

No, I see that you could probably build the 3-parameter shaper using
two simple token buckets with the correct configuration of SucceedNext.

Regards,

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

_______________________________________________
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: Tue, 13 Feb 2001 16:17:14 -0600

I have a nasty feeling that we have started designing a router here,
rather than a generic (lowest common denominator) MIB.

  Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Program Director, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org
Non-IBM email: [email-masked]

---

From: "Kwok-Ho Chan" <[email-masked]>
Date: Tue, 13 Feb 2001 19:23:27 -0500

Steve:
Please see partial reply below.
-- Kwok --

>two simple token buckets with the correct configuration of SucceedNext.

Good, I Agree, so that means no change to the structures of how the parameters
can be organized.  Do you think diffServTBParamEntry is adequate for this?
Hoping for a yes answer. :)

---

From: Fred Baker <[email-masked]>
Date: Tue, 13 Feb 2001 16:54:58 -0800

>can be organized.  Do you think diffServTBParamEntry is adequate for this?

what makes a leaky bucket into a token bucket? It seems that you want the 
shaper configured with a burst size...

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 14 Feb 2001 09:03:48 +0200 (EET)

> rather than a generic (lowest common denominator) MIB.

i have had this same feeling since this mib work started.  most vendors
have their own variants of various diffserv mechanisms and a generic mib
can't be used to configure them.  the worst thing, however, is the
opposite, i.e., that some vendors think that the mib defines how a
diffserv box should be implemented.

in summary, i don't see what purpose the mib serves and i would suggest
to drop the effort. if that is not acceptable, then the mib should be
much more abstract and contain pointers to other (in many cases vendor
specific) mibs that define the actual details of the various diffserv
mechanims.

-- juha

---

From: Fred Baker <[email-masked]>
Date: Tue, 13 Feb 2001 23:55:06 -0800

At 09:03 AM 2/14/2001 +0200, Juha Heinanen wrote:
>to drop the effort.

I can go either way. If there is going to be a public MIB, I want it to be 
one that makes some sense, and that's the only reason I'm involved in this 
effort. But if there is a consensus to not have one, I'm also game. That's 
up to the chairs and their ADs.

I will note that there is a standing rule that any technology we develop 
has to be manageable...

>if that is not acceptable, then the mib should be

um, you haven't noticed the RowPointers? It can point to about anything.

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 14 Feb 2001 10:37:58 +0200 (EET)

> um, you haven't noticed the RowPointers? It can point to about anything.

i was refering to the discussion regarding the meters, markers,
policers, etc. where the mib already seems to have made up its mind by
suggesting how the mechanisms look like.  those kind of things should be
defined in conjunction with separate rfcs that describe a given meter,
marker, policer, shaper, red algorithm, etc. otherwise there is a big
danger that the mib defines one particular implementation of a diffserv
box.

-- juha

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Feb 2001 07:15:37 -0600

Well, we are chartered to produce a MIB, so a MIB will be sent to the
IESG. But Juha's comment reassures me that I am on the right track:
when in doubt, cut it out. I don't detect any support on the list
for including the shaper/scheduler. Vendors can always add bells
and whistles, just as they can ignore unwanted features that the
MIB happens to support.

  Brian

---

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

IMHO,
The diffServTBParamEntry is used only to hold the parameters,
for either Token Bucket or Leaky Bucket.  It does not dictate
how the parameters get used, either as Token Bucket or Leaky Bucket.
So it is possible to build the 3-parameter shaper (Committed Rate,
Peak Rate, Burst Size) using 2 simple token/leaky buckets (2
diffServTBParamEntry).

I am concentrating on what MIB Tables+Entry definitions are needed to
configure the DiffServ device.
If the name "diffServTBParamEntry" is the issue, lets change it and get
it done.
If the description of using the words Token Bucket or Leaky Bucket is
the issue, lets change it and get it done.
I think the MIB Table and Entry setup and definitions for diffServTBParam
are good enough as is.

This vote is for NO change to what is in MIB-07 and MIB-08(dated 02/12/2001).
-- Kwok --

---

From: Steve Blake <[email-masked]>
Date: Wed, 14 Feb 2001 17:23:00 -0500

> Peak Rate, Burst Size) using 2 simple token/leaky buckets (2

It is not entirely clear to me how you would do this, without cascading
a queue/scheduler on the succeed-next or fail-next branch.  If I am
correct, that is way too complicated to represent a 3-parameter shaper.

On the other hand, DiffServSchdParamEntry.diffServSchdParamMaxRateAbs
can specify the peak rate, so the existing text is fine with me with
the understanding that the token bucket parameters (diffServTBParamEntry)
govern the CIR/burst size for this shaper (e.g., the shaper output
satisfies the service curve

      s(t) <= MIN [ diffServSchdParamMaxRateAbs * t,
                    diffServTBParamBurstSize + diffServTBParamRate * t ]  

So if my understanding is correct then I am satisfied with the scheduler
text.

> This vote is for NO change to what is in MIB-07 and MIB-08(dated 02/12/2001).

Four suggestions:

1.  Lose diffServClfrElementPkts/diffServClfrElementHCPkts (pp., 36, 38, 39).
    Rationale: Anyone who wants to implement these counters can represent
    them in the MIB using count actions.

2.  Change diffServClfrDstAddrMask and diffServClfrSrcAddrMask to
    InetAddress (pp., 40, 41, 42).
    Rationale: Unsigned32 is obviously not large enough for IPv6
    addresses.

3.  Fix the description for diffServSchdParamMinRateRel and
    diffServSchdParamMaxRateRel (pp. 80, 81) that spills over 72
    columns.

4.  Add diffServSixTupleClrfDscpMask (Dscp); pg., 40.  You can probably
    lose DscpOrAny and change diffServSixTupleClfrDscp to Dscp if you
    implement this (use a null mask for wildcard).
    Rationale: until Diffserv is fully deployed we may still have to 
    occassionaly classify IP Precedence bits at the network edge.

Regards,

---

From: Fred Baker <[email-masked]>
Date: Wed, 14 Feb 2001 15:24:46 -0800

At 05:23 PM 2/14/2001 -0500, Steve Blake wrote:
>a queue/scheduler on the succeed-next or fail-next branch.

in a scheduler, exactly what would trigger us following a succeed-next or 
fail-next branch? As in, what would fail? In RFC 2963, the thing that would 
"fail" is that a queue feeding into the scheduler fails to be on one side 
or the other of a depth threshold. The thing does an arithmetic calculation 
to decide when it should send, and the only "if" is to select which rate to 
send at. If you want to implement the shaper using MIB objects, we're going 
to need a lot more than that.

I think we define the shaper and give it an algorithm, much like we say 
that a scheduler is using a priority or a rate-based algorithm.

---

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

Steve:
Thank you very much for your feedback.
Please see response embedded.

BELOW ALSO CONTAIN SOME DECISIONS THE WG NEED TO
MAKE.  PLEASE SEE THE UPPER-CASE TYPING.
WE NEED FEED BACK FROM CONCERNED INDIVIDUALS.

-- Kwok --

>So if my understanding is correct then I am satisfied with the scheduler

The current diffServSchdParamEntry does NOT have BurstSize.
diffServSchedulerSpecific is used to reference either diffServSchdParamEntry
OR diffServTBParamEntry, but NOT BOTH at the same time.

Options:
1. Add BurstSize to diffServSchdParamEntry for Shaping.
2. Don't use BurstSize for Shaping.
In both options 1 and 2 diffServSchdParamEntry can be used,
using diffServSchdParamMaxRate as PeakRate
and diffServSchdParamMinRate as CommittedRate.
3. Continue to use the cascading scheduler for multi-rate shaping.
    Acceptable complexity?

CHOOSING OPTION 1 OR 2 MAY RESULT IN REMOVING
diffServSchedulerFailNext and changing diffServSchedulerSucceedNext
to diffServSchedulerNext.
THIS REVERSE THE DICISION MADE IN SAN DIEGO WG MEETING,
PLEASE REFER TO THE MINUTE OF THE MEETING FOR DETAILS.

SHOULD diffServSchedulerFailNext BE REMOVED??  ANYONE WANTS
TO KEEP THIS PLEASE SPEAK UP.  For one I would like to keep it for
excess bandwidth scheduling, but can not say how that will be use in
public, anyone else in the same boat?

CHOOSING OPTION 3 WILL LEAVE THE COMPLEXITY AND ALLOW
EXCESS BANDWIDTH SCHEDULER BE ADDED WITHOUT CHANGE TO
THE MIB.

>    occassionaly classify IP Precedence bits at the network edge.

I think this has been discussed earlier and dicision was made to not use
DscpMask.

---

From: Steve Blake <[email-masked]>
Date: Wed, 14 Feb 2001 18:40:59 -0500

> that a scheduler is using a priority or a rate-based algorithm.

Kwok earlier mentioned being able to use multiple diffServTBParamEntry's to parameterize the shaper algorithm (ex/ for a 3-parameter token bucket).
I don't understand how you would do this without two cascaded schedulers.

Regards,

---

From: Fred Baker <[email-masked]>
Date: Wed, 14 Feb 2001 16:05:20 -0800

At 06:40 PM 2/14/2001 -0500, Steve Blake wrote:
>Kwok earlier mentioned being able to use multiple diffServTBParamEntry's 
>to parameterize the shaper algorithm (ex/ for a 3-parameter token bucket).

but all you need is two rates!

And I'm serious - if you want to follow a "failNext", what fails? What 
test, specifically, do you use to decide to follow that?

---

From: Fred Baker <[email-masked]>
Date: Wed, 14 Feb 2001 17:26:48 -0800

>3. Continue to use the cascading scheduler for multi-rate shaping.

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?