Re: how the QUIC skips the gaps for the lost SACK?

Ian Swett <ianswett@google.com> Mon, 31 July 2023 21:19 UTC

MIME-Version: 1.0
References: <CADvbK_eKC51aqLQ_ESR-C-HK76TTO9_HX2w4kUUEGOwvKXM8+Q@mail.gmail.com> <E11149EA-1CC8-4373-A0D8-E464DE55B4CA@huitema.net> <CADvbK_dM4Czju6S--oBPwV9QdmLteedn4jt-2N6s6G7gK1CD_A@mail.gmail.com>
In-Reply-To: <CADvbK_dM4Czju6S--oBPwV9QdmLteedn4jt-2N6s6G7gK1CD_A@mail.gmail.com>
From: Ian Swett <ianswett@google.com>
Date: Mon, 31 Jul 2023 17:18:47 -0400
Message-ID: <CAKcm_gMCZ_7e9cw4YRdwnOArfn7=ti6x_syWx_bnQkbrfMDq7Q@mail.gmail.com>
Subject: Re: how the QUIC skips the gaps for the lost SACK?
To: Xin Long <lucien.xin@gmail.com>
Cc: Christian Huitema <huitema@huitema.net>, lars@eggert.org, quic@ietf.org
Content-Type: multipart/alternative; boundary="000000000000864e360601cefa56"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/5Ty_D6ahFxDcyPplBdvjbHFJ0-c>
Precedence: list

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 <lucien.xin@gmail.com> 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 <huitema@huitema.net>
> 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 <lucien.xin@gmail.com> 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.
> > >
> >
>
>

how the QUIC skips the gaps for the lost SACK? Xin Long
Re: how the QUIC skips the gaps for the lost SACK? Christian Huitema
Re: how the QUIC skips the gaps for the lost SACK? Xin Long
Re: how the QUIC skips the gaps for the lost SACK? Ian Swett