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

[Martin Thomson <[e-mail]>]

martinthomson approved this pull request.



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