Subject: Re: [Diffserv] Dropper issues

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 20 Aug 2001 18:42:17 -0400

I may be wrong, but it looks to me like this is something that should be 
added later, rather than trying to shoehorn this in at the last minute.  I 
suspect that when we get to shared memory drop configurations implemenbtors 
probably have gotten much cleverer than we can easily conceive.
Yours,
Joel

At 05:35 PM 8/20/01 -0400, Weiss, Walter wrote:
>As per the meeting, here is my concern with the existing MIB dropper tables.
>The existing droppers work well when all traffic is dropped along a specific
>data path and when statistical percentages of traffic are dropped from a
>given queue. However, Queue based dropping tends to be far more difficult in
>practice because many implementations share buffering resources across a set
>of queues (in some cases across interfaces). In these implementations, it is
>not uncommon for each queue to be assigned some minimum number of buffers,
>but share the remaining buffers among the set of queues. Hence the current
>MIB is unable to support these implementations.
>
>Droppers can be implemented using a number of strategies. However, in order
>to utilize shared buffers effectively, queue depth calculations must take
>into consideration the total number of buffers available for all the queues.
>One common approach is to calculate the queue depth as a sum of all the
>buffers allocated across the set of queues sharing the buffer pool. This
>approach can allow for unique thresholds to be allocated on a per queue
>basis.
>
>In order to support a dropper that is influenced by multiple queue depths,
>we must make the following changes to the MIB:
>
>1. A new table called diffServQueueDepthMeasure must be defined. The
>attributes diffServRandomQueueMeasure, diffServRandomDropWeight and
>diffServRandomDropSamplingRate would be removed from the RandomDrop table
>and moved to this new table. In addition, each table entry also has an
>integer attribute (secondary index) used to identify the list of queues that
>a RandomDrop table entry should apply it's thresholds to.
>
>2. The RandomDrop table should have the new attribute storing the secondary
>index specified in the new QueueDepthMeasure table. This secondary index
>allows a specific RandomDrop table entry to point to a list of
>QueueDepthMeasure entries which in turn each point to a specific queue.
>
>regards,
>
>-Walter
>
>_______________________________________________
>diffserv mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/diffserv
>Archive: 
>http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

_______________________________________________
diffserv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html