QUIC ACKs could be delayed by congestion controllers

[yangfurong@…]

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:

1. 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;
2. 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).

[Roman Arutyunyan]

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.

[Roman Arutyunyan]

The attached patch should fix the issue. However we haven't seen any performance improvements under normal conditions. The evaluation is still ongoing.

[yangfurong@…]

This patch could generate a pure ACK pkt for every incoming ack-eliciting packet when there is no available cwnd. In ngx_quic_generate_ack, it only delays ACK if the send queue is empty (​https://hg.nginx.org/nginx/rev/a90f79792b5d).