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

From: Andrew Smith <[email-masked]>
Date: Thu, 8 Jun 2000 13:57:34 -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

> -----Original Message-----
> 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.
> 
> Einstein had it right:  "complex as it needs to be, and no more".
> 
> I do hope you straightened them out.
>  
> > 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
> 
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Jun 2000 17:04:49 -0500

Andrew,

You do have to consider that the EF deployment that Phil and Tiziana
referred to is one in which the routers don't really have full-blown,
designed-as-such EF support - i.e. they had to do the experiments
to find out which particular combination of the vendor's mechanisms
actually deliver EF behaviour. We've had to so the same here at iCAIR.org
(and in fact we are indirectly connected to Tiziana's experiment).

Hopefully this is not the long term situation, with any vendor.

Enough for this list, I think.

  Brian