Subject: Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs
From: Pete Heist <[email-masked]>
To: Greg White <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Tue, 12 Nov 2019 10:10:59 +0100
List-Id: Transport Area Working Group <tsvwg.ietf.org>

> On Nov 11, 2019, at 10:51 PM, Greg White <[email-masked]> wrote:
> 
> ....actually, I think I misread your comment (and plot*).   The latency spike is _not_ for the TCP cubic flow, but rather for the Prague flow.
> 
> So, this is a case of fq immediately cutting the BDP in half due to the arrival of a second flow, but not providing sufficient congestion signaling to Prague to cause it to reduce its cwnd quickly.   The sluggish ramp up of the marking probability in the CoDel AQM being a mismatch to the Prague congestion response is the cause here.

Yes, I think that’s what’s happening. This would likely be solved by RFC 3168 bottleneck detection and transitioning to a compatible response. We usually use the term “standard” here as opposed to “sluggish”, but that reveals the two perspectives. :)

> *in my defense the flent plots aren't the friendliest for color-deficient viewers.

This can happen to me as well with green vs teal. I’ll see if we can’t improve that a bit.