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: <0D4D02AB-3FA9-42F2-BBB9-5011C11527D5@akamai.com>
Date: Tue, 12 Nov 2019 18:14:19 +0100
Cc: Wesley Eddy <wes@mti-systems.com>,
 "rgrimes@freebsd.org" <rgrimes@freebsd.org>,
 "Black, David" <David.Black@dell.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E9B784CC-3E12-4689-8881-A07A2E8CC9DC@heistp.net>
References: <201911120204.xAC24jqO037009@gndrsh.dnsmgr.net>
 <c4a40e37-b451-8d13-f182-54cace8c759d@mti-systems.com>
 <0D4D02AB-3FA9-42F2-BBB9-5011C11527D5@akamai.com>
To: "Holland, Jake" <jholland@akamai.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/DlNa32eYyRalUIHi0PkoDC9_oJ8>
Subject: Re: [tsvwg] TCP Prague's RFC 5033 guidelines status?
Precedence: list

Thanks, this looks like a good start on an application of 5033 to L4S.=20=


I wanted to back up and mention that what led me to RFC5033 was a =
reference to it in section 5 of draft-fairhurst-tsvwg-cc. I=E2=80=99d =
been looking for guidance on how to evaluate SCE. Even though it=E2=80=99s=
 older, it resonated with me due to its emphasis on the need for =
scientific rigor when evaluating new CC proposals (thanks to the late =
Sally Floyd for that).

I admit I'll need to read and re-read some of the L4S literature =
referred to, as some of the below has likely been addressed in theory. =
Although there may be other theoretical questions, my interest is in =
ascertaining what if any more closed experiments are required before =
public experiments begin? I=E2=80=99ve put a few (*) next to what seems =
most important to me.

Comments below=E2=80=A6

Pete

> On Nov 12, 2019, at 8:19 AM, Holland, Jake <jholland@akamai.com> =
wrote:
>=20
> Thanks Wes, this is a helpful start.
>=20
> I think the [DualQ-Test] reference from dualq also probably fits
> in #2: difficult environments, with an examination of behavior in
> the presence of fixed completely unresponsive UDP traffic at
> various levels:
> https://riteproject.files.wordpress.com/2018/07/thesis-henrste.pdf
>=20
> What my request was about is that I suspect there's probably more,
> it's just hard to comb through it all to see what's missing.
>=20
> Best,
> Jake
>=20
>=20
> =EF=BB=BFOn 2019-11-11, 20:49, "Wesley Eddy" <wes@mti-systems.com> =
wrote:
>=20
> Thanks, you make good points.
>=20
> I noticed that it was done very clearly for CUBIC in=20
> https://tools.ietf.org/html/rfc8312 which looks like a great recent=20
> example of how the 5033 topics were each addressed.
>=20
> For Prague + L4S, I think we have a lot of material spread out in=20
> various places, and are pretty much covering all the bases to some=20
> extent, but lack a single place where it's all collected.
>=20
> Here are my thoughts on what we have:
>=20
> (1) Impact on Standard TCP
>=20
> Parts of Appendix A and Section 4 of l4s-id draft are relevant, e.g.=20=

> A.1.4 "Fall back to Reno-friendly congestion control on classic ECN=20
> bottlenecks"
>=20
> Results w/ CUBIC + Prague in github/heistp/sce-l4s-bakeoff and=20
> l4s.cablelabs.com data are relevant.
>=20
> Issue 16 results from l4s.cablelabs.com are relevant.
>=20
> 4.1.1 of the dualq doc is relevant.
>=20
> (2) Difficult Environments
>=20
> I'm not sure this is super-deeply investigated yet?
>=20
> Some parts of the dualq draft touch on it, though since dualq is a=20
> construction where the actual AQM algorithm(s) can vary, it's maybe=20
> sufficient that those AQMs are suitable for the environments they're=20=

> used in?
>=20
> Scenario 5 in github/heistp/sce-l4s-bakeoff and l4s.cablelabs.com =
tests=20
> may be one data point, though I think the gist of 5033 is wider on=20
> wireless access, etc.

Here=E2=80=99s a non-exhaustive list of difficult environments and their =
characteristics mentioned or implied in 5033. The two *=E2=80=99d are =
very common and may present challenges.

- wireless and other bursty links (*)
- asymmetric links and delays (*)
- very high and very low speed links
- high delay links (e.g. GEO sat)
- high BDP links
- intermittent link connectivity

> (3) Investigating a Range of Environments
>=20
> Section 4 and A.1.6 ("Scaling down to fractional congestion windows") =
of=20
> the l4s-id doc partly speak to this.  A.2.2 ("Faster than Additive=20
> Increase") is also partly relevant.
>=20
> The scenarios used for github/heistp/sce-l4s-bakeoff and=20
> l4s.cablelabs.com data have some datapoints and use different base=20
> delays, but I think the gist of this in 5033 is probably towards wider=20=

> sweeping of the underlying network rates, numbers of flows, and other=20=

> variables.

Some other conditions:

- bi-directional traffic (*)
- compatibility with other existing RFC3168 AQMs, e.g. RED and PIE =
(CoDel / fq_codel we started on)
- many flows in a bottleneck
- packet loss, corruption and re-ordering
- misbehaving senders, receivers or routers (really (6))

> (4) Protection Against Congestion Collapse
>=20
> A.1.3 ("Fall back to Reno-friendly congestion control on packet loss")=20=

> pretty much covers this?
>=20
> (5) Fairness within the Alternate Congestion Control Algorithm
>=20
> Section 4 and A.1.5 ("Reduce RTT dependence") of l4s-id are relevant. =20=

> Also A.2.3 ("Faster Convergence at Flow Start") is relevant.
>=20
> The two-flow cases in github/heistp/sce-l4s-bakeoff and=20
> l4s.cablelabs.com data are a simple case of this (2 flow cases /=20
> prage-vs-prague).
>=20
> (6) Performance with Misbehaving Nodes and Outside Attackers
>=20
> Section 8 of l4s-arch + Section 4 of dualq and covers this?
>=20
> Scenario 4 results from the github/heistp/sce-l4s-bakeoff and=20
> l4s.cablelabs.com tests have some relation to this also?

Scenario 4 covers the case of what happens if ECT(1) is set on all =
packets for a =E2=80=9Cclassic=E2=80=9D flow, and that seems to work as =
designed.

Could a flow instead set ECT(1) on only the =E2=80=9Cright=E2=80=9D =
packets, like only so many per RTT, in order to gain some advantage?

> (7) Responses to Sudden or Transient Events
>=20
> This could be related to parameter tuning of AQMs used in the dualq=20
> construction and to Prague, but I'm not sure it's applicable to the=20
> higher-level L4S architecture itself.

Might include:
- sudden congestion, capacity, and RTT changes (*)
- bottleneck shifts (*)
- multipath routing and routing changes

> (8) Incremental Deployment
>=20
> Section 6.3 of l4s-arch covers this?

Compatibility with existing RFC3168 AQMs due to the redefinition of CE =
was one of our main concerns here. Some of its impacts on fairness and =
TCP RTT have been explored in the =E2=80=9Cbakeoff=E2=80=9D tests.

There=E2=80=99s mention of it in l4s-arch 6.3.3 and it=E2=80=99s =
addressed further in the recent paper "TCP Prague Fall-back on Detection =
of a Classic ECN AQM=E2=80=9D.