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

Jana Iyengar <notifications@github.com> Wed, 20 November 2019 08:28 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 7DAE712004F for <quic-issues@ietfa.amsl.com>; Wed, 20 Nov 2019 00:28:06 -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 Zleb03vanqx4 for <quic-issues@ietfa.amsl.com>; Wed, 20 Nov 2019 00:28:05 -0800 (PST)
Received: from out-24.smtp.github.com (out-24.smtp.github.com [192.30.252.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04195120A83 for <quic-issues@ietf.org>; Wed, 20 Nov 2019 00:28:05 -0800 (PST)
Received: from github-lowworker-edec459.ac4-iad.github.net (github-lowworker-edec459.ac4-iad.github.net [10.52.18.32]) by smtp.github.com (Postfix) with ESMTP id 1FE726A1C20 for <quic-issues@ietf.org>; Wed, 20 Nov 2019 00:28:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1574238484; bh=lQ4K5DY6aqnauxmEzeUeEo3xKemC/oQLIteTOKS+VKk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=TK8D/KY0EUbplKgIdrawY1MKoQASxXHXy40gw8CY2d3s7O1b3atlWZCCitRdmTvvq 7M9EEqcQmmiPUy55IpEYwSnHLYkgrh7RPI1LyKPxnBDEEI6KDx4JidE1C+XPxtBGwu fLfqtBf4hslUmLDZJpauuCn7RetqgKdnlmCVuj5E=
Date: Wed, 20 Nov 2019 00:28:04 -0800
From: Jana Iyengar <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7U7DY7KXEGM7UM3F534IVZJEVBNHHB6TAYWQ@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/319659546@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_5dd4f91410ba8_4f593fe9feacd960138757"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: janaiyengar
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/6ZyX0am5k747NJJGdUJutIGqSOc>
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: Wed, 20 Nov 2019 08:28:06 -0000

janaiyengar 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 resend a DATA_BLOCKED or STREAM_DATA_BLOCKED frame when there are no
+ack-eliciting packets in flight.

I would add some text to the idle timeout section as well (section 10.2). Something like "An endpoint should be careful to avoid an idle timeout if it is idle because of flow control; see Section XX".

> @@ -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

Suggested rephrase: "If a sender is blocked for a period longer than the idle timeout ({{name-idle-timeout}}), the connection might get closed even when data is available for transmission. To keep the connection from closing, a sender SHOULD periodically send a STREAM_DATA_BLOCKED or DATA_BLOCKED frame when there are no ack-eliciting packets in flight."

-- 
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-319659546