Subject: Re: Which service class for a scalable flow ?

From: [email-masked] (Mark W Garrett)
Date: Tue, 2 Jul 1996 11:33:04 -0400

> Francois Toutain: 
 > ...
 > My question is: given the current service classes being discussed, how
 > could such a stream be properly handled ? Are additional assumptions
 > needed ? (eg. token bucket conformance for the baseband...)

Well, to put a name on this, let's call it the ``interactive
video with layered coding'' problem.  My understanding is that
you can send each layer in a different flow, and then each
subscriber can make a reservation for the subset of flows that
they want.  Either controlled load or guaranteed service would
work, by reserving bandwidth and buffer resources.  You need a
leaky-bucket description of the traffic for each flow.  Both
services claim to offer low delay and low loss.  Perhaps the
baseband layer should use Guaranteed, if you believe that the
loss will be lower than with Controlled Load.  This claim
cannot be assumed from the specs, and the actual behavior will
depend very much on how people implement these services.

I can think of two things missing in the protocols for this
problem: you would like a router, when congested, to
preferentially drop the lower-priority layers.  There is no
mechanism in rsvp (now) to gang the flows together with (loss)
priority ordering.  Similarly, there is no way to assure that
they share a common route.  Second, it would further optimize
the system if the lower-priority layers would be dropped at a
point in the multicast tree where there are no subscribers
downstream.  At the moment all layers would be sent to all
branches with Best Effort quality where no reservation exists.

-Mark

-------------------------------------------------------------------------------
			Bellcore   Rm. 1A-220B			+1 201 829-4439
Mark W. Garrett		445 South St.			[email-masked]
			Morristown NJ 07960-6438  USA	     (FAX 201 829-2504)
                        WWW: ftp://ftp.bellcore.com/pub/mwg/homepage.html
-------------------------------------------------------------------------------

---

From: Roch Guerin <[email-masked]>
Date: Tue, 02 Jul 1996 14:55:23 -0400

>Both

Mark, the Guaranteed service specifies buffer allocation rules that
will ensure lossless operation, or at least losses comparable to those
caused by bit errors.  I'll certainly grant you that many things
depend on implementation details.  However, any implementation that
claims to support Guaranteed Service needs to provide this level of
loss guarantees.  This can not only be assumed from the specs, it is
mandated by the specs.

Roch

---

From: Mark Handley <[email-masked]>
Date: Tue, 02 Jul 96 21:02:19 +0100

>they share a common route.

You really do want to try and ensure they take the same route for a
whole bunch or reasons, although as an app, you have little control
over this.  In particular, delaying one layer demands that you delay
all layers to match at the receiver for such layered apps, so you get
worst-case service.  Also it would be good in many cases (if you
believe in RSVP) to use one shared-explicit reserveration to cover
several contiguous layers.

In PIM, we had the potential at one time to force different layers to
take different paths.  This problem has been avoided, but does depend
on contiguous (or at least clustered) address allocation to work.

As for ganging the flows together with RSVP - I would hope that RSVP
is normally being used to reserve for a flow that's within its TSpec.
If the traffic source is badly behaved, or the reservation is made for
less than the TSpec, then all bets are off.  Thus a shared-explicit
reservation for the sum of the flows for which you can get a
reservation combined with a controlled load service seems like what is
required.  You don't need drop priorities within that band because no
packets within your summed TSpec should be dropped (but there's never
an absolete guarantee with IP anyway).  You can try best effort for
layers above the layers you get the reservation for, and you may or
may not get anything useful - if not, you should leave the group to
avoid dragging the traffic as far as the bottleneck and wasting
bandwidth.

Guaranteed service seems like overkill for this application.

Mark

---

From: Roch Guerin <[email-masked]>
Date: Tue, 02 Jul 1996 14:55:23 -0400

Roch

---

From: Mark Handley <[email-masked]>
Date: Tue, 02 Jul 96 21:02:19 +0100

Mark

---

From: Arun Viswanathan <[email-masked]>
Date: Wed, 3 Jul 1996 14:15:18 -0400 (EDT)

> loss will be lower than with Controlled Load.  This claim

I am not sure if Controlled Load would be always suitable for the sub-bands.
Since the layers may have a timing relationship between them and hence may
require guaranteed delay. Applications can certainly adapt to the delay and
jitter between the layer (not just within the flow) then the flow cannot
be termed as "real-time interactive". Or some of the lower sub-bands may
become unusable despite reservation. The jitter between the layers can be
pronounced with Controlled Load if the layers follow different multicast
distribution tree.

-arun

-------------------------------------------------------------------
Whenever you find that you are on the side of the majority, it is time
to reform.
		-- Mark Twain
-------------------------------------------------------------------

---

From: John Krawczyk <[email-masked]>
Date: Wed, 3 Jul 96 17:04:50 EDT

On Wed, 3 July, Arun Viswanathan ([email-masked]) wrote:

   The jitter between the layers can be
   pronounced with Controlled Load if the layers follow different multicast
   distribution tree.

If it's jitter you are worried about, guaranteed doesn't buy you
anything.  It just bounds the maximal delay.  To quote the spec
directly:

   This service does not attempt to minimize the jitter (the difference
   between the minimal and maximal datagram delays); it merely controls
   the maximal queueing delay.  Because the guaranteed delay bound is a
   firm one, the delay has to be set large enough to cover extremely
   rare cases of long queueing delays.  Several studies have shown that
   the actual delay for the vast majority of datagrams can be far lower
   than the guaranteed delay.  Therefore, authors of playback
   applications should note that datagrams will often arrive far earlier
   than the delivery deadline and will have to be buffered at the
   receiving system until it is time for the application to process
   them.

-jj

---

From: Roch Guerin <[email-masked]>
Date: Wed, 03 Jul 1996 19:02:14 -0400

>anything.  It just bounds the maximal delay.  To quote the spec

jj, 
You are absolutely right that guaranteed does not target control
of jitter as this means that you control BOTH minimum and maximum
delays, but controlling one (maximum) should nevertheless help you.
Furthermore, if you actually use reshaping at enough intermediate
network elements, this can go a very long way towards reducing jitter.
Essentially, if you were reshaping at each network element and
controlling maximum delay, your end-to-end jitter could typically be 
limited to that introduced at the last network element.
Roch