Return-Path: X-Original-To: quic-issues@ietfa.amsl.com Delivered-To: quic-issues@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3C1F3A0EB9 for ; Mon, 8 Jun 2020 11:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.518 X-Spam-Level: *** X-Spam-Status: No, score=3.518 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_SUMOF=5, HTML_IMAGE_ONLY_24=1.618, 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-K_FxZQLbjC for ; Mon, 8 Jun 2020 11:41:15 -0700 (PDT) Received: from out-17.smtp.github.com (out-17.smtp.github.com [192.30.252.200]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEE2E3A106C for ; Mon, 8 Jun 2020 11:40:43 -0700 (PDT) Received: from github-lowworker-52827f8.ash1-iad.github.net (github-lowworker-52827f8.ash1-iad.github.net [10.56.108.24]) by smtp.github.com (Postfix) with ESMTP id 0B97B6E1306 for ; Mon, 8 Jun 2020 11:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1591641643; bh=xrVGRjEMijT722lR1ojGv3RcmEU9xmqltArCG3hE96k=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=f8vkhDr+cvSa/fe6aXvWuSKM3Y/kNizJ/XTFb42qApHi+T9m6aX0gN0IKz6YGbT2X F+al04uzD0sfQ36TzsNdeTLlC0QYlQ+M0u5aiRB0FZ3wiOhOc/DTh2u6Q2M/966KwZ uu07gmSTlOoaVlL5DTteTEc/ClTfFAzgH/7MNpsU= Date: Mon, 08 Jun 2020 11:40:42 -0700 From: Mike Bishop Reply-To: quicwg/base-drafts To: quicwg/base-drafts Cc: Subscribed Message-ID: In-Reply-To: References: Subject: Re: [quicwg/base-drafts] Why do we have final size? (#3739) Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5ede862aef721_39363fd32c2cd96010109f"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: MikeBishop X-GitHub-Recipient: quic-issues X-GitHub-Reason: subscribed X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: quic-issues@ietf.org Archived-At: X-BeenThere: quic-issues@ietf.org 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: Mon, 08 Jun 2020 18:41:21 -0000 ----==_mimepart_5ede862aef721_39363fd32c2cd96010109f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit @MikeBishop commented on this pull request. > @@ -908,10 +908,13 @@ 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. +The final size of a stream is always signaled to the recipient. The final size +is the sum of the Offset and Length fields of a STREAM frame with a FIN flag, +noting that the length might be implicit. Alternatively, the Final Size field True. That will only be the case when a stream has only one STREAM frame, so it would be _unusual_ for the final STREAM frame to have an implicit Offset, but it's certainly not prohibited. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/quicwg/base-drafts/pull/3739#discussion_r436914997 ----==_mimepart_5ede862aef721_39363fd32c2cd96010109f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@MikeBishop commented on this pull request.

In draft-ietf-quic-transport.md:

> @@ -908,10 +908,13 @@ 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.
+The final size of a stream is always signaled to the recipient.  The final size
+is the sum of the Offset and Length fields of a STREAM frame with a FIN flag,
+noting that the length might be implicit.  Alternatively, the Final Size field

True. That will only be the case when a stream has only one STREAM frame, so it would be unusual for the final STREAM frame to have an implicit Offset, but it's certainly not prohibited.

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

----==_mimepart_5ede862aef721_39363fd32c2cd96010109f--