Subject: [Diffserv] Dropper issues

From: "Weiss, Walter" <[email-masked]>
Date: Mon, 20 Aug 2001 17:35:16 -0400

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 20 Aug 2001 17:54:04 -0500

Question to the WG: do we *want* the MIB to "support a dropper that is 
influenced by multiple queue depths" as Walter suggests?

   Brian

---

From: "Andrew Smith" <[email-masked]>
Date: Mon, 20 Aug 2001 17:23:44 -0700

Well .... last time we discussed this the consensus was to leave it out of
the MIB. But I'm all in favour of having the MIB reflect reality, despite
the increased complexity in this case. So I'd tend to support this one of
Walter's proposals in principle. However, I'm not sure I entirely follow the
detail of the proposal - I'd like to see the specific changes/additions (I'm
confused by this new "list of queues" concept).

BTW, this scenario *is* implicitly allowed by the current Model draft
although it does not call it out explicity as a valid example. So I don't
think any changes are indicated to that draft.

Andrew

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Brian E Carpenter
Sent: Monday, August 20, 2001 3:54 PM
To: Weiss, Walter
Cc: [email-masked]
Subject: Re: [Diffserv] Dropper issues

   Brian

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

---

From: Dimitrios Stiliadis <[email-masked]>
Date: Tue, 21 Aug 2001 09:30:18 -0400 (EDT)

I would agree that accounting for shared memory strategies in the MIB
is a good idea .. Of course, it can always be extended later, and 
I am not sure I follow the proposal ??? 

Dimitri

---

From: Dan Grossman <[email-masked]>
Date: Tue, 21 Aug 2001 10:15:42 -0400

> influenced by multiple queue depths" as Walter suggests?
I'll have to admit to not paying as much attention to the MIB as I should have.  Yes, this is necessary functionality.  Thanks to Walter for pointing it out.
Dan

---

From: Roch Guerin <[email-masked]>
Date: Tue, 21 Aug 2001 10:25:16 -0400

Many buffer management devices I'm familiar with
do provide for a combination of dedicated and
shared memory pools for queues, and drop decisions
when accessing the shared pool are typically based
on both the current individual queue size/share and 
how much is left in the shared pool.  So supporting
this in the MIB would certainly be useful, provided
that adding that capability does not delay things
too much.

My 2c.

Roch