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

From: ianswett <[email-masked]>
Date: Tue, 20 Nov 2018 18:35:21 +0000 (UTC)

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

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

-- Commit Summary --

  * Restarting from idle

-- File Changes --

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

-- Patch Links --

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

---

From: MikkelFJ <[email-masked]>
Date: Tue, 20 Nov 2018 10:52:29 -0800

mikkelfj commented on this pull request.

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

How about slowly reducing the current window thorugh exponential decay down to initial window? Otherwise e.g. video might get quite chunky as buffers fill and the connection idles. But of course other connetions might have taken the bandwidth meanwhile, so it might not be a good idea after all, depending on decay speed.

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

---

From: ianswett <[email-masked]>
Date: Tue, 20 Nov 2018 10:57:58 -0800

@ianswett pushed 1 commit.

75482c7  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/2023/files/4149b3cf0b2048d8a235ab313094b1e636d91671..75482c7c90e0173ae771dcd509fa7c284b8ac670

---

From: ianswett <[email-masked]>
Date: Tue, 20 Nov 2018 11:25:24 -0800

5d9203f  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/2023/files/75482c7c90e0173ae771dcd509fa7c284b8ac670..5d9203fc67c1d562b7bd5afea1e365577007bda6

---

From: ianswett <[email-masked]>
Date: Tue, 20 Nov 2018 11:26:36 -0800

ianswett commented on this pull request.

+## Resumption from idle
+

I don't know of a best practice for doing what you're describing, so unless you can find one in a TCP RFC or elsewhere, I'm hesitant to recommend 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/2023#discussion_r235138733

---

From: MikkelFJ <[email-masked]>
Date: Tue, 20 Nov 2018 11:33:49 -0800

+## Resumption from idle
+

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/2023#discussion_r235141104

---

From: MikkelFJ <[email-masked]>
Date: Tue, 20 Nov 2018 12:05:00 -0800

+## Resumption from idle
+

FYI: I have not read this paper, except the abstract, but it seems to touch upon the current text (no my suggestion) related to pacing packets on idle restart https://www.isi.edu/~johnh/PAPERS/Visweswaraiah97b.pdf

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

---

From: MikkelFJ <[email-masked]>
Date: Tue, 20 Nov 2018 12:09:05 -0800

+## Resumption from idle
+

Again, only abstract read, ,but it speaks of decaying the cwnd on idle.
https://tools.ietf.org/html/rfc2861

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

---

From: ianswett <[email-masked]>
Date: Tue, 20 Nov 2018 12:12:42 -0800

+## Resumption from idle
+

5681 obsoletes 2581, but makes no mention of 2861.  I'll let @janaiyengar decide what to do here.

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

---

From: janaiyengar <[email-masked]>
Date: Tue, 20 Nov 2018 20:13:50 +0000 (UTC)

janaiyengar commented on this pull request.

> @@ -1040,6 +1040,24 @@ As an example of a well-known and publicly available implementation of a flow
 
+## 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
 
+## 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
 
+## 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
 
+## 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
 
+## 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
 
+## 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
 
+## 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}}."

+## Resumption from idle
+

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

---

From: ianswett <[email-masked]>
Date: Tue, 20 Nov 2018 12:15:53 -0800

2fde7b9  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/2023/files/5d9203fc67c1d562b7bd5afea1e365577007bda6..2fde7b97b2b0c8251e9391c0ff4f4c612c27e6f2

---

From: ianswett <[email-masked]>
Date: Tue, 20 Nov 2018 12:21:24 -0800

+## Resumption from idle
+

If the goal is to reduce bursts, I think we need to advocate for limiting the burst of a paced connection to nothing larger than the restarting window of an unpaced connection.

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

---

From: ianswett <[email-masked]>
Date: Tue, 20 Nov 2018 12:23:45 -0800

d776217  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/2023/files/2fde7b97b2b0c8251e9391c0ff4f4c612c27e6f2..d776217a9834a9b0017ab9002634160c0e87a145

---

From: MikkelFJ <[email-masked]>
Date: Tue, 20 Nov 2018 12:25:13 -0800

Can't comment on @janaiyengar's other comment for some reason. But my suggestion is only to decay exponentially, not to aggressively grow the window from where at landed.

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

---

From: janaiyengar <[email-masked]>
Date: Tue, 20 Nov 2018 15:16:53 -0800

janaiyengar approved this pull request.

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

---

From: ianswett <[email-masked]>
Date: Tue, 20 Nov 2018 15:21:28 -0800

Merged #2023 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/2023#event-1978726380