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

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

On 10/23/13 4:44 PM, Emil Ivov wrote:
> 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.

If that's what it takes.. ;)

> 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).

So if you don't know about your traffic, you would opt to go for the 
most aggressive, least conservative value? I would find it natural to be 
more conservative in that case, play it safe.

> 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.

Yes, explaining the rationale definitely makes sense. However, what is 
"safe", I'm assuming, has to do with generated traffic volume, i.e., 
bandwidth consumption, either for you, your peer, or perhaps for a DoS 
attack target.


Cheers,
Ari