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

On 2/14/13 5:20 PM, Dan Wing wrote:
>> -----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.

Interesting point. Does anyone know what kind of pacing was actually 
used when these failures were observed?

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

Yes, definitely. So we shouldn't go below 20ms with non-RTP either. 
Perhaps need to add some more justification/warning text about this too.

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

FYI, I forwarded the original mail to the Transport ADs too.

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
>