From: =?iso-8859-1?Q?Ari_Ker=E4nen?= <ari.keranen@ericsson.com>
To: Emil Ivov <emcho@jitsi.org>
Thread-Topic: [MMUSIC] ICE-bis: pacing of ICE connectivity checks
Thread-Index: Ac7MD6NfvGuI93GmRnipYmfd4J6njP//4E2AgAAueYCAAT86AIAAFkwAgAM3nwCAAEZjgIAAQsKA
Date: Mon, 21 Oct 2013 23:11:51 +0000
Message-ID: <861759C7815040489720E3CC184F51DD1C477C0F@ESESSMB205.ericsson.se>
References: <526147C3.9040204@ericsson.com>
 <CAPvvaa+8osKGTNCS6RJywS9Bmf+RdbnChN=XqA9d+gLnBBAGow@mail.gmail.com>
 <5261704B.9090307@nostrum.com> <52627C14.8080309@jitsi.org>
 <1373AC9C23D80E44856F5CF6F883ACAB115574BB@xmb-rcd-x06.cisco.com>
 <52651780.60108@ericsson.com>
 <CAPvvaaL2ToQ1dxkYJbYHrLtQCFsYH7r2C=E1eYHD8KhzHsJXSA@mail.gmail.com>
In-Reply-To: <CAPvvaaL2ToQ1dxkYJbYHrLtQCFsYH7r2C=E1eYHD8KhzHsJXSA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <207A714EE01D6C4F8B7E942EA8ECEC08@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] ICE-bis: pacing of ICE connectivity checks
Precedence: list

On Oct 21, 2013, at 10:12 PM, Emil Ivov wrote:

> I still don't get it. Why would we recommend values for different applica=
tions? We already tell applications to pace checks in accordance with expec=
ted traffic, which they supposedly can gauge better than the text in our RF=
C.
>=20
> 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 t=
here is a formula, for other traffic you're on your own (come up with formu=
la, 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.
>=20
> --sent from my mobile
>=20
> On 21 Oct 2013 14:01, "Ari Ker=E4nen" <ari.keranen@ericsson.com> wrote:
> On 10/19/13 4:53 PM, Pal Martinsen (palmarti) wrote:
> On Oct 19, 2013, at 05:33 AM, Emil Ivov <emcho@jitsi.org> 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
>=20
> They're protecting us against RTP arriving at a rate of 20ms per
> packet.
>=20
> 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.
>=20
> 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.
>=20
> 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!?
>=20
> I agree. No need to add more complexity. ICE should be ignorant of
> what traffic goes through the pinholes.
>=20
> 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 informati=
on" (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 recommen=
ded value. If you would have something similar with non-RTP traffic, you co=
uld use that.
>=20
> But then for both endpoints agreeing on the value in order to have connec=
tivity checks happening simultaneously for the same pairs, we'd probably ne=
ed to do some negotiation, similar to what was done with ICE on HIP (http:/=
/tools.ietf.org/html/rfc5770#section-4.4).
>=20
>=20
> Cheers,
> Ari