Subject: [quicwg/base-drafts] Allow alternate restarts after idle (#2187)

From: janaiyengar <[email-masked]>
Date: Fri, 14 Dec 2018 15:35:04 -0800

Closes #2138.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Allow alternate restarts after idle

-- File Changes --

    M draft-ietf-quic-recovery.md (15)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/2187.patch
https://github.com/quicwg/base-drafts/pull/2187.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/2187

---

From: ianswett <[email-masked]>
Date: Fri, 14 Dec 2018 15:48:29 -0800

ianswett approved this pull request.

One small suggestion, but LGTM

> @@ -1030,14 +1030,17 @@ application limited or after a retransmission timeout. In order to limit
 the size of bursts sent into the network, the behavior when restarting from
 idle depends upon whether pacing is used.
 
-If the sender uses pacing, the connection should limit the initial burst of
-packets to no more than the initial congestion window and subsequent packets
-SHOULD be paced. The congestion window does not change while the connection
-is idle.
+If the sender uses pacing, the congestion window MUST not increase and does not

Possibly the "MUST not increase CWND" part should move a paragraph up, since it's really not pacing specific?

-- 
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/2187#pullrequestreview-185324195

---

From: ianswett <[email-masked]>
Date: Fri, 14 Dec 2018 16:09:25 -0800

ianswett commented on this pull request.

 A sender that does not use pacing SHOULD reset its congestion window to the
-minimum of the current congestion window and the initial congestion window.
-This recommendation is based on Section 4.1 of {{?RFC5681}}.
+smaller of the current congestion window and the initial congestion window, as
+recommended for TCP (see Section 4.1 of {{?RFC5681}}).
+
+A sender MAY implement alternate mechanisms to update its congestion window
+after idle periods, such as those proposed for TCP in {{?RFC7661}}.

To be clear, we're not really expecting anyone to implement this, right?

-- 
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/2187#pullrequestreview-185327521

---

From: MikkelFJ <[email-masked]>
Date: Fri, 14 Dec 2018 16:42:25 -0800

mikkelfj commented on this pull request.

As formulated this does not permit bursts up to a decayed cwnd because init cwnd is required if not pacing.

-- 
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/2187#discussion_r241928333

---

From: janaiyengar <[email-masked]>
Date: Fri, 14 Dec 2018 17:00:25 -0800

janaiyengar commented on this pull request.

We do want to limit bursts to init cwnd. Beyond that, instead of describing alt mechanisms here, I think RFC 7661 offers a good and well thought out set of considerations.

-- 
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/2187#discussion_r241929896

---

From: janaiyengar <[email-masked]>
Date: Fri, 14 Dec 2018 17:00:48 -0800

@janaiyengar pushed 1 commit.

847edda4e164108ae9fcdaf87e73c4a425aeac37  restructure

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2187/files/a655ba684c4a9fc61c9fa147b69aa80d4d45c550..847edda4e164108ae9fcdaf87e73c4a425aeac37

---

From: janaiyengar <[email-masked]>
Date: Fri, 14 Dec 2018 17:01:53 -0800

I've restructured the section a bit more.

-- 
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/2187#issuecomment-447522230

---

From: MikkelFJ <[email-masked]>
Date: Sat, 15 Dec 2018 02:08:58 -0800

Right, I suspected as much, just wanted to be sure.

-- 
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/2187#discussion_r241944826

---

From: janaiyengar <[email-masked]>
Date: Sun, 16 Dec 2018 11:08:21 -0800

@ianswett: Take a look again -- I've made some changes.

-- 
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/2187#issuecomment-447667743

---

From: Martin Thomson <[email-masked]>
Date: Sun, 16 Dec 2018 19:16:06 -0800

martinthomson approved this pull request.

-SHOULD be paced. The congestion window does not change while the connection
-is idle.
-
-A sender that does not use pacing SHOULD reset its congestion window to the
-minimum of the current congestion window and the initial congestion window.
-This recommendation is based on Section 4.1 of {{?RFC5681}}.
+## Sending data after an idle period
+
+A sender is considered idle if it has no bytes in flight and no pending
+ack-eliciting data to send.  A sender can become idle when it is application
+limited or when it encounters a retransmission timeout.
+
+A sender's congestion window MUST not increase while it is idle.
+
+When a sender starts sending data after an idle period, it's sending rate SHOULD

```suggestion
When a sender starts sending data after an idle period, its sending rate SHOULD
```

> -SHOULD be paced. The congestion window does not change while the connection
-is idle.
-
-A sender that does not use pacing SHOULD reset its congestion window to the
-minimum of the current congestion window and the initial congestion window.
-This recommendation is based on Section 4.1 of {{?RFC5681}}.
+## Sending data after an idle period
+
+A sender is considered idle if it has no bytes in flight and no pending
+ack-eliciting data to send.  A sender can become idle when it is application
+limited or when it encounters a retransmission timeout.
+
+A sender's congestion window MUST not increase while it is idle.
+
+When a sender starts sending data after an idle period, it's sending rate SHOULD
+be decided as follows.

```suggestion
be decided as follows:
```

> +A sender is considered idle if it has no bytes in flight and no pending
+ack-eliciting data to send.  A sender can become idle when it is application
+limited or when it encounters a retransmission timeout.
+
+A sender's congestion window MUST not increase while it is idle.
+
+When a sender starts sending data after an idle period, it's sending rate SHOULD
+be decided as follows.
+
+  - If the sender uses pacing, it does not need to reduce its congestion
+    window. It SHOULD however pace the congestion window and MAY allow an
+    initial burst no larger than the initial congestion window.
+
+  - If the sender does not use pacing, it SHOULD reset its congestion window to
+    the smaller of the current congestion window and the initial congestion
+    window, as recommended for TCP (see Section 4.1 of {{?RFC5681}}).

Maybe ignore my suggestions and use this instead:

> When sending data after becoming idle, a sender MUST reset its congestion window to the initial congestion window (see blah), unless it paces the sending of packets.  A sender MAY retain its congestion window if it paces the sending of any packets in excess of the initial congestion window.

I realize that this changes the emphasis slightly, but I think that it's clearer and more succinct.

I still think that this is an abrupt transition, but I guess the answer to any complaint there is simply "pacing".

-- 
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/2187#pullrequestreview-185427318

---

From: MikkelFJ <[email-masked]>
Date: Mon, 17 Dec 2018 01:21:52 -0800

I don't understand this. "MAY allow initial burst no larger", does this it MAY also allow larger?

-- 
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/2187#pullrequestreview-185496255

---

From: ianswett <[email-masked]>
Date: Mon, 17 Dec 2018 08:28:43 -0800

I'm a bit worried we're subtly missing an important case we want to catch.

> -the size of bursts sent into the network, the behavior when restarting from
-idle depends upon whether pacing is used.
-

Probe timeout?  Also, we want the case after a PTO to be considered idle, correct?  But one may have data to send, so this text doesn't catch that.

How about "It MAY allow an initial burst as large as the initial congestion window and MUST pace out the rest of the congestion window."

Pacing is the answer.

-- 
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/2187#pullrequestreview-185676204

---

From: MikkelFJ <[email-masked]>
Date: Mon, 17 Dec 2018 08:45:27 -0800

better

-- 
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/2187#discussion_r242225239

---

From: MikkelFJ <[email-masked]>
Date: Mon, 17 Dec 2018 08:50:04 -0800

There is a degenerate case where traffic arrives in blocks just under init cwnd at a high rate. The application can then burst at a high frequency.

-- 
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/2187#discussion_r242227021

---

From: ianswett <[email-masked]>
Date: Mon, 17 Dec 2018 12:36:21 -0800

ianswett requested changes on this pull request.

I meant to un-approve this before.

-- 
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/2187#pullrequestreview-185786932

---

From: janaiyengar <[email-masked]>
Date: Mon, 17 Dec 2018 16:43:20 -0800

2133100198ca6801ec4c2f2caa3e0f62d8995efe  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/2187/files/b866ed6f97c9559ea5bf5c1479096d8edcc02b5d..2133100198ca6801ec4c2f2caa3e0f62d8995efe

---

From: janaiyengar <[email-masked]>
Date: Mon, 17 Dec 2018 16:43:28 -0800

2bbc1fffd379f3a6abe6b373105d9a122322f739  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/2187/files/2133100198ca6801ec4c2f2caa3e0f62d8995efe..2bbc1fffd379f3a6abe6b373105d9a122322f739

---

From: janaiyengar <[email-masked]>
Date: Mon, 17 Dec 2018 16:48:20 -0800

I've replaced retransmission with probe. 
Actually I think this entire second point is wrong now. A sender does not become idle on a PTO, it might become idle once loss is established, when an ACK is received.

-- 
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/2187#discussion_r242372103

---

From: janaiyengar <[email-masked]>
Date: Mon, 17 Dec 2018 16:49:46 -0800

Also, idle is when there's nothing in flight. I don't think we need the "pending data to send" bit.

-- 
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/2187#discussion_r242372376

---

From: janaiyengar <[email-masked]>
Date: Mon, 17 Dec 2018 16:57:56 -0800

I like this better. I'm using 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/2187#discussion_r242374078

---

From: janaiyengar <[email-masked]>
Date: Mon, 17 Dec 2018 16:58:44 -0800

6fdb947a4e20302cbb882154addf0cae03c66a9d  more changes

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2187/files/2bbc1fffd379f3a6abe6b373105d9a122322f739..6fdb947a4e20302cbb882154addf0cae03c66a9d

---

From: janaiyengar <[email-masked]>
Date: Mon, 17 Dec 2018 16:59:22 -0800

Ok, comments incorporated. I like @martinthomson's text, so I'm using that.

-- 
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/2187#issuecomment-448056532

---

From: ianswett <[email-masked]>
Date: Tue, 18 Dec 2018 02:28:27 +0000 (UTC)

This looks better, but I'm still a bit confused about the post-PTO case

> -application limited or after a probe timeout. In order to limit
+A sender is considered idle if it has no bytes in flight.  A sender can become

```suggestion
 A sender is idle if it has no bytes in flight.  A sender can become
```

-
-If the sender uses pacing, the connection should limit the initial burst of
-packets to no more than the initial congestion window and subsequent packets
-SHOULD be paced. The congestion window does not change while the connection
-is idle.
-
-A sender that does not use pacing SHOULD reset its congestion window to the
-minimum of the current congestion window and the initial congestion window.
-This recommendation is based on Section 4.1 of {{?RFC5681}}.
+
+## Sending data after an idle period
+
+A sender is considered idle if it has no bytes in flight.  A sender can become
+idle when it is application limited and has no data to send, or when it marks
+packets as lost (and therefore not in flight).

Is this aiming at the PTO case?

-- 
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/2187#pullrequestreview-185884412

---

From: Martin Thomson <[email-masked]>
Date: Tue, 18 Dec 2018 21:32:22 +0000 (UTC)

martinthomson commented on this pull request.

Or

```suggestion
 A sender becomes idle if it has no bytes in flight.  A sender can become
```

-- 
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/2187#discussion_r242713079

---

From: janaiyengar <[email-masked]>
Date: Tue, 18 Dec 2018 21:54:57 +0000 (UTC)

-

The text that was there was probably leftover from a while ago... at any rate there is no PTO case. There is nothing marked as lost on a PTO, and bytes in flight does not change on a PTO (modulo the two packets that are sent in response).  So a sender cannot become idle on a PTO.

-- 
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/2187#discussion_r242720105

---

From: janaiyengar <[email-masked]>
Date: Tue, 18 Dec 2018 13:55:16 -0800

adfc4a0d1dd6e4b8f819f97b30fa5f563af351d3  becomes

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2187/files/6fdb947a4e20302cbb882154addf0cae03c66a9d..adfc4a0d1dd6e4b8f819f97b30fa5f563af351d3

---

From: ianswett <[email-masked]>
Date: Tue, 18 Dec 2018 14:17:08 -0800

+A sender becomes idle if it has no bytes in flight.  A sender can become idle
+when it is application limited and has no data to send, or when it marks packets

```suggestion
 when it is application limited and has no data to send, or when it marks all packets
```

-- 
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/2187#pullrequestreview-186308773

---

From: ianswett <[email-masked]>
Date: Tue, 18 Dec 2018 14:17:28 -0800

-
+as lost (and therefore not in flight).

```suggestion
 as lost, and therefore not 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/2187#pullrequestreview-186308879

---

From: ianswett <[email-masked]>
Date: Tue, 18 Dec 2018 14:18:36 -0800

-

Can this also happen when all packets are acknowledged?  I'm not sure what the preferred behavior is in that case.  But the current text now properly captures the "my last PTO was acked and everything else was declared lost."

-- 
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/2187#discussion_r242727084

---

From: janaiyengar <[email-masked]>
Date: Tue, 18 Dec 2018 22:30:08 +0000 (UTC)

-

Yes, that is a fine case ... this is what we've always had, the RTO text was incorrect. Basically the sender goes idle as soon as bytes in flight goes to 0. Maybe that's all we need to say. I've removed more text to make this clearer.

-- 
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/2187#discussion_r242730224

---

From: janaiyengar <[email-masked]>
Date: Tue, 18 Dec 2018 14:31:27 -0800

1053a1f9b9f027f22b142fb321eb149281f623ed  simpler

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/2187/files/adfc4a0d1dd6e4b8f819f97b30fa5f563af351d3..1053a1f9b9f027f22b142fb321eb149281f623ed

---

From: ianswett <[email-masked]>
Date: Tue, 18 Dec 2018 14:42:11 -0800

-- 
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/2187#pullrequestreview-186317232

---

From: janaiyengar <[email-masked]>
Date: Tue, 18 Dec 2018 15:10:59 -0800

Merged #2187 into master.

-- 
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/2187#event-2034347396