Re: [quicwg/base-drafts] Only send one immediate ACK after reordering (#3357)

[Gorry Fairhurst <[e-mail]>]

I think it will impact the robustness to loss/congestion on the return path compared to the way TCP operates, but the use of PTO generally mitigates this...

There are cases where relying only on the PTO would delay congestion detection, such as when there is a significantly reduced path RTT at the same time as loss (we could think of scenario where this is a result of re-routing for the path).

I’m also interested in a case where there is loss in both directions (which can also happen in congestion collapse). The reduction of ACK information could result in unnecessary duplicated data (because the sender does not receive ACK range info). This issue seems most severe when there are too few ACKs per RTT. 

It seems there is merit in ensuring there are sufficient ACKs per RTT - e.g., a rule that sends ACKs at least every (say) 1/8 RTT would seem wise.

Overall, I am in favour of the proposal to change the response after loss/reorder. QUIC currently generates a lot more ACK traffic (in volume) than TCP.  ACK after loss event are common with RENO overflowing a router buffer (we are looking at this now). This proposed change is likely to really help reduce ACK traffic volume on the return path.  

If the arguments for this seem valid, I think related issue #3304 needs to be considered again. 


-- 
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/3357#issuecomment-594444311