Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <77BDEE23-E07C-4CED-A554-4774E66B1778@heistp.net>
Date: Mon, 10 Feb 2020 17:05:26 +0100
Cc: Dave Taht <dave@taht.net>,
 tsvwg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <7D22D3D0-98BB-4EAF-B99A-3712C057EEBE@gmx.de>
References: <87y2tctowj.fsf@taht.net>
 <77BDEE23-E07C-4CED-A554-4774E66B1778@heistp.net>
To: Pete Heist <pete@heistp.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/zisDVWqk1ut0PAhT8Aow7_wMjUM>
Subject: Re: [tsvwg] rrul yet?
Precedence: list



> On Feb 9, 2020, at 17:18, Pete Heist <pete@heistp.net> wrote:
>=20
>=20
>> On Feb 9, 2020, at 4:34 AM, Dave Taht <dave@taht.net> wrote:
>>=20
>> Has anyone done a rrul style benchmark yet? (flooding the uplink and
>> downlink with mixed traffic, especially one with asymmetric =
bandwidth)
>>=20
>> Probably my greatest concern with either approach was the gradual =
rate
>> reduction stuff would be too gradual when the return path is inflated
>> by other traffic.
>=20
> We have run rrul in a few different ways, one of which was a 50:1 =
asymmetric link with higher flow counts in the =E2=80=98wrong' =
direction.
>=20
> With SCE, the existing multiplicative backoff CE signal is still =
available as a backstop, when the SCE signal alone either isn=E2=80=99t =
enough or isn=E2=80=99t being responded to, without necessarily having =
to resort to drop. In a test like this, you=E2=80=99ll typically see =
both heavy SCE marking and CE marks as well.

Okay, any information on how L4S' dualq and TCPPrague deal with the same =
load?

Best Regards
	Sebastian