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

Kazuho Oku <notifications@github.com> Tue, 26 November 2019 01:55 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654B3120FD0 for <quic-issues@ietfa.amsl.com>; Mon, 25 Nov 2019 17:55:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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_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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NE5KCTa8l4un for <quic-issues@ietfa.amsl.com>; Mon, 25 Nov 2019 17:55:02 -0800 (PST)
Received: from out-7.smtp.github.com (out-7.smtp.github.com [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F5AE120F9C for <quic-issues@ietf.org>; Mon, 25 Nov 2019 17:54:50 -0800 (PST)
Date: Mon, 25 Nov 2019 17:54:49 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1574733289; bh=jJTmUTMZLJJG0eJJZ6La1tqZWLdgdyEtboQ1d3fr+EA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=lr6ZD/e1hVL6eF7pZCZfQPzkpjE00JHdKkOIu8TmMlD9G9NqfzwFMRqatTmc3PkO7 WwjPVI/pt251f0Lhi9/H18Mpkh8TCfD5q2O+1wyEC7JmlPrQTI7EgtutOSpP4y/tLe jI1+WOeWbXJeIdk/yTqeXRooRyAIB4wZGR+5Roo0=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2WQTA3CTA5D3A7KE535G4GTEVBNHHB6TAYWQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3266/review/322687047@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3266@github.com>
References: <quicwg/base-drafts/pull/3266@github.com>
Subject: Re: [quicwg/base-drafts] Prevent Idle Timeout while Blocked (#3266)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ddc85e92f026_7e3f3fb9b70cd964133360"; 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
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/Juj8BqQoa81sfPlWczgFjAuFfTk>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
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, 26 Nov 2019 01:55:03 -0000

kazuho commented on this pull request.

@nibanks Corresponding text already exists in section 4.5.
>  An endpoint that is unable to open a new stream due to the peer's limits SHOULD send a STREAMS_BLOCKED frame ({{frame-streams-blocked}}).  This signal is considered useful for debugging.

My point is that we might want to update this too, as the sender should behave the same way when it is blocked by data flow control vs. when blocked by stream-level concurrency.

> @@ -2353,7 +2351,8 @@ processed successfully.  The timer is also restarted when sending an
 ack-eliciting packet (see {{QUIC-RECOVERY}}), but only if no other ack-eliciting
 packets have been sent since last receiving a packet.  Restarting when sending
 packets ensures that connections do not prematurely time out when initiating new
-activity.
+activity.  An endpoint should be careful to avoid an idle timeout if it is idle
+because of flow control (see {{data-flow-control}}).

Maybe change the reference to {{flow-control}}? Otherwise, blocked by stream concurrency would be out-of-scope.

Or, we might say "data flow control ({{data-flow-control}}) or stream concurrency ({{controlling-concurrency}})."

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3266#pullrequestreview-322687047