Subject: Re: [Diffserv] Model draft - model for algorithmic droppers

From: "Robert Moore" <[email-masked]>
Date: Wed, 6 Dec 2000 10:13:32 -0500

I also raised questions related to this topic on the list,
last Friday.  Interestingly, I concluded that the existing
Figure 5 gave the more useful view.  The problem I have with
the direction you're proposing now is not the picture, but
the words that you use to describe the operation of an
algorithmic dropper.  In trying to emphasize its similarity
with other conditioning elements, you say that a dropper makes
a drop decision on a packet that "arrive[s] at its input."
But I see a difference between dropping a packet that's "in"
the dropper, and dropping a packet that's sitting at some
specified position in a queue (which is a different
conditioning element).  The only way to make it right, and I'm
*not* going to try to draw this, would be to say that when
there's a tail dropper involved, the last position in the
queue is *in* the tail dropper, rather than in the queue
object.  Similarly, a head dropper would contain the first
position in the queue.  With this arrangement, putting a
packet onto the tail of a queue would be identical to having
it arrive at the tail dropper's input.  And moving up from
position 2 to position 1 in a queue would be identical to
arriving at the head dropper's input.

I don't like this formulation at all:  it's ugly to have
the queue element represent most, but not quite all, of the
positions in a queue.  And the "next" associations between
a tail dropper and its queue, and between a queue and its
head dropper, become very different from the other "next"
associations in the model.  But if you're going to put the
algorithmic droppers in the data path, and if you're going
to say that they act on packets that arrive at their inputs,
then I think you have to say something like this.

A somewhat independent point:  if you're going to represent
head droppers in the way you propose, then you're going to
have to amend the "canonical" orders of conditioning elements
in a queuing block and in a TCB.  In both cases these
canonical orders exclude the case of a queue followed
immediately by an algorithmic dropper.

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:31:44 -0800

Bob,

I'm not sure it needs to be thought of in this way: I think of the dropper as 
something fairly stateless in the data plane, at least as far as not needing it 
to "contain a packet" for any finite length of time. We can describe the 
tail-dropper as "as the packet arrives at its input .... drop it or allow it
through to the follwing element (e.g. the FIFO)" without needing to have the 
last FIFO position inside the dropper. Similarly for head-drop: "as the packet 
is removed from the FIFO .... drop it or allow the it through to the next 
element (e.g. a scheduler)" without the first FIFO position needing to be "in 
the dropper". I agree with you that it would be too clumsy if that were needed.

Agree about amending the "canonical" rules.

Andrew