Re: [tsvwg] TCP Prague's RFC 5033 guidelines status?

[Pete Heist <[e-mail]>]

Thanks, this looks like a good start on an application of 5033 to L4S. 

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’d been looking for guidance on how to evaluate SCE. Even though it’s 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’ve put a few (*) next to what seems most important to me.

Comments below…

Pete

> On Nov 12, 2019, at 8:19 AM, Holland, Jake <[e-mail]> wrote:
> 
> Thanks Wes, this is a helpful start.
> 
> 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
> 
> 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.
> 
> Best,
> Jake
> 
> 
> On 2019-11-11, 20:49, "Wesley Eddy" <[e-mail]> wrote:
> 
> Thanks, you make good points.
> 
> I noticed that it was done very clearly for CUBIC in 
> https://tools.ietf.org/html/rfc8312 which looks like a great recent 
> example of how the 5033 topics were each addressed.
> 
> For Prague + L4S, I think we have a lot of material spread out in 
> various places, and are pretty much covering all the bases to some 
> extent, but lack a single place where it's all collected.
> 
> Here are my thoughts on what we have:
> 
> (1) Impact on Standard TCP
> 
> Parts of Appendix A and Section 4 of l4s-id draft are relevant, e.g. 
> A.1.4 "Fall back to Reno-friendly congestion control on classic ECN 
> bottlenecks"
> 
> Results w/ CUBIC + Prague in github/heistp/sce-l4s-bakeoff and 
> l4s.cablelabs.com data are relevant.
> 
> Issue 16 results from l4s.cablelabs.com are relevant.
> 
> 4.1.1 of the dualq doc is relevant.
> 
> (2) Difficult Environments
> 
> I'm not sure this is super-deeply investigated yet?
> 
> Some parts of the dualq draft touch on it, though since dualq is a 
> construction where the actual AQM algorithm(s) can vary, it's maybe 
> sufficient that those AQMs are suitable for the environments they're 
> used in?
> 
> Scenario 5 in github/heistp/sce-l4s-bakeoff and l4s.cablelabs.com tests 
> may be one data point, though I think the gist of 5033 is wider on 
> wireless access, etc.

Here’s a non-exhaustive list of difficult environments and their characteristics mentioned or implied in 5033. The two *’d 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
> 
> Section 4 and A.1.6 ("Scaling down to fractional congestion windows") of 
> the l4s-id doc partly speak to this.  A.2.2 ("Faster than Additive 
> Increase") is also partly relevant.
> 
> The scenarios used for github/heistp/sce-l4s-bakeoff and 
> l4s.cablelabs.com data have some datapoints and use different base 
> delays, but I think the gist of this in 5033 is probably towards wider 
> sweeping of the underlying network rates, numbers of flows, and other 
> 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
> 
> A.1.3 ("Fall back to Reno-friendly congestion control on packet loss") 
> pretty much covers this?
> 
> (5) Fairness within the Alternate Congestion Control Algorithm
> 
> Section 4 and A.1.5 ("Reduce RTT dependence") of l4s-id are relevant.  
> Also A.2.3 ("Faster Convergence at Flow Start") is relevant.
> 
> The two-flow cases in github/heistp/sce-l4s-bakeoff and 
> l4s.cablelabs.com data are a simple case of this (2 flow cases / 
> prage-vs-prague).
> 
> (6) Performance with Misbehaving Nodes and Outside Attackers
> 
> Section 8 of l4s-arch + Section 4 of dualq and covers this?
> 
> Scenario 4 results from the github/heistp/sce-l4s-bakeoff and 
> 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 “classic” flow, and that seems to work as designed.

Could a flow instead set ECT(1) on only the “right” packets, like only so many per RTT, in order to gain some advantage?

> (7) Responses to Sudden or Transient Events
> 
> This could be related to parameter tuning of AQMs used in the dualq 
> construction and to Prague, but I'm not sure it's applicable to the 
> higher-level L4S architecture itself.

Might include:
- sudden congestion, capacity, and RTT changes (*)
- bottleneck shifts (*)
- multipath routing and routing changes

> (8) Incremental Deployment
> 
> 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 “bakeoff” tests.

There’s mention of it in l4s-arch 6.3.3 and it’s addressed further in the recent paper "TCP Prague Fall-back on Detection of a Classic ECN AQM”.