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: <87y2tctowj.fsf@taht.net>
Date: Sun, 9 Feb 2020 17:18:30 +0100
Cc: tsvwg@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <77BDEE23-E07C-4CED-A554-4774E66B1778@heistp.net>
References: <87y2tctowj.fsf@taht.net>
To: Dave Taht <dave@taht.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/vdkYdHXT4AtT6zOSgXMk-Wfwrv4>
Subject: Re: [tsvwg] rrul yet?
Precedence: list


> 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.

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.

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.