Subject: [Ice] Continue discussion of global pacing based on feedback from "transport guys"

From: Peter Thatcher <[email-masked]>
Date: Wed, 14 Sep 2016 07:40:32 -0700

At the WG meeting in Berlin, we agreed to take our plan for global pacing
to the "transport guys" and see what they say.  They responded with a
design different than the one we had come up with (a bitrate limit).
Instead, they proposed this:

1.  A maximum number of outstanding request packets, call it MaxPackets
which SHOULD be 10.

2.  A timeout for request packets, call it handshake timeout or HTO which
SHOULD be 2*RTT if the RTT is known and 500ms otherwise.

3.  A global pacing rate of 5ms (like a global Ta).

If all packets are dropped and the RTT is not known, then 1+2 are
effectively 20 packets per second, well below what you would get with the
bitrate limits we were asking for.  However, they feel that these should be
SHOULD values, not MUST values, and allow implementations to choose lower
values of HTO and higher values of MaxPackets.

So, the question for the WG: Do we find the MaxPackets+HTO+pacing an
appropriate solution for a global limit?   If so, we can begin writing text
for it.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 14 Sep 2016 08:56:54 -0700

On Sep 14, 2016, at 7:40 AM, Peter Thatcher <[email-masked]> wrote:
> 
> 2.  A timeout for request packets, call it handshake timeout or HTO which SHOULD be 2*RTT if the RTT is known and 500ms otherwise. 

[BA] Since there is detailed existing text in RFC 5389 Section 7.2.1 (see below) I would prefer to start from that and make modifications where necessary. Does this just come down to recommending an initial RTO of 500 ms for all links (not just wired)?

From RFC 5389 Section 7.2.1:

A client SHOULD retransmit a STUN request message starting with an interval of RTO ("Retransmission TimeOut"), doubling after each retransmission. The RTO is an estimate of the round-trip time (RTT), and is computed as described in RFC 2988 [RFC2988], with two exceptions. First, the initial value for RTO SHOULD be configurable (rather than the 3 s recommended in RFC 2988) and SHOULD be greater than 500 ms. The exception cases for this "SHOULD" are when other mechanisms are used to derive congestion thresholds (such as the ones    defined in ICE for fixed rate streams), or when STUN is used in non- Internet environments with known network capacities. In fixed-line access links, a value of 500 ms is RECOMMENDED. Second, the value of RTO SHOULD NOT be rounded up to the nearest second. Rather, a 1 ms accuracy SHOULD be maintained. As with TCP, the usage of Karn's algorithm is RECOMMENDED [KARN87]. When applied to STUN, it means that RTT estimates SHOULD NOT be computed from STUN transactions that result in the retransmission of a request.