Subject: Re: [Diffserv] Droppers with classifiers? (Model and MIB)

From: "Nabil Seddigh" <[email-masked]>
Date: Tue, 6 Jun 2000 19:36:33 -0400 (EDT)

Dan Grossman writes:

>> 
>I guess the only question I have is how ugly 
>it would be to to configure nearly duplicative classifiers.  
>I suppose that it works in the modelling 
>domain, but I can't imagine actually implementing such a thing.  

More on Andrew's email later but....
I'm not sure the implementation or configuration of the additional 
classifier will necessarily be ugly. IMHO the "2nd stage" classifier 
can be as feature-rich as the implementation requires. In the case I'm 
interested in it would be a very simple classifier focused
on mapping the DSCP to a set of RED parameters. 
Other implementations may choose to support more fields
in the "2nd-stage" classifier.

Best,
---
Nabil Seddigh
[email-masked]

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 8 Jun 2000 17:38:01 -0400

> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]]
>
> At 11:50 AM 6/7/00 -0400, Dan Grossman wrote:
> >There is no QoS pixie dust that you can sprinkle on and make 
> QoS happen
> >without complexity...
> >Einstein had it right:  "complex as it needs to be, and no more".
> >
> >I do hope you straightened them out.
> 
> The gentleman is very familiar with ATM, and generally 
> comfortable with its 
> complexity. I listed on the board what it meant for ATM to 
> place a CBR call:
> 
>   - DTE places a call requesting a certain rate etc, which 
> the network routes
>     and guarantees.
>   - DTE generates traffic at less than or equal to that rate.
>   - DCE polices to that rate, dropping excess.
>   - All switches queue traffic so that it gets minimum jitter 
> while rate is
>     observed
>   - Traffic is delivered end to end with high reliability, 
> specified rate,
>     and low jitter.
> 
> I then wrote down what is required to place an EF data flow:
> 
>   - Edge device may reserve a certain rate for a traffic 
> stream, which the
>     network routes and guarantees. (if no explicit 
> reservation in the sense
>     of Aggregate RSVP, then overprovisioning and traffic 
> engineering is used
>     to accomplish same)
>   - Edge device generates traffic at less than or equal to that rate.
>   - Edge router/switch polices to that rate, dropping excess.
>   - All routers/switches queue traffic so that it gets 
> minimum jitter while
>     rate is observed
>   - Traffic is delivered end to end with high reliability, 
> specified rate,
>     and low jitter.

This is clever. But it's the first time I see an IP solution having to prove
itself no _more_ complex than the ATM counterpart.

One thing, though. To achieve your example of minimum jitter, without
counting on plenty of excess capacity, how does diffserv propose to do this
without finally pinning routes? As you alluded to above, with "aggregate
RSVP"?

Or have I missed that diffserv is moving to such a solution?

Bert
[email-masked]

---

From: "Nabil Seddigh" <[email-masked]>
Date: Thu, 8 Jun 2000 20:46:16 -0400 (EDT)

>
>****************************************
>The proposal would be that you simply model this scenario,
> if necessary, by prefacing an Algorithmic Dropper element 
>with a (set of) Classifier element(s) which branch out to the 
>multiple Algorithmic Droppers which have
>the separate parameter sets. These additional Classifier 
>elements would have to be distinct from any used 
>previously in the path - we already have a "level" mechanism 
>to support this in the MIB - although they could share any
>existing classifier filter elements (e.g. the 6-tuple element). The
>interesting observation is that this requires absolutely 
>no changes to the current Model - it is just another form of 
>the "concatenated TCB" scenario that we already support - 

Andrew: just to clarify. The above proposal requires no 
changes to the model but it will require a slight change 
to the current MIB. Right? ..... or did I miss something?

Regards
---
Nabil Seddigh

---

From: Andrew Smith <[email-masked]>
Date: Fri, 9 Jun 2000 07:59:12 -0700

