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

[Emil Ivov <[e-mail]>]

I still don't get it. Why would we recommend values for different
applications? We already tell applications to pace checks in accordance
with expected traffic, which they supposedly can gauge better than the text
in our RFC.

A minimum value does make sense because it would basically say: "don't go
below this value or you might brake the network or otherwise cause harm".
That's actually useful advice.

Now, having two such values starts being weird again, unless we have data
that shoes that networks break differently depending on the UDP payload or
port number or whatever.

--sent from my mobile
On 21 Oct 2013 14:01, "Ari Keränen" <[e-mail]> wrote:

> 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<http://tools.ietf.org/html/rfc5770#section-4.4>
> ).
>
>
> Cheers,
> Ari
>