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

Subodh Iyengar <> Tue, 31 July 2018 17:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD327130E0F for <>; Tue, 31 Jul 2018 10:08:45 -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 mlnlm_3doHya for <>; Tue, 31 Jul 2018 10:08:43 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CA3CE127598 for <>; Tue, 31 Jul 2018 10:08:43 -0700 (PDT)
Date: Tue, 31 Jul 2018 10:08:43 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1533056923; bh=l5uCF+NxAVamsSPwjBzEw+fEG9vuxQFB/ObWo6p1dYA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=jfrkbvbyB17qK7HRg9a+k3CZXuCC6D+q96+4u2pP2Ld6M25rtgDOS6rSg0ZDWToc/ p+rtEen7JZueXeQqMtM1QqTcmRSyLuq7Og36BtDe8PGDYacn99qCJaxHLCKy4Bf/Ow jxpXkQ+CA8hOST8jO/Tmm9Gtmv6/lGxI8ZunHRGo=
From: Subodh Iyengar <>
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_5b60979b38099_15723fc4ec4d45b880642"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: siyengar
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:08:46 -0000

@huitema Not sure I understand, do you mean verifying a MUST behavior is not justfied? In my reading of the clause, an implementation that checks for whether the peer is sending lower values is totally allowed in the current draft if it knows that the peer has sent this subsequently. This is because my reading of the MUST check. 

I think a receiver should be allowed to verify that this happens, it is just not required to do so, and we should also allow for implementations that don't verify this check. So if an implementation does send a frame pattern like this, it should be aware that it will not interoperate against some implementations. 

If we want to change this, then you might want propose a change, otherwise I think the current draft allows receivers to verify the MUST.

@mikkelfj was there any discussion about this? My understanding is that we have always implied that packet number == ordering. All the loss recovery mechanisms assume this. If this is not true we need to have a deeper conversation :) Also I don't agree with the analogy of frames as streams.

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