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

MikkelFJ <> Tue, 31 July 2018 16:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 85E4E130DEB for <>; Tue, 31 Jul 2018 09:33:56 -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 fLTETjdI4fG6 for <>; Tue, 31 Jul 2018 09:33:54 -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 8206E127B92 for <>; Tue, 31 Jul 2018 09:33:54 -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=9t5rN3pqap4p2MA3v32gTZctmsI=; b=cfK2riTRGOLz0AVl ag86j743ooNUmJiLlgUJrKWRZbyBoddKoAC0or3lOFWHc35MZb/I3FxKSP1E0C2k bLtXnrNIqXGs8qx/5O6IZJEQBZfsMvpNy6boKts4uGNLxTN5dh39u8UU26nmg1i1 7A/pb0KstlE2vmTVAxz0IE0T7GE=
Received: by with SMTP id filter1101p1las1-18230-5B608F70-2E 2018-07-31 16:33:53.039919031 +0000 UTC m=+497029.177563519
Received: from (unknown []) by (SG) with ESMTP id myrEH4yyR8aZ7I-wWBQ_eA for <>; Tue, 31 Jul 2018 16:33:52.981 +0000 (UTC)
Received: from (localhost []) by (Postfix) with ESMTP id E23AB3E094E for <>; Tue, 31 Jul 2018 09:33:52 -0700 (PDT)
Date: Tue, 31 Jul 2018 16:33:53 +0000
From: MikkelFJ <>
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_5b608f70e03c0_16dd3fcb49ed45b43043af"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak3NF0SlIQU18kY14QpRDaxwYYnD0I0LrL+WYa m+42thfZQTdltDkOtEPoC8hPNwjbLNLXPuviFgEoulBX4MKLr0DMOE4384d9JbQNRK7195Vqz4WpFK 7M/zzacQgLwGh84S3OHMYK4BZKdy559I26z1Y5MTz2HdS13yO7rtFzvrkgy9zQp2Vn2vbHTQOfqBMf 8=
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:33:57 -0000


> @mikkelfj what do you mean by the ordering not coming from packet number?

I mean that the general principle of QUIC is for packets to vessels of frames that do not carry any semantic such as ordering, except for the connection context itself. I am not saying there is other ordering for MAX_DATA, only that when there is ordering, it should not, and generally does not, derive from packet numbers. For example, streams are ordered by stream offsets, and streams are ordered by stream ID's. Implying a problem because of ordering related to packet numbers is fundamentally against this design.

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