Subject: Concerns about exported numbers 12/22/95 13:14:20

From: "Roch Guerin ((914) 784-7038)" <[email-masked]>
Date: Fri, 22 Dec 95 16:38:15 EST

Reference:  Your note of Fri, 22 Dec 1995 13:14:20 -0800

Fred, guess I'll have to beg to differ with some of the points your making,
but I also think I may understand some of what you are asking for (see
bottom of this note).

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

First, there is a significant difference between guaranteeing bandwidth
and guaranteeing delay.  The first part is obviously the fixed delay
component you have on any path, e.g., propagation delay and the like,
which is clearly an important component of your end-to-end delay,
and has no impact on your bandwidth guarantee.  I'd like to know
what it is, so that I know what's left over from my total budget,
that can then be devoted to queueing delays in the routers.  For
example, if I need 100 msec to get good synchronization or a truly
interactive session and 50 msec is eaten up by fixed delays, I will
have to ask for a much better service from the routers than if only
10 msec had been spent.  Unless I have been provided with that
information (by having it exported and advertised), I wont really
know what I need to ask from the routers.

Now, coming back to the more interesting part of the delay, i.e., the
one that is under the routers' control and related to some extent to
bandwidth, there are nevertheless significnat differences between
the two.  You can guarantee me 2 Mbps but that means very little in
itself.  Does it mean that you'll deliver 2kilobits every millisec,
or 2Megabits every sec, or 20Megabits every 10 sec, or what?  Unless
there is a coherent definition for what it means, there is no way
you can consistently translate that into delay guarantees without
advertising any quantity (C terms).  Even if you require that the
schedulers used in ALL the routers be identical, i.e., WFQ schedulers,
so that the C term is the maximum packet size for all of them, you
still have a dependency on some accumulated quantity, i.e., the
number of routers you go through.

What your testing probably tells you is that if you go through a
known fixed number of routers, that are all using a WFQ scheduler,
then sure you will provide delay guarantees simply by providing
rate guarantees.

As far as I am concerned, this is a rather restrictive framework
to provide a generic service which gives end-to-end delay guarantee.

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

Will drop Craig a note with descriptions on the use of the C and D
terms for WFQ and rate-controlled schedulers some time next week.

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

Well, hope I have answered that question in the above explanation,

>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?

Some of that stuff is discussed in the other Research report I mentioned
in my previous note (RC 20250), but the jist of it is that you do need
some form of numbers from the switches/clouds that do not run RSVP natively,
and typically it will be available in the form of a D term only.

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

Hmmmm, I think I may need more than 2, but let's look at the two you give.
For guaranteed service, ATM CBR, RT-VBR, you need more than getting a
certain bit rate across the net, unless you have a very specific definition
for across that is not spelled out here.  Across when you have delay
guarantees means 'that many bits within a well defined amount of time'.
Unless you gather the information
needed to provide that kind of guarantee, you wont deliver on it.
Now for the second service, let me just point out that NRT-VBR is pretty
deterministic in what bit rate needs to get across.  The network may have
some flexibility in terms of the delay (and jitter) that it experiences,
but that's about it.  No kidding around with adjusting bandwidth in the
middle.  That's where I see a need for another service pretty much
along the lines of controlled load or ATM-ABR, which has much less
stringent requirements in terms of the bandwidth guarantees.

>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?

Here, let me try to make a suggestion.  What Guaranteed Service defines
currently is a Guaranteed Delay service, and for that you need to dork
with the numbers....  What you seem to want is a Guaranteed Bandwidth
Service, where delay guarantees would only be loosely expressed.  I
certainly think that would be a valuable service, with probably fewer
interoperability constraints when crossing other clouds (in particular
ATM and Frame Relay), and capable of satisfying the needs of many
applications.  However, that's a service spec that is quite different
from the current Guaranteed Service one, and which would require some
work to properly define.  It might be worth putting together such a
spec and I'd actually be happy to help work on such a spec,
but that's a different story from trying to bend the current
Guaranteed Service specs to fit that model.

Well, that's about it and Happy Holidays to all.
Roch

P.S.:  I'm going to stay far away from my email for the next few days,
so I wont be responding to any new posting before I come back.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 26 Dec 95 12:00:16 PST

Roch,
 
> and typically it will be available in the form of a D term only.

It is one thing to say that "you do need some form of numbers from the
switches/clouds". But to make this practical one also has to spell out
*in details* how these numbers could be obtained. And as Fred pointed
out, ATM is not the only technology that could pose a problem for getting
these numbers. For example, how would you propose to get these numbers
in the presence of Ethernet switches ?

Yakov.