Re: [quicwg/base-drafts] QUIC Transport - sending after final size? (#3721)

Mike Bishop <notifications@github.com> Fri, 05 June 2020 15:07 UTC

Return-Path: <noreply@github.com>
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 256CA3A077A for <quic-issues@ietfa.amsl.com>; Fri, 5 Jun 2020 08:07:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.555
X-Spam-Level:
X-Spam-Status: No, score=-1.555 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_20=1.546, 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: 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 wEDj36Kfrcpc for <quic-issues@ietfa.amsl.com>; Fri, 5 Jun 2020 08:07:34 -0700 (PDT)
Received: from out-3.smtp.github.com (out-3.smtp.github.com [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A34013A0765 for <quic-issues@ietf.org>; Fri, 5 Jun 2020 08:07:34 -0700 (PDT)
Received: from github-lowworker-ca5950c.va3-iad.github.net (github-lowworker-ca5950c.va3-iad.github.net [10.48.17.57]) by smtp.github.com (Postfix) with ESMTP id 9E1282C1C8A for <quic-issues@ietf.org>; Fri, 5 Jun 2020 08:07:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1591369653; bh=858VKUv1h3xwkQDg1JXJRmkuhvjWnJBWywZzg1HBfpo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ep2CHAeglZkIj+RgkSp0IfCMNr64jb2VBckZX4NPCBSNqnoBanPJtjha5iL8BLEqw Tt+k1jX3zS9W0tzUW2EVYLtobm8rdKRK/3z+eS4FrHm9HNhT8s+678f0GJ88lW/ce1 ob/CCS0/mraE30oGEYrxgh8AQxGaOaklSOnjHC6Q=
Date: Fri, 05 Jun 2020 08:07:33 -0700
From: Mike Bishop <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2622ORQEF65IBPWWN44ZALLEVBNHHCLGB37E@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3721/639553291@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3721@github.com>
References: <quicwg/base-drafts/issues/3721@github.com>
Subject: Re: [quicwg/base-drafts] QUIC Transport - sending after final size? (#3721)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5eda5fb5905ec_15f3fb5266cd96c7897c"; 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: <https://mailarchive.ietf.org/arch/msg/quic-issues/m7qykgCcFgYore17M4GpgcBwHYs>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jun 2020 15:07:36 -0000

Because the Final Size is used to synchronize flow control consumption.  If the Final Size is not, in fact, the last data ever sent on a stream, the two sides will disagree about how much flow control credit has been consumed.

The reaction of the receiver isn't to ignore; in the very next paragraph:

> A receiver SHOULD treat receipt of data at or beyond the final size as a FINAL_SIZE_ERROR error, even after a stream is closed. Generating these errors is not mandatory, but only because requiring that an endpoint generate these errors also means that the endpoint needs to maintain the final size state for closed streams, which could mean a significant state commitment.

-- 
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/issues/3721#issuecomment-639553291