Subject: Concerns about exported numbers 12/2 1/02/96 14:52:12

From: "Roch Guerin ((914) 784-7038)" <[email-masked]>
Date: Tue, 2 Jan 96 19:02:38 EST

Reference:  Your note of Tue, 2 Jan 1996 14:52:12 +0100

Christian and Jon,

I'll definitely grant you that bandwidth is a key QoS parameter with
which you can get a lot done, and one that's easier to realize than delay
because of the local vs end-to-end nature.  On the other hand as Thomas
points out there are quite a few cases for which bandwidth alone wont do,
and I'd like to add a few observations to his comments.

It's not unheard for switches to have several MBytes of buffer for each
link, and at OC-3 rate a 2MByte buffer can introduce a delay (and delay
variation) of up to about 100msec.  You'll need lots of propagation
delay and/or your own burstiness to get close to that.  What I'd contend
is that you need some level of understanding of the kind of delay
characteristics associated with a particular bandwidth guarantee.
Granted, IF all the switches and routers on your path provide bandwidth
guarantees using some kind of dynamic priority scheduler, e.g., WFQ,
then you can argue that to some extent propagation delay and your own
burstiness will be the dominant factor (the b/R and Dtot in the
Guaranteed Service specs).  However, that's a big IF and
it's likely there will be many cases where this will not hold.  For
example, if you use static priorities you can see rather large delays
and delay fluctuations as you move away from the top priority classes,
even if you have been given a certain bandwidth guarantee.
The magnitudes clearly depend on the type of traffic being muxed and
the size of the buffers, but you can expect to see pretty wild things.

For example, I'm not sure I would count on ABR with some form of MCR
guarantees to provide you with a sufficient level of service.  Given
that ABR has NO delay guarantees whatsoever, if the switches use deep
buffers, as they will need to simply to deal with the rate fluctuations
feasible under the ABR protocol, you can expect to see pretty large
delays and delay variations.  These may not be compatible with the
requirements of multimedia traffic.

The question seems then to be how strong a delay characterization do
we need associated with a bandwidth guarantee.  The approach in the
Guaranteed Service specs is to give you, in addition to a bandwidth
guarantee, a very strong characteristic for the associated delay,
namely a value that will never be exceeded.  The benefit is that
you know exactly where you stand using a reasonably simple procedure
to determine this value.  The disadvantages are that it imposes some
requirements on the scheduling to be used at the switches and routers,
and may be more than what many applications need.  Wrt the latter, if
your application is not too picky about the delay, you can always
ask for a service rate (bandwidth) close to your average rate.  You'll
get a pretty bad upper bound, but if the network is reasonably loaded,
you should see decent averages.  On the other hand, if your application
really needs a deterministic value, then you can get it.

I certainly don't want to argue that providing a deterministic delay
characterization is required, but I don't think that a bandwidth
guarantee service without some a priori delay characterization will do.

Roch

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 03 Jan 1996 14:01:38 -0500

In message <[email-masked]>, "Roch Guerin ((914) 784-7038)
> characteristics associated with a particular bandwidth guarantee.

That's a bit less than the RTT from Hawaii to the US East coast with
no queueing at all, with about as direct a fiber path as you can get.

If you have admission control on real time traffic and queue real time
ahead of elastic, the size of the queue will help elastic traffic
acheive better utilization without hurting real time traffic.  IMO a 2
MB buffer would be about right for OC3 in the US if most of the
traffic was continental US and the buffering was used efficiently (not
4KB or 8KB packet buffers with 40 byte packets in them).

I don't think anyone proposes to build 100msec queues of real time
traffic.  Elastic traffic yes, for slow circuits we already do.
Putting RAM in the box for other queueing requirements doesn't mean
you have to queue up that much real time traffic.

> requirements of multimedia traffic.

ABR with minimum and attempting to exceed the minimum to probe for
additional bandwidth is actually a bit more problematic than admission
of controlled rate and policing for real time.  Policing however is
highly undesirable for elastic traffic.

> really needs a deterministic value, then you can get it.

There is a need to accomodate the applications that can reasonably be
expected.  There may be applications such as the ones pointed out on
this list, applications requiring echo cancellation was one for which
guarenteed delay is great.  Even then, a well grounded expectation
that delay will be held reasonably low may be sufficient.

There is certain to be real time applications for which controoled
load is just fine.  There is certain to be elastic applications for
which controlled load meets a need.  These two are different and need
to be handled differently, which controlled load does not accomodate.

> guarantee service without some a priori delay characterization will do.

The arguments seem to be:

  1.  controlled delay is overkill for (pick one - some/many/most)
      applications.

  2.  controlled delay is highly problematic for some interface types
      and unproven for others.

The first is not an issue as long as there is the option as an
equipment vendor or provider to not offer controlled delay and there
is the option as a user to not use it if it offers little or no
benefit and any additional cost is passed back.  Best of luck.

The second is an issue as long as the IETF still believes in working
code and not just conjecture that something might or probably will
work and there is rough consensus to go forward in the face of some
uncertainty as to whether it will work.  This is all interesting, but
Personally, I'd like to see this stay draft until there are working
implementations and some experience.  Standardize now, worry about
whether it works later is definitely not the IETF way of doing things.

Curtis