Subject: RE: [Diffserv] Proposal for Diffserv MIB - droppers

From: Andrew Smith <[email-masked]>
Date: Thu, 1 Jun 2000 14:19:59 -0700

Nabil (and a picture for Fred too),

> I think this can be done easily enough. Currently, the
> diffServActionEntry has a field with diffservActionNext
> that points to the next datapath element. e.g. the Queue.
> With this info, we can map DSCPs to specific Queues.
> Why not have another entry in this structure that points
> to the RED params. See below: 

With this approach we would also have to add the forward pointer to the RED
parameters to Action, Meter *and* Classifier entries: any of these elements
can reflect the path through the TCB followed by packets of particular DSCP
"colouring(s)". As I wrote earlier to Fred, a single 6-tuple classifier
filter is not adequate to describe "AF11 OR AF12" even though these 2 DSCPs
might be fed through the same meter and/or marker and/or counter to the same
algorithmic dropper.

Maybe the following diagram helps:

  ---> AF11 ---+---> Meter1 ---> Marker1 --+--> AlgDropper1 --->
               |          |                |
  ---> AF12 ---+          +----> Marker2 --+
                                           |
  ---> AF13 -------> Meter2 ---------------+

The problem is that AlgDropper1 needs to know what the (possibly
re-marked)DSCP is as the packet stream enters it: it wants to apply
different drop probability depending on the DSCP. The fact that the stream
has been classified once already is good: it means that there is already an
existing element to represent each pattern. But "the fact that we know via
which path through the diagram it got to the dropper" (to paraphrase Fred)
is not enough information because paths have been merged and split in
between the classifiers and the dropper. So, unfortunately, we need an
explicit linkage.

My initial cut at this, that Dan objected to, was to say that, no, you
should not be allowed to join and split along the path. Dan argued that this
was just plain inefficient - it would lead you to have to create a whole
bunch more blocks in the diagram. But I don't think that will fly for the
more serious reason that there would be no way to link together 2
separately-classified traffic flows to share the same resource pool measured
by a common Meter, as shown above. I think there are probably other reasons
too.

> I am assuming that if we seek to maintain multiple
> RED parameters per Q (a la MRED) then we would
> have multiple entries of diffServRandomDropEntry 
> as opposed to multiple entries of diffServAlgDropEntry.
> If it is the latter then we can modify the action
> to point to the AlgDropEntry instead.

I am assuming that diffServAlgDropEntrys exist one-to-one with
diffServRandomDropEntrys. RandomDrop is a class that is "derived from" the
more general AlgDrop in OO terminology. If there are multiple drop
algorithms in effect then I assume you would chain together the
diffServAlgDropEntrys with their Next pointers in this incarnation of the
model.

Andrew

> -----Original Message-----
> From: Nabil Seddigh [mailto:[email-masked]]
> Sent: Thursday, June 01, 2000 3:39 AM
> To: Fred Baker
> Cc: Andrew Smith; [email-masked]; Nabil Seddigh
> Subject: Re: [Diffserv] Proposal for Diffserv MIB - droppers

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

---

From: Fred Baker <[email-masked]>
Date: Thu, 01 Jun 2000 16:02:58 -0700

>diffServAlgDropEntrys with their Next pointers in this incarnation of the

that has a better image match for me...