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

Marten Seemann <> Tue, 31 July 2018 17:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F327130E4A for <>; Tue, 31 Jul 2018 10:37:30 -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 pzWlPCXnjAB9 for <>; Tue, 31 Jul 2018 10:37:28 -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 5B476130E46 for <>; Tue, 31 Jul 2018 10:37:28 -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=jr+RJVpPHgNCtGR/11RFaaChAAg=; b=Gd+uIj965kVYjvfL V1Vk1TrkM/nN6dMeRIe64c7fSbJa1jYhnfAqYZc5yiPj8kX8nPbz47tshd0HfJ8r gukcpQ/81Fr/SWVmbG5zhVos8uQiivoDO9my2iFvLYXcKKjAWUUDpBJdw6V1hiNi Zy6B0DNKz4PFhK7X1TZBL6XJusM=
Received: by with SMTP id filter1229p1las1-6784-5B609E56-43 2018-07-31 17:37:27.056026693 +0000 UTC m=+501114.624331389
Received: from (unknown []) by (SG) with ESMTP id -GmtpeBfRTyEqQGjWlcQjw for <>; Tue, 31 Jul 2018 17:37:26.944 +0000 (UTC)
Received: from (localhost []) by (Postfix) with ESMTP id E4FAB6C1342 for <>; Tue, 31 Jul 2018 10:37:26 -0700 (PDT)
Date: Tue, 31 Jul 2018 17:37:27 +0000
From: Marten Seemann <>
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_5b609e56e35ec_6a523f83f0abe628304184"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: marten-seemann
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak1dcVpTXqCVjsgfErph2WcnC8gl5Xn7ehX0VG bPoPDbUQXtIukalAiwOgdtidiwLD4chJPbY6fE5rz6b1z3zbeXaXLX5R2ua9nqVUbhemlDc7yaY62W N6YBSp3IqQH3zVWzIn01ASvFqjrJQFZ9DiNJFp5KcA59DSz0dBYrhA7TTh39mus1XqyHGUyVnx/iak Q=
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 17:37:30 -0000

> A receiver MUST NOT renege on an advertisement; that is, once a receiver advertises an offset, it MUST NOT subsequently advertise a smaller offset. A sender could receive MAX_DATA or MAX_STREAM_DATA frames out of order; a sender MUST therefore ignore any flow control offset that does not move the window forward.

This sentence is maximally confusing. You're not allowed to advertise a smaller offset, but then the peer is not allowed to check for this violation either. If I interpret this correctly,  Chrome, Litespeed and quic-go are violation the spec by implementing a slightly less than optimal retransmission strategy, and mvfst is violating the spec by performing a check of the flow control offset.
We should definitely make this wording clear, one way or the other.

I understand that optimisations are fun to implement, and once you've done it they seem trivial and obvious, but we shouldn't require an implementation to optimise anything. Retransmitting every packet as it is (just repacking it with a different packet number) is the most basic retransmission strategy that allows for a functional implementation of the protocol, and I think an implementation should be allowed to do this.

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