Subject: Re: [MEDIACTRL] QOS control: what is in scope?

From: Sukanta ganguly <[email-masked]>
Date: Sun, 29 Jul 2007 15:36:15 -0700 (PDT)

I do agree that the QoS needs are application specific but the framework needs to facilitate them and hence framework needs awareness. So I can't see how one can do QoS ignoring the framework completely.

Are you guys (Tom and Diego) proposing that the a seperate set of specs need to be defined to address QoS?

SG

----- Original Message ----
From: Diego B <[email-masked]>
To: Tom Taylor <[email-masked]>
Cc: [email-masked]
Sent: Sunday, July 29, 2007 1:28:11 PM
Subject: Re: [MEDIACTRL] QOS control: what is in scope?

Hi all;

I have been involved in the design and implementation of a Bandwidth 
Allocation System for multimedia sessions
for  a WiMAX vendors. The architecture is such that an Application 
residing in a SIP Application Server
is responsible for interfacing with a Policy function System 
(Diameter/XML interface) for bandwidth allocation for an incoming session.
The PF in turn, interfaces with the Base-Station using the wimax-forum 
R3 interface (RADIUS/DIAMETER).

In the past the bandwidth allocation protocol was residing in the UA ( 
CPE ). Only CPEs implementing the protocol (proprietary at that time)
were able to negotiate qos/bandwidth and allocate it from the WiMAX 
base-station. To make this inter operable with all SIP CPEs/PBXs/Phones
the protocol was moved to the network.

I think the qos/bandwidth issue have to be out of scope of the 
framework. It is more an application requirement than a framework 
requirement.
In the WiMAX case I sited above, the only element involved is an 
application running on the SIP Application Server. Nor the UA
or the Media Server is aware of the negotiation.

I agree with Tom that a Media SErver has to be prepared for any change 
in the media session parameters. But I think this is achieved using 
standar SIP reINVITE and
UPDATE.

Regards
Diego B

Tom Taylor wrote:
> The question arises, whether QOS control is at all in scope, and what 
> components of the architecture it would affect.
>
> This question arises out of one I posed to the meeting. The 
> architecture defined by the MultiService Forum (MSF, 
> http://www.msforum.org) is primarily IMS-based, has a strong 
> resemblance to the MediaCtrl framework architecture in the relevant 
> parts, but has an open issue regarding which component was responsible 
> for reserving QOS resources for media streams originating at the Media 
> Server. We are talking concretely about a Diameter interface to a 
> Bandwidth Manager.
>
> It is clear from list discussion about AS understanding of SDP that it 
> would not be a popular suggestion that the AS have this 
> responsibility. On the other hand, Media Server vendors plead that 
> their boxes have no service understanding, and should not be the 
> responsible components either.
>
> It was clear from meeting discussion that if there is per-session QoS 
> control at all, it should be done close to the UA rather than at any 
> of the AS, MS, or MRB.
>
> There are a couple of points that came out in discussion, however, 
> that the list should consider. One is that the framework (section 7.1) 
> allocates responsibility for assembling media resources to the Media 
> Server. This may need clarification. The other point is that at a 
> protocol level the MS may have to understand something like SIP 
> preconditions, which may be used to coordinate the setting up of QoS. 
> At the very least, the Media Server has to be prepared to be 
> responsive to offers that initially make a stream inactive, changing 
> it to active in a re-INVITE when QoS resources have been arranged.
>
> Comments on how if at all this affects the framework or other documents?
>
> Tom Taylor
>
>
> _______________________________________________
> MEDIACTRL mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

____________________________________________________________________________________
Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545469

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: Tom Taylor <[email-masked]>
Date: Mon, 30 Jul 2007 08:12:29 -0400

My main interest was in clarifying the architectural principles. I was drawing 
on the expertise of the people at the meeting. The Chairs suggested this go to 
the list for further consideration, but I would be surprised if there were any 
sort of consensus for a QoS-related document as part of the mediactrl work.

Sukanta ganguly wrote:
> I do agree that the QoS needs are application specific but the framework
> needs to facilitate them and hence framework needs awareness. So I can't see
> how one can do QoS ignoring the framework completely.
> 
...

---

From: Diego B <[email-masked]>
Date: Mon, 30 Jul 2007 15:18:00 +0300

Hi;
I don't think mediactrl has to produce any kind of QoS documents.

I remember a thread in the old list regarding SDP parsing YES/NO, I 
don't remember what was the conclusion (if any) of the thread,
but I do remember opinions in favor and against. If QoS will need any 
kind of SDP parsing on the AS, this will come up again.
But, anyway, I still think qos/bandwidth allocation belongs to the 
application realm and mediactrl may not deal with it.

Regards
Diego B

Tom Taylor wrote:
> My main interest was in clarifying the architectural principles. I was 
> drawing on the expertise of the people at the meeting. The Chairs 
> suggested this go to the list for further consideration, but I would 
> be surprised if there were any sort of consensus for a QoS-related 
> document as part of the mediactrl work.
>
> Sukanta ganguly wrote:
>> Are you guys (Tom and Diego) proposing that the a seperate set of 
>> specs need
>> to be defined to address QoS?
>>
> ...