Subject: RE: [Diffserv] Dropper issues

From: "Weiss, Walter" <[email-masked]>
Date: Tue, 21 Aug 2001 14:28:02 -0400

Joel,

I would agree, except that a subsequent change would significantly alter the
RandomDrop table or replace it altogether requiring support for both
implementations. I certainly know of implementations that could make use of
this change. However, the question of whether this change is insufficient to
meet a larger cross-section of implementations is a reasonable one. If this
improves the usability of the MIB, I would like to see it added. If it
remains insufficient for a significant number of implementations, I would
agree with Joel and hold off on making this change.

regards,

-Walter

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]]
> Sent: Monday, August 20, 2001 6:42 PM
> To: Weiss, Walter; [email-masked]
> Subject: Re: [Diffserv] Dropper issues
> 
> 
> 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/cur
rent/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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Aug 2001 15:45:36 -0500

Of the people who have spoken up (about 2% of the people on the list:-),
a majority were in favour of this change - yet Joel raises a valid doubt below
and Walter partly agrees. I don't really feel this is a consensus for
adding it, but if you think that is a false conclusion please yell now
rather than waiting for Last Call.

   Brian Carpenter
   diffserv co-chair

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org

"We shall need a number of efficient librarian types 
 to keep us in order." - Alan Turing, 1947.