Subject: [quicwg/base-drafts] Pacing when under-utilizing the Congestion Window (#2686)

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 10 May 2019 02:07:54 -0700

"Bursting more than an intial window’s worth of data into the network might cause short-term congestion and losses."
• Is that really "more than...", I think the evidence was that a larger IW (as in QUIC) can lead to congestion.
• We could explain burst size and scenarios, or could simply say something like:
"Bursting an initial window’s worth of data into the network can cause short-term congestion and losses for some path conditions."
(This also fixes /intial/initial)?

-- 
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/2686

---

From: ianswett <[email-masked]>
Date: Fri, 10 May 2019 03:02:52 -0700

I think we should address this in PR #2675

-- 
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/2686#issuecomment-491234587

---

From: ianswett <[email-masked]>
Date: Fri, 10 May 2019 03:08:37 -0700

Linux pacing has an initial burst of 10 packets, followed by pacing, so this is intended to allow for that style of sending.  In which case, I think "more than" is the right term?

I think the evidence you have in mind is some data presented early on that pacing + IW32 had lower losses than no pacing and IW10?  That gap largely is driven by the large initial burst out of quiescence without pacing, which would be mitigated by sending a 10 packet burst and pacing the rest(or doing some form of slow start after idle).

-- 
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/2686#issuecomment-491236249

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 10 May 2019 05:25:29 -0700

Ah, my reading of the text led me in a different direction - I think we can now talk.

( I know Google shared data on IW10 and also later on other IW proposals. I also think I have seen other analysis that suggested that a larger IW can have an impact - IW10, or larger - can have collateral damage to flows sharing a bottleneck. In this case, because there is no ACK-clocking. )

Could I propose describing limiting the max burst size and enabling pacing for any remaining packets sent above this using the remaining (cwnd-max_burst). My reading is that the current text sets the max_burst size to IW. That is certainly one choice, and could be an upper limit. I am less clear that IW (the startup cwnd) should always be the same as the maximum burst size. Some SCTP implementation uses 4 packets, and I suspect that there could be cases where someone proposed a larger IW, but retained a max_burst that is lower than the increased 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/2686#issuecomment-491270604

---

From: ianswett <[email-masked]>
Date: Fri, 10 May 2019 05:44:32 -0700

I think making IW the max burst size, rather than the recommended burst size is sensible.  I've certainly seen real-world traces where bursting 4 packets would not have caused loss, but 10 did.

Text suggestions on the PR very welcome.

-- 
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/2686#issuecomment-491275769

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 10 May 2019 16:35:19 -0700

@gorryfair, I think you might be talking about a general max burst size, where the recovery draft (and @ianswett) is trying to talk about an "initial" window's size -- the size of a burst after quiescence. Is that right? I think we need to do some wordsmiting, but I want to make sure that we're talking about the same thing first.

-- 
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/2686#issuecomment-491457523

---

From: MikkelFJ <[email-masked]>
Date: Fri, 10 May 2019 23:02:53 -0700

>  general max burst size

Is there such a thing. I'm wondering: if you use pacing, you still want to cluster your transmissions so you don't get too frequent timer interrupts unless the network adapter is capable of pacing. So how do you decide the granularity of bursts when 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/2686#issuecomment-491482905

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 11 May 2019 01:37:34 -0700

That's a different thing -  pacing shouldn't mean you can't have (smallish) bursts.

-- 
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/2686#issuecomment-491492028

---

From: Gorry Fairhurst <[email-masked]>
Date: Sat, 11 May 2019 01:47:10 -0700

In response to Jana: I think it would be a good step to first make sure we understand the same by IW - which is initial cwnd, and somewhat dependent on RTT - and a function of the capacity; and max_burst; which isn't related to RTT, but could be related to when it is helpful to "pace". As a starting point, RFC4960 recommends max_burst as 4. Would we agree  for instance, largest(max_burst) <= 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/2686#issuecomment-491492725

---

From: ianswett <[email-masked]>
Date: Mon, 13 May 2019 18:15:57 -0700

The current text(before my outstanding PR) does not mention out of quiescence anymore.  However, upon re-reading the text, I think it could be clearer, so I updated it in PR #2675.

-- 
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/2686#issuecomment-492041882

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 16 May 2019 18:50:27 -0700

Gorry: Yes, I agree that micro-bursts ought to be smaller than IW. That's sensible, I think, but we really don't have a best practice for micro-bursts that we can point to (I just remembered that I had written a [draft](https://tools.ietf.org/html/draft-iyengar-burst-mitigation-01) with mallman 14 years ago on trying to specify micro-burst behavior!).

Yes, RFC 4960 uses a simple micro-burst of 4 segments, but that was based on RFC 3390, which used to limit the initial window to at most 4 segments. That's changed now, but I'd be wary of reflecting that change onto micro-bursts, because the analysis is quite different.

So while I agree that largest(max_burst) <= IW, I think talking about max_burst adds something new to what the draft is currently talking about. The draft is simply using IW for both connection start-up and noting that as a known upper bound for bursts. That is not the same as specifying max_burst however.

I think we ought to say something for senders coming out of an app limited period. (Perhaps we should say that bursting SHOULD be limited in the absence of pacing and add a note to various past max_burst limits without specifying a new one?)

I'm not keen to specify a max_burst here (but I'm not sure if that's a tenable position).

-- 
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/2686#issuecomment-493289281

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 22 May 2019 14:52:54 +0000 (UTC)

I'm not advocating a max burst size of 4 (although I do believe this is safe, other sizes larger may also be safe), however my thought was that the draft infers IW as a safe size to burst - I don't know that this is always true - especially if we look to the future use of a larger IW. You could (I think you do) argue that IW is an upper bound to this safe burst size without pacing.

I will try just a little more: 
• I think we **should** limit the cwnd when coming out of an app-limited period. 
• I think we should limit a burst <= some size or that pacing is needed, or if not then it MUST (!) reduce to a safe IW.

Does that help?

-- 
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/2686#issuecomment-494837702