RFC9000 has a fairly detailed description, FYI:
https://datatracker.ietf.org/doc/html/rfc9000#name-managing-ack-ranges

On Fri, Jun 30, 2023 at 3:18 PM Xin Long <[email protected]> wrote:

> 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.
> > >
> >
>
>

Reply via email to