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

From: "Weiss, Walter" <[email-masked]>
Date: Tue, 13 Feb 2001 10:46:56 -0500

> 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.
>
Agreed.
 
> 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.
> 
I would suggest more generic terms. The behavioral semantics if WFQ are not
interpreted consistently across implementations anyway. My take would be
WorkConservingBandwidthScheduler (it is a bit long so abbreviation is
appropriate) and NonWorkConservingBandwidthScheduler. WorkConserving implies
a proportion while NonWorkConserving implies a specific bandwidth
allocation.

Having a Boolean is inappropriate since it is not relevant to Priority or
WRR schedulers.

> 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)?

I would agree that the first question leaks into the second. When we settle
the first, we can word smith the second.

regards,

-Walter

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Thu, 15 Feb 2001 01:14:07 +0100

Inline

> ----------
> From: 	Robert Moore[SMTP:[email-masked]]
> Sent: 	Wednesday, February 14, 2001 10:05 PM
> To: 	Brian E Carpenter
> Cc: 	Dan Grossman; Weiss, Walter; diffserv
> Subject: 	Re: [Diffserv] MIB-07 comments on Shapers
> 
> Brian,
> 
> >"managing" diffserv nodes doesn't (in the case of this MIB) mean
> *configuring*
> >them - that is either the PIB or SNMPCONF. So the mandate is a MIB that
> >provides meaningful generic info about what a node is doing
> diffserv-wise.
> 
> This wasn't my understanding.  The SNMPCONF DiffServ Policy MIB
> got very small in its most recent incarnation precisely because
> most of the work of making DiffServ configurable via SNMP was
> taken care of in the DiffServ MIB itself.  That's why almost all
> of the accessible objects in the DiffServ MIB have MAX-ACCESS
> read-create, and why almost all of the tables have RowStatus
> objects.
> 
Right, and I am very happy with that.
Pls keep that configurability!!!!!

> If the DiffServ MIB really is only for monitoring and for
> reporting on how DiffServ functions are currently configured,
> then it's got a lot of unnecessary stuff in it.  I don't
> think its role is this narrow, though, so I don't think the
> elements I mentioned are unnecessary.
> 
> Regards,
> Bob
> 
Bert

_______________________________________________
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: Steve Blake <[email-masked]>
Date: Wed, 14 Feb 2001 19:34:33 -0500

oops I meant RFC 2212.

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

---

From: "Iliff, Tina" <[email-masked]>
Date: Thu, 15 Feb 2001 20:24:12 +0000

Walter,
 
It sounds as though you are suggesting that Schedulers are policers.  They
are not.  Meters police and ,using two pointers, can allow packets to
continue being processed or to be dropped.  Schedulers are only concerned
with when a packet leaves.  This has been the reason why I have disagreed
with the FailNext and SucceedNext attributes in the Scheduler table.  It
does not make sense for a Scheduler to distinguish between failing and
succeeding packets.  Once packets hit the scheduler then they will all pass
whether it be outbound into the network or into another scheduler to be
combined with other traffic, etc.

Tina Iliff 

-----Original Message-----
From: Weiss, Walter [mailto:[email-masked]]
Sent: Thursday, February 15, 2001 1:40 PM
To: 'John Schnizlein'; diffserv
Subject: RE: [Diffserv] MIB-07 comments on Shapers

> At 11:27 AM 02/15/2001 -0500, Weiss, Walter wrote: 
> >... The scenario we have all grown comfortable with is one where 
> >a bandwidth scheduler allows a conforming packet through but a 
> >subsequent priority scheduler rejects the packet. 
> >In this scenario, the first scheduler succeeded, but the second 
> >schduler failed. 
> 
> We are not all comfortable with this concept of the scheduler. 
> Cascading schedulers without queues between, in contrast to schedulers 
> that might implement hierarchical scheduling directly, does not make 
> sense to me. 
> 
If you are not comfortable with this concept, you need to be more vocal.
This has been expressed for the past year in numerous instantiations of both
the informal model and the MIB. I certainly did not suggest, nor do I
endorse, the placement of queues in between schedulers. My previous text was
ment to suggest that while one scheduling dicipline may permit the
departure(transmission) of a packet, a subsequent scheduling function bound
to the same queue may deny the departure due to some criteria not considered
by the first scheduler.

