lsquic icon indicating copy to clipboard operation
lsquic copied to clipboard

ACK have not retransmission but detect ack loss

Open xuananwhu opened this issue 4 years ago • 3 comments

Hello, everyone. I have a problem for Ack retransmission. I used http_client to request server, server is not http_server, I used quiche.

This problem occurs on weak network: Packet loss rate : 20%, and out-of-order, RTT: 200ms

Error log:
[ERROR] [QUIC:E0E472A59C470774] conn: Abort connection: generating ACK frame failed: 22

catch the packets in client: image

catch the packet in server: image

My test command: ./http_client -p /test/get/case/1k -H test.com -s 8443 -o version=ff00001d -t -l sendctl=debug

Analysis

  1. In the handshake phase, the client send 3 ACK frame to server, but the server just received 2 ACK frame;
  2. lsquic_send_ctl_init: ctl->sc_retx_frames = IQUIC_FRAME_RETX_MASK; image
  3. ietf_full_conn_ci_tick: image

image

  1. Debug log:
14:37:45.247 [DEBUG] [QUIC:4CE440F5A445D6CB] sendctl: send_ctl_detect_losses
14:37:45.247 [DEBUG] [QUIC:4CE440F5A445D6CB] sendctl: loss by sent time detected: packet 4
14:37:45.247 [DEBUG] [QUIC:4CE440F5A445D6CB] sendctl: lost ACK in packet 4
14:37:45.247 [DEBUG] [QUIC:4CE440F5A445D6CB] sendctl: lost unretransmittable packet 4
14:37:45.247 [DEBUG] [QUIC:4CE440F5A445D6CB] sendctl: pns = 1, lossed_detected = 0
14:37:45.247 [DEBUG] [QUIC:4CE440F5A445D6CB] sendctl: No retransmittable packets: clear alarm

Here is my understanding of the question: lsquic forbidden the ACK frame to retransmit, but it will be check ack if its loss, then lead to the generation of ACK packets is failed.

Question: ACK Frame won't be retransmitted in hanshake and application phase, but why detect its loss? I cant understand. Looking forward to your reply.

xuananwhu avatar Dec 02 '21 11:12 xuananwhu

@litespeedtech @dtikhonov

xuananwhu avatar Dec 02 '21 11:12 xuananwhu

Same issue when testing over Nginx's QUIC (https://hg.nginx.org/nginx-quic).

Run with following commands:

./http_client -n 1 -w 2 -R 2 -r 4 -H ... -s ...

that reuses a UDP connection occasionally causing following prints:

conn: Abort connection: generating ACK frame failed: 22

When it occurs, in generate_ack_frame_for_pns(), conn->ifc_rechist[pns].rh_n_used will be set to 0 after calling of lsquic_rechist_received(), while pns == 1.

The difference from normal case is immediately generating ACK after processing the 1st App PNS packet. Beg for fixing...

Fierralin avatar Dec 08 '21 11:12 Fierralin

Same issue,Beg for fixing...

ddk915 avatar Jun 08 '22 09:06 ddk915