Subject: Re: Concerns about exported numbers

From: [email-masked] (Fred Baker)
Date: Fri, 22 Dec 1995 13:14:20 -0800

At 2:33 PM 12/22/95, Roch Guerin ((914) 784-7038) wrote:
>Let me try to take a crack at responding to some of the comments/questions
>in your note, at least those concerning the guaranteed service. I'd like
>to also take the opportunity to say that I consider the exported information
>of that service specification to be key to providing coherent and consistent
>end-to-end service characteristics.  I'll try to provide details clarifying
>that statement in the rest of this note, but let me first respond to the
>specific issues you raised.

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), controlled load, and controlled delay, and exporting
nothing. You'll have to show me a live fire test that fails the service
specifications, because my testing to date says that I in fact deliver on
the guarantees.

And I advertise nothing whatsoever.

>Probably not directly as I don't think any of them uses this specific
>notation.  However, all the "necessary" information is there!

I finally got a definition from John W last night; he is sending the text
off to Craig.

>All IBM Research reports that have not appeared in other publicly
>available form, e.g., conf proceedings, journals, etc. are
>available through the IBM Research Publication server whose URL is
>
>               http://www.watson.ibm.com:8080

Thanks, that's helpful... I have now printed off said report.

>Actually, the best way to do that is probably by means of
>a few examples, that could be added to the "Guidelines for Implementors"
>section, of what the C and D terms would be for some common schedulers
>that router may use.  If there are no volunteer, I can probably take a
>crack at putting together such a few paragraphs for both a WFQ scheduler
>and a rate-controlled scheduler.

This would be real nice. Drop a note to Craig with the text.

>C and D will typically be fixed quantities that depend on the type of
>schedulers you use.  The harder part, implementation wise, is likely to
>be the scheduler itself, but quite a few people have demonstrated that
>schedulers that fit the "Guaranteed Service" model can indeed be
>implemented, e.g., WFQ and rate-controlled.  We are ourselves working
>on such an implementation, and I do not foresee any major show-stopper
>that would invalidate the model.

I have a WFQ scheduler deployed - some of the links over the atlantic are
*now* using WFQ for best effort traffic. I have no reason to believe that
it cannot be done. I have no clue why one would need these constants to do
it...

>>If the accumulated delays are supposed to externalize the actual mean end
>>to end delay, all of the above are non-trivial components and are neither
>>measured nor reported, and it's not clear how they might be measured or
>>reported. I suppose we could dedicate 43 K of RAM per VCI in an ATM switch
>>to keep track of maximal end to end delays...

>Bottom line is that
>you want to know the fixed component of your end-to-end delay,
>so that you can determine what to ask from the routers for the portion
>that is under their control, i.e., through the scheduling.  Btw, there is
>no mean end-to-end delay component in the Guaranteed Service, since
>it only deals with bounds.

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? If the answer is that you do, how
do you plan to get the numbers from the switches?

>Not sure I follow you there.  The point is not to find out what you are
>getting by experimentation.  Rather, what you want is to get enough info,
>so that you can decide what to ask in order to get what you need.  Also,
>asking for higher or lower levels of service does not help much unless
>I know what these mean, and that all the routers on my path use the same
>definition.  Imho, this is one of the strength of the Guaranteed Service
>model, in that it ensures end-to-end consistency and performance.

huh? I need one of two things: I need to be able to get a certain bit rate
(the output rate of the encoder) across the network (guaranteed service ~
ATM CBR or RT-VBR), or I need to get a less determinate bit rate across the
network with certain delay characteristics (controlled something, ATM
RT-VBR).

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? What's
the question here that dorking with the numbers can solve?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Some ideas are so crazy that only an intellectual could believe them...
        George Orwell

---

From: John Wroclawski <[email-masked]>
Date: Fri, 22 Dec 1995 22:42:41 -0500

From: [email-masked] (Fred Baker)

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

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

To get that better upper bound...

				-john