| Internet-Draft | ISP L4S Deployment Design | May 2023 |
| Livingood | Expires 24 November 2023 | [Page] |
The IETF's Transport Area Working Group (TSVWG) has finalized experimental RFCs for Low Latency, Low Loss, Scalable Throughput (L4S) and new Non-Queue-Building (NQB) per hop behavior. These documents do a good job of describing a new architecture and protocol for deploying low latency networking. But as is normal for many such standards, especially those in experimental status, certain deployment design decisions are ultimately left to implementers. This document explores the potential implications of key deployment design decisions and makes recommendations for those decisions that may help drive adoption.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 24 November 2023.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
The IETF's Transport Area Working Group (TSVWG) has finalized experimental RFCs for Low Latency, Low Loss, Scalable Throughput (L4S) and Non-Queue-Building (NQB) per hop behavior [RFC9330] [RFC9331] [RFC9332] [I-D.ietf-tsvwg-l4sops] [I-D.ietf-tsvwg-nqb] [I-D.ietf-tsvwg-dscp-considerations]. These documents do a good job of describing a new architecture and protocol for deploying low latency networking. But as is normal for many such standards, especially those in experimental status, certain deployment design decisions are ultimately left to implementers.¶
This document explores the potential implications of key deployment design decisions and makes recommendations for those decisions that may help drive adoption. In particular, there are best practices based on prior experience as a network operator that should be considered and there are network neutrality types of considerations as well. These technologies are benign on their own, but the way they are operationally implemented can determine whether they are ultimately perceived positively and adopted by the broader Internet ecosystem. That is a key issue for low latency networking, because the more applications developers and edge platforms that adopt new packet marking for low latency traffic, then the greater the value to end users, so ensuring it is received well is key to driving strong initial adoption.¶
It is worth stating though that these decisions are not embedded in or inherent to L4S and NQB per se, but are decisions that can change depending upon differing technical, regulatory, business or other requirements. Even two network operators with the same type of access technology and in the same market area may choose to implement in different ways. Nevertheless, this document suggests that certain specific deployment decisions can help maximize the value of low latency networking to both users and network operators.¶
It is also apparent from the IETF's work that it is clear that nearly all modern application types need low latency to some degree and that applications are best positioned to express their needs via application code and packet marking. Furthermore, unlike with bandwidth priority on a highly/fully utilized link, low latency networking can better balance the needs of different types of best effort flows (with some caveats - see Section 3).¶
For additional background on latency and why latency matters so much to the Internet, please read [BITAG]¶
In the course of working to improve the responsiveness of network protocols, the IETF concluded with their L4S and NQB work that there were fundamentally two types of Internet traffic and that these two major traffic types could benefit from having separate network processing queues in order to improve the way the Internet works for all applications, and especially for interactive applications.¶
One of the two major traffic types is Queue Building (QB) - things like file downloads and backups that are designed utilize as much network capacity as possible but with which users are usually not interacting with in real-time. The other was Non-Queue-Building (NQB) - such as DNS lookups, voice interaction with artificial intelligence (AI) assistants, video conferencing, gaming, and so on. NQB flows tend to be ones where the end user is sensitive to any delays.¶
Thus, the IETF created specifications for how two different network processing queues. Early results, such as from the IETF-114 hackathon [IETF-114-Slides], demonstrate that L4S and NQB (a.k.a. dual queue networking, and simply "low latency networking" hereafter) can work across a variety of access network technologies and deliver extraordinary levels of responsiveness for a variety of applications. It seems likely that this new capability will enable entirely new classes of applications to become possible, driving a wave of new Internet innovation, while also improving the applications people use today.¶
The Introduction says that unlike with bandwidth priority on a highly/fully utilized link, low latency networking can better balance the needs of different types of best effort flows. But this bears a bit of further discussion to understand more fully.¶
L4S does *not* provide low latency in the same way as previous technologies like DiffServ Quality of Service (QoS). That prior QoS approach used packet prioritization, where it was possible to assign a higher relative priority to certain application traffic, such as Voice over IP (VoIP) telephony. This approach could provide consistent and relatively low latency by assigning high priority to a partition of the capacity of a link, and then policing the rate of packets using that partition. This traditional approach to QoS is hierarchical in nature.¶
That QoS approach is to some extent predicated on an idea that network capacity is very limited and that links are often highly utilized. But in today's Internet, it is increasingly the case that there is an abundance of capacity to end users (e.g., symmetric 1 Gbps), which makes such traditional QoS approaches ineffective in delivering ever-lower latency. This new low latency networking approach is not based on hierarchical QoS prioritization. Rather, it is built upon conditional priority scheduling between its two queues that operate at best effort QoS priority.¶
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 in many countries and so should be taken into account in making deployment design decisions.¶
It is also possible that there can be confusion - for people who are not deep in this highly technical subject - between prioritization, provisioned end user capacity (throughput or bandwidth), and low latency networking. As it is envisioned in the design of the protocols, the addition of a low latency packet processing queue at a network link is merely a second packet queue and does not mean that this queue is hierarchically prioritized or that it has more capacity. Thus, a low latency queue does not create a so-called "fast lane" (in the way that this term is used in policy-related discussions in the U.S. to describe higher than best effort priority or greater capacity being assigned to some traffic compared to default traffic) - but there are certainly other NN considerations in the operational implementation worth exploring.¶
In short: implemented right, low latency networking is fully-aligned with net neutrality and has no impact on user choice and competition.¶
The principles below describe guidelines for a user-centric, application-agnostic, and monetizable implementation of low latency networking that is aligned with NN frameworks and interpretations, at least in the U.S. and Europe.¶
A key principle of NN is that all applications should be treated the same by ISPs. As such, any application should be able to request access to low latency networking using the available marking techniques, and the network should forward packets through a low latency queue only based on such markings, without inferring or taking into consideration from which application certain packets originate.¶
To incentivize low latency networking deployments, ISPs should be able to monetize it in some way, such as by enabling it on specific tiers of service. This could be misinterpreted as paid prioritization. To avoid such conflicts or misinterpretations, ISPs should charge users (and not application providers) for access to low latency networking, 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, in home network equipment maintenance, in home network services (e.g., parental controls), provision of low latency networking, or other service attributes. Thus, ISPs should not limit the number or types of applications that can access low latency networking, as this would eventually conflict with the application-agnostic requirement.¶
A key aspect of NN is that traffic to certain Internet destinations or for certain applications should not be prioritized over other Internet traffic. This means in practice that all Internet traffic in an ISP network should be carried at the same (best effort) priority and that any network management practices imposed by the network should be protocol (application) agnostic. Low latency networking is fully consistent with this aspect of NN, because it is designed so that all traffic is treated on a best effort basis in the ISP network (this is not necessarily be the case for a user's in-home Wi-Fi network due to the particulars of how the IEEE 802.11 wireless protocol [IEEE] functions at the current time - see [RFC8325]).¶
In addition, as noted above, unlike with bandwidth priority on a highly/fully utilized link, low latency networking can better balance the needs of different types of best effort flows.¶
Low latency networking is also consistent with the NN goal of not creating a fast lane, because the same end user throughput in an ISP access network is shared between both classic and low latency (L4S/NQB) queues. Thus, applications do not get access to greater throughput depending on whether or not the leverage low latency networking.¶
Ultimately, the emergence of low latency networking represents a fundamental new network capability that applications can choose to utilize as their needs dictate. It reflects a new ground truth about two fundamentally different types of application traffic and demonstrates that networks continue to evolve in exciting ways.¶
In addition, this new network capability can be implemented in a variety of network technologies. For example in access network technologies this could be implemented in DOCSIS [LLD], 5G [Ericsson], PON [CTI], and many other types of networks. Anywhere that a network bottleneck could occur may benefit from this technology.¶
Like any network or system, a good deployment design and configuration matters and can be the difference between a well-functioning and accepted design and one that experiences problems and faces opposition. In the context of deploying low latency networking in an ISP network, this document describes some recommended deployment design decisions that should help to ensure a deployment is resilient, well-accepted, and creates the environment for generating strong network effects. In contrast, creating barriers to adoption in the early stages through design and policy decisions will presumably reduce the predicted potential network effect, thus choking off further investment across the Internet ecosystem, leading to a vicious circle of decline - and then the potential value is never realized.¶
Only applications should mark traffic to inidate their preference for the low latency queue, not the network. This is for several reasons:¶
Any application provider should be able to mark their traffic for the low latency queue, with no restrictions other than standards compliance or other reasonable and openly documented technical guidelines. This maintains the loose cross-layer coupling that is a key tenet of the Internet's architecture by eliminating or greatly reducing any need for application providers and networks to coordinate on deployment (though such coordination is normal in the early experimental phase of any deployment).¶
As noted above, this is another example that low latency networking will have strong network effects, any barriers to adoption such as this should be avoided in order to maximize the value to users and the network of a new low latency queue.¶
Both customer-owned and ISP-administered Customer Premise Equipment (CPE) should be supported, when applicable (not all networks support this nor is it necessary in some networks). This avoids the risk that an ISP can be perceived as giving preference to their own network demarcation devices, which may carry some monthly recurring fee or other cost. This also means that retail CPE manufacturers need to make the necessary development investment to correctly implement low latency networking, though this may not interest or may be outside the capabilities of some organizations. In any case, the more devices that implement then adoption is broader, positively driving network effects.¶
During technical trial experiments of low latency networking, ISPs should consider making available some mechanism for users to opt out of (deactivate) it. If low latency networking is functioning correctly, it seems extremely unlikely that a user should ever want or need to turn it off. On the other hand, it is also possible that it may be desirable in some troubleshooting situations to turn it off.¶
As this technology enters full production, there will not be a long term need or practical benefit to having an opt out mechanism will not longer be necessary or practical; any problems should be handled like typical production network problems.¶
The specifications in [I-D.ietf-tsvwg-nqb] describe a concept of Traffic Protection, also known as a Queue Protection Function [ref]. The document says that Traffic Protection is optional and may not be needed in certain networks. In the case of an ISP deploying low latency networking with two queues, an ISP should consider deploying such a network function to at least detect mismarking (if not necessarily to correct mismarking). This may be implemented for example in end user CPE, last mile network equipment, and/or elsewhere in the ISP network - or closely monitors network statistics and user feedback for any indication of widespread NQB packet mismarking by applications.¶
If possible, based on a network's existing use of DSCP values, a network should try to maintain the use of DSCP 45 on an end-to-end basis without remarking. While this may not be possible in all networks, it can reduce complexity, enable simpler network operations, and ease troubleshooting of NQB traffic flows. In some cases a network may need to migrate an existing, private internal use of DSCP 45 to some other mark to achieve this. In the long term that may be best, even if it takes a bit more initial effort when deploying low latency networking. In addition, if a network does have their own private internal use of DSCP 45, then they alone should be responsible for any necessary remarking for traffic passing through their network (it would be unfair and unreasonable for a given network's private use of a DSCP mark to pose a burden on other networks).¶
As noted above with respect to prioritization of packets in the ISP network, all packets should be handled with the same best effort priority. However, in a user's home Wi-Fi (wireless) local area network (WLAN), this is more complicated because there is not a precise mapping between IETF packet marking and IEEE 802.11 marking, explored in [RFC8325].¶
In short, today's 802.11 specifications enable a Wi-Fi network to have multiple queues, using different "User Priority" and "Access Category" values. At the current time, these queues are:¶
Thus, as recommended in [I-D.ietf-tsvwg-nqb], the low latency queue should be different from the best effort queue. That means default best effort traffic will be in User Priority 0 or 3 (AC_BE) and it is recommended that the low latency queue will be in User Priority 4 or 5 (AC_VI). For additional context, please refer to Section 8.1 of [I-D.ietf-tsvwg-nqb].¶
It is also worth noting that, in the short-term, Microsoft has taken a slightly different approach to packet marking on their Xbox platform [Microsoft]. They are using DSCP-46 rather than DSCP-45, though presumably once the IANA port assignment for DSCP-45 is made this will change. As a result, a more permissive WLAN marking policy is recommended, which will put packets marked with DSCP-46 into the low latency queue. They are also using the AC_VO queue rather than the AC_VI queue, but it is not known if that may change when the DSCP marking changes.¶
Thanks to Bob Briscoe, Mat Ford, Sebastian Moeller, Sebnem Ozer, Jim Rampley, Dan Rice, Greg White, and Yiannis Yiakoumis for their review and feedback on this document.¶
RFC Editor: Please remove this section before publication.¶
This memo includes no requests to or actions for IANA.¶
RFC Editor: Please remove this section before publication.¶
This memo includes no security considerations.¶
RFC Editor: Please remove this section before publication.¶
This memo includes no security considerations.¶
RFC Editor: Please remove this section before publication.¶
v00: First draft¶
v01: Incorporate comments from 1st version after IETF-115¶
v02: Incorporate feedback from the TSVWG mailing list¶
RFC Editor: Please remove this section before publication.¶
- Open issues are being tracked in a GitHub repository for this document at https://github.com/jlivingood/IETF-L4S-Deployment/issues¶