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

From: [email-masked] (Christian Huitema)
Date: Tue, 2 Jan 1996 14:52:12 +0100

At 7:43 AM 26/12/95, Roch Guerin ((914) 784-7038) wrote:
>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.

Granted.  On the other hand, I have a few practical observations.  When we
played with multimedia applications, e.g. on the MBONE, we observed that
bandwidth, not delay, was the critical component of quality.  It is very
hard to specify a delay target - the smaller is always the better, but
there is no hard limit.  It is on the other hand very easy to realize that
if you cannot pass at least 4 kbps of data through the pipe, then you are
not going to hear any voice.

In fact, the type of service which fits our applications best would be
something like "ABR with guaranteed minimum".  The network would guarantee
some bandwidth; we would have the liberty to send more, and the switches
would either transmit it or drop the part in excess.

Christian Huitema

---

From: Jon Crowcroft <[email-masked]>
Date: Tue, 02 Jan 1996 14:24:44 +0000

>would either transmit it or drop the part in excess.
 
Christian 

this is a message i've been trying to put over for some time 

given that you design networks for multimedia for the average load,
and you have seperate queues or some other ways of partitioning
traffic for meeting the contract implied by a request for a capacity
(i.e. admission test hlds for both parties:-), it is safe to assume
in most networks (except perhaps mobile/wireless)
that delay is totally dominated by propogation, and delay variance by ones own
burstiness....then, the only reason for giving any delay specific QoS
parameters for most applications is for route selewction (which, btw,
we proved _must_ be done subsequent to route pre-selection based on capcity
requirement) - the delay variance and related terms (e.g. slack) are 
_only_ needed by providers who want to play very clever risk games
with their load and traffic predicitons - sure thay let those
providers do better - but in an _internet_ it is not clear that this
game can be played anymore....whereas the capacity one can.....

on a related topic, if we consider ATM ABR RM cells as part and
parcel of signaling, then should we not have an IP explict rate
message (either as an extension to the ICMP source queuench, or
perhaps more properly as an unsolicited RSVP new rate message).....

and given the long life of most mbone UDP applications, should we not
have some API thoughts about handing up such messages to applications
that have bound UDP port+IP address to an interface that talks to a
net that can deliver long lived (i.e. more than one packets worth:-)
of guarantees...

in fact, shouldn't all signaling be in terms of events/in-band
messages like RM cells...?

 jon

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 02 Jan 1996 19:52:29 +0200

> would either transmit it or drop the part in excess.

this is almost what i have in several occasions proposed as the minimal 
service.  my version is as follows:

- the minimal service is best effort with a flow, that is, each best 
effort user gets its own flow that is isolated from other flows; this 
allows easy implementation of per flow queuing and quarantees that each 
best effor user (udp or tcp) gets its fair share of the available 
bandwidth

- as an option, a best effort user can request a minimum bandwidth 
quarantee; by default the minimum quarantee is zero 

this service would be easy to understand and would be a great 
improvement to current mbone users and network managers that try to keep 
the internet alive.  i strongly suggest that we would start from 
something as simple as above before defining more complicated services 
like the controlled load/delay, etc. atleast it is not fair to call them 
a minimal service.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 02 Jan 1996 20:18:21 +0200

> net that can deliver long lived (i.e. more than one packets worth:-)

jon,

someone told me that we already have some form of feedback as part of 
rtp control protocol, ie., that the destination can tell to the rtp 
source, how many packets it received from the network and the source can 
then use this information to slow down or speed up.  i would prefer such 
a higher level feedback mechanism to having the feedback at ip layer. so 
for tcp applications, tcp takes care of the feedback and for udp 
applications the feedback is part of a higher layer protocol, such as 
rtp.

-- juha

---

From: "Thomas H. Speeter" <[email-masked]>
Date: Tue, 2 Jan 1996 10:34:28 -0800

On Jan 2,  2:52pm, Christian Huitema wrote:

> It is very

Service parameters such as delay are often "don't cares", but in many
cases they are critical.  It's important that an understanding be reached
on who DOES care about delay.

As someone who's worked on interactive television and on circuit switched
voice, I'd like to point out that in these two instances, delay targets
are real, and are readily specified.

For voice, the reason is obvious .. echo cancellation.  Many people
don't realize that much of the fuss about ATM cell size had to do with
whether cell delay would necessitate additional echo cancellation
in the switched phone network.  The body of literature quantifying
this problem is very large.  Although the Internet, and internets in
general are not likely to replace the switched phone network, the same
rules apply, particularly if mixing or bridging are involved.

For broadband multimedia (like interactive TV), delay, in the form of
pipeline delay is important.  How long it takes all buffers in
the network to empty after a request to stop, or switch to another
piece of video impacts UI design is a very direct way.  In this case,
the fact that clients switch, rapidly, from one video stream to another
makes buffering and delay in the network a critical design parameter.

-- 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Thomas H. Speeter                    Phone: (415)-933-2585
                                         Fax:   (415)-390-4679
                                         Email: [email-masked] 
    Silicon Graphics Inc.                   
    2011 N. Shoreline Blvd  - 9U-971
    Moutain View, California - 94043

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 3 Jan 1996 10:11:30 +0200

looks like i screwed up my replies to christian and jon last night.  i
was experimenting with a new web browser to read my email.  back to
emacs ...

christian was proposing a new service category that is similar to what i
have been talking about in several occasions.  i call my version "best
effort with minimum guaranteed bandwidth":

- each best effort user can ask for a flow which isolates that user from
other best effort users

- the user can optinally ask for a minimum guaranteed bandwidth for the
flow

with that kind of simple, easy to understand service, each best effort
user would be guaranteed its fair share of the available best effort
bandwidth plus optionally a minimum bandwidth.  it would be a great
improvement to the current internet, where udp users can override well
behaving tcp users and can, in fact, easily collapse the whole internet.
mbone management would become alot easier and with minimum guaranteed
bandwidth, mbone quality is likely to become better.  if implemented
using WFQ (what i have understod router vendors are actively doing
anyway), also the delay would become bounded.

to jon i would like to comment that i don't like the idea of introducing
a feedback mechanism at the ip layer.  such mechanisms belong better to
higher layers.  tcp already has one and i have heard that also rtp has a
control protocol that allows the destination to tell to the source, how
many packets it has actually received.

-- juha

---

From: Zheng Wang <[email-masked]>
Date: Wed, 03 Jan 1996 12:15:36 +0000

> quarantee; by default the minimum quarantee is zero 

I guess the issue here is where the service interface lies between the
users and the network. The delay has to be translated into bandwidth 
at some stage but the question is where or by who.

If a user specifies e2e a delay requirement, it is then translated 
into bandwidth by the network (taking into account all other factors 
that affect delay).

If a users specifies a bandwidth requirement, the translation is done by the
users outside the network.

For top level (ie, guaranteed) services, it would be easier to do 
the translation inside the network since some information is not 
really available to the users.

For lower level (or minumum) services, it seems to make sense to
request bandwidth rather than delay.  There may be little
difference in the actual implementation, but bandwidth seems less abstract
than delay.

Cheers
Zheng