Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Pete Heist <pete@heistp.net>
In-Reply-To: <D79022F7-7509-45C9-9ECF-D420AE255E60@cablelabs.com>
Date: Tue, 12 Nov 2019 10:10:59 +0100
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DF71D8AD-3C8A-4B7C-8F88-03A8AD6F8C9A@heistp.net>
References: <8321f975-dfe7-694c-b5cc-09fa371b9b61@mti-systems.com>
 <B58A5572-510E-42C7-8181-42A0BE298393@gmail.com>
 <D2E12331-F504-4D5F-B8E7-A1A5E98DDF7E@cablelabs.com>
 <2275E6A5-C8F8-477F-A24A-3E6168917DDF@gmail.com>
 <55F724CD-6E74-40D9-8416-D1918C2008DD@cablelabs.com>
 <BBE7C7A9-0222-4D84-BF27-8D5CAE2F995E@gmail.com>
 <6f189711-ffa0-90f4-fd16-3464ba4df3ce@mti-systems.com>
 <4A706B11-3239-4DAC-BE85-0B4BFF2D8FF8@heistp.net>
 <8B28ECE4-FF4B-4BB2-ACBE-80B30708F97E@cablelabs.com>
 <AAEA9AC2-B8A1-4837-A7C9-8EEA21A7C523@gmx.de>
 <D5D560CB-BC47-45BE-811E-E73E2D4909E3@cablelabs.com>
 <40B5DA8A-8290-41DC-8A2B-B9DE9661D605@heistp.net>
 <1D98B69D-5D15-4516-8851-119AE706FA7B@cablelabs.com>
 <D79022F7-7509-45C9-9ECF-D420AE255E60@cablelabs.com>
To: Greg White <g.white@CableLabs.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/lTdfBwRDomoBLxWweaiNGKAM1DM>
Subject: Re: [tsvwg] L4S status: #17 Interaction w/ FQ AQMs
Precedence: list


> On Nov 11, 2019, at 10:51 PM, Greg White <g.white@CableLabs.com> =
wrote:
>=20
> ....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.
>=20
> 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=E2=80=99s what=E2=80=99s happening. This would likely =
be solved by RFC 3168 bottleneck detection and transitioning to a =
compatible response. We usually use the term =E2=80=9Cstandard=E2=80=9D =
here as opposed to =E2=80=9Csluggish=E2=80=9D, 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=E2=80=99ll see if we =
can=E2=80=99t improve that a bit.