Subject: I-D Action: draft-ietf-quic-recovery-33.txt

From: [email-masked]
Date: Sun, 13 Dec 2020 15:22:56 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the QUIC WG of the IETF.

        Title           : QUIC Loss Detection and Congestion Control
        Authors         : Jana Iyengar
                          Ian Swett
	Filename        : draft-ietf-quic-recovery-33.txt
	Pages           : 53
	Date            : 2020-12-13

Abstract:
   This document describes loss detection and congestion control
   mechanisms for QUIC.

Note to Readers

   Discussion of this draft takes place on the QUIC working group
   mailing list ([email-masked] (mailto:[email-masked])), which is
   archived at https://mailarchive.ietf.org/arch/
   search/?email_list=quic.

   Working Group information can be found at https://github.com/quicwg;
   source code and issues list for this draft can be found at
   https://github.com/quicwg/base-drafts/labels/-recovery.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-quic-recovery-33.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-recovery-33

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Giorgi Gulbani <[email-masked]>
Date: Mon, 14 Dec 2020 14:06:37 +0000

Dear all,

I wonder if it would be possible to further clarify the offset field usage in section 2.2 as quoted between two asterisks below:

STREAM frames (Section 19.8) encapsulate data sent by an application. An endpoint uses the Stream ID and Offset fields in STREAM frames to place data in order. *Offset filed contains/represents the frame sequence number within the given stream*.

Kind regards,

Giorgi Gulbani

P.S. I work at 3GPP CT4 and have joined QUIC forum not so long ago.

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, 14 December 2020 1.23
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action: draft-ietf-quic-recovery-33.txt

Abstract:

Note to Readers

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 14 Dec 2020 06:27:27 -0800

Hi Giorgi,

you commented on the recovery draft but refer to the transport draft, just
for clarity.

Stream frames do not actually have sequence numbers. To illustrate consider
the following example:

If you send three stream frames each 10 bytes long, one starting at offset
0 and one starting at offset 10, and one at offset 20 with each frame sent
in a separate packet A, B, and C. Now packet A and C gets lost and only
packet B is recieved and acknowledged (but the acknowledgement is not
necessarily received by the sender). The sender retransmits the content at
offset 0..9 and 20..29 because packet A and C were declared lost. It also
includes the range from packet B because it hasn’t decided if B was lost.
So it sends a single frame at offset 0 with length 15, and another frame at
offset 15 with length 15.

So there is no concept of a frame identifier or sequence number. Only the
payload of the frame matters. Retransmission happen in new frames that may
start at different offsets and have different lengths, as long as all the
information eventually reaches the opposite endpoint, or the stream or
connection is closed prematurely.

Historically there was a long discussion on how to describe stream offsets
because empty streams are possible and this needs careful formulation.

Mikkel

On 14 December 2020 at 15.07.05, Giorgi Gulbani ([email-masked])
wrote:

Dear all,

I wonder if it would be possible to further clarify the offset field usage
in section 2.2 as quoted between two asterisks below:

STREAM frames (Section 19.8) encapsulate data sent by an application. An
endpoint uses the Stream ID and Offset fields in STREAM frames to place
data in order. *Offset filed contains/represents the frame sequence number
within the given stream*.

Kind regards,

Giorgi Gulbani

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, 14 December 2020 1.23
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action: draft-ietf-quic-recovery-33.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the QUIC WG of the IETF.

Abstract:

Note to Readers

Please note that it may take a couple of minutes from the time of
submission until the htmlized version and diff are available at
tools.ietf.org.

---

From: Giorgi Gulbani <[email-masked]>
Date: Mon, 14 Dec 2020 14:38:27 +0000

Thanks Mikkel,

Now I see. If you don’t mind, I’ll use your example to explain things in 3GPP TR 29.893.

Kind regards,

Giorgi

From: Mikkel Fahnøe Jørgensen [mailto:[email-masked]]
Sent: Monday, 14 December 2020 16.27
To: Giorgi Gulbani <[email-masked]>; [email-masked]
Subject: RE: I-D Action: draft-ietf-quic-recovery-33.txt

Hi Giorgi,

you commented on the recovery draft but refer to the transport draft, just for clarity.

Stream frames do not actually have sequence numbers. To illustrate consider the following example:

If you send three stream frames each 10 bytes long, one starting at offset 0 and one starting at offset 10, and one at offset 20 with each frame sent in a separate packet A, B, and C. Now packet A and C gets lost and only packet B is recieved and acknowledged (but the acknowledgement is not necessarily received by the sender). The sender retransmits the content at offset 0..9 and 20..29 because packet A and C were declared lost. It also includes the range from packet B because it hasn’t decided if B was lost. So it sends a single frame at offset 0 with length 15, and another frame at offset 15 with length 15.

So there is no concept of a frame identifier or sequence number. Only the payload of the frame matters. Retransmission happen in new frames that may start at different offsets and have different lengths, as long as all the information eventually reaches the opposite endpoint, or the stream or connection is closed prematurely.

Historically there was a long discussion on how to describe stream offsets because empty streams are possible and this needs careful formulation.

Mikkel

On 14 December 2020 at 15.07.05, Giorgi Gulbani ([email-masked]<mailto:[email-masked]>) wrote:
Dear all,

Kind regards,

Giorgi Gulbani

-----Original Message-----
From: QUIC [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Monday, 14 December 2020 1.23
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: I-D Action: draft-ietf-quic-recovery-33.txt

Abstract:

Note to Readers

Discussion of this draft takes place on the QUIC working group
mailing list ([email-masked]<mailto:[email-masked]> (mailto:[email-masked]<mailto:[email-masked]>)), which is
archived at https://mailarchive.ietf.org/arch/
search/?email_list=quic.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 14 Dec 2020 06:45:00 -0800

Sure, glad it was of use.

On 14 December 2020 at 15.38.30, Giorgi Gulbani ([email-masked])
wrote:

Thanks Mikkel,

Now I see. If you don’t mind, I’ll use your example to explain things in
3GPP TR 29.893.

Kind regards,

Giorgi

*From:* Mikkel Fahnøe Jørgensen [mailto:[email-masked]]
*Sent:* Monday, 14 December 2020 16.27
*To:* Giorgi Gulbani <[email-masked]>; [email-masked]
*Subject:* RE: I-D Action: draft-ietf-quic-recovery-33.txt

Hi Giorgi,

Mikkel

Dear all,

Kind regards,

Giorgi Gulbani

-----Original Message-----

Abstract:

Note to Readers