Re: [quicwg/base-drafts] are flow control frames really idempotent? (#1612)

Christian Huitema <> Tue, 31 July 2018 16:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 966C6130E00 for <>; Tue, 31 Jul 2018 09:21:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.11
X-Spam-Status: No, score=-6.11 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 xn1uJ4o_4AZA for <>; Tue, 31 Jul 2018 09:21:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C67DF130DD9 for <>; Tue, 31 Jul 2018 09:21:04 -0700 (PDT)
Date: Tue, 31 Jul 2018 09:21:03 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1533054063; bh=hkKNTvWIYfLPztA+gbdWk/0+9ESDxAgyJgfEfkErlz0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=oT5MCemAVRZd+fhVHWVlEyO3m8ZxZ7wLwEsCDfaj7W13kIA0KD/1SHSpYW7W3zc7h yHyx8MVAYZKEQYXfU0d/LsoALBiDAYJ0A8oe4X220SHDfqCTh23kKA8jPHJaiVruWX bsDhmUQG51TaTneZYMNpxcklgg/Y9AwWoo9UGxZI=
From: Christian Huitema <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/1612/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] are flow control frames really idempotent? (#1612)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b608c6fd0698_63253f882eed45b8646a7"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.27
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: Tue, 31 Jul 2018 16:21:07 -0000

I think the current state is just fine: the receiver just ignores values lower than the highest advertised max data, etc. That means that, for the sender, attempting to send a lower value would just be a noop.

Triggering errors is problematic. Not just because of retransmission, which is indeed easy to fix, but mostly because of reordering. Take the extreme case of an implementation that sends max data with every ack. Someof those are bound to arrive out of order. Do you really want to tear down the connection at that point?

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