Re: [MMUSIC] Updating the pacing of ICE connectivity checks

[Ari Keränen <[e-mail]>]

Hi,

Playing around with the numbers: the connectivity check messages are 
(depending on usernames) about 100 bytes each and bandwidth requirement 
for G.711 is about 80 Kbps. For connectivity checks that would translate 
to roughly one check every 10ms. So, assuming G.711 capable network, one 
every 20 ms should be somewhat safe also from bandwidth point of view.

For total port usage, we have already the 100 candidates max RECOMMENDED 
value (http://tools.ietf.org/html/rfc5245#section-5.7.3).

And NAT timing, I think 20ms is quite "fast enough" (50 candidate pairs 
started during first seconds) for a lower bound.

So, along these lines, I'd propose the following for non-RTP traffic:

- MUST NOT set Ta lower than 20ms.
- RECOMMENDED 100 ms if no better information is available.
(this would be the new conservative guess)
- MAY use external information if such is available (e.g., RTP-like 
formula for bandwidth) to set lower Ta than the recommended.

Then, both agents need to agree on the pacing for the checks to go 
forward in sync. For this purpose, they should indicate in the 
offer/answer what they are ready to use as the Ta and the highest of the 
two would be used.


Cheers,
Ari
(as individual)

On 2/21/13 10:25 PM, Cullen Jennings (fluffy) wrote:
>
> This is a hard problem to figure out but glad it is being tackled as
> the current draft was fiction created to get it approved more.
>
> I'd be tempted to think of their being a few different things to
> conserve or constraints we need to not exceed
>
> 1) nat timing
>
> 2) total ports in usage on the NAT
>
> 3) bandwidth usage that is not congestion controlled
>
> For 1) I'm not seeing any reasons to move off the 20 ms lower bound -
> but if someone has empirical data that would be nice as the empirical
> data we are basing this on is old.
>
> For 2) some Carrier Grade Nats (CGNs) are restricting a given client
> to something like 1000 ports. There may be other limits too. It might
> be worth setting up ICE so that a given ICE client never used more
> than 100 ports at a time. I think this is a new type of constraint
> that is not a big deal today but may be a bigger deal in the future
> and we should consider it in an ICE bis.
>
> For 3) Its very hard to come up with something that is fast enough
> that the media guys like it and slow enough the transport folks are
> sure it is safe. My strawman proposal would be use more more
> bandwidth than G.711 with 20 ms packets as we have been doing that
> all over the place - without congestion control  - and the internet
> has not melted down.
>
>
>
>
> On Feb 14, 2013, at 6:49 AM, Ari Keränen <[e-mail]>
> wrote:
>
>> Hi all,
>>
>> Updating the pacing parameter, Ta, of ICE for non-RTP traffic (for
>> background, see [1] and [2]), as discussed at the Atlanta meeting,
>> will be one of the important changes in the new version of ICE.
>>
>> Currently the RFC5245 says (for non-RTP traffic) "Ta SHOULD be
>> configurable, SHOULD have a default of 500 ms, and MUST NOT be
>> configurable to be less than 500 ms."
>>
>> This results in very slow pace of starting connectivity checks if
>> ICE is used with non-RTP traffic. With RTP, the Ta is calculated
>> based on the expected bandwidth used by the RTP stream and can be
>> down to 20 ms. Therefore, many current implementations apparently
>> ignore the "MUST NOT" above and set Ta to something lower.
>>
>> The quite conservative value of 500 ms was originally chosen
>> because of the fear of congesting the links with the connectivity
>> check messages. This is obviously still a valid concern, but would
>> suggesting something lower still make sense? How low would it be
>> reasonably safe to go? What is currently used in practice? Can we
>> come up with a formula similar to RTP (perhaps based on expected
>> bandwidth usage)?
>>
>>
>> Cheers, Ari
>>
>> [1] http://tools.ietf.org/html/rfc5245#appendix-B.1 [2]
>> http://tools.ietf.org/html/rfc5245#section-16.2
>> _______________________________________________ mmusic mailing
>> list [e-mail] https://www.ietf.org/mailman/listinfo/mmusic
>