Subject: [Diffserv] Modeling of algorithmic droppers and queues

From: "Robert Moore" <[email-masked]>
Date: Fri, 1 Dec 2000 15:57:43 -0500

After reading through the -05 Informal Model, and comparing
it with the new -02 QDDIM, it appears that neither of us is
quite there yet on modeling the relationship between an
algorithmic dropper and a queue.  There are (at least!) two
ways of modeling these two elements, and both documents
contain elements of both approaches.

Option 1:  an algorithmic dropper sits before its queue
in the data path, and based on what it sees in the
queue, it discards "packets that arrive at its input"
(Informal Model, p. 27).  This is what the Informal Model
describes as the alternative it has chosen.  It is the
basis for the NextService association in QDDIM and the
Next pointer in the -06 MIB, which show a progression
from <some preceding element>-to-AlgorithmicDropper-to-queue.

Option 2:  an algorithmic dropper sits beside its queue,
outside the data path, and based on what it sees in the
queue, it discards packets "from the head, tail, or other
part of the associated queue" (Informal Model, p. 29).
Figure 5 in the Informal Model shows this interpretation
very clearly, and it's also represented in the QDDIM
by the HeadTailDropQueueBinding association.

If we look at the example TCB in section 8.2 of the
informal model, we see that the droppers are all placed
before their associated queues, as Option 1 requires.
But they're also dropping from the tails of the queues,
which, given the picture, isn't too much of a stretch:
if the observed properties of the queue tell it to,
the dropper drops a packet that it's holding, rather
than putting it onto the tail of the queue.

What would the picture look like if the dropping were
from the head of one of the queues?  We can't place the
dropper after the queue -- both the Informal Model and
the MIB explicitly rule this out.  The only picture
that works is the one for Option 2.  But here the
dropper is plainly not dropping a packet that "arrives
at its input" -- it's dropping a packet from the head
of the queue.

I'm not sure what's the best way to clarify all of this.
My inclination, though, would be to say that Option 2
is the right way to think of this relationship, with
the *convention* that the chain of Next pointers /
NextService associations always goes
<preceding element>-->AlgorithmicDropper-->queue.

I'm also wondering whether, in the QDDIM, we should
have made HeadTailDropQueueBinding a subclass of
NextService,  This would embody the convention that
I just described, without requiring a separate NextService
association between the dropper and the queue, alongside
the HeadTailDropQueueBinding.  (This assumes that the
queue that a HeadTailDropper monitors is always the
same one from which it causes packets to be dropped --
I haven't seen anything to indicate that this is not
the case.)

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]

_______________________________________________
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: Andrew Smith <[email-masked]>
Date: Thu, 07 Dec 2000 11:05:10 -0800

Bob,

OK, glad to see that someone actually reads the fine print - thanks! You caught 
the Model draft in an inconsistent state between it's prior use of Option 1 in 
-03 and earlier and the -04/-05 versions which use Option 2 for the Figure 5 
diagram (a lot of the text and Section 8.2's example didn't get made consistent 
with Option 2 - that's my fault). But I'm now proposing we go back to the Option 
1 formulation (see my Diffserv WG message "Model draft - model for algorithmic 
droppers" from 12/5, as well as subsequent discussion, for my reasoning).

You said:
 > We can't place the
 > the MIB explicitly rule this out
but, of course, we are at liberty to change these explicit statements if the WG 
so desires. For Option 1, you would have to allow the Algorithmic Dropper to go 
after the queue in order to represent Head Drop (those explicit statements, in 
the Model draft at least, *were* updated to match the Option 2 representation).

Apologies for the inconsistency in the current Model draft text/figures.

Andrew Smith
(Model draft editor)

> I haven't seen anything to indicate that this is not

******************************************************************