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

Sebastian Moeller moeller0 at gmx.de
Wed Mar 20 06:17:11 EDT 2019

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

More information about the Bloat mailing list