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

Dmitri Tikhonov <> Tue, 31 July 2018 12:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 81015128CF2 for <>; Tue, 31 Jul 2018 05:33:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.11
X-Spam-Status: No, score=-1.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_NONE=-0.0001, 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 jPI9dvqGdk8y for <>; Tue, 31 Jul 2018 05:33:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9DBC3129AB8 for <>; Tue, 31 Jul 2018 05:33:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=Ed9NsVg4b3fijkjS5uoCmJcQeZQ=; b=jnHrAYQj3MLAuRk7 1881lD2bnU8gkuVq2J8aIaOUwewC6xXtV4RWp8D2lIqZ22jkbXClyGLbVTMVbChv WGNHcP726ow72Ss6J4CrL1F0jA34DISDscuiz/+ManG/yIN3tx4vCZMLbyWpl2qz r1Up8rDWtczpvFkcqs8MHcuI8M4=
Received: by with SMTP id filter1287p1mdw1-10044-5B6056A3-32 2018-07-31 12:31:31.856037587 +0000 UTC m=+482998.259821484
Received: from ( []) by (SG) with ESMTP id 7cfS9ZsgTWi_rosJ7YbJvA for <>; Tue, 31 Jul 2018 12:31:31.514 +0000 (UTC)
Date: Tue, 31 Jul 2018 12:31:32 +0000
From: Dmitri Tikhonov <>
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_5b60569d90ba0_52093fcc0f4d45c09396c"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: dtikhonov
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak1gHtJl9QqTO8Zu2GCGurqjHXjRahhvzuC4hV XQxEnhg/bA2qx0xJQt4x8V11LojnSZfdyZ7erVWT/CiIEJuyt82MbwBfo/kH6JWaPCwkC8mvsR2o8v ZrBHRGOosGcJiCbGBechwlMmBidloY610dZF9ttbhzLDXWY7gtdBVPpgU0rjtnMFJDHNYnYfRMqQqg 4=
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 12:33:51 -0000

@siyengar writes:
> a receiver who wants to help peers prevent flow control bugs from happening

One could detect _potential_ bugs in the peer in many other cases.  I vote against mandating such error detection at the protocol level.

@kazuho writes:
> some existing QUIC implementations simply retransmit a packet (by re-encrypting it using a new PN) when it is deemed lost. I think that such implementations should be allowed to exist.

This is true. This is what the LiteSpeed implementation does with GQUIC's _WINDOW_UPDATE_ frames. The smaller values are [ignored]( It is more expedient (and is cheaper) to discard lower values on receipt rather than update or remove the old values on retransmit.

Yes, let us exist!

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