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

From: "Weiss, Walter" <[email-masked]>
Date: Tue, 5 Dec 2000 16:42:47 -0500

Andrew,

> The example diagram (for a tail dropper), replacing current 
> figure 5, would then be:
> 
>          +----------------+    +-----------+
>          |  +-------+     | n  |smoothing  |
>          |  |trigger|<------/--|function(s)|
>          |  |alg.   |     |    |(optional) |
>          |  +-------+     |    +-----------+
>          |      |         |       ^
>          |      v         |       |Depth
>    Input |  +-------+ no  |   ------------+  to next
> ---------->|action |-----------> |x|x|x|x|------->
>          |  |   ?   |     |   ------------+  e.g. Scheduler
>          |  +-------+     |      FIFO
>          +------|---------+
>    Algorithmic  |yes
>    Dropper      v
>              +------+
>              |Next  |e.g. AbsDrop,Mark
>              |Action|
>              +------+
> 
I like this picture better than the previous version. However, I have a
couple of observations. First, there is a fairly lengthy discussion of
queuing blocks (algorithmic droppers, queues, and schedulers) and the
relationships between them. When you seperate the drop function from the
triggering function, you introduce the possibility if an action in the
middle of queuing block, creating a number of inconsistencies in this
portion of the text. It may be helpful to add some additional text
recognizing that a Marking action would (MUST?) be bound back to the same
FIFO as the no path.

> This still leaves the problem of the name: everybody seems to 
> complain about 
> "Algorithmic Dropper" but nobody has/had a better name. And 
> now it can do things 
> other than Drop. How about "Algorithmic", "Algorithmic 
> Element", "Algorithmic 
> Trigger", "Trigger Condition", "Trigger Element" or "Trigger 
> Action"? Vote early 
> and often (assuming you like the proposed revision of course).

Whatever this new block does, it will now have to be defined as a logically
seperate block. Staying with the theme of other terms (Classifier, Meter,
Dropper, etc.) I am fine with the term "Trigger".

regards,

-Walter

---

From: Andrew Smith <[email-masked]>
Date: Thu, 07 Dec 2000 12:01:17 -0800

Walter - good points, all of them. I'm not quite comfortable with a "MUST" there 
though - I wouldn't want to prejudice what ECN or some other congestion control 
algorithms might say about binding back to the same queue. But some additional 
text there would be a good thing.

Andrew

Weiss, Walter wrote:

> recognizing that a Marking action would (MUST?) be bound back to the 
> same FIFO as the no path.
> 
> Whatever this new block does, it will now have to be defined as a 
> logically seperate block. Staying with the theme of other terms 
> (Classifier, Meter, Dropper, etc.) I am fine with the term "Trigger".
> 
> regards,
> 
> -Walter

_______________________________________________
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