Subject: [quicwg/base-drafts] Fix spelling and style consistency nits (#3946)

From: Lars Eggert <[email-masked]>
Date: Thu, 23 Jul 2020 01:08:19 -0700

You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3946

-- Commit Summary --

  * Fix spelling and style consistency nits

-- File Changes --

    M draft-ietf-quic-transport.md (32)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3946.patch
https://github.com/quicwg/base-drafts/pull/3946.diff

-- 
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/3946

---

From: Martin Thomson <[email-masked]>
Date: Thu, 23 Jul 2020 07:52:54 -0700

@martinthomson commented on this pull request.

> @@ -3667,12 +3667,12 @@ acknowledgements.
 
 An endpoint measures the delays intentionally introduced between the time the
 packet with the largest packet number is received and the time an acknowledgment
-is sent.  The endpoint encodes this delay in the Ack Delay field of an ACK
+is sent.  The endpoint encodes this delay in the ACK Delay field of an ACK

I think that this is good.

However, some of the other uses here refer to a concept and that is tricky.  We don't really define "ACK delay" as a concept and we probably should.

> @@ -3720,7 +3720,7 @@ containing that information is acknowledged.
   unless the endpoint has sent a RESET_STREAM for that stream.  Once an endpoint
   sends a RESET_STREAM frame, no further STREAM frames are needed.
 
-* ACK frames carry the most recent set of acknowledgements and the Ack Delay
+* ACK frames carry the most recent set of acknowledgements and the ACK delay

This refers to the field so it should be "ACK Delay field"

> +  the cost of lower resolution.  Because the receiver doesn't use the ACK delay
   for Initial and Handshake packets, a sender SHOULD send a value of 0.

This refers to the field, so it should be "ACK Delay field" again.

> @@ -3509,7 +3509,7 @@ guidance offered below seeks to strike this balance.
 ### Sending ACK Frames {#sending-acknowledgements}
 
 Every packet SHOULD be acknowledged at least once, and ack-eliciting packets
-MUST be acknowledged at least once within the maximum ack delay. An endpoint
+MUST be acknowledged at least once within the maximum ACK delay. An endpoint

This looks like the only place we use "ACK delay" as a concept.  We might be better referring to the max_ack_delay transport parameter.

-- 
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/3946#pullrequestreview-454213994

---

From: Lars Eggert <[email-masked]>
Date: Thu, 23 Jul 2020 07:55:03 -0700

@larseggert commented on this pull request.

The principle that I thought was used elsewhere, and which I tried to apply here, was to call it "ACK Delay" when talking about the frame field, and "ACK delay" otherwise.

-- 
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/3946#discussion_r459511771

---

From: Lars Eggert <[email-masked]>
Date: Thu, 23 Jul 2020 07:55:31 -0700

OK

-- 
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/3946#discussion_r459512175

---

From: Lars Eggert <[email-masked]>
Date: Thu, 23 Jul 2020 07:55:36 -0700

OK

-- 
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/3946#discussion_r459512247

---

From: Lars Eggert <[email-masked]>
Date: Thu, 23 Jul 2020 07:55:44 -0700

Will make the change

-- 
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/3946#discussion_r459512378

---

From: Lars Eggert <[email-masked]>
Date: Thu, 23 Jul 2020 07:59:18 -0700

Actually, this seems to refer to the value, not the field. ("ACK frames carry" the value.)

-- 
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/3946#discussion_r459515105

---

From: Lars Eggert <[email-masked]>
Date: Thu, 23 Jul 2020 08:04:03 -0700

@larseggert pushed 1 commit.

19a53b39e44af9eb58a67964bfbb28d179842549  Address some of @martinthomson's review comments

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3946/files/6e32e4692e3cc0e685420ee2ed45d6e1bb5cda6a..19a53b39e44af9eb58a67964bfbb28d179842549

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 23 Jul 2020 13:57:18 -0700

@janaiyengar commented on this pull request.

Thanks, Lars, a few suggestions.

We shouldn't use "ACK delay" without defining it, and if we do, I would suggest using "acknowledgement delay" instead.

 frame; see {{frame-ack}}.  This allows the receiver of the ACK to adjust for any

```suggestion
frame; see {{frame-ack}}.  This allows the receiver of the ACK frame to adjust for any
```

how about "and the acknowledgement delay from the largest acknowledged packet ({{host-delay}})" ?

> @@ -5284,8 +5284,9 @@ ACK Delay:
   to the power of the value of the ack_delay_exponent transport parameter set by
   the sender of the ACK frame; see {{transport-parameter-definitions}}.  Scaling
   in this fashion allows for a larger range of values with a shorter encoding at
-  the cost of lower resolution.  Because the receiver doesn't use the ACK Delay
-  for Initial and Handshake packets, a sender SHOULD send a value of 0.
+  the cost of lower resolution.  Because the receiver doesn't use the value in
+  the ACK Delay field for Initial and Handshake packets, a sender SHOULD send a

```suggestion
  the ACK Delay field of Initial and Handshake packets, a sender SHOULD send a
```

-- 
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/3946#pullrequestreview-454479546

---

From: Lars Eggert <[email-masked]>
Date: Thu, 23 Jul 2020 22:57:14 -0700

Applying Jana's change.

-- 
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/3946#discussion_r459864806

---

From: Lars Eggert <[email-masked]>
Date: Thu, 23 Jul 2020 23:01:53 -0700

0b04498bc7d167a2d7118675244d182bd99cd5fc  ACK delay -> acknowledgement delay (ACK Delay always refers to the field)

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3946/files/19a53b39e44af9eb58a67964bfbb28d179842549..0b04498bc7d167a2d7118675244d182bd99cd5fc

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 24 Jul 2020 18:39:20 -0700

> +  indicated in the Largest Acknowledged field, was received by this peer.  This
+  acknowledgement delay in the ACK Delay field is scaled by multiplying the
+  encoded value by 2 to the power of the value of the ack_delay_exponent
+  transport parameter set by the sender of the ACK frame; see
+  {{transport-parameter-definitions}}.  Scaling in this fashion allows for a
+  larger range of values with a shorter encoding at the cost of lower
+  resolution.  Because the receiver doesn't use the value in the ACK Delay field
+  of Initial and Handshake packets, a sender SHOULD send a value of 0.

This text was already confusing, and probably needs more rework. For this PR though, I would suggest something like: "The ACK Delay field carries an encoded acknowledgement delay. The delay is decoded by multiplying the value in the ACK Delay field by 2 ..."

-- 
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/3946#pullrequestreview-455250591

---

From: ianswett <[email-masked]>
Date: Mon, 27 Jul 2020 18:29:22 -0700

@ianswett commented on this pull request.

I agree with Jana that the "ACK Delay" paragraph could use a bit more work, hopefully my suggestions are helpful.

> @@ -3720,11 +3720,11 @@ containing that information is acknowledged.
 
-* ACK frames carry the most recent set of acknowledgements and the Ack Delay
-  from the largest acknowledged packet, as described in
-  {{sending-acknowledgements}}. Delaying the transmission of packets
-  containing ACK frames or resending old ACK frames can cause the peer to
-  generate an inflated RTT sample or unnecessarily disable ECN.
+* ACK frames carry the most recent set of acknowledgements and the
+  acknowledgement delay from the largest acknowledged packet, as described in

Ack Delay is the name of the field in the ACK frame, so I thought the old text was correct?

> @@ -5279,13 +5279,14 @@ ACK Delay:
 
 : A variable-length integer representing the time delta in microseconds between
   when the ACK frame was sent and when the largest acknowledged packet, as

```suggestion
  when the largest acknowledged packet, as indicated by the
```

> @@ -5279,13 +5279,14 @@ ACK Delay:
 
 : A variable-length integer representing the time delta in microseconds between
   when the ACK frame was sent and when the largest acknowledged packet, as
-  indicated in the Largest Acknowledged field, was received by this peer.  The
-  value of the ACK Delay field is scaled by multiplying the encoded value by 2
-  to the power of the value of the ack_delay_exponent transport parameter set by
-  the sender of the ACK frame; see {{transport-parameter-definitions}}.  Scaling
-  in this fashion allows for a larger range of values with a shorter encoding at
-  the cost of lower resolution.  Because the receiver doesn't use the ACK Delay
-  for Initial and Handshake packets, a sender SHOULD send a value of 0.
+  indicated in the Largest Acknowledged field, was received by this peer.  This

```suggestion
  Largest Acknowledged field, was received and the ACK frame was sent.  This
```

-- 
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/3946#pullrequestreview-456237364

---

From: Lars Eggert <[email-masked]>
Date: Mon, 27 Jul 2020 22:37:00 -0700

It depends on whether the text is supposed to mean that the ACK frame carries the ACK Delay field, or if it carries the acknowledgment delay value. I assumed the latter.

-- 
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/3946#discussion_r461329495

---

From: Lars Eggert <[email-masked]>
Date: Mon, 27 Jul 2020 22:38:22 -0700

d347e055e64905342ab343226045438614e7c5ff  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3946/files/0b04498bc7d167a2d7118675244d182bd99cd5fc..d347e055e64905342ab343226045438614e7c5ff

---

From: Lars Eggert <[email-masked]>
Date: Mon, 27 Jul 2020 22:38:29 -0700

3480bc22c2dd8c3465c2f3175de61b57474ef21a  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3946/files/d347e055e64905342ab343226045438614e7c5ff..3480bc22c2dd8c3465c2f3175de61b57474ef21a

---

From: Lars Eggert <[email-masked]>
Date: Mon, 27 Jul 2020 22:45:41 -0700

@larseggert pushed 21 commits.

6bfa25a4eda6b4efe52fb802940b0efb04d15f99  Current time PTO clarification
a5cc128e346c5d5ac0111a8a192fdc682ba4a3dd  Update draft-ietf-quic-recovery.md
58f73149cd0bc83afa499877ac092635a541a44c  Update draft-ietf-quic-recovery.md
61584650b49075d6645d6d14f6c6fdc8450c234e  Better example of persistent congestion
2780f26cc63a9d5143abc08731cadcabadf37e27  use PTO
6d16cc98ecc8caaa02896d5eca57b2552c9af33b  write out
cb5635178e68203d1ce58044a77db2a1805a8a7a  capitalize
58d973c9fa322b7b33866eb275a8932ce7a9a0c8  Fix spelling and style consistency nits
1e2504601352a8c6c7940fc2bff1f19e60d162aa  Fix spelling and style consistency nits
658e19d623bd1183c3d2fde2d08614f5fb12463c  Move transport error codes to a separate subsection.
fcfb51f4b530affc97635d5d2032cd5208156900  Merge pull request #3948 from larseggert/recovery-nits-lars
aaaf057ad85694ea7152a965956652df0a8e8212  Merge pull request #3947 from larseggert/tls-nits
42aed511f0e3931533b35106b182c8f2dd885095  Merge pull request #3952 from bencebeky/bencebeky-quic-transport-error
e0aa78966fc74475b6a5ef8d12d9472497cdfd2d  Merge pull request #3911 from quicwg/ianswett-current-time
bae4459886c4cfb0cb58af9268f78a64b4a38bdc  kazuho's and martin's comments
f5b7fc54911f5708f30df45f1a25a641a73fee0e  lint
af66c0e3f788133fcaec5b29699257ffd6739c82  Merge pull request #3929 from quicwg/jri/change-example
6d7b4e0b9bc42501b2daf1cca7bc8276f2873d73  Fix spelling and style consistency nits
8ef2052af5e848e867e53ac277709ee2cc0f6f7d  Address some of @martinthomson's review comments
551461ee6bcef774ae89695f3aa045dbd71c54ed  ACK delay -> acknowledgement delay (ACK Delay always refers to the field)
71edf40189a46ad6d71d94b03c5e4c4ffa1aced7  Address more review comments

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3946/files/3480bc22c2dd8c3465c2f3175de61b57474ef21a..71edf40189a46ad6d71d94b03c5e4c4ffa1aced7

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 30 Jul 2020 05:54:58 -0700

yes, in the context of the sentence, `acknowledgement delay` is more appropriate.

-- 
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/3946#discussion_r462974462

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 30 Jul 2020 06:01:35 -0700

@janaiyengar approved this pull request.

This is basically good, and it should be merged so it doesn't rot.

-- 
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/3946#pullrequestreview-458376502

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 30 Jul 2020 06:02:32 -0700

@martinthomson : Can you merge this once you're done?

-- 
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/3946#issuecomment-666350394

---

From: Martin Thomson <[email-masked]>
Date: Thu, 30 Jul 2020 07:51:17 -0700

This seems to be reiterating a bunch of other changes.

> @@ -5278,14 +5278,15 @@ Largest Acknowledged:
 ACK Delay:
 
-  when the ACK frame was sent and when the largest acknowledged packet, as
+  when largest acknowledged packet, as indicated in the Largest Acknowledged

```suggestion
  when the largest acknowledged packet, as indicated in the Largest Acknowledged
```

> @@ -5278,14 +5278,15 @@ Largest Acknowledged:
 ACK Delay:
 
 : A variable-length integer representing the time delta in microseconds between
-  when the ACK frame was sent and when the largest acknowledged packet, as
-  indicated in the Largest Acknowledged field, was received by this peer.  The
-  value of the ACK Delay field is scaled by multiplying the encoded value by 2
-  to the power of the value of the ack_delay_exponent transport parameter set by
-  the sender of the ACK frame; see {{transport-parameter-definitions}}.  Scaling
-  in this fashion allows for a larger range of values with a shorter encoding at
-  the cost of lower resolution.  Because the receiver doesn't use the ACK Delay
-  for Initial and Handshake packets, a sender SHOULD send a value of 0.
+  when largest acknowledged packet, as indicated in the Largest Acknowledged
+  field, was received and the ACK frame was sent. The ACK Delay field carries
+  this encoded time delta. It is decoded by multiplying the value in the ACK

```suggestion
  this encoded time difference. It is decoded by multiplying the value in the ACK
```

-- 
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/3946#pullrequestreview-458433692

---

From: ianswett <[email-masked]>
Date: Thu, 30 Jul 2020 07:58:35 -0700

In some cases, you changed Ack Delay to ACK Delay, and in others you changed ACK Delay to ACK delay.  I believe I prefer "ACK Delay", but the main goal is consistency?  Or maybe I just can't see the diffs properly because of other PRs that were merged since this one started.

> @@ -1695,7 +1707,7 @@ No significant changes.
 
 - Path validation can be used as initial RTT value (#2644, #2687)
 - max_ack_delay transport parameter defaults to 0 (#2638, #2646)
-- Ack Delay only measures intentional delays induced by the implementation
+- ACK delay only measures intentional delays induced by the implementation

Up above 'Delay' is capitalized, unless I'm missing something.

-- 
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/3946#pullrequestreview-458482741

---

From: Lars Eggert <[email-masked]>
Date: Thu, 30 Jul 2020 08:28:19 -0700

e8a7246a7972d3a92d231aac60cbbae514c4ae5e  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3946/files/71edf40189a46ad6d71d94b03c5e4c4ffa1aced7..e8a7246a7972d3a92d231aac60cbbae514c4ae5e

---

From: Lars Eggert <[email-masked]>
Date: Thu, 30 Jul 2020 08:28:33 -0700

8a50ae770b235b1fd3254b90d0a9bc283e250e77  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3946/files/e8a7246a7972d3a92d231aac60cbbae514c4ae5e..8a50ae770b235b1fd3254b90d0a9bc283e250e77

---

From: Lars Eggert <[email-masked]>
Date: Thu, 30 Jul 2020 08:29:44 -0700

There should only be "ACK Delay" for the ACK frame field and "acknowledgment delay" for the value/the concept. Let me double check this.

-- 
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/3946#discussion_r463082114

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 30 Jul 2020 08:31:34 -0700

> @@ -378,7 +378,7 @@ default values.
 On subsequent RTT samples, smoothed_rtt and rttvar evolve as follows:
 
 ~~~
-ack_delay = min(Ack Delay in ACK Frame, max_ack_delay)
+ack_delay = min(ACK Delay in ACK frame, max_ack_delay)

```suggestion
ack_delay = min(acknowledgement delay from ACK frame, max_ack_delay)
```
This is the decoded value, not the encoded bits

-- 
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/3946#pullrequestreview-458516143

---

From: Lars Eggert <[email-masked]>
Date: Thu, 30 Jul 2020 08:31:51 -0700

f92cb25a04e813a91099e8dcca667a0f402d0625  Update draft-ietf-quic-recovery.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3946/files/8a50ae770b235b1fd3254b90d0a9bc283e250e77..f92cb25a04e813a91099e8dcca667a0f402d0625

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 30 Jul 2020 08:32:48 -0700

> @@ -7475,7 +7479,7 @@ Substantial editorial reorganization; no technical changes.
 - You don't always need the draining period (#871)
 - Stateless reset clarified as version-specific (#930, #986)
 - initial_max_stream_id_x transport parameters are optional (#970, #971)
-- Ack Delay assumes a default value during the handshake (#1007, #1009)
+- ACK delay assumes a default value during the handshake (#1007, #1009)

```suggestion
- ACK Delay assumes a default value during the handshake (#1007, #1009)
```

-- 
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/3946#pullrequestreview-458517297

---

From: Lars Eggert <[email-masked]>
Date: Thu, 30 Jul 2020 08:33:01 -0700

So there are some cases of "ACK delay" left, which I will change to "acknowledgment delay".

-- 
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/3946#discussion_r463084403

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 30 Jul 2020 15:33:09 +0000 (UTC)

> +- Include ACK delay in RTO(and TLP) computations (#981)
+- ACK delay in SRTT computation (#961)

```suggestion
- Include ACK Delay in RTO(and TLP) computations (#981)
- ACK Delay in SRTT computation (#961)
```

-- 
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/3946#pullrequestreview-458517622

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 30 Jul 2020 08:33:16 -0700

```suggestion
- ACK Delay only measures intentional delays induced by the implementation
```

-- 
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/3946#pullrequestreview-458517746

---

From: Lars Eggert <[email-masked]>
Date: Thu, 30 Jul 2020 08:33:35 -0700

I didn't make changes to the changelogs, since they will be removed anyway. Should I have?

-- 
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/3946#discussion_r463084779

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 30 Jul 2020 08:33:42 -0700

The only ones that have "ACK delay" instead of "ACK Delay" are in the changelog

-- 
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/3946#pullrequestreview-458518178

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 30 Jul 2020 08:34:51 -0700

@martinthomson : "reiterating a bunch of other changes" - What do you mean?

-- 
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/3946#issuecomment-666463889

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 30 Jul 2020 08:35:42 -0700

This was a change,  I'm reverting it

-- 
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/3946#discussion_r463086068

---

From: Lars Eggert <[email-masked]>
Date: Thu, 30 Jul 2020 15:39:02 +0000 (UTC)

8919206b422be7b3073d993086b4092d82328876  ACK delay -> acknowledgment delay

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3946/files/f92cb25a04e813a91099e8dcca667a0f402d0625..8919206b422be7b3073d993086b4092d82328876

---

From: Martin Thomson <[email-masked]>
Date: Thu, 30 Jul 2020 08:53:16 -0700

> +| t=6    | Send packet #7 (app data)  |
+| t=8    | Send packet #8 (PTO 1)     |
+| t=12   | Send packet #9 (PTO 2)     |
+| t=12.2 | Recv acknowledgement of #9 |
+
+Packets 2 through 8 are declared lost when the acknowledgement for packet 9 is
+received at t = 12.2.
+
+The congestion period is calculated as the time between the oldest and newest
+lost packets: 8 - 1 = 7.  The duration for establishing persistent congestion
+is: 2 * 3 = 6.  Because the threshold was reached and because none of the
+packets between the oldest and the newest lost packets were acknowledged, the
+network is considered to have experienced persistent congestion.
+
+While this example shows the occurrence of PTOs, they are not required for
+persistent congestion to be established.

@janaiyengar this is what I mean.  I think that this was in one of your PRs.

-- 
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/3946#pullrequestreview-458536075

---

From: Martin Thomson <[email-masked]>
Date: Thu, 30 Jul 2020 08:53:43 -0700

-QUIC error codes are 62-bit unsigned integers.
+## Transport Error Codes {#transport-error-codes}

@janaiyengar and this was from Bence.

-- 
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/3946#pullrequestreview-458536438

---

From: Lars Eggert <[email-masked]>
Date: Thu, 30 Jul 2020 08:57:08 -0700

Yeah, that is not a change I made.

-- 
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/3946#discussion_r463100948

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 30 Jul 2020 09:04:35 -0700

@lars, I think you need to rebase.

-- 
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/3946#issuecomment-666490025

---

From: Lars Eggert <[email-masked]>
Date: Thu, 30 Jul 2020 09:26:43 -0700

@larseggert pushed 48 commits.

065a6bd49dc0ddc7a1fb6b7b8a2142834b0158af  Version field <-> Version is not invariant
6b19c710bd1ea0df6553a314a2fc473f776b55f0  Version is for endpoints
d1e84109bcf74cc2fb4c0961effc56bd7966b393  change error to PROTOCOL_VIOLATION when receiving an invalid RCID frame
8d15c9b4a61a391541b7344166cb60f431bca1a0  3x amplification limit for CONNECTION_CLOSE
2d92d2c893add972496120d364e881af55c70e11  No RTT samples, no persistent congestion
414498f28aff12124a94fd5ffc5c7c2ece8105bf  Update draft-ietf-quic-recovery.md
b10404aba157fc11c01b3cbd62b359988bb3d614  4-byte identifier rather than integer
4479b16ed2d268284f7777d5ceb0935fcbdfd950  Merge branch 'master' into version-not
642cc0f0de4dd9160feea5b6727aeab5fdd4c306  Fixup xref and s/numbers/values
13cfae81cd06270203423bbf93d6ce294dbc676e  May use 64+bit CIDs as address validation
5a790e1484d9eef476a63248bd8b2b5a3f91cdee  Update draft-ietf-quic-recovery.md
eabdc5c82c92ef0077d368a58c9f02e7f16b1394  Update draft-ietf-quic-recovery.md
a5cfbdcf73f306a3cd2c3dc80159d7883d2121a8  Update draft-ietf-quic-recovery.md
918e823125d0111b7ab1c62268d2a8df880f1178  Update draft-ietf-quic-transport.md
c2d50c6f103af8f66f2985f4d82861772b37fc99  Update draft-ietf-quic-transport.md
7590ad3639cfb3cabd918498cad2ee93d90d25fa  Update draft-ietf-quic-transport.md
6874d0047957ab40acba32937cc915fb2fb47a8a  Updates from MT, Jana and Kazuho's suggestions
89e99d1428500ac413cb5197afd67631290ed09b  Update draft-ietf-quic-recovery.md
4139dce450ec3c8f9e9bf658d6245e6a11426c51  Update draft-ietf-quic-recovery.md
1acc648093ef6782cea2bf3942a66471d170b2cd  Update draft-ietf-quic-recovery.md
3ddca85d4b885e053a7312f02af4dfb49bb9d3ea  Kazuho's suggestion
7f6999a60d3ccd687f3592a00370b2a29af8f7bc  Require coalesced packets to have the same connection ID
e4601fe7238b8cc101915888ad0585a673efef16  Update draft-ietf-quic-recovery.md
92b25a11d37ad2b86082763b5e07a08ec2af6c93  Fix spelling and style consistency nits
203377ea35d22d5fdc226ce424fabe019e8ba1e9  Emphasize still talking about sending (#3934)
d9368bd94f4e7c638617239793ff2b7db05849c6  which -> that where appropriate & related nit fixes
7c4acb7c19474b355b170c9dc70512938f81065d  Incorporate @afrind's suggestion
c0c3f4ad4cff5d816d200518edab82fa888f04bd  Merge pull request #3889 from quicwg/ianswett-no-rtt
134f481f96637252e932f10d3c272e002257eb42  Merge pull request #3861 from marten-seemann/fix-invalid-retire-connection-id-error-code
edf21647c5b4c34e875a16f1ae432e425e701757  Merge pull request #3864 from quicwg/close-amplification
f329f7dd96213db18aad78f3325eac44b5d80f5e  Merge pull request #3785 from quicwg/version-not
4cf260c202baa9ea4ab033bd14e87bd7f1abfd57  Merge pull request #3930 from quicwg/same-connection-id
ca51fd116c60868e392720170768807380119032  Merge pull request #3924 from quicwg/ianswett-dcid-address-validation
e907711312e7c36c85346910d0dbec4f6ee8d211  Wrap
c9d42addbc7f1090ac4bc9b02274dbd68a8eb0b5  Merge pull request #3964 from larseggert/which-that
c674decf9a93a16590c3e082b31081df186c2af4  Fix spelling and style consistency nits
1459a733cfdeedf746d4656aa29db976df391e70  Address some of @martinthomson's review comments
8e6c89112cbbff4d1300548a90dfe0d1d9cca758  ACK delay -> acknowledgement delay (ACK Delay always refers to the field)
386adc0f6a2a7e71504e7f67daa781c65fdd75c8  Fix spelling and style consistency nits
2661d0da74ce589c19bd974597474e15f037e2ce  Address some of @martinthomson's review comments
480964c94eed11d838ac6a1ff94d981830d00813  ACK delay -> acknowledgement delay (ACK Delay always refers to the field)
2de86bac9de2f32bd85f08279ccdf9e18743d075  Update draft-ietf-quic-transport.md
99c51f87b58c85ecdee09d75f6c8a277d6bdaf04  Update draft-ietf-quic-transport.md
23e317fad34adf9695a396b190c7529df8b5fcd4  Update draft-ietf-quic-transport.md
0eeb392f68010a2adf134342fe94c04dacdf9a46  Update draft-ietf-quic-transport.md
69c4c91626adfc5ea8064a6f07c0481d5255bbb5  Update draft-ietf-quic-recovery.md
dafba8b0c3da5b3a26a43c921e89d5a25624086b  ACK delay -> acknowledgment delay
45a8abb9d649e1f85a6905f4898045ecb9831324  Merge branch 'recovery-nits' of github.com:larseggert/base-drafts into recovery-nits

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3946/files/8919206b422be7b3073d993086b4092d82328876..45a8abb9d649e1f85a6905f4898045ecb9831324

---

From: Lars Eggert <[email-masked]>
Date: Thu, 30 Jul 2020 09:27:46 -0700

Yeah, I tried to rebase, but I guess that just failed spectacularly :-(

-- 
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/3946#issuecomment-666506760

---

From: Lars Eggert <[email-masked]>
Date: Thu, 30 Jul 2020 09:29:54 -0700

OK, there is now way I will untangle this tonight. I guess the easiest is just to start the PR over.

-- 
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/3946#issuecomment-666507948

---

From: Martin Thomson <[email-masked]>
Date: Thu, 30 Jul 2020 09:45:26 -0700

Don't worry, I'll fix it.  I'm almost done.

-- 
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/3946#issuecomment-666517149

---

From: Martin Thomson <[email-masked]>
Date: Thu, 30 Jul 2020 09:46:19 -0700

Merged manually and pushed.

-- 
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/3946#issuecomment-666517578

---

From: Martin Thomson <[email-masked]>
Date: Thu, 30 Jul 2020 09:46:20 -0700

Closed #3946.

-- 
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/3946#event-3604806417

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 30 Jul 2020 13:37:17 -0700

Thanks, @mt! The diff still looks quite terrible. Where did you push to?

-- 
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/3946#issuecomment-666680025

---

From: Martin Thomson <[email-masked]>
Date: Thu, 30 Jul 2020 22:40:36 -0700

I fixed the branch, merged to master, and pushed directly.  It's naughty, but I've found that sometimes you have to do this or you spend forever debugging git.

-- 
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/3946#issuecomment-666935293