[Ecn-sane] [Bloat] [iccrg] Fwd: [tcpPrague] Implementation and experimentation of TCP Prague/L4S hackaton at IETF104

[Sebastian Moeller]

Dear All,


> On Mar 20, 2019, at 00:59, Dave Taht <dave.taht at gmail.com> wrote:
> 
> On Tue, Mar 19, 2019 at 5:44 AM Greg White <g.white at cablelabs.com> wrote:
>> [...]
>> But, L4S has been demonstrated in real equipment and in simulation, and leverages an existing congestion
> 
> Not under circumstances I can control. That's Not Science.
[...]

It would be great if the L4S project maybe could help kick-start independent testing, by creating an sharing two VMs one with the appropriate client side patches and one with a L4S aware AQM (probably curvy RED to avoid the patent issue, assuming the patent does not cover curvyRED). So that it is easier to "kick" the tiers in a way that tests what the L4S project considers compliant clients/AQM. Personally I am interested to see how robust and reliable the  detection of non-L4S CE sources is and how well the L4S side of the AQM will tolerate CE-marked packets from non-L4S senders, or in other words how well the "isolation" works. And also how L4S endpoints will deal with SCE emitting AQMs on their path.
I admit that I have doubts that ECT(1), basically a single "constellation" of a 2-bit bitfield can serve as a replacement for a single independent bit in a single-bit bit-field, that seems required for real isolation of flows of different ECN-response types.

Best Regards
	Sebastian