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

From: Andrew Smith <[email-masked]>
Date: Mon, 5 Jun 2000 15:22:41 -0700

So, let me try to summarise this long-running discussion and propose a
resolution.

1. Assume you want to send packets to an algorithmic dropper which contain
multiple "drop algorithm selection" markings.
2. Assume these packets do not flow through the model along distinct paths
from classifier elements that might have distinguished the markings apart.
3. Assume that you want the dropper to use different parameter sets on
packets of these different markings
4. Then, you really need either (a) a classifier in the dropper or (b) some
"out-of-band" connection between some external classifier elements that pick
out those markings and the dropper.
4.1 You could also model the multiple parameter sets as separate Algorithmic
Dropper elements (in series maybe?) with the out of band pointers pointing
at the appropriate one
4.2 Those out-of-band connections can be drawn as arrows in the model or
RowPointers in the MIB: there is also a choice as to which direction they
should point.
4.3 You probably also want to be allowed to have those out-of-band
connections connect onto Meter and/or Action elements, as well as Classifier
elements.

It seems like the right structural approach is 4(a). These out-of-band magic
things seem to overly complicate the model. However, it also seems ugly to
replicate classifier functionality inside another element. So, with thanks
to Joel and Fred for clarifiying this in my mind ...

****************************************
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 - the Classifier and Absolute Dropper elements would
form a subsequent TCB from the Model's point of view (and TCBs are not
really represented in the MIB at all).
*******************************************

Please comment on this proposal and also let us know if you think this
requires an extra ASCII diagram in one of the drafts to explain it and also
if you think this requires any additional textual explanation in one or both
drafts.

Andrew

> -----Original Message-----
> From:	Nabil Seddigh [SMTP:[email-masked]]
> Sent:	Sunday, June 04, 2000 10:26 PM
> To:	Fred Baker
> Cc:	[email-masked]
> Subject:	Re: [Diffserv] Proposal for Diffserv MIB - droppers
> 
> "Fred Baker" <[email-masked]> writes:
> 
> >At 12:05 AM 6/2/00 -0400, Nabil Seddigh wrote:
> >>The above makes an assumption that AF11 maps to dropParameters1,
> >>AF12 maps to dropParameters2 and AF13 maps to dropParameters3.
> >
> >you're implying that it would not? The structure of the MIB 
> >is oriented around that assumption. I tried to make that real 
> >clear both in the talk I gave in Washington and in the 
> >text in the document.
> 
> I'm actually trying to do more than imply :) I hoped I was
> being clear and direct enough.
> 
> With the aid of the current MIB, the router software
> doesn't make the hard-coded assumption that AF11 maps to Queue 0, 
> AF12 maps to Queue 0, AF21 maps to Queue 1, AF32 maps to Queue2 
> etc. Why not? Quite simply, we have deemed it beneficial
> to allow the net admin to configure which queues to
> direct streams of packets emerging from the classifier
> meter & action blocks. This is clearly valuable!
> 
> In the same way, it is useful for the same
> blocks (classifier, meter & action) to allow indication
> of which dropParameter[i] to use for making 
> the drop decision prior to enqueuing of the
> different AFij packets. Again my suggestion is to
> add a simple pointer to do this. Implmentations that 
> choose to hard-code as in your previous email,
> can be free to do so and can NULL this pointer.
> 
> >
> >>In the absence of a configurable M:N mapping, hard-coded
> >>assumptions need to be made.
> >
> >But that seems a pretty different problem than we're looking 
> >at with respect to classification. How would knowing the classifier 
> >solve this? Remember that the classifier is completely general 
> >- it's not just DSCPs, but six-tuples, IPX addresses, BGP 
> >communities, MAC Addresses on other interfaces, interface 
> >identifiers, whatever bizarre thing comes into 
> >someone's head to classify on. What has the fact that the message 
> >came from a certain neighboring router on some other interface 
> >got to do with the parameters for the queue dropper on this 
> >interface, other than that it happened to be relevant to the 
> >fact that I decided to put it into this queue?
> 
> I think your last line hits it on the head. *Somewhere* you have
> decided to put the pkt on the queue. Currently in the MIB, this
> is specified thru a linkage between the TCBs and the queuing element.
> This linkage is configurable and not hard-coded.
> Then *somewhere* you need to make a decision as to which packets
> to apply against which RED parameters. You have chosen to 
> make that decision thru a mapping that is hard-coded.
> That's fine. However, others would like the ability to make
> that mapping explicit so that changes in the mapping don't
> require new software loads. Seems pretty reasonable to me.
> 
> >I still see a pretty strong layer violation or object 
> >boundary violation in having the protocol-independent 
> >queue manager know something about the protocol-dependent 
> >classifier, and it seems pretty strange for the 
> >classifier (which is looking at protocol values in 
> >messages) to know anything about the outbound queues.
> >
> 
> Why strange? Routers cannot get away without the mapping. 
> If the mapping is not via configurable MIB parameters then 
> it has to be hard-coded. 
> 
> In any case, am I reading that you are opposed to the
> MIB allowing a TCB blk to explicitly point to a Q?
> Or are you opposed to having the TCBs point to
> a set of dropper parameters? Or are you opposed to
> both?
> 
> 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/

