Subject: Re: [quicwg/base-drafts] Define idle period for congestion control (#2555)

From: Praveen Balasubramanian <[email-masked]>
Date: Sun, 07 Apr 2019 09:00:20 -0700

@ianswett pacing or limiting burst is the right idea. TCP RFC limits the burst to IW but it says do that after an idle period of an RTO. Presumably the authors and community considered that period to be small enough that network capacity / conditions hadn't changed drastically. 

Implementation wise how would we do this without a timer? If not pacing, when would one decide to cut cwnd back to restart cwnd (say IW)? 

-- 
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/2555#issuecomment-480603574

---

From: ianswett <[email-masked]>
Date: Wed, 10 Apr 2019 12:57:53 -0700

Your interpretation of RFC5661 looks correct and is different from what's in the QUIC recovery doc.  But the implications are that it's ok to send an unlimited sized burst into the network as long as you only drained the pipe very recently.  I think that recommendation is a poor one unless the window sizes are fairly small(in which case they'd be close to IW10 anyway).

The sender is bursting packets into the network, which previously did not cause loss because they were ack-clocked, but one or more buffers on the network doesn't have enough space for the full CWND.  It seems likely this could cause losses for other flows sharing the link as well.  This could happen frequently in HTTP applications such as DASH video playback.

NewCWV is already referenced for decaying CWND after idle.  I could change the text to say nothing about reducing CWND to IW upon full idle and instead say you shouldn't burst more than IW into the network at once ever, and senders may use pacing, ACK-clocking, and/or timers to accomplish that?

https://tools.ietf.org/html/rfc7661 may also be relevant to this topic?

-- 
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/2555#issuecomment-481839350

---

From: Praveen Balasubramanian <[email-masked]>
Date: Wed, 10 Apr 2019 13:21:41 -0700

I guess the bigger question is what are we attempting to document in this draft. Is it whats in the TCP standard RFCs OR what most current TCP implementations do OR what the Linux kernel implementation does? By documenting NewReno instead of CUBIC we've chosen to not document the state-of-the-art and erred on the side of simplicity. In the spirit of that I think handling idle period and app limited states are optimizations for better network citizenship on cetrtain type of networks and not a hard requirement.

For this particular issue I'd like to point out that the Windows TCP implementation has worked fine without handling the idle period (not capping cwnd burst and neither pacing). The idle cwnd restart knob in Windows is off by defualt and I believe Google TCP turns it off on Linux as well.

Yes RFC 7661 is relevant and I think I cited it on the application limited case handling issue. I think there is a fine balance between managing burst size and taking advantage of TSO like optimizations. For example in WAN and DC bulk flows it might better to burst higher than IW with TSO for CPU efficiency than to pace and on the Internet pacing might be better.  

But I like your direction on this since it sidesteps what is meant by "idle". How about framing it as a suggestion and not a requirement. Something along the lines of:

Bursts of more than IW into the network at once may cause losses. Implemementations should consider using pacing, ACK-clocking, and/or timers to minimize bursts.

Paging @janaiyengar to this issue as well.

-- 
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/2555#issuecomment-481847107

---

From: ianswett <[email-masked]>
Date: Wed, 10 Apr 2019 20:33:03 +0000 (UTC)

My goal is to document the best practices and reference existing RFCs whenever possible.  And yes, my understanding is that everyone disables slow start after idle, so I'd like to come up with something I think is more likely to be deployed.

When QUIC was started, Cubic wasn't an RFC, which is the other reason we documented Reno instead of Cubic, FYI.

I'll write up a PR based on your suggestion and hopefully we can get some text we all think is acceptable.

-- 
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/2555#issuecomment-481850840

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 10 Apr 2019 19:02:15 -0700

RFC7661 is already cited in the section, and it was added there to defer to it so we didn't have to delve into details in this doc.

I think what we're really discussing here is whether we need the MUST in the sentence "When sending data after becoming idle, a sender MUST reset its congestion window to the initial congestion window".  I'm in agreement with what I'm sensing here -- that we don't need a requirement, but we can discuss the implications of various decisions here and current best practices.

Higher-level note, yeah, we always wanted to document current best practices, rather than what was in TCP or even linux TCP.  I think most things came from linux TCP because that was what we were familiar with.

FWIW, agreed that Cubic wasn't an RFC at the time, but it was close to becoming one, and we did discuss it.  We decided that it was too complex and adds a ton more complexity to this document. We wanted to have something simple but good enough that implementations could have as a starting point, and then move on to more esoteric algorithms as deployments needed.

(I'll disagree that Cubic is the best known CC at the moment -- unless you're talking about DC environments, it's not.)

-- 
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/2555#issuecomment-481936247

---

From: ianswett <[email-masked]>
Date: Wed, 10 Apr 2019 19:18:08 -0700

Thanks for the discussion, I updated #2605 based on this, though I'm a bit concerned that SHOULD is too weak in regards to bursts into the network.  Then again, if that's what Windows is doing, maybe we have to accept the reality of current deployments?

-- 
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/2555#issuecomment-481939041

---

From: mirjak <[email-masked]>
Date: Mon, 15 Apr 2019 09:52:45 +0000 (UTC)

Given that I think that the general guidance for QUIC is "use pacing", I think a "MUST reset to IW if not paced" is actually the right thing to do to support that pacing gets implemented with QUIC from the start. 

-- 
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/2555#issuecomment-483186136