Subject: heterogeneity on reservation

From: Carmen Gonzalez <[email-masked]>
Date: Sun, 20 May 2001 01:19:12 -0400

Hi;
By the time the paper by White,P. from the University College London was
published: "RSVP and Integrated Services in the Internet:A tutorial" (IEEE
Communications Magazine, May 1997), RSPV still did not sustained
heterogenity in a multicast reseravtion for the same session. Is still the
case?

Carmen

---

From: Lixia Zhang <[email-masked]>
Date: Sat, 19 May 2001 23:14:42 -0700 (PDT)

> heterogenity in a multicast reseravtion for the same session.

I missed that '97 paper.  So wonder if you could define "did not sustained
heterogenity"?

I recall RSVP spec talked at length about how to handle heterogeneous
requests --- isnt that the same thing as heterogenity in the same mcast
session?

> Is still the case?

we all learn from trials and errors.  Only after stumbled over the
complexity of merging heterogeneous reservations did I realize a much
simpler way for the same problem would be using a few sub-sessions for the
same mcast applucation flow, with each sub-session being
homogeneous. I presented this at an RSVP WG meeting way back when
('94?). Academically one might worry how many sub-sessions would be needed
but pragmatically it should be less than handful (e.g. how many ways to
connect, dialup, DSL, T1, Ethernet, there you probably get enough BW for
full stream)

wonder exactly what problems *you* try to solve...

Lixia

---

From: Carmen Gonzalez <[email-masked]>
Date: Sun, 20 May 2001 18:31:34 -0400

Hi Lixia;
Not any specific problem. I am trying to get a good idea about what are the
particularities of the RSVP protocol. As a part of the ADSPEC seccion of
the Path message there is a statment:
At present RSVP does not accommodate heterogeneity of services between
receivers within a given multicast Session.

If I understand correctly he talks about the different services offered by
the sender which can be advertised in the ADSPEC portion. Guaranteed
Service and Controled-Load. Each of the two could be used to "forced"
everyone in a multicast session to request that service especeifically.

I would love to know also more about how set heterogeneous sessions
requests. Where to find such information?

Carmen

---

From: Maria Elena Villapol <[email-masked]>
Date: Mon, 21 May 2001 11:39:49 +0930

Hi Carmen:

> receivers within a given multicast Session.

I had read the paper sometime ago. But after I read that statement I read that
part again. I am wonder if there is a mistake in the sentence and what the
author wanted to say is
At present RSVP does not accommodate homogeneity .....

because as far as I know one of the goals of RSVP is to support heterogeneous
receiver requests within a multicast session and it is done by using reservation
styles and merging .

> requests. Where to find such information?

I think RFC 2205 is the best source. There is also a book about RSVP:
http://www.wiley.com/compbooks/durham/
it can be useful.

I hope it helps.

Maria

--
Maria Elena Villapol
PhD Student
Institute for Telecommunications Research
University of South Australia

email: [email-masked]
       [email-masked]

Web Page: http://www.itr.unisa.edu.au/~maria/index.htm

---

From: John Wroclawski <[email-masked]>
Date: Sun, 20 May 2001 22:12:22 -0400

At 11:14 PM -0700 5/19/01, Lixia Zhang wrote:
>homogeneous.

This approach might (see below) address the "layered codec" problem, 
where you have a single source sending with a multiplicity of 
rates/qualities/whatever and want to allow different receivers to get 
different qualities.

However, I don't see any way that it can address the "group of 
senders" problem, in which you have a shared channel, as with a group 
audioconference, and want to allow each listener to faithfully 
receive as much of the group as it can.

ie, tele-conference of 10 participants, each generating, say, 10 kb/s 
voice data.

- person on a thin pipe can only reserve 10kb/s, gets to hear one 
person clearly, may get distortion if more than one speak at once.

- person on a fatter pipe reserves 30 kb/s, can hear up to three 
people clearly, gets distortion if more speak, thinks that's OK 
because she can only understand three people at once anyway.

- archival recording device reserves 100kb/s, gets every detail perfectly.

I'm personally of the opinion that group-communication support 
functions (not just in RSVP) like this are useful things that have 
been getting a little too lost in the recent past, with everyone so 
focused on making the internet safe for telephony.

Regarding the multi-mcast-group approach, it's an interesting 
starting point but it could benefit from some further work as well. 
The problem is that it's got the wrong timescale. It's fine if you 
want to use zero-packet-loss QoS services everywhere (ie, for all 
codec layers), but in many layered coding situations you can get 
better overall quality and make more efficient use of the net if you 
are able to use the layering info to drop the least important data to 
handle short-term congestion.

One way to do this would be to use different QoS parameters for each 
mcast group, with settings that make losses in the less important 
layers more likely. But thats not really right, because what you are 
really looking for is correlated loss behavior across layers. Plus, 
it's hard to control loss rates accurately enough to make this work 
usefully with more than two or _maybe_ three layers.

Pure multi-mcast-groups congestion management, as in RLM, seems like 
an imperfect idea to me - trying to drive the join-leave mechanism 
fast enough to address short-term congestion is fundamentally unsound 
because of necessary estimation and signalling timeconstants.

So you are left with the idea of some sort of multi-mcast-group 
traffic scheduler support, to provide cross-layer-aware loss 
behavior. Seems technically possible, but perhaps a bit, um, ugly.

(But, you say, what about the Jacobson/Shenker argument that layered 
coding + selective drop reduces the incentive of an 
endsystem/application to implement congestion control?)

Right. So the ideal situation would be to have a traffic scheduler 
for layered coding situations that implements selective drop at short 
timescales, to provide the best possible quality for short-term burst 
congestion and while adapting, but implements random or even 
dis-selective (you know what i mean..) drop over longer timescales, 
to encourage end-to-end congestion control mechanisms. Neither 
current RSVP/intserv nor multi-mcast-groups is able to support this 
terribly well at present, but if one were to go down this path it's 
not clear that multi-mcast-groups makes it noticeably easier.

John