Re: [quicwg/base-drafts] What to ack in an ACK frame (#764)

[martinduke <[e-mail]>]

@janaiyengar I must not have expressed myself clearly on case (A). Here is an example.
Acks for packets 1001-1200 and 1210-1300 are inflight.
Then I receive (much delayed) packet 1000.

The timestamp information would be quite useful, I imagine, as this will spike the rttvar. If I include all ack blocks, then largest_acked is 1300 and I have no way to express a timestamp 300 packet numbers below largest_acked.

A corner case, yes. It's possible to write some intricate code to handle this case. It's much simpler to not send higher ack blocks as a matter of course. This is how I ended up on option (ii) above.

Anyway, my intent is not to necessarily argue for what I did. It would be useful to get a sense of what people are doing and include an implementation note (or a SHOULD) if there's rough consensus.

@ianswett In the zero-loss case there is no difference between (ii) and (iv).

Comparing (ii) and (iv), each packet loss or burst loss in a window will cost me from 2 to 9 bytes of overhead in each packet. From a wire efficiency perspective, this is much worse than just sending it when the ack is lost, which when using case (ii) may require the loss of multiple acks and is generally quite improbable. OTOH, delivering the ack in < 2RTT with very high probability is good for avoiding spurious retransmissions and congestion backoff. 

This tradeoff doesn't seem obvious to me, but again I think the important thing is to capture the consensus.

-- 
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/764#issuecomment-330670706