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

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Ari Keränen
> Sent: Thursday, February 14, 2013 5:49 AM
> To: mmusic
> Subject: [MMUSIC] Updating the pacing of ICE connectivity checks
> 
> 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.

That would explain failures claimed to justify the desire for running
over one port.  

The 20ms threshold for the initial connectivity checks is because some 
NATs could not create new mappings quickly.  This problems appears to
persist today, considering that both Chrome and Windows 8 limit their 
number of outstanding DNS queries in an apparent attempt to work around
that very same NAT UDP mapping behavior.

If trying to create NAT mappings with 0ms pacing, it will certainly 
cause NAT mapping failures and force retries.

> 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)?

A good question for the transport area, which is the origination of the
suggestion to send ICE connectivity checks paced to not exceed the 
bandwidth of the subsequent media.  Perhaps the arguments that TCP 
IW=10 is not harmful could be brought to the party.

-d

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