jlivingood
commented
1 year ago From Dave Taht in agreement:
The below framing is extremely good. The caveats are key phrases, like L4S "implemented right", and the conflation of NQB's behaviors with L4S's other behaviors. I don't have any real issue with the NQB codepoint! but...
L4S has been shown to be extremely RTT unfair, with issues in slow start, path jitter, latecomer disadvantages, the need for "policers", and so on. The only implementation I've seen of an L4S AQM allocates 9/10s of the bandwidth to it...
Over here, in the network neutrality section, is a pretty good set of links to existing law in the USA: https://libreqos.io/features/ It's a mess! A big legal problem is there doesn't seem to be agreed upon definitions for what prioritization OR deprioritization mean when it comes to packets vs a vs applications.
Section 2: ... NQB flows tend to be limited in their capacity needs - for example a DNS lookup will not need to consume the full capacity of an end user's connection - but the end user is highly sensitive to any delays.
There is at least one popular application where this is not the case: interactive video streaming of content rendered at the edge/server (eventually a high-quality, 60FPS video stream is transmitted). This can be read as that there is a significant trade-off between throughput and latency, and therefore other apps won’t be incentivized to use a low-latency service. See below comment on user-centric access control for more context on this. Maybe remove it all together?
Section 3 : Network Neutrality and Low Latency Networking
The document frames the discussion on net neutrality as “L4S is not a fast-lane”, and “it doesn’t affect other apps throughput”. This is risky and somewhat flawed. Zero-Rating services had the exact same characteristics (new capability, orthogonal to throughput) and ended-up regulated/banned both in US and Europe.
An alternative is “implemented right, L4S is fully-aligned with NN and has no impact on user choice and competition”. In case you find it useful, here is a rewrite of Section 3 that roughly captures this.
Network Neutrality (a.k.a. Net Neutrality, and NN hereafter) is a concept that can mean a variety of things within a country, as well as between different countries, based on different opinions, market structures, business practices, laws, and regulations. Generally speaking, NN means that Internet Service Providers (ISPs) should not limit user choice or affect competition between application providers. In the context of the United States' marketplace, it has come to mean that ISPs should not block, throttle, or deprioritize lawful application traffic, and should not engage in paid prioritization, among other things. The meaning of NN can be complex and ever changing, so the specific details are out of scope for this document. Despite that, NN concerns certainly bear on the deployment of new technologies by ISPs, at least in the US, and so should be taken into account in making deployment design decisions.
The principles below describe guidelines for a user-centric, application-agnostic, and monetizable L4S that we believe is aligned with NN frameworks and interpretations, at least in the U.S. and Europe.
Application-Agnostic L4S
NN demands that all applications should be treated the same by ISPs. As such, any application should be able to request access to an L4S service using the available marking techniques, and the network should forward packets through an L4S queue only based on such markings, without inferring or taking into consideration which application packets originate from.
User-Centric Monetization
To incentivize L4S deployments, ISPs should be able to monetize it. This can be controversial and perceived as paid prioritization. To avoid such conflicts, providers should charge users (and not application providers) for access to L4S, and follow common charging regimes used for best-effort services. For example, different price-points may be achieved by adjusting the throughput, monthly data allowance, or maximum latency of an L4S service. Providers should not limit the number or types of applications that can access L4S, as this would eventually conflict with the application-agnostic requirement described above.
User-Centric Access Control
In some cases, an end-user might want to control which applications have access to their L4S service. For example, they might have a 1GB monthly data cap for L4S, and opt to use it only for a gaming application instead of video calls. Or they may want to prevent a legacy device that uses DSCP markings from accessing L4S, as this could possibly degrade its operation. When needed, access control should be user-centric, and respect the application-agnostic requirement described above.
Access control that depends on application signature detection from a network router would violate the application-agnostic requirement, as it will be coarse, inaccurate, and will only support a limited number of popular applications supported by the network vendor (as explained in Section X.X). In contrast, access control that uses an Operating System’s permission capabilities is compatible with the application-agnostic requirement, as any application can trivially request access to such a permission and users can manage the decision. Similarly, a home WiFi router that allows users to control which devices can potentially access L4S provides an application-agnostic mechanism to deal with legacy devices.