Subject: Concerns about exported numbers 12/22/95 22:42:41

From: "Roch Guerin ((914) 784-7038)" <[email-masked]>
Date: Tue, 26 Dec 95 07:43:31 EST

Reference:  Attached note from jtw at lcs.mit.edu

Fred, let me just add a few words to John very comprehensive explanation.

A Guaranteed Delay services is ALSO a Guaranteed Bandwidth service,
but the converse is NOT true.

With a guaranteed Delay service, you know that all the bits you are
entitled to send, as per the TSpec you specified, will make it through
the network within a maximum amount of time (the delay bound).  Hence,
you know that you'll get through that many bits per that much time,
which is essentially a bandwidth guarantee.  However, note that the
rate/bandwidth guarantee you get is pretty much your average rate (over
large time intervals)  Actually, (b+rt)/t if your peak rate is
unspecified, which gives you r when t gets very large.

Now, the rate R which the application ends up asking from the network
is typically greater than r.  This is because, it wants to get a
better delay bound, i.e., gets its bits across faster than if it just
had a circuit of rate r.  As John points out, the reason you need the
Ctot and Dtot terms is for the application to determine what R value
to ask.  This is because the network cannot give you a service which
exactly emulates a rate R circuit.  Whatever packet schedulers the
network elements use, they introduce "error terms" (C and D at each
hop) which need to be made explicit if the application is to get any
a priori idea of the service (delay bound) it will get for a given
requested rate R.  This is true even if all the schedulers are WFQ.

Roch
*************** Forwarded Note ***************

Date: Fri, 22 Dec 1995 22:42:41 -0500
From: John Wroclawski <jtw at lcs.mit.edu>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked], [email-masked]
Subject: Re: Concerns about exported numbers

   From: [email-masked] (Fred Baker)

   They'd better find a way for it not to require the level of resources that
   are currently required. I am currently guaranteeing bandwidth (the
   guaranteed delay service is actually a guaranteed bandwidth service; you
   get the delay because the sender doesn't exceed his bandwidth
   specification)

Fred,

You've said this in a couple of different conversations now, and I
think it is at the root of some of the difficulties we're having in
this discussion. Let me know if any of the following makes sense?

In a guaranteed-bandwidth service, the application can ask for some
specific amount of bandwidth to be guaranteed, and either get it or
not.

In a guaranteed-delay service, the application can ask for some
specific maximum end-to-end packet delay to be guaranteed, and either
get it or not.

This means that the application can request some specific numerical
value for the maximum end-to-end packet delay it will see. This is
different than just saying "I want there to be some hard bound on the
delay, and I'll figure out what it is by watching the packets". The
app is actually giving a number.

The current 'guaranteed service' is a guaranteed-delay service. The
way the application requests a specific delay is to calculate a value
for R using the formula given in the "end-to-end service" section of
the specification, and to request that R from the network.

The formula which allows the application to calculate the R it should
ask for to get the delay bound it wants requires two kinds of
information - info about the application's traffic (the token bucket
size b, the token rate r, and the peak rate p), and info about the
network (Ctot and Dtot, which are calculated from the C and D terms
provided at each hop).

If the hops don't provide the C and D terms, then the information
necessary for the application to calculate the R it should ask for
isn't there. Now, to first approximation, you have a guaranteed-
bandwidth service, not a guaranteed-delay service. This is, I think,
what you've implemented.

   Let me try again. If you need arcane constants to provide a guaranteed
   delay service from the routers, and in a path you have 20 switches of which
   10 are routers, why do you not need said constants from the non-routing
   switches in order to provide the service?

You do!

   If the answer is that you do, how do you plan to get the numbers
   from the switches?

The int-serv specs don't talk about routers, they talk about network
elements. Network elements include routers, QoS controllable subnets,
host network code - anything that can affect the QoS of a path.

For a network element which is not controlled directly at the int-serv
level (such as a frame relay or ATM cloud) some other network element
(such as a border router) has to do two things

 - request an appropriate QoS from the cloud it is using to pass data,
by speaking whatever language the cloud wants (Q.2931, say), and

 - reflect that QoS back into the IP-level system by exporting
information (for guaranteed, C and D parameters) which reflect the
behavior of the cloud as well as the router. In other words, a router
has to act as proxy for links, etc, that it is controlling, both when
accepting service requests and when exporting characterization
parameters.

(The same is true in other cases, say two hosts communicating over a
single ATM cloud with no routers - whatever network element does the
int-serv to xxx translation has to generate proxy export parameters
for the xxx).

   Limiting the thoughts to the Guaranteed service, if I ask for more
   bandwidth than I need, I will get a better weight from a WFQ algorithm, and
   therefore *might* get a better upper bound on delay. But I won't get more
   bits through - I will get the bits through that I send, end of story.

   Why would I ever ask for more than the encoder says it can produce?

To get that better upper bound...

				-john