Subject: RE: [Diffserv] Draft 11 MIB Edits

From: Fred Baker <[email-masked]>
Date: Tue, 21 Aug 2001 06:17:56 +0800

At 05:48 AM 8/21/2001, Weiss, Walter wrote:
>*   diffServSchedulerFailNext             RowPointer, (points to another
>scheduler for
>                                                        which excess
>bandwidth is available)

as I mentioned in London, a scheduler selects a packet or does not select a 
packet, and in this case there is some rule by which it lets a second 
scheduler select a packet rather than itself selecting a packet. It does 
not, however, "fail".

I would really like to see something proposed which described what actually 
happened.

_______________________________________________
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: "Weiss, Walter" <[email-masked]>
Date: Tue, 21 Aug 2001 14:21:48 -0400

As I mentioned in our discussion in London, the problem I am addressing is
the scenario where one queue is capable of borrowing excess resources in
other queues. One example of this is hierarchical CBQ, which controls
borrowing from other queues via a hierarchy. The diagram below demonstrates
this specific scenario.

Q1-(2M)--\
Q2-(5M)---S1-(15M)--\
Q3-(8M)--/           \
                     -S4-(22M)--\
Q4-(3M)--\          /            \
Q5-(4M)---S2-(7M)--/              -S5-(45M)
                                 /
Q6-(11M)--S3-(23M)--------------/
Q7-(12M)-/

In this specific model if Q1 consumes more than 2M, it first borrows from Q2
and Q3. If this does not succeed, it will borrow from S2 (via S4), which has
the up to 7M available. If S2 has no resources Q1 attempts to borrow from S3
(via S5). Hence the semantics for chaining schedulers together is not to
block the sending of a packet in S4 when S1 allows the sending of the
packet. Rather S1 is incapable (fail may be a poor term) of sending a packet
and is asking other schedulers for borrowed resources. Note further that if
S1 had sufficient resources, S1 may pass the packet to a seperate scheduler
(not shown in the diagram), such as a priority scheduler that may reject the
packet.

I would argue that borrowing excess capacity from other queues is not unique
to just hierarchical CBQ. I have come across other implementations that have
similar issues. The point with this specific change is that I am pointing
out that relationships for managing excess capacity are distinct from the
relationships for what the next behavior action should be after a packet has
been successfully scheduled by a scheduler. However, to Fred's point,
"borrow" may be a better term than "fail" for this specific attribute.

The other change I was proposing was to address the scenario where a
hierarchical sequence of schedulers both rely on queue specific parameters.
This scenario and the scenario described above are both discussed in detail
in the mail I sent to the list on the 9th.

regards,

-Walter

> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]]
> Sent: Monday, August 20, 2001 6:18 PM
> To: Weiss, Walter
> Cc: 'Brian E Carpenter'; [email-masked]
> Subject: RE: [Diffserv] Draft 11 MIB Edits
> 
>