Subject: Some comments/questions on the lates 7/07/95 17:05:59

From: "Roch Guerin ((914) 784-7038)" <[email-masked]>
Date: Sat, 8 Jul 95 18:54:39 EDT

Reference:  Your note of Fri, 07 Jul 95 17:05:59 -0700

*************** Referenced Note ***************

>    These are quick comments -- I'll try (particularly if you can make
>a copy of the IBM report available) to give you a more detailed reply
>later.

You can get the report from the IBM Research Publication Web Server,
aka CyberJournal.  The URL is http://www.watson.ibm.com:8080
In case anyone has problems retrieving the report, I'll be happy to
send a postscript copy by email, or a hardcopy by snailmail if
everything else fails :-(

>     o As is stated in the Motivation section, the guaranteed-delay service
>      is designed for applications which have strict delay guarantees.
>      One way of specifying this, is by guaranteeing a backlog clearing
>      rate R along with a couple of error terms C and D at each network
>      element.  This is closely tied with the Weighted Fair Queuing (WFQ)
>      Policy.

Understood, and actually what we wanted to make sure was that we could
use the template as it is currently defined with other policies than
WFQ.

>>     Is it possible to specify the per-hop delay by setting
>>     R = infinity and D = per-hop-delay?
>
>Probably though that wasn't intended.  D is supposed to be equal to your
>constant per-hop cost (e.g., if you've got a pipeline with minimum delay
>X, X gets added to D).

Guess this means that we could then use this to include both the constant
node/link delay and the delay upper bound guaranteed by the service
discipline

>>     The main reason for this, is that there are scheduling policies
>>     that can outperform WFQ, e.g.,  Rate Controlled Service Disciplines
>>     (see IBM Research Report # RC 20064).

>Can you make the report available so the WG can read it and see what it
>thinks?

Yes, see above for the URL of where to get it.

>>   o The Traffic Specification and Policing section in the "Network
>>     Element Service Specification Template", specifies that traffic is
>>     described by a token bucket filter which specifies the token bucket
>>     rate r, and the bucket depth b.  In practice, the b tokens can never
>>     be depleted instantaneously in a real network.  Rather, there is a
>>     maximum (peak) rate associated with the traffic, which is the maximum
>>     rate at which tokens can be depleted from the token bucket.  It is
>>     advantageous to include the peak rate of the traffic in the
>>     specification of the token bucket filter, as this can be used to
>>     further reduce the amount of resource reservation that is required
>>     to provide guaranteed (or controlled) delay service.  In addition, it
>>     is also a very important quantity when trying to determine the buffer
>>     size needed to properly support a connection.
>
>Scott and I left this out because it wasn't clear it was useful to specify the
>peak rate and we're happy to consider putting it in.
>
>Let me push back slightly, however.  Given a peak rate R and bucket rate r,
>the worst case rate at which the bucket gets drained is b/r (if each hop
>gives it a bandwidth share of r), in which case R is superfluous.  Indeed,
>if you read Parekh's thesis, while he specifies the bucket in three
>parts b,r,R -- the results only use b and r.

Correct, but this is only because of how he derives the bounds and is
not an inherent property of WFQ.  It is actually possible to improve
these bounds by including peak rate and/or the smallest link speed on
the path (based on some recent results by Rene Cruz or using a lemma
we have in the technical report I mentioned).
In any case, it is an important parameter for other policies than WFQ,
and can also play a significant role for buffer sizing.  This is why
we would have liked to see it included.

>Thanks for the comments!
>Craig

Thanks for the quick response.
Roch