Re: [quicwg/base-drafts] Should we allow ACK-only packets to be declared lost? (#3451)

[ianswett <[e-mail]>]

I'd prefer to keep this as is, because I think ensuring everything works correctly with an updated design is going to be a bit complex and potentially error prone, and I don't see any value in the change.

For example, when an ACK is lost, if the CWND is reduced, that doesn't reduce the rate of ACKs, it just reduces the rate of sending future data.  Because ACKs do not count towards bytes in flight, the congestion window would never increase if a peer is only sending ACKs, so we'd be putting peers in a situation that the CWND could decrease, but never increase.  That alone seems sub-optimal.

FWIW, I do believe we discussed this at length a few years ago and ended up where we did because of (at least) three points:
1) ACKs are not required to be acknowledged, even once.
2) This is very similar to what TCP does.
3) Congestion controlling ACKs is a research topic.

@martinthomson We track lost packets for a while in case they were declared lost too early, so the existing design is quite natural and a bit simpler.

If in QUICv2/etc we think it's worth making ACK-only packets congestion controlled and count towards bytes in flight, I think that would be a more holistically appealing design.  I also think it's quite a bit of work and research to get right.

But I do think we should make this point a bit clearer in recovery and articulate why this choice was made.

-- 
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/3451#issuecomment-585253162