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

[Jana Iyengar <[e-mail]>]

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