Subject: Re: [quicwg/base-drafts] congestion window increase on every ACKed packet could result in bursty sends (#3094)

From: Tommy Pauly <[email-masked]>
Date: Wed, 15 Jan 2020 15:31:19 -0800

Bringing conversation in from the list:

With regards to #3232, one of the things we found in testing was that it could (a) still allow an implementation to be vulnerable to too much bursting (the original problem), but more importantly (b) locked receivers into an ack pattern of acking every other packet. My main concern is that this causes problems if receivers want to experiment with and change acking strategies going forward in way that otherwise would be fine.

One way to look at the problem described by this issue is that the existing text has a minor underspecification, in which it has the notion of a burst limit but says nothing about the frequency of such bursts. Two "bursts" of 10MSS that are sent within a couple nanoseconds are really one burst that's too big. Another way of fixing this is to remove even the specification of the 10MSS limit if we really don't want too much text about the non-pacing cases.

Essentially, what this comes down to is: pace, or even if you don't pace, you need to not send bursts above some frequency; and if you don't set some pacing timers, you'll likely underutilize the link.

-- 
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/3094#issuecomment-574906214

---

From: Martin Thomson <[email-masked]>
Date: Wed, 15 Jan 2020 19:14:40 -0800

I'm going to put this out there: the answer is MUST pace.

You might formalize this by saying the number of packets sent in any interval `t` cannot exceed `cwnd * 2 * t / RTT` by more than the initial cwnd (i.e., the 10MSS).  That allows for bursting, but requires a period of quiet either preceding or following any burst.

-- 
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/3094#issuecomment-574962313

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 21 Jan 2020 10:44:14 -0800

@martinthomson Yes, it does largely reduce to "implementations MUST pace" (even if the pacing algorithm isn't very nuanced, in which case you'll perform poorly).

The formalization of the rate, one option for which was specified in #3351, I think is the heart of what should be done 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/issues/3094#issuecomment-576822317