Sure, glad it was of use.
On 14 December 2020 at 15.38.30, Giorgi Gulbani ([email protected]) 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 protected]] *Sent:* Monday, 14 December 2020 16.27 *To:* Giorgi Gulbani <[email protected]>; [email protected] *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 protected]) 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:[email protected]] On Behalf Of [email protected] Sent: Monday, 14 December 2020 1.23 To: [email protected] Cc: [email protected] 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 ([email protected] (mailto:[email protected])), 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/
