Opened 3 years ago

Closed 2 years ago

#23 closed defect (fixed)

Implementation status

Reported by: wes@… Owned by: draft-ietf-tsvwg-l4s-arch@…
Priority: major Milestone: L4S Suite - WGLC Preparation
Component: l4s-arch Version:
Severity: - Keywords:

Description (last modified by wes@…)

There have been questions about implementation status.

Number of implementations, maturity, etc. are not well-understood in the working group, especially in terms of how these are tracking the draft updates, transport work, etc.

This was discussed at IETF 105 (issue "H"). It was mentioned at the open microphone by Pete Heist.

This is closely related to issues on testing concerns, IPR concerns, and deployment feasibility.

There may be some confusion in this discussion about L4S in the network versus "L4S transport" code at the endpoints, which probably need to be dealt with as distinct topics.

It would be helpful to hear more from vendors, operators, etc. that are working with L4S.

Change History (6)

comment:1 Changed 3 years ago by wes@…

  • Description modified (diff)

comment:2 Changed 3 years ago by ietf@…

If one read this issue cold one would imagine that no information about all the implementations was being provided.

I'm not sure what 'good' would look like? What is required here, that isn't already available?

Network implementations are certainly more mature (esp. the Linux reference implementation, Low Latency DOCSIS, and the shallow threshold variant of FQ_CoDel, but there are also two less mature radio-link implementations and a hi-speed switch implementation).

The Linux reference implementation of TCP Prague is a primary focus, on which other end-system work probably depends (for instance, integration into BBRv2), and it's coming together much more rapidly now. But there are also less complete implementations: in rmcat SCReAM and coming along in FreeBSD/TCP, and in QUIC.

Ultimately, all the references to the code (at least the open source or openly spec'd code) are grouped together on the L4S landing page and regularly given at the IETF, e.g. the 4 or so slides in the Jul'19 L4S status update. So if anyone doesn't understand how many, or how mature they are, or doesn't believe any of this, they only have to check it all out.

comment:3 Changed 3 years ago by jholland@…

I took Pete's comments to be about deployment feasibility and observed issues with the published linux implementation.

Just to explain why this was a reasonable ticket to open, in spite of the info provided to the wg: As he was reporting at the time, the Jul'19 status was that the published linux source was based on an obsolete kernel with known security flaws, making it unsuitable for deployment or for reliable testing (a point that had not been previously mentioned to the wg). IIRC there also wasn't yet a timeline on when more realistic testing would be possible, as well as open questions about whether it might cause any performance regressions. As this was a surprise to the external testers, there was some reasonable confusion.

It looks like that may have been fixed now with the latest using 5.4-rc3 (from ) if I'm reading it right, so now perhaps all that's missing is the new additions and an overview of how any previously presented results may have changed as a result.

To answer what 'good' would look like: it might be helpful to provide an Implementation section in one or more of the drafts, following the guidelines from

comment:4 Changed 3 years ago by pete@…

Yes, there were earlier concerns about the age and problems with the 3.x series Linux kernel version in use at the time. Some time after Montreal, I communicated with the L4S team offline for a short time as they got their public repo in shape so I could complete the bakeoff tests. I tested on their most recent tag as of 11/5/2019, and no longer have a concern that there's a functional implementation available for testing, so that may mean this issue can be closed unless there were other things contributing to its existence.

I would comment that although we recognize the border between the network (signaling mechanism) and endpoint (transport code), there is no working congestion control without both of them together. Thus, the two cannot be considered completely independently. I don't know what that means procedurally though.

comment:5 Changed 2 years ago by ietf@…

All are agreed that the original issue was a genuine problem but it is now resolved. See this thread:

The new suggestion that an implementation considerations section would be helpful has been addressed sufficiently (in the opinion of Jake who raised it), tho not ideally, by the existing references to implementations where relevant in the drafts. Specifically:

aqm-dualq-coupled-11 refers to the following implementations where relevant:

AQM implementations:

Scalable CC implementations:

It also has a Contributors section, which lists all the implementers and their implementations.

ecn-l4s-id-10 refers to the following implementations where relevant:

Scalable CC implementations:

l4s-arch-06 refers to the following implementations where relevant:

Scalable CC implementations:

  • TCP Prague [PragueLinux?],
  • QUIC Prague,
  • an L4S variant of the RMCAT SCReAM controller [RFC8298]
  • the L4S ECN part of BBRv2 [I-D.cardwell-iccrg-bbr-congestion-control] intended for TCP and QUIC.
  • more accurate ECN feedback for TCP (AccECN) [I-D.ietf-tcpm-accurate-ecn], [PragueLinux?].

AQM implementations:

  • DualPI2 [DualPI2Linux]
  • Curvy RED.
  • A DualQ Coupled AQM variant based on PIE implemented for Low Latency DOCSIS [DOCSIS3.1].

A full list of implementations has also been provided for the chairs slides for the tsvwg interim on 27-Apr-20:

This includes all the above, plus a closed source Nokia L4S WiFi? AP.

comment:6 Changed 2 years ago by wes@…

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.