Re: [quicwg/base-drafts] Why do we have final size? (#3739)

Martin Thomson <> Sat, 06 June 2020 09:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 12ED43A1020 for <>; Sat, 6 Jun 2020 02:42:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.899
X-Spam-Level: *
X-Spam-Status: No, score=1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_SUMOF=5, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 82z5coTnghDr for <>; Sat, 6 Jun 2020 02:42:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AE5A63A02C1 for <>; Sat, 6 Jun 2020 02:42:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F0ADBE0BC9 for <>; Sat, 6 Jun 2020 02:42:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1591436565; bh=XR41jT7YoOkfB+BQ8ptP34yC5rbzS4S/XZ0Np6kQbRU=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=LwsyyyJtXlXQ0c/HYshGJvG9P44kZbeD6p0U2QgSRjAiNcpbgJuFRkbvAEkZjE6MM RXLUWUpJdQkdw3it21ABB0qRxsTsX6xO1Ip/awgvSREC8rDbqjem3+w3byeXIcC+jc 5LGs2ngC1KfvxMbV9sMSMT1MHDc6CTVjQUy4nBps=
Date: Sat, 06 Jun 2020 02:42:45 -0700
From: Martin Thomson <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3739/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Why do we have final size? (#3739)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5edb6515e00ef_73b13fee138cd96c3366f1"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 06 Jun 2020 09:42:48 -0000

@martinthomson commented on this pull request.

> @@ -908,10 +908,11 @@ final size is the number of bytes sent.  More generally, this is one higher
 than the offset of the byte with the largest offset sent on the stream, or zero
 if no bytes were sent.
-For a stream that is reset, the final size is carried explicitly in a
-RESET_STREAM frame.  Otherwise, the final size is the offset plus the length of
-a STREAM frame marked with a FIN flag, or 0 in the case of incoming
-unidirectional streams.
+At the end of a stream, the sender communicates the final size to the recipient,
+ensuring flow control state is synchronized.  For a stream that is reset, the
+final size is carried explicitly in a RESET_STREAM frame.  Otherwise, the final
+size is the offset plus the length of a STREAM frame marked with a FIN flag, or
+0 in the case of incoming unidirectional streams.

I think that Kazuho is right regarding unidirectional streams (implying that a nothingness has size is silly), but I would go further.

There are three cases we care about: STREAM w/ data and FIN in which case the final size is offset+length.  We include an offset even when there is no data so that the final size is communicated in that frame.  Then there is RESET_STREAM, which carries the final size.  That way, no matter how the stream transitions to closed, the size is known.  So I would say that:

> The final size of a stream is always signaled to recipient.  Final size is signaled as the sum of the Offset and Length fields of a STREAM frame, noting that the length might be implicit.  Alternatively, the Final Size field of a RESET_STREAM frame carries this value.  This ensures that all ways that a stream can be closed result in the number of bytes on the stream are reliably transmitted. This guarantees that both endpoints agree on how much flow control credit was consumed by the stream.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: