Subject: [quicwg/base-drafts] How long idle is idle? (#2138)

From: Martin Thomson <[email-masked]>
Date: Wed, 12 Dec 2018 21:49:35 -0800

[Section 7.8 of -recovery](https://quicwg.org/base-drafts/draft-ietf-quic-recovery.html#restart-after-idle) specifies rules for what a sender does when it starts sending after an idle period.  But surely this doesn't apply when the idle period is short.  Reading that text, an idle period of any duration would trigger this requirement, but I don't think that is the intent.  The period should be defined.

-- 
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/issues/2138

---

From: MikkelFJ <[email-masked]>
Date: Thu, 13 Dec 2018 01:55:13 -0800

I did propose an exponential decay in some other issue and added a link to some TCP RFC 2861 and research that touches upon this.
https://github.com/quicwg/base-drafts/pull/2023#discussion_r235152230

-- 
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/issues/2138#issuecomment-446908408

---

From: ianswett <[email-masked]>
Date: Thu, 13 Dec 2018 14:14:35 +0000 (UTC)

The intent is this is triggered after an idle period of any length.  As it says in the draft, the reason is to limit bursts into the network.

It turns out bursting 100 packets at once into the network almost always causes losses, and two solutions are pacing and resetting the CWND to a lower value out of idle and allowing ack-clocking to smooth the flow.

-- 
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/issues/2138#issuecomment-446982684

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Dec 2018 15:26:13 -0800

Idleness happens very frequently.  You are basically saying that you always have to pace.  Or that you can only burst packets up to the initial congestion window If that's the intent, please say so.

-- 
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/issues/2138#issuecomment-447158218

---

From: ianswett <[email-masked]>
Date: Fri, 14 Dec 2018 11:56:27 -0800

I think that's what the text does say.  If you think it's unclear, tell me and I can fix it or feel free to send a PR.

-- 
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/issues/2138#issuecomment-447437014

---

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

The text in Section 7.8 says that if you enter idle, then you leave in one of two ways: pace, or reduce your cwnd to init_cwnd.  We're choosing to not really spend energy on performance for the non-pacing cases, because pacing is an undocumented BCP.

When not pacing, it's reasonable to do something along the lines of what @mikkelfj suggests -- indeed that's roughly what NewCWV (RFC 7661) stipulates. I don't think we need to get into defining exactly how to do this, but I'll propose some text that allows senders to do some sort of slow decaying when 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/issues/2138#issuecomment-447508217

---

From: janaiyengar <[email-masked]>
Date: Tue, 18 Dec 2018 23:10:59 +0000 (UTC)

Closed #2138 via #2187.

-- 
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/issues/2138#event-2034347398