Opened 4 weeks ago
Last modified 3 weeks ago
#2621 new defect
QUIC ACKs could be delayed by congestion controllers
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | other | Version: | 1.23.x |
Keywords: | quic, ack | Cc: | |
uname -a: | 4.19.91-013.xxxxx.xxxxx.x86_64 | ||
nginx -V: | nginx/1.23.0 |
Description
In NGINX QUIC, all QUIC ACK frames have to go through the congestion window limitation. This is problematic, as ACK frames could be delayed too much (even exceeding the max_ack_delay). As a consequence, the peer communicating with NGINX could see prolonged RTTs and may not be able to timely increase its congestion window.
Ideally, the ACK returning logic should be:
- If there is free space in the congestion window and there are other frames going to be sent, ACK frames could be bundled with these frames and sent out together;
- If the max_ack_delay has been reached, ACK frames must be sent immediately no matter whether there is available cwnd or not (pure ACK packets should be sent if there is no available cwnd).
Attachments (1)
Change History (3)
comment:1 by , 3 weeks ago
by , 3 weeks ago
Attachment: | quic-ack-cwnd added |
---|
comment:2 by , 3 weeks ago
The attached patch should fix the issue. However we haven't seen any performance improvements under normal conditions. The evaluation is still ongoing.
Note:
See TracTickets
for help on using tickets.
Thanks for reporting this. I see two potential benefits from this improvement. The first one is resolving a potential temporary deadlock when both peers are waiting for ACKs and both congestion windows are exhausted. The second one is a performance improvement while operating normally. We are currently evaluating a solution.