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

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

OK, so a couple of adjustments to my answer (Thanx Christian
and Henning).  IPv6 has a priority field (3 or 4 bits, depending
on how you count) that could be used for this purpose, though
some usage conventions among implementors would probably need
to be worked out.  And a receiver who doesn't want a particular
layer would simply not subscribe to the multicast tree (in
addition to not sending a reservation).  Then no unappreciated
traffic would flow.

-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: [email-masked] (Madhu Sudan)
Date: Wed, 3 Jul 1996 11:32:11 -0700

[In the message "Re:  Which service class for a scalable flow ?", Jul  2,, Prakash Jayaraman writes:]
|
|	I think a proposal to support layered encoding within RSVP was
|given by someone in the last IETF at Montreal. According to the proposal,
|the layer information (number of layers and the Tspec parameter for each
|layer) will be carried by the Path message. The receivers also make
|separate reservations for each layer. In this proposal, there is an
|ordering of the layers. If a receiver wants to reserve layer i, then all
|layers from 1 to i-1 should have been reserved. Someone else argued that
|the ordering may not be appropriate depending on what is carried by the
|layer. (if audio is in layer 1 and video in layers 2- 5, and I don't want
|audio.. what do I do?)  Things will become clear after the minutes are
|out.
|	Prakash
|
|
- End of Excerpt from Prakash Jayaraman

I presented the draft in the last IETF at Montreal on session group support
in RSVP. We assume a "unique ordering" defined among the different
sessions in the session group. Based on the ordering, the sessions are
assigned ranks. All the receivers can choose to receive "any subset" of the 
sessions (not necessarily starting from layer 1) , but they cannot change the 
ordering. So if there are 5 sessions, receiver 1 can specify (using a bitmap) 
{1,2,3} and receiver 2 can specify {2,4,5} and so on (depending on their 
preferences). 

Assigning a unique rank to a particular session simplifies things during 
admission control. The network knows that whenever layers x and y (x < y) 
are competing for resources, layer y could be dropped in case of lack of 
resources. On the other hand, if each receiver defines its own ordering 
(and hence chooses its own ranking), then the problem becomes significantly 
complex. 

In case of hierarchically encoded data, the ordering is determined by
the source (which encodes the data) and hence each receiver cannot define 
its own ordering. This leads to two possibilities. If layer 'i' depends on
layer 'i-1' then there is a "unique ordering". If layer 'i' does not
depend on layer 'i-1' then there is "no ordering" (any two layers can
be combined ). In the former case,  our proposed solution would
work. In the latter case, these is no need for session grouping (the
receiver can join/leave any session that it wants).

The draft and the slides (from the talk) are available  from:

ftp://ftp.csl.sri.com/pub/hmc/rsvp/draft-madhu-session-groups-00.txt (for draft)
ftp://ftp.csl.sri.com/pub/hmc/rsvp/id-slides.ps  (for slides)

As Don mentioned in his earlier message, we would like to hear from
people about scenarios where our assumption of "unique ordering" or
"no ordering" for layered encoding does not work.

Regards,
-Madhu