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

From: John Rosenberg <[email-masked]>
Date: Mon, 30 Oct 2006 11:42:02 -0600

Dan Wing wrote:

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

I think the justification here is to allow a call controller/session 
manager to exert influence over the endpoints' behavior in choosing 
the DSCP value to use for a bearer stream. For example in the US, 
DISA has some requirements for their Defense Information System 
Network that specify that a call controller must instruct served CPE 
regarding what DSCP value to use in the bearer based on the 
precedence level that the user requests - this involves an 
authentication and authorization to use that level in the call 
controller (a B2BUA).

While it's interesting, and potentially useful, for one EP to tell 
another "Hey, I'm going to use DSCP 41" I think that view of this 
draft misses its point, and that the real power is allowing a call 
controller/session manager to drive the endpoint's behavior. This 
allows for all kinds of good things - like authorization - to come 
into play w.r.t. use of particular DSCP values and the PHBs they imply.

In cases when the bearer streams cross network boundaries, I would 
expect Session Boarder Controllers to rewrite the SDP and modify the 
DSCP attribute as appropriate per policy - similar to how STPs that 
interconnect ISUP networks modify IAMs transmitted between networks.

John Rosenberg
Lucent Technologies

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

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 30 Oct 2006 12:04:06 -0600

Even a better reason then to use the config-framework instead of
mandating
a B2BUA in the middle pretending to be the other end. 

> -----Original Message-----
> From: John Rosenberg [mailto:[email-masked]] 
> Sent: Monday, October 30, 2006 9:42 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [MMUSIC] New ID on conveying a DSCP 
> marking/remarking in an Offer
> 
> Dan Wing wrote:
> 
> 
> >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.
> 
> I think the justification here is to allow a call 
> controller/session manager to exert influence over the 
> endpoints' behavior in choosing the DSCP value to use for a 
> bearer stream. For example in the US, DISA has some 
> requirements for their Defense Information System Network 
> that specify that a call controller must instruct served CPE 
> authentication and authorization to use that level in the 
> call controller (a B2BUA).
> 
> While it's interesting, and potentially useful, for one EP to 
> tell another "Hey, I'm going to use DSCP 41" I think that 
> view of this draft misses its point, and that the real power 
> is allowing a call controller/session manager to drive the 
> endpoint's behavior. This allows for all kinds of good things 
> - like authorization - to come into play w.r.t. use of 
> particular DSCP values and the PHBs they imply.
> 
> In cases when the bearer streams cross network boundaries, I 
> would expect Session Boarder Controllers to rewrite the SDP 
> and modify the DSCP attribute as appropriate per policy - 
> similar to how STPs that interconnect ISUP networks modify 
> IAMs transmitted between networks.
> 
> John Rosenberg
> Lucent Technologies
> 
>

---

From: John Rosenberg <[email-masked]>
Date: Mon, 30 Oct 2006 12:10:21 -0600

I don't think anything is mandating a B2BUA in the middle. In the 
DISA case there *is* a B2BUA in the middle and the requirement is 
that it have a way to tell the endpoint what DSCP value to use. The 
mechanism James is proposing fits the bill in that situation, and 
would also be useful in an IMS network to allow a CSCF or App Server 
to exert control over the DSCP values and thus the Per Hop behaviors 
that they imply.

John

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 30 Oct 2006 15:46:05 -0500

It most certainly is mandating a b2bua in the middle. As folks have 
pointed out, and I concur, it makes more sense for a local network to 
tell its UA what DSCP to use. SIP negotiation is wrong for that, since 
it's between endpoints. Thus, for the mechanism to be useful, it 
requires that:

1. the SIP provider is the same as the access provider,
2. the SIP provider runs a b2bua to modify SIP/SDP signaling

I also see no reason why the DSCP value would be dynamic (i.e., it won't 
change on a call-by-call basis). It thus seems much more appropraite to 
me to use whatever the configuration mechanism is for the phone.

Thanks,
Jonathan R.

John Rosenberg wrote:

> I don't think anything is mandating a B2BUA in the middle. In the DISA 
> case there *is* a B2BUA in the middle and the requirement is that it 
> have a way to tell the endpoint what DSCP value to use. The mechanism 
> James is proposing fits the bill in that situation, and would also be 
> useful in an IMS network to allow a CSCF or App Server to exert control 
> over the DSCP values and thus the Per Hop behaviors that they imply.
> 
> John
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: John Rosenberg <[email-masked]>
Date: Mon, 30 Oct 2006 15:00:18 -0600

Jonathan -

 >me to use whatever the configuration mechanism is for the phone.

