Subject: [MMUSIC] New ID on conveying a DSCP marking/remarking in an Offer

From: "James M. Polk" <[email-masked]>
Date: Thu, 26 Oct 2006 17:51:39 -0500

MMUSIC WG

I've written a new individual ID on how an offer can carry a DSCP marking 
for a session, to be used upon initial offer or an offer within an 
established session that needs remarking of the DSCP used for the RTP 
stream.  This link to the ID is here:

http://www.ietf.org/internet-drafts/draft-polk-mmusic-dscp-attribute-00.txt

I would appreciate comments

Thanks
James

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

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 26 Oct 2006 19:34:28 -0500

Hi James,

I'm not sure I see the rationale for negotiating DSCP in SDP.

In environments that span networks, different numerical values could be
used
(and the packets could be re-mapped accordingly at the border of these
networks).

It seems to me to be more a matter of config-framework.

And within a single network, both ends would get the same values
from the config-framework. 

Within different networks, they'd get different values (which is the
desired outcome).

Also seems to me that this idea has the whole that it may result in the
answered being inadvertently tricked into using the wrong DSCP (e.g, 
a more expensive one, a lesser-quality one, etc.).

I'd like to understand why you believe that handling DSCP through
configuration (e.g, config-framework) would not be more appropriate.

> -----Original Message-----
> From: James M. Polk [mailto:[email-masked]] 
> Sent: Thursday, October 26, 2006 3:52 PM
> To: [email-masked]
> Subject: [MMUSIC] New ID on conveying a DSCP 
> marking/remarking in an Offer
> 
> MMUSIC WG
> 
> I've written a new individual ID on how an offer can carry a 
> DSCP marking for a session, to be used upon initial offer or 
> an offer within an established session that needs remarking 
> of the DSCP used for the RTP stream.  This link to the ID is here:
>

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 26 Oct 2006 17:57:39 -0700

3.  Offer/Answer Behavior

   An offer/answer exchange using the 'dscp' attribute allows endpoints 
   provide media packets the desired DSCP through a routed 
   infrastructure.  Including the 'dscp' in an offer or answer 
   attribute is not a negotiation.

"declarative" would be a good description of what you're doing with the
a=dscp attribute.

   3.2 Answerer Behavior

   An answerer MUST adhere to the 'dscp' attribute in the offer if the 
   offer in whole is acceptable to the answerer.  The 'dscp' attribute 
   of each media stream MUST be used by the answerer to set the DSCP 
   field of the respective media stream packets from the answerer.  An 
   answerer MUST NOT delete or change the 'dscp' attribute from offer 
   to answer (analogous to copying from offer to answer), and SHOULD 
   NOT ignore the 'dscp' attribute of the offer when setting the 
   respective media stream packets towards the offer

What if my network wants or needs me to use, say, DSCP 20, and yours wants
or needs you to use DSCP 46?  Are you assuming that an SBC (or other device
that mucks with both SDP and IP packets) will interwork those at our
respective network edges so that the SDP and the RTP packets have the
appropriate a=dscp values and IP DSCP values, as seen by each of us?

I agree with Francois -- I need to understand the justification for this
functionality.  This seems only germain to each local network and I don't
see the value in signaling this in SDP.

-d 

> DSCP marking

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 31 Oct 2006 16:03:59 -0600

First of all, sorry for not responding earlier

comments in-line

>(and the packets could be re-mapped accordingly at the border of these

and that leaves all the control at the border, and zero in the middle of 
the network (i.e. no server can change a value). This proposal allows for a 
server that can change the SDP of an offer/answer to inform the offerer or 
answerer what DSCP to use per media session (different for each media too)

>from the config-framework.

Will all UAs understand to use a specific DSCP for their RTP, or is this 
more hopeful?

This mechanism provides a way for domains that have controlling 
intermediaries to include what DSCP to use for voice, and what to use for 
video.

If network conditions change (for whatever reason) during a (voice or 
video) call, each media can be changed to a new DSCP.

>Within different networks, they'd get different values (which is the

And when conditions change, say when a resrevation is lost, but local 
policy is to not terminate the call - but the DSCP has to change, this 
mechanism does that

>a more expensive one, a lesser-quality one, etc.).

OK, but the only entities that should be mucking with the DSCP are 
intermediary SIP servers, which have to be inplicitly trusted anyway, I'm 
not sure how this has less trust than other aspects of a offer/answer exchange

>configuration (e.g, config-framework) would not be more appropriate.

One mechanism for setting and changing DSCPs per media stream.

An important requirement we have is on the changing of the DSCP of a 
specific media flow of an established session/call. How to isolate down to 
a specific flow needs this granularity IMO.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 31 Oct 2006 16:21:27 -0600

>see the value in signaling this in SDP.

Signaling this in SIP cannot get to the media level. In other words, lets 
say only the video stream of a multi-stream flow between two endpoints 
needs adjusting mid-stream. SIP cannot pick out the video only, and not 
affect the audio stream, I do not believe.