Re: [quicwg/base-drafts] Restarting from idle (#2023)

[janaiyengar <[e-mail]>]

janaiyengar commented on this pull request.



> @@ -1040,6 +1040,24 @@ As an example of a well-known and publicly available implementation of a flow
 pacer, implementers are referred to the Fair Queue packet scheduler (fq qdisc)
 in Linux (3.11 onwards).
 
+## Resumption from idle
+
+A connection is idle if bytes in flight is 0 and there is nothing

"if there are no bytes in flight"

> @@ -1040,6 +1040,24 @@ As an example of a well-known and publicly available implementation of a flow
 pacer, implementers are referred to the Fair Queue packet scheduler (fq qdisc)
 in Linux (3.11 onwards).
 
+## Resumption from idle
+
+A connection is idle if bytes in flight is 0 and there is nothing
+retransmittable to send.  This occurs when the connection is application

"no pending retransmittable data to send"

> @@ -1040,6 +1040,24 @@ As an example of a well-known and publicly available implementation of a flow
 pacer, implementers are referred to the Fair Queue packet scheduler (fq qdisc)
 in Linux (3.11 onwards).
 
+## Resumption from idle
+
+A connection is idle if bytes in flight is 0 and there is nothing
+retransmittable to send.  This occurs when the connection is application
+limited and after a verified retransmission timeout.  In order to limit the

"This can occur when the connection is application limited, or after a retransmission timeout." @pravb had some concerns about not doing this on unverified RTOs, about the safety of not reducing the cwnd if there was an rtt spike.

> @@ -1040,6 +1040,24 @@ As an example of a well-known and publicly available implementation of a flow
 pacer, implementers are referred to the Fair Queue packet scheduler (fq qdisc)
 in Linux (3.11 onwards).
 
+## Resumption from idle

```suggestion
## Restart after idle
```

> @@ -1040,6 +1040,24 @@ As an example of a well-known and publicly available implementation of a flow
 pacer, implementers are referred to the Fair Queue packet scheduler (fq qdisc)
 in Linux (3.11 onwards).
 
+## Resumption from idle
+
+A connection is idle if bytes in flight is 0 and there is nothing
+retransmittable to send.  This occurs when the connection is application
+limited and after a verified 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 pacing is used, the connection should limit the initial burst of packets to

"If the sender uses pacing"

> @@ -1040,6 +1040,24 @@ As an example of a well-known and publicly available implementation of a flow
 pacer, implementers are referred to the Fair Queue packet scheduler (fq qdisc)
 in Linux (3.11 onwards).
 
+## Resumption from idle
+
+A connection is idle if bytes in flight is 0 and there is nothing
+retransmittable to send.  This occurs when the connection is application
+limited and after a verified 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 pacing is used, 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 pacing is not used, the congestion window SHOULD be reset to the minimum of

"If the sender does not use pacing"

> @@ -1040,6 +1040,24 @@ As an example of a well-known and publicly available implementation of a flow
 pacer, implementers are referred to the Fair Queue packet scheduler (fq qdisc)
 in Linux (3.11 onwards).
 
+## Resumption from idle
+
+A connection is idle if bytes in flight is 0 and there is nothing
+retransmittable to send.  This occurs when the connection is application
+limited and after a verified 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 pacing is used, 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.

I don't think this initial burst bit is necessary. All you need to say is that if the sender uses pacing, the cwnd does not need to be reduced. How about "A sender that uses pacing can retain its congestion window through an idle period."

> +
+A connection is idle if bytes in flight is 0 and there is nothing
+retransmittable to send.  This occurs when the connection is application
+limited and after a verified 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 pacing is used, 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 pacing is not used, the congestion window SHOULD be reset to the minimum of
+the current congestion window and the initial congestion window.  If the
+slow start threshold is larger than the congestion window, the congestion window
+will grow back to the congestion window prior to idle via slow start.  This
+recommendation is based on Section 4.1 of {{?RFC5681}}.

Similarly, I would reduce this to a sentence and remove the sentence about slow start. I'm ok with leaving the ref to 5681 in here, but I would like to remove it in a later PR and replace it with more text explaining the rationale directly (instead of pointing to 5681). 

For now, how about "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}}."

> @@ -1040,6 +1040,21 @@ As an example of a well-known and publicly available implementation of a flow
 pacer, implementers are referred to the Fair Queue packet scheduler (fq qdisc)
 in Linux (3.11 onwards).
 
+## Resumption from idle
+
+A connection is idle if bytes in flight is 0 and there is nothing retransmittable
+to send.  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 pacing is used, 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 pacing is not used, the congestion window SHOULD be reset to the minimum of
+the current congestion window and the initial congestion window.  If the
+slow start threshold is larger than the congestion window, the congestion window
+will grow back to the congestion window prior to idle via slow start.
+
 ## Pseudocode

RFC 2861 describes how to do this exponentially, but that was always considered too aggressive and resulted in folks turning it off in real deployments.  The new one is RFC 7661, which reduces the cwnd once to max(cwnd/2, IW) and ssthresh to max(ssthresh, 3/4 x cwnd).  We could use these reductions here, though 7661 is an experimental RFC, since it has gone through TCPM review.

-- 
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/2023#pullrequestreview-176947468