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

[Mikkel Fahnøe Jørgensen <[e-mail]>]

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 ([e-mail])
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

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

-----Original Message-----
From: QUIC [mailto:[e-mail]] On Behalf Of
[e-mail]
Sent: Monday, 14 December 2020 1.23
To: [e-mail]
Cc: [e-mail]
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.

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 ([e-mail] (mailto:[e-mail])), 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/