[quicwg/base-drafts] Restructure RTT section (#2567)

[Jana Iyengar <[e-mail]>]

>From #2506, @martinthomson had a suggestion for restructuring the RTT estimation section.

```
The baseline concepts here are:

- the observed RTT (latest_rtt in the code), which includes any processing delays on the receiver end

- minimum RTT, which is set to the minimum observed RTT for the path. this doesn't include any processing delays on the receiver end, which might inflate the value a little, but we assume that receivers will immediately acknowledge a packet at some point (usually this is a good idea for a new path, and handshaking more or less depends on that)

- ack delay, which captures the processing time and any forced delays on the receiver. This is limited to the maximum value the receiver advertises. This value is self-reported, so any error needs to result in using less network capacity, not more, or it could be used to increase network load inappropriately. The goal here is to have an RTT estimate that is larger. Thus, the design is such that if ACK delay is under-reported, or the maximum is set lower than the reality, this will result in an inflated RTT estimate. If this is over-reported, the maximum will cap the value and again cause the RTT estimate to be driven up also.

- The final RTT calculation. This is calculated based on the observed RTT and the adjusted ack delay. The value is smoothed so that some history is retained.

This structure matches the code, but I think that changes aren't really necessary.
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2567