It's also a case of "you can't have your cake and eat it" - the PHB
"specifications" are deceptively simple. The reason we have a Model and a
MIB that are so complex is because they are fighting to represent the
complete generality (or at least the 95th percentile) of the multitude of
implementation possibilities that can fit under the Precedence, AF and EF
definitions. You can argue that this is a wonderful thing or that it is a
nightmare (I think it's a bit of both myself).

One of the papers at IWQoS here in Pittsburgh this week (Phil Chimento and
Tiziana Ferrari) was talking about some operational experience with an
implementation of EF. Some of their conclusions were interesting - primarily
one that implied (maybe I was reading too much into the paper - apologies to
them if I am) that you needed to have control of both the choice of
scheduling algorithm (priority vs. WRR) and the parameters of the chosen
algorithm, in order to achieve an end-to-end behaviour to suit the
applications being used. To me, this implies (this conclusion *entirely* due
to my reading between the lines of the paper) that the concept of "EF" is
either over-generalised or else under-specified in the RFC. Further, that
this Conceptual Model (and instantiations of it, like the MIB) becomes
doubly important as an annex to the PHB definitions: not just an
informational piece, playing around with model building blocks, but an
integral part of what an implementor has to provide to their users along
with the product implementation in order to deploy an end-to-end service.
Otherwise interoperability will be a sham.

Andrew

> From:	Dan Grossman [SMTP:[email-masked]]
> Sent:	Wednesday, June 07, 2000 8:50 AM
> To:	Fred Baker
> Cc:	[email-masked]
> Subject:	Re: [Diffserv] Droppers with classifiers? (Model and MIB) 
> 
> 
> > Would you believe - I was speaking with the Chinese IP Standardization
> > Bureau yesterday, and they were concerned that diff-serv is too
> complicated
> > now. They wanted to know if they could simplify things by reducing
> services
> > to two or three service classes (perhaps EF and 2 AF, something like
> that)
> > and make the thing snap configurable.
> > 
> This is ever so slightly off topic, but it is unfortunate that people
> don't 
> understand that multiservice networks with QoS guarantees **are** complex.
> 
> There is no QoS pixie dust that you can sprinkle on and make QoS happen 
> without complexity, a need to configure the complexity to do something
> useful 
> and technical folk who understand the complexity well enough to configure
> it.  
> Some people still think that Diffserv is that magic pixie dust, just set a
> 
> DSCP and your problems go away.  Of course, these are the same folks who
> think 
> that a PHB is an end-to-end service.
> 
> > As I look at these discussions on the MIB, I don't see an ethic of
> "start
> > with something simple and working, and add as needed", which line of
> > reasoning has gone into every IETF MIB to date, but rather "how can I
> make
> > it all singing and all dancing from the get-go." 
> This is a philosophical debate, but there is something to be said for 
> generality.  It is a lot more difficult to add things in in a second and
> third 
> round than it is to get it right in the first place.
> 
> > The things that Andrew
> > described could be modeled simply, perhaps using cascaded TCBs, and we
> wind
> > up with a simpler MIB. If you're willing to describe something that
> wouldn't
> > in actuality be built in order to accomplish these things, and interpret
> > from that how to manage what you actually did build, then surely the
> > complexity of that intuition isn't the issue.
> I'm having trouble parsing that...  do you mean the model should or should
> 
> not reflect a reasonable implemenetation?  do you mean that there should
> or 
> should not be congruence between the model and the MIB?
> > 
> > I'd really like us to describe this as simply and generically as
> possible,
> > and add stuff in a next generation MIB when implementation experience
> tells
> > us it is necessary and desirable.
> > 
> Leading into the subjective question of what is and isn't simple and
> generic, 
> necessary and desirable.
> 
> Dan
> 
>

---

From: Andrew Smith <[email-masked]>
Date: Fri, 9 Jun 2000 11:34:09 -0700

Yes - very succinctly put as usual Joel. To answer Nabil's question, no I do
not think any new MIB syntax is needed for this but we might want to add
some explanation of it somewhere in either the MIB or the Model drafts
(either in the pre-amble or in a DESCRIPTION somewhere).

Andrew

> From:	Joel M. Halpern [SMTP:[email-masked]]
> Sent:	Thursday, June 08, 2000 2:20 PM
> To:	Fred Baker
> Cc:	[email-masked]
> I suspect that we are saying the same thing in different words.
> If you diagram the collected objects taht will be constructed to solve 
> Andreww's problem, and don't try to draw "TCB" boundaries around the 
> objects, you will end up with the output of the marker being the input to
> a 
> classifier, whose outputs go to different droppers.
> 
> As far as I can tell, using the existing constructs, one can easily 
> represent this.  You do not create two MIBs, since that would be a very 
> strange construct.  You create extra classifiers with different "levels" 
> (diffServClassifierLevel).  [Just to confirm, I searched the draft and
> this 
> is the only MIB variable which refers to TCB.
> 
> Yours,
> Joel M. Halpern
> 
> PS:  TO put it differently, the TCB is described in the document as 
> implicit in and only in the level.  I do not know what the sentence "This 
> MIB is a TCB" means.  In particular, I do not know how that sentence would
> 
> allow multiple TCBs.  I suspect I am misunderstanding your words.
> 
> At 04:51 AM 6/9/00 +0800, you wrote:
> >At 01:15 PM 6/7/00 -0400, Joel M. Halpern wrote:
> >>But, Andrew's proposal (adding Classifiers) IS cascaded TCBs. The only 
> >>sense in which TCBs exist in this MIB is in terms of the level number in
> 
> >>the Classifier.
> >
> >This MIB *is* a TCB. I'm arguing that adding an additional classifier in 
> >the action step is unnecessary complexity, as we can cascade another TCB 
> >to accomplish the same result, or (as you, Andrew, and I have discussed
> in 
> >private mail) the TCB can be structured differently to accomplish the 
> >goals he has proposed.
> 
>

---

From: "Nabil Seddigh" <[email-masked]>
Date: Sun, 11 Jun 2000 12:47:04 -0400 (EDT)

Just to clarify this discussion. Would the following 
chaining of blocks be one possible **example** that is 
allowed by the current Model?

Classifier1->Meter->Action->Classifier2->algDropEntry->Queue

If so, the MIB text talks about chaining classifiers, meters
and actions directly to Queues. It doesn't mention that
the Classifier/Meter/Action could be chained to the
dropEntry. Do we need to enhance the text for:
diffServClassifierNext & diffservActionNext to 
say that they can also point to diffServAlgDropEntry?

Nabil

---
Nabil Seddigh

---

From: Andrew Smith <[email-masked]>
Date: Mon, 12 Jun 2000 11:44:08 -0700

I'll fix up the definitions to be clear that this is allowed.

Andrew

> From:	Nabil Seddigh [SMTP:[email-masked]]
> Sent:	Sunday, June 11, 2000 9:47 AM
> To:	Andrew Smith
> Cc:	Joel M. Halpern; [email-masked]
> Subject:	RE: [Diffserv] Droppers with classifiers? (Model and MIB)
>