Subject: Some comments/questions on the latest int-serv specs

From: "Roch Guerin ((914) 784-7038)" <[email-masked]>
Date: Fri, 7 Jul 95 14:16:54 EDT

Subject: Int-Serv comments (fwd)

Comments on the draft-ietf-intserv-guaranteed-del-svc-01.txt, and
draft-ietf-intserv-svc-template-0.1.txt

Appended below are two questions we have on the last version of the
above specs.  Since we are "new" to the process which has led to current
version of the document, we apologize in advance for aspects of these
questions which may be based on some misunderstanding.

 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.  However, the application is interested in the delay that
   its packets experience, and not the backlog clearing rate.  While
   R, can be used to derive the delay, the service specification
   should allow for the network element to specify the per-hop worst
   case delay regardless of the backlog clearing rate.  Maybe this can
   be done through the parameter D which is not clearly specified in
   the draft.  Is it possible to specify the per-hop delay by setting
   R = infinity and D = per-hop-delay? If this is true, it should
   probably be spelled out clearly in the service specification.  If not,
   we think it is important to be able to specify the per-hop delay
   explicitly, rather than through a backlog clearing rate, and would
   therefore like to see such a capability added.  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), and operate by specifying per-hop-delays, rather than
   a backlog clearing rate.  In general, if policies are forced to
   specify delay bounds in terms of WFQ parameters, this may then
   prevent them from providing better delay bounds than WFQ, which as
   pointed above is feasible.

 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.  As a matter of
   fact, the flow specifications of RFC 1363 did include a "Maximum
   Transmission Rate" in addition to a "Token Bucket Rate" and a "Token
   Bucket Size."  From our experience with a number of scheduling
   policies and the associated resource reservations, we believe that
   including a "Maximum Transmission Rate" is an important and useful
   requirement.

Thanks in advance for any response or clarification on the above.

Roch Guerin

---

From: Craig Partridge <[email-masked]>
Date: Fri, 07 Jul 95 17:05:59 -0700

Hi Roche:

    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.

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

       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?

       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.

Thanks for the comments!

Craig

---

From: Pawan Goyal <[email-masked]>
Date: Sat, 8 Jul 1995 14:05:10 -0500 (CDT)

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

In the above context, the WG may find the following paper also relevant:

Hui Zhang and Domenico Ferrari, "Rate Controlled Service Disciplines",
In Journal of High Speed Networks, 3(4) 1994.

Pawan Goyal