In the DISA scenario, it absolutely can change on a call by call 
basis. In DISA's requirements, the bearer DSCP to use is determined 
based on the precedence level requested for the call, which can 
change for each call a user makes. The Local Call Controller serving 
the user's endpoint authenticates and determines whether the 
requested precedence level is authorized for that user. It then must 
instruct the endpoint what DSCP value to use for the bearer stream(s) 
associated with that call.

James' draft allows for exactly the necessary behavior described above.

I also believe that it does not mandate a B2BUA in the middle. If one 
is not there then it's an endpoint to endpoint discussion (not 
negotiation) regarding the bearer DSCP that they intend to use.

John

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 30 Oct 2006 15:14:07 -0600

Well, sure, it can be dynamic based on precedence level.

You could have a static rule that assigns a DSCP codepoint
to different precedence level.

> Sent: Monday, October 30, 2006 1:00 PM
> To: Jonathan Rosenberg
> Cc: Audet, Francois (SC100:3055); [email-masked]; 
> [email-masked]
> Subject: Re: [MMUSIC] New ID on conveying a DSCP 
>  >I also see no reason why the DSCP value would be dynamic 
> (i.e., it won't  >change on a call-by-call basis). It thus 
> seems much more appropraite to  >me to use whatever the 
> configuration mechanism is for the phone.
> 
> In the DISA scenario, it absolutely can change on a call by 
> call basis. In DISA's requirements, the bearer DSCP to use is 
> determined based on the precedence level requested for the 
> call, which can change for each call a user makes. The Local 
> Call Controller serving the user's endpoint authenticates and 
> determines whether the requested precedence level is 
> authorized for that user. It then must instruct the endpoint 
> what DSCP value to use for the bearer stream(s) associated 
> with that call.
> 
> I also believe that it does not mandate a B2BUA in the 
> middle. If one is not there then it's an endpoint to endpoint 
> discussion (not

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Oct 2006 15:13:58 -0800

>  >(i.e., it won't

If you really want to enable such communication without a B2BUA,
tacking on a new SIP header seems better than messing with the SDP.

> negotiation) regarding the bearer DSCP that they intend to use.

If my network authorized me to use 0110, and your network
authorized you to use 1001, and there isn't an SBC(*) between
us, it seems Things Will Break.  I'll send you an invitation
and indicate I am using 0110, and you'll either reject the
session entirely (which is nasty) or you'll ignore the DSCP
attribute and use the authorized DSCP value.  When your 
media packet gets into my network, 1001 might be my 
scavanger class.

(*) It has to be an SBC, not just a B2BUA; the media packets
need to have their DSCP bits changed.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Oct 2006 17:34:23 -0800

> >this functionality.  This seems only germain to each local network
> >and I don't see the value in signaling this in SDP.
> 
> the DSCP value to use for a bearer stream.

But this draft doesn't describe how a call controller or session
manager does that.  Rather, from the SIP perspective, the endpoint
dreams up a DSCP value and, following this specification, declares
that value in its SDP and requires its peer to use the same DSCP
value.  

> For example in the US, 

The flow I'm imagining is this:

                                 Call
                  Alice       Controller       B2BUA
                    |              |             |
 1. offhook-------->|              |             |
 2. dialed digits-->|              |             |
 3.                 |--555-1212--->|             |
 4.                 |<--DSCP=0100--|             |
 5.                 |--INVITE, a=dscp:0100------>|

Where draft-polk-mmusic-dscp-attribute-00.txt is only describing message 5.
Is that about right?

> into play w.r.t. use of particular DSCP values and the PHBs 

As written, the draft only describes the offerer having that privilege to
decide the DSCP value it'll use in its call setup.  The draft doesn't
describe steps (3) and (4) in the above flow.

Now, if we imagine an *incoming* call (that is, a call going towards Alice),
I could see where the B2BUA, in conjunction with the Call Controller, could
decide the DSCP value for the incoming call.  Something like this:

                       Call
        Alice       Controller       B2BUA
          |              |             |
 1.       |              |             |<--INVITE To: Alice
 2.       |              |<-DSCP?------|
 3.       |              |--DSCP=0101->|
 4.       |<-INVITE, a=dscp:0101-------|

In which case the draft, as written, makes sense.

> interconnect ISUP networks modify IAMs transmitted between networks.

Yes, something needs to modify the DSCPs as they cross the network boundary.
SBCs are a heavy way to do that, but we don't have a better mechanism to do
such remarking on a per-flow basis.

-d

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 31 Oct 2006 10:54:56 -0600

I think it would make sense to have the precedence level being conveyed
in SIP, and the DSCP associated with it locally at each end.

Id Alice calls Bob with precendence level X indicated in SIP, then 
both Alice and Bob can use the DSCP coding associated by their
respective
network to the proper precedence level.

That way, you preserve the dynamic feature of the functionality you
need, but
you don't need to negotiate the DSCP value dynamically. Only the
precedence.

> From: Dan Wing [mailto:[email-masked]] 
> Sent: Monday, October 30, 2006 5:34 PM
> To: 'John Rosenberg'; [email-masked]
> controller/session 
> But this draft doesn't describe how a call controller or 
> session manager does that.  Rather, from the SIP perspective, 
> the endpoint dreams up a DSCP value and, following this 
> specification, declares that value in its SDP and requires 
> its peer to use the same DSCP value.  
> 
> > For example in the US,
> precedence 
> > level that the user requests - this involves an authentication and 
> > authorization to use that level in the call controller (a B2BUA).
> 
> As written, the draft only describes the offerer having that 
> privilege to decide the DSCP value it'll use in its call 
> setup.  The draft doesn't describe steps (3) and (4) in the 
> above flow.
> 
> 
> Now, if we imagine an *incoming* call (that is, a call going 
> towards Alice), I could see where the B2BUA, in conjunction 
> with the Call Controller, could decide the DSCP value for the 
> incoming call.  Something like this:
> 
>                        Call
>         Alice       Controller       B2BUA
>           |              |             |
> SBCs are a heavy way to do that, but we don't have a better 
> mechanism to do such remarking on a per-flow basis.
> 
> -d
>

---

From: "Nguyen, An P CIV NCS NC2" <[email-masked]>
Date: Tue, 31 Oct 2006 12:02:43 -0500

Classification:  UNCLASSIFIED 
Caveats: NONE

Just a clarification: Are we talking about a private network in which we
can assign different DSCP codepoints for different precedence level?

An

-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: Monday, October 30, 2006 4:14 PM
To: John Rosenberg; Jonathan Rosenberg
Cc: [email-masked]; [email-masked]
Subject: RE: [MMUSIC] New ID on conveying a DSCP marking/remarking in an
Offer

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 31 Oct 2006 12:52:04 -0500

This sounds like session policies. Session-specific ones in particular 
were developed to address this issue of how ones own SIP provider, if 
they also own the access network, can tell you want kind of media things 
they want you to do.

-Jonathan R.

Francois Audet wrote:

>>>>I agree with Francois -- I need to understand the 
>>
>>justification for 
>>
>>>Network that specify that a call controller must instruct 
>>
>>served CPE 
>>
>>>expect Session Boarder Controllers to rewrite the SDP and 
>>
>>modify the 
>>

---

From: John Rosenberg <[email-masked]>
Date: Tue, 31 Oct 2006 12:58:23 -0600

The DISA example is, in fact, a private network. But there are 
similar applications in the public network (e.g. 911, GETS/ETS) that 
could benefit from having a call controller or app server instruct 
endpoints what DSCP values they should use on a call by call basis.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 31 Oct 2006 13:25:14 -0600

Different networks (private or public: doesn't matter) may use different
DSCP values for the same type of traffic (e.g., voice with precedence
x).

> From: Nguyen, An P CIV NCS NC2 [mailto:[email-masked]] 
> Sent: Tuesday, October 31, 2006 9:03 AM
> To: Audet, Francois (SC100:3055); John Rosenberg; Jonathan Rosenberg
> Cc: [email-masked]; [email-masked]; Nguyen, An P CIV NCS NC2
> marking/remarking in an Offer (UNCLASSIFIED)
> 
> Just a clarification: Are we talking about a private network 
> in which we can assign different DSCP codepoints for 
> different precedence level?
> 
> An
> 
> You could have a static rule that assigns a DSCP codepoint to 
> different precedence level.
> 
> (i.e., it 
> > won't  >change on a call-by-call basis). It thus seems much more 
> > appropraite to  >me to use whatever the configuration 
> mechanism is for 
> > the phone.
> > 
> > based on the precedence level requested for the call, which 
> can change 
> > for each call a user makes. The Local Call Controller serving the 
> > user's endpoint authenticates and determines whether the requested 
> > precedence level is authorized for that user. It then must instruct 
> > the endpoint what DSCP value to use for the bearer stream(s) 
> middle. If one

---

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

>a B2BUA in the middle pretending to be the other end.

Francois, don't take this wrong, but I read your comment as me stating 
there has to be a B2BUA in every network.  I'm only saying there needs to 
be a intermediary that can modify SDP in those nertworks that may want this 
feature.

---

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

>tacking on a new SIP header seems better than messing with the SDP.

How will SIP change the DSCP of a Video stream and not change the DSCP of 
the audio stream within the same Call-ID?

---

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

>that value in its SDP and requires its peer to use the same DSCP

Shown clearly in Figure 1 (page 4), Alice's UA, making the initial offer 
doesn't have this "a=dscp" attribute in her Offer.  The intermediary added 
it.  Thus, the endpoint didn't "dream up" this DSCP value.

As for the rest of your message below - I'm open to you sending text to 
"fix this"... ;-)

---

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

At 03:46 PM 10/30/2006 -0500, Jonathan Rosenberg wrote:
>pointed out, and I concur, it makes more sense for a local network to tell 
>its UA what DSCP to use. SIP negotiation is wrong for that, since it's 
>between endpoints. Thus, for the mechanism to be useful, it requires that:
>
>change on a call-by-call basis).

Say there is a local policy of establishing a reservation between edge 
routers for every call in a network.  The phones know nothing of this 
reservation, or even which reservation protocol is used.  Local policy has 
all calls using a certain DSCP for audio calls (say 46).  But the local 
network also has a policy that if the reservation goes away (for whatever 
reason) the call can stay up, but without the reservation.  These calls now 
need to have a less than Expedited Forwarding class treatment through the 
network.  The mid-call DSCP value has to change from 46 to something else.

This mechanism does this on a per call basis.

>It thus seems much more appropraite to me to use whatever the 

If only set at call set-up, I tend to agree. However, of the DSCP needs to 
be changed, doing this in a consistent way (i.e. using the same mechanism) 
seems to make sense to me.

>>case there *is* a B2BUA in the middle and the requirement is that it have 
>>a way to tell the endpoint what DSCP value to use. The mechanism James is 
>>proposing fits the bill in that situation, and would also be useful in an 
>>IMS network to allow a CSCF or App Server to exert control over the DSCP 
>>values and thus the Per Hop behaviors that they imply.
>>John

---

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

>DSCP values for the same type of traffic (e.g., voice with precedence

yes

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 31 Oct 2006 15:37:54 -0800

> How will SIP change the DSCP of a Video stream and not change 
> the DSCP of the audio stream within the same Call-ID?

Here is a crazy straw-man idea:

  Media-priority: audio=high; video=low

And each endpoint is provisioned to know which DSCP value its supposed to
use for 'high' or 'low'.

Gross?  Yes.  Worse than mandating diddling with SDP in a B2BUA?  Maybe so.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 31 Oct 2006 16:04:44 -0800

> Shown clearly in Figure 1 (page 4), Alice's UA, making the 
> initial offer doesn't have this "a=dscp" attribute in her 
> Offer.  The intermediary added it. 

Thanks.  Sorry I had missed that.

> Thus, the endpoint didn't "dream up" this DSCP value.
>
> As for the rest of your message below - I'm open to you 
> sending text to "fix this"... ;-)

Call the intermediary what it is -- an SBC.

Figure 1 shows a network with only one SBC.  However, Alice's network would
have its own SBC and Bob's network would also have its own SBC.  In such a
situation an SBC would be necessary to modify the DSCP values of the RTP
packets as they cross into Alice's and Bob's networks.

    Alice        Alice-SBC     Bob-SBC         Bob         
      |              |            |             |
      |     Offer    |            |             |          
      |------------->|  Offer     |             |  
      |              |  a=dscp 46 |  Offer      |    
      |              |----------->|  a=dscp 47  |
      |              |            |------------>|
      |              |            |             |
      |              |            |  Answer     |
      |              | Answer     |  a=dscp 47  |
      |  Answer      | a=dscp 47  |<------------|
      |  a=dscp 46   |<-----------|             |
      |<-------------|            |             |
      |              |            |             |
      |=RTP,dscp 46=>|==========RTP,dscp47=====>|
      |<====RTP,dscp46============|<=RTP,dscp47=|
      |              |            |             |   

This will all work with your I-D as written, without changes.  Sorry that I
missed the lack of Alice's UA indicating DSCP in Figure 1.

-d

> privilege to
> towards Alice),

---

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

>Thanks.  Sorry I had missed that.

np

It is more subtle than it should be in the ID

I should show something like

Alice --- INVITE (no DSCP attribute) ---> intermediary ...

>Call the intermediary what it is -- an SBC.

actually I never thought of the intermediary as an SBC, but I guess it could be

>have its own SBC and Bob's network would also have its own SBC.

where there is an SBC, there are likely to be 2, yes

>In such a

The SBC can simply modify the DSCP value of each RTP packet it transmits, 
but not what it receives. The SBC would need to signal or negotiate this 
with the other side.  I am proposing this be done in SDP, and not SIP, 
because SDP gets to the specific media level, whereas SIP doesn't.  In 
other words, Alice and Bob may have more than one stream within a Call-ID, 
but something less than all of the streams need to be modified.  I don't 
believe SIP can do this. SIP would only be equivalent to session level in 
SDP (affecting all streams with a session) here between Alice and Bob.

>       |              |----------->|  a=dscp 47  |

If the intermediaries were SBCs, this is a more complete diagram than 
Figure 1 in the ID.

Should I include such a detailed diagram in the ID?