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

Kazuho Oku <> Sat, 06 June 2020 01:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2902E3A041D for <>; Fri, 5 Jun 2020 18:08:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.697
X-Spam-Status: No, score=-1.697 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, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ETcPrVV2SAic for <>; Fri, 5 Jun 2020 18:08:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D51C53A0437 for <>; Fri, 5 Jun 2020 18:08:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 88A2D9602A7 for <>; Fri, 5 Jun 2020 18:08:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1591405700; bh=KgbkqdY8gnofBgdnV/gfr2y6zk+1XMBJUxWqUoAemMA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=jWDpUYBbqHA0k4wPTel2yZ+DyKFG4pXINsvMZbWuVhjCKnck/uexpOtKpFXiKZ1J/ tUeQPtGoLNEZytEwkCCtqyEJ1f1vpvKpCloZqShovMcwn6Uiu9TB27lJzDRSA52Ecd Y7hf3OsghP8U+CW4Z91+YBEh1fu8RhLqcwa9W0D0=
Date: Fri, 05 Jun 2020 18:08:20 -0700
From: Kazuho Oku <>
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_5edaec847903d_bb53fe5ebccd95c146731"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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 01:08:23 -0000

@kazuho 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.

To me it seems that the text starting from "or, ..." is confusing. That is because a "sender" does not communicate the final size of incoming undirectional stream, contrary to what the first sentence of this paragraph suggests.

I think it might make sense to either simply drop "or... ", or modify the first sentence to state that such communication is made for streams that has the send side.

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