Re: [quicwg/base-drafts] Prevent Idle Timeout while Blocked (#3266)

ianswett <> Wed, 20 November 2019 01:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 18804120935 for <>; Tue, 19 Nov 2019 17:39:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 igKpwDFZ4g8M for <>; Tue, 19 Nov 2019 17:39:56 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 47619120143 for <>; Tue, 19 Nov 2019 17:39:48 -0800 (PST)
Date: Tue, 19 Nov 2019 17:39:47 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1574213987; bh=oL/rb/9Ug5VptaaQkeaRTCof25vncA3/vhZTweVkXMI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=bfDYsrwtld6XHTg4fvhDbxMASYG80O9H/jnRl+NmrNfknS2jOIPzBUF7BNmfVWLIt TbZPCt83AJySecmJdCG/xzJ3h693pJcmgjKGZ+hkvxZZ3iITSNXLKtLpUBjfsXu5BM ANtMtzOtxKK0shYU92aIZjx3eDR/ojDMk/O33TMA=
From: ianswett <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/3266/review/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Prevent Idle Timeout while Blocked (#3266)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dd49963583a9_7a3b3f882dacd95c20182"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
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: Wed, 20 Nov 2019 01:39:58 -0000

ianswett commented on this pull request.

> @@ -785,13 +785,12 @@ flow control limits.
 If a sender runs out of flow control credit, it will be unable to send new data
 and is considered blocked.  A sender SHOULD send a STREAM_DATA_BLOCKED or
 DATA_BLOCKED frame to indicate it has data to write but is blocked by flow
-control limits.  These frames are expected to be sent infrequently in common
-cases, but they are considered useful for debugging and monitoring purposes.
-A sender SHOULD NOT send multiple STREAM_DATA_BLOCKED or DATA_BLOCKED frames
-for the same data limit, unless the original frame is determined to be lost.
-Another STREAM_DATA_BLOCKED or DATA_BLOCKED frame can be sent after the data
-limit is increased.
+control limits.  If a sender is blocked for long enough it is possible for the
+connection to idle timeout, even though the data is actively queued to be sent.
+To prevent this idle timeout from occurring, the sender SHOULD continue to
+periodically send the STREAM_DATA_BLOCKED or DATA_BLOCKED frame.  One method is
+to immediately resend the frame on acknowledgment of the previous one if the

I tend to think this might be overly aggressive?  If 10 streams are blocked, there's no reason to send 10 frames an RTT, is there?

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