Subject: [MMUSIC] Resource reservation flows and SDP

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 22 Oct 2002 09:04:00 +0300

Folks,

the draft below was released some days ago:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-reservation-flows-00.txt

We would like to encourage people to give us feedback on this document.
3GPP will be needing this funcionality, so the idea is to issue a WGLC
as soon as we address any possible concern that the WG might have.

This draft is very short, and in my opinion, non controversial. If
people could spare 10 minutes to read it and send comments, we would
appreciate it.

Thanks,

Gonzalo
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Dan Firac" <[email-masked]>
Date: Tue, 22 Oct 2002 11:45:00 +0200

Hello Gonzalo,

The purpose of the draft is to start a single RSVP session from a sender to
a receiver, no matter how many media streams are sent between them. Right?
As far as I know, the reservation process using RSVP has (roughly speaking)
2 steps:
a) source is sending an RSVP message(PATH) to the receiver(s), FOR EACH flow
it is sending;
b) the receivers return a RSVP message(RESV) to the source, confirming the
reservation.
The RESV message is the one how triggers the reservation state in the
network.

So, If the source wants to start a single RSVP session with some
receiver(s), the source has to transmit a single PATH message for all the
media streams it is transmitting. Of course, the PATH must contain the
global description for media streams (only [DstAddr, Protocol]).
And the receivers would answer with a global RESV for all the streams it is
accepting (here you have a big problem if you don't accept all the streams
the source is willing to send!!!, because you don't have the RSVP flow
descriptions for each flow!!!). But let's assume, you accept all.

My points are:
1) your SDP global reservation is redundant. Because one can do this only
using RSVP.
2) The SOURCE IS RESPONSIBLE with STARTING a RSVP session (by sending PATH
messages), not the receiver (which only accepts/rejects the session)!!!!
3) you gave an example about grouping two media streams: audio & video, and
requesting the same reservation for both of them. In practice, due to some
real things(traffic involved, user impact, low network resources), you WON'T
request the same QoS class for video and audio!!!! Usually audio gets GS
(Guaranted Service) and video gets EF (Expedited Forwading).

I think the draft is very controversial and redundant.

Best regards,
Dan Firac,
Software Engineer,
+40 723 260 623
Redline Communications,
Romania.

----- Original Message -----
From: "Gonzalo Camarillo" <[email-masked]>
To: "mmusic" <[email-masked]>
Cc: "Joerg Ott" <[email-masked]>; "Colin Perkins" <[email-masked]>
Sent: Tuesday, October 22, 2002 8:04 AM
Subject: [MMUSIC] Resource reservation flows and SDP

> the draft below was released some days ago:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-reservation-flows-00.t
xt

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 22 Oct 2002 16:22:03 +0300

Dan,

> a receiver, no matter how many media streams are sent between them. Right?

I do not know from where you got that impression. The word RSVP appears
only in a section called "Example", and it specifically states that SIP
and RSVP were picked up only for the sake of the example.

From the draft:

   For this example, we have chosen to use SIP [4] to transport SDP
   sessions and RSVP [5] to establish reservation flows. However, other
   protocols or mechanisms could be used instead without affecting the
   SDP syntax.

And even if you use RSVP, you can send two different PATH messages
specifying different port numbers. You would have a different RSVP
session for each different media stream.

But, as I said, there are more resource reservation protocols besides
RSVP. When such reservation protocols deal with resources over a radio
interface, it matters a lot whether all the streams are sent over a
single reservation flow or a different reservation flow is used for each
stream.

Thanks,

Gonzalo

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 24 Oct 2002 14:55:00 -0400

inline.

> session for each different media stream.

Actually, there is some truth about the tie of this draft to RSVP.

My first thought when I read this draft was, "why do we need to 
COMMUNICATE the issue of which streams are associated with which 
reservations?" It wasn't clear why this wasn't just a local choice. For 
example, if I am using a sender initiated reservation, I could simply 
choose which streams I bundle together into a single reservation. Why do 
I need to tell the other side?

THe reason, I think, is RSVP. Since its receiver oriented, I need my 
peer to send the proper PATH messages so that I can do the reservation I 
want. Thus, I would argue that this draft is, in fact, intimiately 
coupled with RSVP.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 25 Oct 2002 09:46:48 +0300

Jonathan,

> want. Thus, I would argue that this draft is, in fact, intimiately

Well, I wouldn't go so far to say that it is coupled with RSVP. But you
are right pointing out that this mechanism is only useful when certain
types of reservation mechanisms are used. And, as you also point out,
RSVP belongs to one of these types.

I will add a clarification to the draft saying that the mechanism
described in this draft is intended to be used with reservation
protocols that require the colaboration of the peer that does not
generate the session description. And only when the actions this peer
should perform are not fully determined by the reservation protocol.

RSVP is an example of this type of reservation protocol, because it uses
mono-directional reservation flows initiated by the sender (i.e., the
sender sends the PATH message). However, there are more reservation
protocols that follow this pattern. PDP context activation is another
example.

Thanks for the comments. I will add them to the next version of the
draft in order to clarify the scope of the mechanism.

Gonzalo