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

[Wesley Eddy <[e-mail]>]

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.

(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.

(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?

(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.

(8) Incremental Deployment

Section 6.3 of l4s-arch covers this?