Subject: RE: [Diffserv] Dropper issues

From: "Weiss, Walter" <[email-masked]>
Date: Thu, 23 Aug 2001 16:22:15 -0400

> 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).

Andrew,

The basic concept of the secondary index (list of queues) is similar to the
one employed in classifiers to specify the set of filters belonging to a
single classifier. In the case of the classifier, the attribute ClassifierId
represents a means for creating multiple tables inside the classifier table.
Each sub-table is specified with a unique ClassifierID.

In this new case, each dropper must be capable of referencing the set of
queues that the dropper is deriving the aggregate queue depth from. This
list is represented as a sub-table specified with the new Id. At the risk of
upsetting some dialup folks, I have included a PDF (5KB) illustrating the
proposed change. The first picture represents the current approach and the
second represents the change. In the current and proposed approaches, the
result Weight and SamplingRate determine a smoothed queue depth. The use of
DepthMeasureId provides a means for summing the smoothed queue depths of a
set of queues. If it were desirable to allow weight the various queue depths
when summing them, attributes could be added to the new DepthMeasure table
(through auxilliary classes) to support more sophisticated dropper
algorithms that shared resources across multiple queues.

regards,

-Walter

---

From: "Andrew Smith" <[email-masked]>
Date: Thu, 23 Aug 2001 14:21:50 -0700

Walter,

OK, thanks for the clarification in those diagrams (isn't it time we/IETF
started allowing for PDF as illustrative material, not normative, at least
on the on-line repositories of drafts and RFCs? perhaps we could slip in a
URL or two into RFCs without anyone noticing?).

As I said before, it seems to be consistent with what we have in the Model
draft http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-06.txt
Figure 5 and its following text:

"The example in Figure 5 also shows a FIFO Queue element from whose tail
the dropping is to take place and whose depth characteristics are used
by this Algorithmic Dropper. It also shows where a depth-smoothing
function might be included: smoothing functions are outside the scope of
this document and are not modelled explicitly here, we merely indicate
where they might be added."

I'm slightly concerned that we chose not to cover the measuring/smoothing in
more detail in the Model and yet your proposal for the MIB involves nailing
down some of that detail - would that over-constrain us moving forward? I
guess that most of your proposal involves the "plumbing" as opposed to the
algorithmic details of measuring - could we make it more generic perhaps?
Your phrase "the set of queues that the dropper is deriving the aggregate
queue depth from" is what worries me most - do you think we (the WG) have a
clear enough idea of what "set of" and "deriving the aggregate" mean, to
translate this phrase into MIBisms? (thinking aloud here).

Regards,

Andrew

-----Original Message-----
From: Weiss, Walter [mailto:[email-masked]]
Sent: Thursday, August 23, 2001 1:22 PM
To: [email-masked]'
Cc: [email-masked]
Subject: RE: [Diffserv] Dropper issues

Andrew,

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