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

Kazuho Oku <> Tue, 31 July 2018 10:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F4089130E7E for <>; Tue, 31 Jul 2018 03:36:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qdRNYX8QApDa for <>; Tue, 31 Jul 2018 03:36:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4839D130E05 for <>; Tue, 31 Jul 2018 03:36:01 -0700 (PDT)
Date: Tue, 31 Jul 2018 03:36:00 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1533033360; bh=5gpozPza0lNqofTVj3IAb1V89aYDQOvupuM+l82YShg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=B7gcAohvTUKEnLcatJLEVPSJkKkAu4h0l8UI0aQjmX9o7DgtUMk7IM4b4KltbQNZV AAUgn7XuTY1wW0yEi2JOuv/k/zd86MnQFibPJqpCSSQ0KS6MlPMGFUFBVWPu0l7sz0 eqcbZ6RYdWeQqNWDn+a9yzO9Iuc2Y8KSk6tLMuDo=
From: Kazuho Oku <>
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_5b603b9042847_4b713f9b780d45b43168ea"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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 10:36:06 -0000

> I didn't say it's impossible, but it would add a lot of code for saving a tiny number of bytes, occasionally.

FWIW, my understanding is it's actually simple to implement the optimal way. What you would do is:
* transmit the maximum when `max(acked_max, inflight_max)` is below the threshold
* when receiving an ack for the max frame, update the `acked_max` and `inflight_max`
* when deeming a packet that contained the max frame as lost, reset `inflight_max` to `acked_max` if the number of max frames in flight is zero, otherwise you leave `inflight_max` as-is. Then, you check if transmission of the maximum is necessary by referring to the rule above

This strategy works well in QUIC v1, because packets are deemed lost in the order they are sent, and there is a guarantee in the logic that packets that are sent later contain a equal-to or greater maximum. The logic is not "perfect" when multipath is involved, though I would assume that it would work well enough in practice.

Regarding the issue, I am fine with allowing receivers to raise protocol error when they see the issue. I would oppose to making that a MUST though.

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