Got it now. In that way, I guess the SACK only needs to carry the gaps of the latest 1 RTT.
Thanks! On Fri, Jun 30, 2023 at 12:38 PM Christian Huitema <[email protected]> wrote: > > Packet number gaps are never filled in QUIC, whether the packet contains ACK, > or Stream data, or some other frame. A packet number is only used once. If it > is lost, the frames in it may be resent, in one or several packets, with > different packet numbers. > > -- Christian Huitema > > > On Jun 30, 2023, at 9:23 AM, Xin Long <[email protected]> wrote: > > > > Hi, Lars, > > > > In QUIC, as the packet containing only ACK frame also consumes a packet > > number, > > I have a question about how the peer manages its "ACK map" for making SACK > > and > > moves forward this gap? > > > > For example, the Client sends data to the Server, and the Server sends > > SACKs. > > If the SACK with packet number 21 from the Server gets lost, the Client will > > not get the number-21 SACK packet. > > > > Later when the Server sends data to the Client, there will always be a gap > > (21) > > when the Client sends SACK , as the Client can never know if the lost > > number-21 > > packet is a stream DATA or SACK-only packet. > > > > To make it more clear: > > > > Client Server > > ... ... > > pkt 10 (DATA) ---> > > <--- pkt 20 (ACK: [10..0]) > > pkt 11 (DATA) ---> > > pkt 12 (DATA) ---> > > pkt 13 (DATA) ---> > > !<--- pkt 21 (ACK: [12..11]) > > !<--- pkt 22 (ACK: [13..11]) > > !<--- pkt 23 (DATA) > > !<--- pkt 24 (DATA) > > pkt 14 (DATA) ---> > > <--- pkt 25 (ACK: [14: 11]) > > <--- pkt 26 (DATA) > > pkt 15 (ACK: [26..25] [20..0]) ---> ? > > > > > > pkt 21-24 from Server are all lost, what will Server do after receiving > > pkt 15 from Client, to tell Client that the lost pkt 21-22 are ACKs and > > the lost pkt 23-24 are DATA, and the gaps in ACK map in Client should > > keep 22-23 only? > > > > Thanks. > > >
