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

From: Tom Taylor <[email-masked]>
Date: Fri, 27 Jul 2007 11:59:42 -0400

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

---

From: Diego B <[email-masked]>
Date: Sun, 29 Jul 2007 23:28:11 +0300

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.
>

---

From: RahulSrivastava 71616 <[email-masked]>
Date: Tue, 31 Jul 2007 00:05:35 +0800

Qos should be in domain of Application.
If AS wants to have the capbility for QOS it can very well parse the SDP and send that to media server.
All this depends on Application.
If application is just meant for few features why to overload it with heavy SDP parsing.(Basic voice call)
On the other hand if features are required let the application do it.
It looks like it should be in Aapplcation design specification.

Can you suggest one use case where the QOS for a UE is different from a QOS of media server? I don't know Diameter at all :)
If its really required we can discuss this but as for now I don't see any use of it.

Rahul 

******************************************************************************************
 This email and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!
 *****************************************************************************************

----- Original Message -----
From: Tom Taylor <[email-masked]>
Date: Friday, July 27, 2007 11:59 pm
Subject: [MEDIACTRL] QOS control: what is in scope?

> architecture defined 
> that the list

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Mon, 30 Jul 2007 11:33:36 -0500

NO

QoS is out of scope for this WG. In any network deployment you address
QoS as a separate topic. You invoke QoS long before you hit the AS.

Cheers,

Martin 

-----Original Message-----
From: RahulSrivastava 71616 [mailto:[email-masked]] 
Sent: Monday, July 30, 2007 12:06 PM
To: Tom Taylor
Cc: [email-masked]
Subject: Re: [MEDIACTRL] QOS control: what is in scope?

Qos should be in domain of Application.
If AS wants to have the capbility for QOS it can very well parse the SDP
and send that to media server.
All this depends on Application.
If application is just meant for few features why to overload it with
heavy SDP parsing.(Basic voice call)
On the other hand if features are required let the application do it.
It looks like it should be in Aapplcation design specification.

Can you suggest one use case where the QOS for a UE is different from a
QOS of media server? I don't know Diameter at all :)
If its really required we can discuss this but as for now I don't see
any use of it.

Rahul 

************************************************************************
******************
 This email and its attachments contain confidential information from
HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure,
reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please
notify the sender by phone or email immediately and delete it!
 
************************************************************************
*****************

---

From: "Adnan Saleem" <[email-masked]>
Date: Mon, 30 Jul 2007 09:37:32 -0700

Same opinion here, as Martin mentioned below.

Adnan  

-----Original Message-----
From: DOLLY, MARTIN C, ATTLABS [mailto:[email-masked]] 
Sent: July 30, 2007 9:34 AM
To: RahulSrivastava 71616; Tom Taylor
Cc: [email-masked]
Subject: RE: [MEDIACTRL] QOS control: what is in scope?

NO

Cheers,

Martin 

-----Original Message-----
From: RahulSrivastava 71616 [mailto:[email-masked]]
Sent: Monday, July 30, 2007 12:06 PM
To: Tom Taylor
Cc: [email-masked]
Subject: Re: [MEDIACTRL] QOS control: what is in scope?

Rahul