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

Subodh Iyengar <notifications@github.com> Tue, 31 July 2018 03:17 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D98E5130E2F for <quic-issues@ietfa.amsl.com>; Mon, 30 Jul 2018 20:17:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Status: No, score=-8.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id YGznvR8Xzufh for <quic-issues@ietfa.amsl.com>; Mon, 30 Jul 2018 20:17:22 -0700 (PDT)
Received: from out-3.smtp.github.com (out-3.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ECF4130E28 for <quic-issues@ietf.org>; Mon, 30 Jul 2018 20:17:22 -0700 (PDT)
Date: Mon, 30 Jul 2018 20:17:20 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1533007040; bh=8cyN0W6Yzta8tAWYD05+0lp+gAIoksjwaCE/RVU7IOo=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=yqfM+ok2qreMdAMuzB8moUmAS4CLFXKxJipMZh680sHoxQbAaTarZAL+g3T7stY0d uwgLwNhIQwmIa87dNFbE/NiQhfiVG0ZlCXl31wq1E1rpOyaE60Y9LvuZXDHWdVt2wd T5O0INb9zwGjpbVsX/GDeVRcGPl5hp5K7t/poKkM=
From: Subodh Iyengar <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abdcad8daebaea9938440799cf8c4b58bc3c49bbde92cf00000001177796c092a169ce149fd7cc@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1612@github.com>
Subject: [quicwg/base-drafts] are flow control frames really idempotent? (#1612)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b5fd4c08b195_32883ffae3ad45bc39311e"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/PyWM7IqG6dwna6jcYUdV2Vft4zk>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.27
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Jul 2018 03:17:24 -0000

we say that in the draft

"All QUIC frames are idempotent.  That is, a valid frame does not cause undesirable side effects or errors when received more than once"

However max stream data has one peculiar property, i.e. lets say a sender sends 4 packets:

packet 1:
max_data ->  value = 1000

packet 2:
max_data ->  value = 2000

packet 3:
max_data ->  value = 1000

packet 4:
max_data -> value = 200

Here the sender, either due to malice or a bug decides to send the same max data in 2 different packets.

Let's say no loss occurs and the receiver gets all the packets. Obviously the receiver could ignore the max data in packets 3 and 4, however a receiver who wants to help peers prevent flow control bugs from happening can know that the peer had sent packet 3 after packet 2 and had thus attempted to accidentally reduce the value. We currently do this in our implementation to help avoid nasty issues like this and has helped us detect bugs. However with some offline discussions people had mixed opinions about this one. One could say that the sentence about idempotence could warrant a receiver allowing this behavior, however what about packet 4 if the sender had clearly never sent the value 200 before?

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