> I agree with Fred that there is confusion between policing 
> and scheduling 
> lurking in these discussions. Only MIB variables that do not depend on 
> complex models of the mechanisms underlying diffserv operations should 
> be included. 
> 
From this statement I can't really tell what you are agreeing with Fred on. 

> "Subsequent priority scheduler rejects the packet" makes no sense. 
> 
Here is Fred's diagram from Feb. 2. What does not make sense? 

        --->classifier -+->||-> S 
                        |       c 
                        +->||-> h 
                        |       e 
                        +->||-> d 
                        |       u 
                        +->||-> l 
                        |       e------------> P 
                        +->||-> r              r 
                        |                      i 
                        +---------------->||-> o 
                        |                      r--> output 
                        +---------------->||-> i 
                        |                      t 
                        +---------------->||-> y 

regards, 

-Walter

---

From: "Weiss, Walter" <[email-masked]>
Date: Thu, 15 Feb 2001 16:12:25 -0500

John,

> As I understand Fred's point, there is no rejection of a packet 
> in a scheduler, although there would be in a policer (meter-dropper). 
> Schedulers choose from queues. 
> Policers delete from (prevent insertion into) queues.
> 
Then my words were poorly chosen. By rejection, I did not mean to imply that
the packet was dropped. Rather, the packet, or rather the queue containing
the packet, was not chosen for servicing. Sorry for my lack of clarity.

> This does not imply cascading schedulers, in general.
> Wasn't Fred's response that cascading schedulers are too complex 
> to deserve inclusion in the standard MIB?
> 
Fred's note from yesterday seems to imply something different (that I agree
with):

'What we want to achieve, I think, is a combination of things.
...
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." '

