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

[Brian Trammell <[e-mail]>]

to summarize (will also post on quic@)...

### 1: Echo (at least) once per RTT. Leave ACK frames unchanged.

(This is what's written up in this PR).

Rationale: What happens in the frame layer stays in the frame layer. Packet number echo is a pure packet-layer change to the transport protocol. Since this is additional overhead, we should work to minimize it, hence once per RTT, the minimum frequency that works for passive latency measurement.

Upsides: It's a tiny change to the protocol as presently described, for a low overhead cost per RTT (1-4 bytes, usually 2). The ACK frame remains self-describing, so the ack frame handling component in an implementation can remain separate from the packet handling component. Endpoints can choose to echo more frequently (e.g., when configured to do so for debugging purposes).

Downsides: an echoing endpoint with a passively-cooperative peer can intentionally skew passive measurements, since the value in the packet header is not necessarily joined to the value in the ack frame. The utility and practicality of such a thing is debatable. It's not clear how good the resulting number/echo stream will be for one-point loss and reordering estimation.

### Echo max-acked on every packet with an ACK frame, and remove it from the ack frame.

Rationale: This information already appears in the ACK layer, so there's no additional overhead.

Upsides: Echo frequency is higher; this should make loss and reordering estimation work better at a single observation point.  No additional overhead.

Downsides: Increased complexity of implementations, which have to pass packet number echo information up the stack. No endpoint control over how often packet numbers are echoed, since max-ack is required by the transport mechanisms.

Mixedsides (depending on your proclivities): The presence of an ACK frame is now exposed to the path. ACK-frame-containing packets can (and given the history of TCP, probably will) be treated differently by the network in certain circumstances.


-- 
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-286442898