_______________________________________________
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: Tue, 06 Jun 2000 08:55:52 -0500

Andrew,

My feeling is that you are correct, in the spirit of a conceptual functional
model. Obviously nobody would actually implement it like that, but that
is not what we are trying to do.

   Brian

---

From: Dan Grossman <[email-masked]>
Date: Tue, 06 Jun 2000 17:57:12 -0400

> things seem to overly complicate the model.
I missed how we got to this conclusion.  It seemed like a good solution a few 
weeks ago.
> However, it also seems ugly to
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.

---

From: Fred Baker <[email-masked]>
Date: Wed, 07 Jun 2000 06:33:49 +0800

>domain, but I can't imagine actually implementing such a thing.

Very ugly, IMHO, and IMHO a model that is not at least *a* way to implement
it doesn't give me much guidance in implementation. I would far prefer to
keep this as simple as we can.

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.

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." 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'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.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 07 Jun 2000 10:41:00 -0500

> and make the thing snap configurable.

Yes, I fully expect the market to settle down to a very small number of
service classes. You won't find much enthusiasm from the diffserv chairs
to add any new PHBs or to see a very large number of PDB definitions.

So I have to agree with Fred, and the general priniciple has to be 
"if in doubt, cut it out."

   Brian

---

From: Dan Grossman <[email-masked]>
Date: Wed, 07 Jun 2000 11:50:22 -0400

> 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.
 
> 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
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?
> 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: "Joel M. Halpern" <[email-masked]>
Date: Wed, 07 Jun 2000 13:15:19 -0400

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.

So, I am left confused as to whether you are agreeing or disagreeing with 
Andrew.

Yours,
Joel

At 06:33 AM 6/7/00 +0800, Fred Baker wrote:
>The things that Andrew
>described could be modeled simply, perhaps using cascaded TCBs

---

From: Kathleen Nichols <[email-masked]>
Date: Wed, 07 Jun 2000 11:39:34 -0700

Well that's an unfortunate equation of services with PHBs.

So, both RFCs 2597 and 2598 have this language up front:

"The XX PHB is not a mandatory part of the Differentiated Services
   architecture, i.e., a node is not required to implement the EF PHB in
   order to be considered DS-compliant.  However, when a DS-compliant
   node claims to implement the XX PHB, the implementation must conform
   to the specification given in this document."

RFC 2474 explains you don't have to have 8 separate queues.
The number of PHBs *implemented* is a choice of the box
vendor. The PHBs *used* is a choice of the network operator.
The visibile "services" and their use of PHBs to realize
their goals is also up to the network operator. I am
sympathetic to the notion that there seem to be more
PHBs defined than there are envisioned services. Given
that one PHB could be combined with different rules to
give a number of services, this seems like something is
backward. I've always thought it was unfortunate that
RFC2597 has this language that is "all or nothing" and
I believe that at least one of its authors feels that
way based on exchanges we had in preparation of a non-public
document. There is nothing in the diffserv definition that
says the Chinese IP folks (or anyone else) can't build a
network with a small number of PHBs. I guess I'd have to
know what is meant by "service": I think several different
services can be offered based on one PHB if a different
bandwidth means a different service. But, not for nothing
are we not standardizing "services".

	Kathie

---

From: Fred Baker <[email-masked]>
Date: Fri, 09 Jun 2000 04:51:00 +0800

>sense in which TCBs exist in this MIB is in terms of the level number in 

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: Fred Baker <[email-masked]>
Date: Fri, 09 Jun 2000 04:51:00 +0800

At 11:50 AM 6/7/00 -0400, Dan Grossman wrote:
>without complexity...

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.

I asked him which step he would like me to remove to make things as simple 
as ATM. I then offered to go into VBR/ABR/UBR services with CLP in 
comparison to AF, and he backed down.

It turned out that what he was probably balking at was that he understood 
AF to *require* him to deploy four AF classes. I walked through how that 
magic number was chosen, some ways that he might use four classes 
(transaction protocols like SAP in one, video in another if not a set of 
EF-like classes, corporate-important data in a third, generic data in a 
fourth), and through some service offerings that I know other networks have 
announced, which generally have one EF and two or perhaps three AF classes.

When he understood that he was being given options rather than 
instructions, he was happy and the discussion went on.

Yes, this is perhaps getting off topic, but there will be room for a 
"deployment experience" paper some day which might find this type of 
question and answer to be useful text or at least topics to address.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 08 Jun 2000 17:19:57 -0400

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:
>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.