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

MartinThompson <> Tue, 31 July 2018 17:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2069F130E4A for <>; Tue, 31 Jul 2018 10:39:42 -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 5AE_ZxvO8Kkz for <>; Tue, 31 Jul 2018 10:39:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 171F6130E46 for <>; Tue, 31 Jul 2018 10:39:40 -0700 (PDT)
Date: Tue, 31 Jul 2018 10:39:38 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1533058778; bh=kh6g8gpwtCZSf78CcSGTKsLgj8qxrhG4AS5+RFIM6tc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=B1PFeM23a2x+8SM5evD6IaeyIECzWjbGcr3PhZVbORd5uFHQcZr1rcI/Mc50QGVXq 90qBnTZ+oa5wePWbYhGQ5I0z5/xdiVKqLz2UeAsViRbobGpyaQn/ZpxF4YVHoUwrqw GJtTZU4c0MsEG4V03JaREFoSKlmu3bhdfFGYI9gA=
From: MartinThompson <>
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_5b609edac3cc7_7be63ff9124be628941f7"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: MartinThompson
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 17:39:42 -0000

I think you guys have tagged the wrong Martin Thompson. You should double check and re-tag the correct one.


> On Jul 31, 2018, at 10:37 AM, Marten Seemann <> wrote:
> 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 were mentioned.
> Reply to this email directly, view it on GitHub <>, or mute the thread <>.

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