Subject: [Ice] Some thoughts on Ta value for 5245bis

From: Peter Thatcher <[email-masked]>
Date: Thu, 17 Mar 2016 22:16:00 -0700

(As an individual, not a chair)

The big question for a long time for 5245bis has been: what's the Ta value?

Here are some of my thoughts/proposals on what we can do:

1.  Since the value can be negotiated, we're really defining two different
things: a minimum and a default.

2.  For both minimum and default, let's drop the distinction between RTP
and non-RTP and have the values for both.  Many endpoints have, for a long
time, been ignoring the formula/value in 5245 anyway (all the WebRTC data
channels, for example, I believe).

3.  I propose a minimum of 5ms.   For two reasons:  first, there's really
no reason to make it less than 5ms, since even with 100 candidate pairs,
one could check all of them in less than 500ms, meaning going lower than
5ms doesn't help much (and typically you have much fewer than 100 candidate
pairs.  Second, from the measurements that we have, it appears that it's
safe to go down to 5ms, except for concerns over bandwidth.

4.  I propose a default of 50ms.  It's a decently low value that we know is
safe because there are lots of endpoints that are using a value at least
that low and it seems to be working well.  There isn't any reason to make
it bigger, and there isn't a strong reason (yes) to make it lower.  For
typical situations with say, 10-20 candidate pairs, that's still only
500-1000ms to do a full round of checks.  If that's still not fast enough,
endpoints can alway negotiate lower.  And, we can update the value later if
future measurements indicate it's safe.

5.  I propose that we continue doing measurements, and if we find that a
default lower than 50ms is safe, then publish a new draft saying "the new
default is Xms".  But 5245bis is still valuable even with a value of "only"
50ms.

As for measurements, in Chrome we plan to roll out lower Ta values and see
the impact they have (so far it's good, but we'd to make the STUN messages
smaller before rolling out more widely).  We've also provided a command
line tool that allows anyone to test even a Ta == 1 and 350 bindings (or
more!) and see what percentage succeed (tool source here:
https://chromium.googlesource.com/external/webrtc/+/master/webrtc/p2p/stunprober/;
we can also provide some binaries if that's more convenient).

6.  I think a rule bandwidth-limiting rule such as "should not send more
than 40kbps" might make sense, but obviously implementations would be free
to to above that if they have some reasonable expectation that the actual
bandwidth available is higher.

7.  I propose we investigate how to reduce the size of initial ICE checks
to allow more checks without worrying about bandwidth limitations.  For
example, perhaps by making 4-byte ufrags recommended, or by sending many
fewer STUN attributes in the initial ICE check and then only sending the
large attributes later once a candidate pair is know to work.

OK, that's probably enough about Ta for one email :).