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

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 <ari.keranen@ericsson.com> 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
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic