Subject: [Diffserv] Shaping in Diffserv MIB-09

From: Andrew Smith <[email-masked]>
Date: Fri, 02 Mar 2001 18:05:55 -0800

Fred Baker wrote:

> At 04:37 PM 3/2/2001 -0800, Andrew Smith wrote:
> 
>> The "ShapingLevel" description is better although it's still not clear 
>> to me whether or how the MIB can represent what you describe as "under 
>> a defined circumstance":
> 
> 
> It can't. I could imagine an object that says what kind of shaper you're 
> implementing - such as an RFC 2963 shaper. That would be a scheduler 
> object, I suppose.

In another message you say that the MIB does try to represent this, at least for 
a RFC 2963 shaper.

> But this is why I say a TCB cannot implement a shaper. There is no 
> "meter" definition that says "is the instantaneous queue depth deeper 
> than this threshold?" (the threshold is defined in the Shaper 
> Parameters), and there is no action that says "then goose the scheduler 
> to remove a packet from this particular queue if this rate applies." The 
> MIB doesn't have the right semantics to do that, and even if it did, I 
> don't think one writes a router using a MIB.

It sounds, again, like you are arguing that the Model draft cannot adequately 
represent this RFC 2963 shaper, and yet you are quite happy to have the MIB 
attempt to do so. I know you do not care that much for the Model document but 
the WG has said, again and again, that it wants that document to represent, in 
an abstract way, the things that the MIB is based on.

I cannot see any record of the WG having decided to add the RFC 2963 shaper 
support to the MIB - but if it did, and I guess it could have been a verbal 
agreement that was not captured in writing anywhere, then I would have expected 
the WG chairs to have insisted that the Model be updated consistently. Right now 
things are, apparently, inconsistent - please supply text to update the Model 
draft or else we should remove the RFC 2963 stuff from the MIB.

Andrew

_______________________________________________
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: Sun, 04 Mar 2001 00:17:40 -0800

At 06:05 PM 3/2/2001 -0800, Andrew Smith wrote:
>It sounds, again, like you are arguing that the Model draft cannot 
>adequately represent this RFC 2963 shaper, and yet you are quite happy to 
>have the MIB attempt to do so. I know you do not care that much for the 
>Model document but the WG has said, again and again, that it wants that 
>document to represent, in an abstract way, the things that the MIB is based on.
>
>I cannot see any record of the WG having decided to add the RFC 2963 
>shaper support to the MIB - but if it did, and I guess it could have been 
>a verbal agreement that was not captured in writing anywhere, then I would 
>have expected the WG chairs to have insisted that the Model be updated 
>consistently.

I understood that there was interest in a multi-rate shaper. I looked at a 
definition for a multi-rate shaper, and put the parameters that definition 
required into the MIB. If you would rather not model a multi-rate shaper, I 
will remove the table from the MIB. You and Steve duke that one out, and 
the chairs can tell me I'm all wet.

As I have said before, the MIB does not directly model a shaper, as we do 
not have a meter that checks the instantaneous queue depth, we do not have 
an action that removes a packet from a queue, and so on. A shaper could 
probably be implemented with a TCB, but the MIB does not directly model 
TCBs, it models classifiers, meters, actions, queues, and schedulers, which 
one can build TCBs out of.

Aren't we a little late for this debate? The MIB has *never* had the 
necessary components to let you build a shaper. A shaper has always been 
something you parameterized, not something you built.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 05 Mar 2001 05:15:51 -0600

> something you parameterized, not something you built.

That was how I understood it. The strong requirement I have is that the MIB
is *consistent* with the model; that doesn't oblige them to be congruent,
so I am not bothered by things being present in one and not the other,
as long as they don't actively contradict each other.

  Brian