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

From: Ari Keränen <[email-masked]>
Date: Fri, 18 Oct 2013 17:37:55 +0300

Hi all,

Trying to close the open issue on the pacing of ICE connectivity checks, 
we still need to come up with the "new conservative default value" for 
the minimum pacing time with non-RTP traffic.

When this was discussed at the Orlando meeting, I proposed 100 ms (see 
[1] and [2]) but during the meeting there was a question that why could 
not we make this even smaller (e.g., 20 ms).

If we think about the worst case scenario with maximum length username 
fragment (256 bytes), that results in maximum size ICE connectivity 
check packets of about 330 bytes. Add a few extensions, rounding it up 
to 350 bytes, we're still at 35 ms "safe" pacing interval if we follow 
the rationale proposed by Cullen in [1] (i.e., similar bandwidth 
requirement as with G.711).

So, to be "conservative enough", how about 50 ms RECOMMENDED pacing 
value if there's no better knowledge of the network? And if there is, 
scale accordingly, but not below 20ms.

Cheers,
Ari

[1] http://www.ietf.org/mail-archive/web/mmusic/current/msg10448.html
[2] 
http://www.ietf.org/proceedings/86/minutes/minutes-86-mmusic#_Interactive_Connectivity_Establishment

---

From: Emil Ivov <[email-masked]>
Date: Fri, 18 Oct 2013 09:44:31 -0500

It might be worth reminding exactly what these 50ms would be
protecting us against, and why is it that we don't need to be
protected against it in the case of RTP where 20ms is accepted as a
fine default value.

Emil

--sent from my mobile

On Fri, Oct 18, 2013 at 9:37 AM, Ari Keränen <[email-masked]> wrote:
> Hi all,
>
> Trying to close the open issue on the pacing of ICE connectivity checks, we
> still need to come up with the "new conservative default value" for the
> minimum pacing time with non-RTP traffic.
>
> When this was discussed at the Orlando meeting, I proposed 100 ms (see [1]
> and [2]) but during the meeting there was a question that why could not we
> make this even smaller (e.g., 20 ms).
>
> fragment (256 bytes), that results in maximum size ICE connectivity check
> packets of about 330 bytes. Add a few extensions, rounding it up to 350
> bytes, we're still at 35 ms "safe" pacing interval if we follow the
> rationale proposed by Cullen in [1] (i.e., similar bandwidth requirement as
> with G.711).
>
> So, to be "conservative enough", how about 50 ms RECOMMENDED pacing value if
> there's no better knowledge of the network? And if there is, scale
> accordingly, but not below 20ms.
>
>
> Cheers,
> Ari
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
Emil Ivov, Ph.D.                       67000 Strasbourg,
Project Lead                           France
Jitsi
[email-masked]                        PHONE: +33.1.77.62.43.30
https://jitsi.org                       FAX:   +33.1.77.62.47.31

---

From: Martin Thomson <[email-masked]>
Date: Fri, 18 Oct 2013 09:44:38 -0700

On 18 October 2013 07:37, Ari Keränen <[email-masked]> wrote:
> So, to be "conservative enough", how about 50 ms RECOMMENDED pacing value if there's no better knowledge of the network? And if there is, scale accordingly, but not below 20ms.

I see no reason not to make this 50ms.  20ms might cross the line, but
I'll let people argue about what is safe below that.  I have done some
calculations on this and even at 20ms, it's not out of proportion.
(I'll send a pointer out when I submit the draft later today).

A good reason not to have a larger pacing timer is the effect that it
has on RTO.  For some configurations, the standard formulae lead to
ICE taking far too long to complete.

--Martin

---

From: Adam Roach <[email-masked]>
Date: Fri, 18 Oct 2013 12:30:51 -0500

On 10/18/13 09:44, Emil Ivov wrote:
> protecting us against

They're protecting us against RTP arriving at a rate of 20ms per packet.

> and why is it that we don't need to be

Well, it's not. This is exactly why we ended up requiring ICE: it 
ensures explicit consent before you start blowing media at someone.

See also http://www.ietf.org/mail-archive/web/mmusic/current/msg04589.html

/a

---

From: Justin Uberti <[email-masked]>
Date: Fri, 18 Oct 2013 11:34:49 -0700

FWIW, we are now doing trials to understand what is the absolute lower
bound for ICE checks on today's internet (i.e. what is the minimum time to
allow for a NAT to create a new UDP binding).

On Fri, Oct 18, 2013 at 10:30 AM, Adam Roach <[email-masked]> wrote:

