Re: [quicwg/base-drafts] Packet number echo with variable-length numbering (#391)

[Brian Trammell <[e-mail]>]

It's not necessarily coupled. If the max-acked field comes out of the ACK frame, a sender MUST send an echo on any packet containing an ACK frame, and MAY on any other packet with a short header. Indeed, if we want to make sure that nobody gets the idea that "packet number echo == ACK-only packet a la TCP" we should ensure that echo also appears on some non-ACK packets.

Thinking about this a bit more... Consider the common case of an extremely asymmetric flow (e.g. big HTTP object GET). The client is going to be sending primarily ACK frames, so will be sending lots of echos. The server won't be ACKing anything, since it got the whole request in the first few packets. The max packet number seen keeps going up, since it's getting a lot of packets full of ACKs, but it's not ACKing them. So you're only seeing echoes in one direction. That's bad for one-point RTT measurement.

(for those not used to thinking about measuring RTT at a single point; here's an illustration I made a few years ago; the main point is you need sufficient samples in both directions so you can add "forward-side" and "reverse-side" estimates together)

![one-point-rtt](https://cloud.githubusercontent.com/assets/1884116/24040943/a7a939a8-0b0b-11e7-92ae-7f1a7e44ad82.png)

So *just* "echo on ACK" is probably insufficient. Let me suggest the following simplification, then:

### Option 3: Echo max-acked / max-seen on every packet with a short header, and remove it from the ACK frame

Rationale: This ensures sufficient samples for high-fidelity RTT measurement regardless of flow asymmetry, and offsets the overhead somewhat and eliminates redundancy by removing the echoed information from the ACK frame.

Upsides: It's very simple to know when to echo. The presence of an ACK frame is not exposed to the path. This provides the best possible signal for passive RTT measurement.

Downsides: A little more overhead. Shares with option 2 the lack of frame self-description for ACK frames.


-- 
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/pull/391#issuecomment-287330020