As an aside (and not directed at you), I am not particularly happy with the
complexity of the MIB. However, DiffServ IS rocket science. We have been
debating the issues and concepts associated with droppers, meters, markers
and schedulers for years. Given that the concepts are non-trivial, it is not
surprising that the infrastructure necessary to manage these concepts is
complicated as well. This is not a question of making it simple. We are also
dealing with issues of scaling, extensibility, and usability (as in "is
there enough here for a majority of implementations to use?"). If we make
the MIB simple, the majority of the interesting management attributes
necessary to define and manage services will be in proprietary MIBs. I am
personally opposed to this.

regards,

-Walter

---

From: "Iliff, Tina" <[email-masked]>
Date: Thu, 15 Feb 2001 21:56:02 +0000

Tina Iliff 

-----Original Message-----
From: Weiss, Walter [mailto:[email-masked]]
Sent: Thursday, February 15, 2001 3:12 PM
To: 'John Schnizlein'; diffserv
Subject: RE: [Diffserv] MIB-07 comments on Shapers

John, 

Each queue will be serviced eventually, now the scheduler will decide in
which order the queues will be serviced based on either priority or min/max
rates. 

I agree with this. 

Agreed. 

regards, 

-Walter

---

From: "Weiss, Walter" <[email-masked]>
Date: Fri, 16 Feb 2001 15:12:06 -0500

Tina, 

>> Then my words were poorly chosen. By rejection, I did not mean to imply
>> that the packet was dropped. Rather, the packet, or rather the queue
>> containing the packet, was not chosen for servicing. Sorry for my
>> lack of clarity. 
>
> which order the queues will be serviced based on either priority or
min/max rates. 

When I am talking about a queue being chosen for servicing, this within the
context of determining which queue to service next. The statement should not
be interpreted to mean that the queue will never be serviced although this
can occur with some scheduling disciplines.

regards,

-Walter

---

From: "Weiss, Walter" <[email-masked]>
Date: Fri, 16 Feb 2001 16:14:07 -0500

Tina,

I would agree that I am blurring the line between meters and schedulers.
However, that is because they can behave very similarly depending on the
scheduling discipline. Consider a scheduler that bounds the amount of
traffic from a given queue to an egress port. Such a function is described
in both AF and EF. The distinction between a scheduler that provides this
function and a meter that provides this function is that a meter is passive
while a scheduler is active. A meter matches each packet against a profile
and prescribes the appropriate behavior to the packet as a function of the
subsequent action clause.

In contrast, a scheduler may use the same profile to hold the packet in the
queue until such time as the packet falls within the profile. Given these
similarities, it is not unreasonable to argue for a scheduler of this form
(re)use the same profile parameters defined for a meter. It is also possible
to define a model that places a meter inside a queuing block as a subelement
of the scheduler. However, this is not the way the model (or the MIB) works
right now.

The main point of the discussion is what breadth of scheduling disciplines
we should represent in this MIB. This is a value, timeliness, complexity
tradeoff. The point of my previous mail was to demonstrate that there are
two examples of scheduling disciplines that are not supported by the MIB if
we don't have some type of FailNext semantic. Both these examples fall in
the category of Bandwidth Borrowing schedulers. Off hand, I can't think of a
reason for a FailNext semantic other than for Bandwidth Borrowing, but given
the functional similarity of bandwidth schedulers to meters, and the
repetitive demand for meter chaining (for both success and failure), it is
intuitively obvious to me (in conjunction with the examples I provided) to
support this same capability for schedulers.

regards,

-Walter

-----Original Message-----
From: Iliff, Tina [mailto:[email-masked]]
Sent: Thursday, February 15, 2001 3:24 PM
To: 'Weiss, Walter'; 'John Schnizlein'; diffserv
Subject: RE: [Diffserv] MIB-07 comments on Shapers

Walter,

Tina Iliff

---

From: "Weiss, Walter" <[email-masked]>
Date: Fri, 16 Feb 2001 16:39:40 -0500

John,

If there is a simpler way of representing cascading schedulers, I for one
don't have a problem with it. I have not seen an alternative from Fred for
cascading schedulers though.

regards,

-Walter 

> From: John Schnizlein [mailto:[email-masked]]
> Sent: Friday, February 16, 2001 8:01 AM
> To: Kwok-Ho Chan
> Cc: Weiss, Walter; 'Fred Baker'; diffserv
> The question is putting DiffServSchedulerFailNext into the MIB.
> My arguments have been against this change.
> Until proven necessary, an arbitrarily long chain of cascading
> schedulers, with the complexity of some signalling between them,
> should not be included in the MIB.
> 
> Answers to your specific questions follow:
> 
> At 04:21 PM 02/15/2001 -0500, Kwok-Ho Chan wrote:
> >
> >Who do you mean by "we"??
> 
> I was disputing the claim that "we have all grown comfortable".
> Just a single person's discomfort falsifies the universal claim.
> Tina Iliff and Fred Baker have also indicated some lack of comfort
> with the notion of "failing" in a scheduler. Without an explicit
> evaluation of the potential existence of consensus, it should not
> be claimed, and should not add speculative implications for the
> implementation of cascading schedulers to the MIB.
> 
> >Please elaborate on:
> >"Cascading schedulers without queues between, in contrast to 
> >schedulers that might implement hierarchical scheduling directly, 
> >does not make sense to me."
> >
> >I would like to understand your concerns and would like to address 
> >it if possible.
> 
> The way to address this concern is to not incorporate the implication 
> of cascading schedulers in the MIB. There are different ways 
> to do this.
> Fred described one that seems much simpler.
> 
> >For some history, much of the scheduling ideas in the MIB came from 
> >the PIB, which Keith is a major co-author of.  Some form of weighted 
> >scheduling feeding into a priority scheduling was in the PIB and MIB 
> >for awhile now.  We have people wanting to do InterOp 
> BakeOffs of the 
> >PIB, with the MIB and PIB so much alike now, we may want to do them 
> >together, after we finish these drafts first. :)
> 
> Thank you for that history lesson. Having discussed the PIB with Keith
> myself occasionally ;-) I see no error in it. The trend 
> toward including
> the complexity of the PIB concepts into the MIB is not a good one. The
> original idea of a MIB reflecting the blocks in the diffserv 
> architecure
> was better. My preference would have been that the model move 
> toward the
> MIB rather than the other way during the process of convergence.
> 
> I agree with completing the MIB ASAP. I am skeptical of the value of
> tying this to the PIB and the whole policy conceptual superstructure.
> Remember that the original point of diffserv has been to compose a
> small set of simple functional blocks with static (at first) 
> configuration.
> 
> >I can understand that people may not agree with the Shaping 
> functionality,
> >but the Scheduling functionality should be pretty solid, if not, the 
> >issues should have been raised a long time ago.
> 
> It remains unclear to me how Shaping can be separated from Scheduling.
> Whenever representations of these functions have attempted that, they
> have raised questions. Fred's e-mail this week summarized the 
> way these
> are essentially different aspects of the process of choosing 
> which packet
> goes when.
> 
> >At 12:53 PM 2/15/01 -0500, John Schnizlein wrote:
> Archive: 
http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h
tml