> Well, it's not. This is exactly why we ended up requiring ICE: it ensures
> explicit consent before you start blowing media at someone.
>

---

From: Emil Ivov <[email-masked]>
Date: Sat, 19 Oct 2013 14:33:24 +0200

Hey Adam,

> 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!?

Emil

-- 
https://jitsi.org

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Sat, 19 Oct 2013 13:53:12 +0000

On Oct 19, 2013, at 05:33 AM, Emil Ivov <[email-masked]> wrote:

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

.-.
Pål-Erik

---

From: Ari Keränen <[email-masked]>
Date: Mon, 21 Oct 2013 15:01:04 +0300

On 10/19/13 4:53 PM, Pal Martinsen (palmarti) wrote:
>> 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!?
>

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

---

From: Ari Keränen <[email-masked]>
Date: Mon, 21 Oct 2013 15:02:44 +0300

> (I'll send a pointer out when I submit the draft later today).

Sounds interesting, looking forward to the pointer.

> ICE taking far too long to complete.

Very true.

Cheers,
Ari

---

From: Ari Keränen <[email-masked]>
Date: Mon, 21 Oct 2013 15:04:14 +0300

On 10/18/13 9:34 PM, Justin Uberti wrote:
> bound for ICE checks on today's internet (i.e. what is the minimum time
> to allow for a NAT to create a new UDP binding).

This sounds very interesting and something we should take into account. 
I hope you can share your results on this soon.

Cheers,
Ari

> On Fri, Oct 18, 2013 at 10:30 AM, Adam Roach <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     See also
>     http://www.ietf.org/mail-archive/web/mmusic/current/msg04589.html
>
>     /a
>
>     [email-masked] <mailto:[email-masked]>

---

From: Emil Ivov <[email-masked]>
Date: Mon, 21 Oct 2013 21:12:59 +0200

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" <[email-masked]> wrote:

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

---

From: Ari Keränen <[email-masked]>
Date: Mon, 21 Oct 2013 23:11:51 +0000

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.

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

---

From: Emil Ivov <[email-masked]>
Date: Tue, 22 Oct 2013 01:37:19 +0200

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

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

---

From: Ari Keränen <[email-masked]>
Date: Tue, 22 Oct 2013 08:01:21 +0000

> given that we've already blessed it as safe and harmless and NAT

20 ms pacing has been blessed NAT friendly but not necessarily safe and harmless for the rest of the network. 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. 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?

Cheers,
Ari

---

From: Emil Ivov <[email-masked]>
Date: Tue, 22 Oct 2013 17:20:36 +0200

Hey Ari,

On 22.10.13, 10:01, Ari Keränen 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.

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

> 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'd also be happy if experimentation shows that the 20ms value needs to 
be changed to something else.

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" <[email-masked]>
>>>> wrote: On 10/19/13 4:53 PM, Pal Martinsen (palmarti) wrote: On
>>>> Oct 19, 2013, at 05:33 AM, Emil Ivov <[email-masked]> 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
>>>>
>>>> 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 [email-masked]
>> PHONE: +33.1.77.62.43.30 https://jitsi.org
>> FAX:   +33.1.77.62.47.31
>
>

-- 
https://jitsi.org

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Tue, 22 Oct 2013 19:55:52 +0000

On Oct 22, 2013, at 17:20 PM, Emil Ivov <[email-masked]> wrote:

> 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.
> 
>> Hence
> 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'd also be happy if experimentation shows that the 20ms value needs to be changed to something else.
> 
I second that.

In the scenario where we have different types of medialines in the same SDP, for instance RTP and BFCP i think it makes sense to use the same value. 

If you set up a separate non RTP session it might be worthwhile choosing a more conservative value. 

.-.
Pål-Erik

---

From: Ari Keränen <[email-masked]>
Date: Wed, 23 Oct 2013 13:31:03 +0000

Hi Emil,

>   that.  This is why Ta has a lower bound of 20 ms.

Yes, with NAT binding creation.

> 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"?

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

> 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

---

From: Emil Ivov <[email-masked]>
Date: Wed, 23 Oct 2013 15:44:56 +0200

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

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

---

From: Ari Keränen <[email-masked]>
Date: Wed, 23 Oct 2013 20:33:37 +0300

On 10/23/13 4:44 PM, Emil Ivov wrote:
> of prayers per day.

If that's what it takes.. ;)

> Either you know what your traffic is and you

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.

> 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