Re: [quicwg/base-drafts] Improve Idle Timeout text (#3414)

Jana Iyengar <notifications@github.com> Thu, 12 March 2020 07:41 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 A041C3A1272 for <quic-issues@ietfa.amsl.com>; Thu, 12 Mar 2020 00:41:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.1
X-Spam-Level:
X-Spam-Status: No, score=-3.1 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, 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 arMjhZxy0t-V for <quic-issues@ietfa.amsl.com>; Thu, 12 Mar 2020 00:41:02 -0700 (PDT)
Received: from out-20.smtp.github.com (out-20.smtp.github.com [192.30.252.203]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E3A03A1271 for <quic-issues@ietf.org>; Thu, 12 Mar 2020 00:41:02 -0700 (PDT)
Date: Thu, 12 Mar 2020 00:41:00 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1583998861; bh=F8hYJvseuHrcwgKewuGnJRvlJFOilYDL5vgArOnZHKs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=uvM3wNoI/7j87TpcwWCRcl6x/uIkTfbwXInVEh0AGH5B+Rhg2yNerD0RNiBzTzCk0 5BDgobSk6VG/w4bujqYcmJB4Z7O4WixqPpMwWg6fsgbsVR27/RrSHBuFxAf+ei9uNN 8S+j69OkjtPWaNAna2MfBnLUThlYaze0glZCRW+c=
From: Jana Iyengar <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7HB3V4GYNNIA5G6B54OXEIZEVBNHHCCYK7ZU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3414/review/372367343@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3414@github.com>
References: <quicwg/base-drafts/pull/3414@github.com>
Subject: Re: [quicwg/base-drafts] Improve Idle Timeout text (#3414)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e69e78cef1fa_62283fb50b6cd9644205f7"; 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/1LugsVwT4oNEmSr4x3epCBnpgoU>
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: Thu, 12 Mar 2020 07:41:04 -0000

janaiyengar commented on this pull request.

a few suggestions

> @@ -2406,33 +2406,30 @@ source address.
 
 ## Idle Timeout {#idle-timeout}
 
-If the idle timeout is enabled by either peer, a connection is silently closed
+If a max_idle_timeout is specified by either peer in transport parameters

```suggestion
If a max_idle_timeout is specified by either peer in its transport parameters
```

> @@ -2406,33 +2406,30 @@ source address.
 
 ## Idle Timeout {#idle-timeout}
 
-If the idle timeout is enabled by either peer, a connection is silently closed
+If a max_idle_timeout is specified by either peer in transport parameters
+(see {{transport-parameter-definitions}}), a connection is silently closed

```suggestion
({{transport-parameter-definitions}}), the connection is silently closed
```

>  and its state is discarded when it remains idle for longer than the minimum of
-the max_idle_timeouts (see {{transport-parameter-definitions}}) and three times
-the current Probe Timeout (PTO).
+the max_idle_timeout values and three times the current Probe Timeout (PTO).

```suggestion
both max_idle_timeout values and three times the current Probe Timeout (PTO).
```

> +Restarting when sending packets ensures that connections do not prematurely time
+out when initiating new activity.  An endpoint might need to send ack-eliciting

```suggestion
Restarting this timer when sending a packet ensures that connections are not
closed after new activity is initiated.  An endpoint might need to send ack-eliciting
```

> +packets to avoid an idle timeout if it is unable to send application data due to
+being blocked on flow control limits (see {{flow-control}}) or is application
+limited, but expecting response data.

```suggestion
packets to avoid an idle timeout if it is expecting response data, but does
not have or is unable to send application data.
```

>  An endpoint that sends packets near the end of the idle timeout period
 risks having those packets discarded if its peer enters the draining state
 before the packets arrive.  If a peer could time out within a Probe Timeout
-(PTO; see Section 6.6 of {{QUIC-RECOVERY}}), it is advisable to test for
-liveness before sending any data that cannot be retried safely.  Note that it
-is likely that only applications or application protocols will know what
-information can be retried.
+(PTO; see Section 6.6 of {{QUIC-RECOVERY}}), it is advisable to send a PING or
+other ack-eliciting frames to test for liveness before sending any data that
+cannot be retried safely.  Note that it is likely that only applications or
+application protocols will know what information can be retried.

This is still a bit hard to read. I'll suggest the following text instead:
```
An endpoint that sends packets close to the effective timeout risks
having them be discarded at the peer, since the peer might enter its
draining state before these packets arrive. An endpoint can send
a PING or another ack-eliciting frame to test the connection for liveness
if the peer could time out soon, such as within a PTO (see Section 6.6 of
{{QUIC-RECOVERY}}). This is especially useful if any available application
data cannot be safely retried. Note that the application determines what data
is safe to retry.
```

-- 
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/3414#pullrequestreview-372367343