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

[Emil Ivov <[e-mail]>]

On Tue, Oct 22, 2013 at 1:11 AM, Ari Keränen <[e-mail]> wrote:
>
> On Oct 21, 2013, at 10:12 PM, Emil Ivov wrote:
>
>> 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.
>
> Exactly. We're not proposing (different) values for different application. The proposal is to pace checks according to the expected traffic. For RTP there is a formula, for other traffic you're on your own (come up with formula, or what ever). The "second" value is only for the cases where you don't know better and should use something conservative.

If you don't know better why wouldn't you just use RTP's 20 ms pacing
given that we've already blessed it as safe and harmless and NAT
friendly?

Emil



>
>
> Cheers,
> Ari
>
>> 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)
>>
>>
>> Cheers,
>> Ari
>



-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
[e-mail]                        PHONE: [phone]
https://jitsi.org                       FAX:   [phone]