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

Any idea why there had to be different pacing for RTP and non-RTP flows
in the first place?

Emil

On 14.02.13, 16:32, Ari Keränen wrote:
> 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
>>
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> 

-- 
https://jitsi.org