Re: [MMUSIC] ICE-bis: pacing of ICE connectivity checks

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

On 10/19/13 4:53 PM, Pal Martinsen (palmarti) wrote:
> On Oct 19, 2013, at 05:33 AM, Emil Ivov <[e-mail]> wrote:
>> On 18.10.13, 19:30, Adam Roach wrote:
>>> On 10/18/13 09:44, Emil Ivov wrote:
>>>> It might be worth reminding exactly what these 50ms would be
>>>> protecting us against
>>>
>>> They're protecting us against RTP arriving at a rate of 20ms per
>>> packet.
>>
>> That would indeed be one of the reasons to pace checks (in addition
>> to fragile NAT boxes IIRC), however in either case, I fail to
>> realise why we need a different pacing strategy for non-RTP. This
>> is what I was asking about.
>>
>> Connectivity check hammers can still resort to RTP if the pacing
>> timer is their only problem and I don't see why shaky NATs would
>> tolerate a 20ms rate for RTP but only a 50ms for anything else.
>>
>> This entire separation sounds quite arbitrary right now. I see why
>> we would pick a value that we consider somewhat safe and secure but
>> I don't understand why we would need two!?
>
> I agree. No need to add more complexity. ICE should be ignorant of
> what traffic goes through the pinholes.

The idea would be to have one recommended value (or set of) for all 
kinds of traffic but with RTP you would have this "additional piece of 
information" (due to the knowledge of your traffic pattern and the 
formula to relate that to pacing) that would allow you to go below the 
conservative recommended value. If you would have something similar with 
non-RTP traffic, you could use that.

But then for both endpoints agreeing on the value in order to have 
connectivity checks happening simultaneously for the same pairs, we'd 
probably need to do some negotiation, similar to what was done with ICE 
on HIP (http://tools.ietf.org/html/rfc5770#section-4.4)


Cheers,
Ari