Subject: [MMUSIC] ICE, TURN, and QoS interactions

From: "Kevin Johns" <[email-masked]>
Date: Fri, 7 Sep 2007 13:26:24 -0600

While looking at ICE, TURN, and QoS interactions I am struggling with a
scenario that I would like to see if others have any thoughts on.
 
The driver for this is a desire to ensure necessary overhead for STUN
Data/Send Indications are accounted for in QoS allocations prior to an
active destination being set by the UA.
 
ICE does not appear to provide any guidance on when the UA should set
the active destination. Section 12.1.1 of ICE talks about interactions
with SIP and requires that no media be sent till a valid candidate for
each component has entered the valid list. If the valid candidate is a
relayed candidate and media begins to flow, should the UA first set the
active destination or send the media wrapped in a STUN Send Indication
and only set the active destination at some later point in the call
flow? I would think you want to set the active destination as soon as
possible to avoid the extra overhead, but was unsure what the
implications of such an approach might be. If the expectation is to
always set the active destination prior to sending media, then the QoS
calculations would not need to account for any additional overhead.
 
Is there a case where media would begin flowing but the UA would be
unable to set the active destination?
 
Thanks
Kevin Johns
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 10 Sep 2007 11:28:06 +0300

> unable to set the active destination?

If it keeps changing its "primary" peer.

Otherwise, you mostly have send/data indications while forking.

-- 
Rémi Denis-Courmont
Software engineer

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 10 Sep 2007 14:32:21 -0400

Really forking is the main case, in fact.

So, the guidance I think is that an implementation would set active 
destination immediately (i.e., prior to the first media packet) when ICE 
completes if it is having only one peer. If there are more than one, it 
sets active destination for one of them and then ideally allocates a 
second turn address and does a reinvite with an ICE restart on the other 
peer, so that you can then set active destination on that one too.

Nothing in ICE says to do this, and for purposes of interop it doesn't 
need to. The client can implement anything it likes. Its probably not a 
bad idea to clarify this in the forking section.

In the Packetcable case is more troubling since you need to know whether 
this behavior is followed or not in order to compute the QoS parameters 
for the CMTS. It may be that packetcable specs need to mandate this 
behavior.

-Jonathan R.

-- 
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: "Kevin Johns" <[email-masked]>
Date: Mon, 10 Sep 2007 16:53:39 -0600

Thanks for the feedback. This does help. 

As for clarifying text, if possible a bit of guidance may be useful. However, it would seem that if a client did not do as you suggest, it would be in potential bandwidth violation and may have packets dropped by the TURN server...

Kevin 

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]] 
Sent: Monday, September 10, 2007 12:32 PM
To: Rémi Denis-Courmont
Cc: [email-masked]
Subject: Re: [MMUSIC] ICE, TURN, and QoS interactions

So, the guidance I think is that an implementation would set active destination immediately (i.e., prior to the first media packet) when ICE completes if it is having only one peer. If there are more than one, it sets active destination for one of them and then ideally allocates a second turn address and does a reinvite with an ICE restart on the other peer, so that you can then set active destination on that one too.

Nothing in ICE says to do this, and for purposes of interop it doesn't need to. The client can implement anything it likes. Its probably not a bad idea to clarify this in the forking section.

In the Packetcable case is more troubling since you need to know whether this behavior is followed or not in order to compute the QoS parameters for the CMTS. It may be that packetcable specs need to mandate this behavior.

-Jonathan R.

Rémi Denis-Courmont wrote:
>> While looking at ICE, TURN, and QoS interactions I am struggling with 
>> a scenario that I would like to see if others have any thoughts on.
>>
>> Data/Send Indications are accounted for in QoS allocations prior to 
>> an active destination being set by the UA.
>>
>> the active destination. Section 12.1.1 of ICE talks about 
>> interactions with SIP and requires that no media be sent till a valid 
>> candidate for each component has entered the valid list. If the valid 
>> candidate is a relayed candidate and media begins to flow, should the 
>> UA first set the active destination or send the media wrapped in a 
>> STUN Send Indication and only set the active destination at some 
>> later point in the call flow? I would think you want to set the 
>> active destination as soon as possible to avoid the extra overhead, 
>> but was unsure what the implications of such an approach might be. If 
>> the expectation is to always set the active destination prior to 
>> sending media, then the QoS calculations would not need to account for any additional overhead.
>>