Re: [quicwg/base-drafts] Recovery Editorial Nits (#2667)

Jana Iyengar <notifications@github.com> Mon, 06 May 2019 23:39 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 AF18C120108 for <quic-issues@ietfa.amsl.com>; Mon, 6 May 2019 16:39:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.01
X-Spam-Level:
X-Spam-Status: No, score=-3.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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 ME_YhQvCbKXh for <quic-issues@ietfa.amsl.com>; Mon, 6 May 2019 16:39:36 -0700 (PDT)
Received: from out-19.smtp.github.com (out-19.smtp.github.com [192.30.252.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 981CA1200F8 for <quic-issues@ietf.org>; Mon, 6 May 2019 16:39:36 -0700 (PDT)
Date: Mon, 06 May 2019 16:39:35 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1557185975; bh=Os/Mz70OUQbvBWe8Zmryix1ersh/MPoPDaRl9/IJFmk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=JN4n8DuLuBoVqgT9vjxMInh93eGKrCBT2wM9/uRjSPITp7aAuO8fDrAUnsjylF/mh VF1TY90qlrC0hg2CrgKtNTTH49VutX72u0ATtcLV1XxK/Z9Yu3D5lNDcDWjpQXElrN 05qAOvN7M1u7h8ut1/jVe+cJPke9HQMUiDhngCUg=
From: Jana Iyengar <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2EZRHHP6SN2GVTYUV23X4DPEVBNHHBUPQDME@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2667/review/234246917@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2667@github.com>
References: <quicwg/base-drafts/pull/2667@github.com>
Subject: Re: [quicwg/base-drafts] Recovery Editorial Nits (#2667)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cd0c5b79d360_3f593fdcbdccd95c253796"; 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/En-yolTAvBfoMQ-eEbBLC4DDA8o>
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: Mon, 06 May 2019 23:39:39 -0000

janaiyengar commented on this pull request.

a few comments

> @@ -118,8 +118,8 @@ ACK-only:
 In-flight:
 
 : Packets are considered in-flight when they have been sent
-  and neither acknowledged nor declared lost, and they are not
-  ACK-only.
+  and neither acknowledged nor declared lost nor abandoned due
+  to keys being discarded, and they are not ACK-only.

suggestion: "Packets are considered in-flight when they have been sent and are not ACK-only, and they are not acknowledged, declared lost, or abandoned along with old keys."

> @@ -214,6 +214,13 @@ Most TCP mechanisms implicitly attempt to infer transmission ordering based on
 TCP sequence numbers - a non-trivial task, especially when TCP timestamps are
 not available.
 
+### Clearer end to a loss epoch

```suggestion
### Clearer Loss Epoch
```

> @@ -214,6 +214,13 @@ Most TCP mechanisms implicitly attempt to infer transmission ordering based on
 TCP sequence numbers - a non-trivial task, especially when TCP timestamps are
 not available.
 
+### Clearer end to a loss epoch
+
+QUIC may reduce cwnd several times on successive losses whereas TCP will keep

s/cwnd/congestion window

Also, this doesn't match the title of this section. I would not talk about the cwnd reduction here, instead focus on what a loss epoch is -- that no congestion window action should occur more than once per roundtrip time, since a controller only sees the response to any action it takes about a roundtrip time later. TCP and QUIC use packet numbers to figure out when this roundtrip ends, but QUIC does it more accurately than TCP, especially when multiple losses occur within the same roundtrip time.

> @@ -469,15 +476,16 @@ as TCP-NCR {{?RFC4653}}, to improve QUIC's reordering resilience.
 
 ### Time Threshold {#time-threshold}
 
-Once a later packet has been acknowledged, an endpoint SHOULD declare an earlier
-packet lost if it was sent a threshold amount of time in the past. The time
-threshold is computed as kTimeThreshold * max(SRTT, latest_RTT).
+Once a later packet has been acknowledged in the same packet number space, an

```suggestion
Once a later packet within the same packet number space has been acknowledged, an
```

> @@ -469,15 +476,16 @@ as TCP-NCR {{?RFC4653}}, to improve QUIC's reordering resilience.
 
 ### Time Threshold {#time-threshold}
 
-Once a later packet has been acknowledged, an endpoint SHOULD declare an earlier
-packet lost if it was sent a threshold amount of time in the past. The time
-threshold is computed as kTimeThreshold * max(SRTT, latest_RTT).
+Once a later packet has been acknowledged in the same packet number space, an
+endpoint SHOULD declare an earlier packet lost if it was sent a threshold amount
+of time in the past. To avoid declaring packets as lost too early, the time

```suggestion
of time in the past. To avoid declaring packets as lost too early, this time
```

> @@ -915,7 +919,7 @@ It is expected that implementations will be able to access this information by
 packet number and crypto context and store the per-packet fields
 ({{sent-packets-fields}}) for loss recovery and congestion control.
 
-After a packet is declared lost, it SHOULD be tracked for an amount of time
+After a packet is declared lost, it could be tracked for an amount of time

```suggestion
After a packet is declared lost, the endpoint can track it for an amount of time
```

-- 
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/2667#pullrequestreview-234246917