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

[Emil Ivov <[e-mail]>]

On Wed, Oct 23, 2013 at 3:31 PM, Ari Keränen <[e-mail]> wrote:
> Hi Emil,
>
> On Oct 22, 2013, at 6:20 PM, Emil Ivov wrote:
>> On 22.10.13, 10:01, Ari Keränen wrote:
>>> On Oct 22, 2013, at 2:37 AM, Emil Ivov wrote:
>>>> 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?
>>>>
>>>
>>> 20 ms pacing has been blessed NAT friendly but not necessarily safe
>>> and harmless for the rest of the network.
>>
>> Apparently we are happy to take the chance (5245):
>>
>>   Experiments have shown
>>   that once every 20 ms is well supported, but not much lower than
>>   that.  This is why Ta has a lower bound of 20 ms.
>
> Yes, with NAT binding creation.
>
>>> Also, if you start sending
>>> connectivity checks faster than your uplink can handle, you'll end up
>>> with false negatives due to dropped connectivity check packets.
>>
>> Sure, but a second bound of 50ms does not address this. Not more than 20ms or 500ms. You can always be on a link that will be saturated.
>>
>
> Of course if the link is already fully saturated there's not much you can do (except detect that using it is a bad idea). But the chances of that happening on a non-saturated link are naturally getting lower and lower the longer pacing you have. With 500 ms pacing there aren't many real-world links (unless they're saturated) that could not handle it. Then the question is if 50 ms is "conservative enough"?
>
>>> Hence
>>> I do see value in being a bit conservative if you don't know better.
>>
>>> But would you like to see only a single value, 20 ms, which should be
>>> used always for pacing and no other recommended values whatsoever?
>>
>> Yes. If we could say, "go at a pace that emulates that of the ensuing streams, but never go below 20ms", I'd be happy.
>
> I agree, that's what we should say ("come up with formula or whatever for your non-RTP traffic to emulate the ensuing streams"). It's just for the cases where you don't have any good information on the ensuing streams when you'd need this second, more conservative, value to fall back to.

Come on :). This sounds like trying to recommend a reasonable number
of prayers per day. Either you know what your traffic is and you
emulate it, or you don't and in that case you just have to stay above
20 ms (or our potential new boundary).

Note that "knowing what your traffic is" is not limited to knowing its
exact bandwidth. You could also just know that it is real-time or not,
involving user interaction or not.  In all of these cases you are free
to choose 50, 100, 500ms depending on your needs. We can certainly
explain that rationale. This will be helpful. We could maybe even
place an upper bound above which ICE becomes dysfunctional (just a
thought, not saying it's necessary)  but just slapping an arbitrary
number is not helping anyone.

Emil

>
>> I'd also be happy if experimentation shows that the 20ms value needs to be changed to something else.
>
> Me too. Let's see what Justin's experiments tell us about this.
>
>
> 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]