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

[ianswett <[e-mail]>]

ianswett commented on this pull request.

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

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.

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

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

> +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}}).

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