One document matched: draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC0970 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.0970.xml">
<!ENTITY RFC2309 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2309.xml">
<!ENTITY RFC2474 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2474.xml">
<!ENTITY RFC3540 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3540.xml">
<!ENTITY RFC6660 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6660.xml">
<!ENTITY RFC2983 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2983.xml">
<!ENTITY RFC3246 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3246.xml">
<!ENTITY RFC3168 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml">
<!ENTITY RFC3649 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3649.xml">
<!ENTITY RFC4340 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4340.xml">
<!ENTITY RFC4960 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4960.xml">
<!ENTITY RFC4774 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4774.xml">
<!ENTITY RFC5562 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5562.xml">
<!ENTITY RFC5681 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5681.xml">
<!ENTITY RFC6077 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6077.xml">
<!ENTITY RFC6679 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6679.xml">
<!ENTITY I-D.ietf-tsvwg-ecn-encap-guidelines SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tsvwg-ecn-encap-guidelines.xml">
<!ENTITY RFC7560 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7560.xml">
<!ENTITY I-D.ietf-tcpm-accurate-ecn SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tcpm-accurate-ecn.xml">
<!ENTITY I-D.ietf-aqm-pie SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-aqm-pie.xml">
<!ENTITY I-D.ietf-aqm-fq-codel SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-aqm-fq-codel.xml">
<!ENTITY I-D.ietf-tcpm-dctcp SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tcpm-dctcp.xml">
<!ENTITY I-D.ietf-tcpm-cubic SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tcpm-cubic.xml">
<!ENTITY I-D.sridharan-tcpm-ctcp SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.sridharan-tcpm-ctcp.xml">
<!ENTITY I-D.moncaster-tcpm-rcv-cheat SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.moncaster-tcpm-rcv-cheat.xml">
<!ENTITY RFC7713 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7713.xml">
<!ENTITY I-D.briscoe-aqm-dualq-coupled SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.briscoe-aqm-dualq-coupled.xml">
<!ENTITY I-D.briscoe-tsvwg-ecn-l4s-id SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.briscoe-tsvwg-ecn-l4s-id.xml">
<!ENTITY I-D.stewart-tsvwg-sctpecn SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.stewart-tsvwg-sctpecn.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info"
docName="draft-briscoe-tsvwg-aqm-tcpm-rmcat-l4s-problem-00"
ipr="trust200902" obsoletes="">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="L4S Problem Statement">Low Latency, Low Loss, Scalable
Throughput (L4S) Internet Service: Problem Statement</title>
<author fullname="Bob Briscoe" initials="B." role="editor"
surname="Briscoe">
<organization>Simula Research Lab</organization>
<address>
<postal>
<street/>
</postal>
<email>ietf@bobbriscoe.net</email>
<uri>http://bobbriscoe.net/</uri>
</address>
</author>
<author fullname="Koen De Schepper" initials="K." surname="De Schepper">
<organization>Nokia Bell Labs</organization>
<address>
<postal>
<street/>
<city>Antwerp</city>
<country>Belgium</country>
</postal>
<email>koen.de_schepper@nokia.com</email>
<uri>https://www.bell-labs.com/usr/koen.de_schepper</uri>
</address>
</author>
<author fullname="Marcelo Bagnulo" initials="M." surname="Bagnulo Braun">
<organization>Universidad Carlos III de Madrid</organization>
<address>
<postal>
<street>Av. Universidad 30</street>
<city>Leganes, Madrid 28911</city>
<country>Spain</country>
</postal>
<phone>34 91 6249500</phone>
<email>marcelo@it.uc3m.es</email>
<uri>http://www.it.uc3m.es</uri>
</address>
</author>
<date day="" month="" year="2016"/>
<area>Transport</area>
<workgroup>Transport Services (tsv)</workgroup>
<workgroup>Active Queue Management (aqm)</workgroup>
<workgroup>TCP Maintenance (tcpm)</workgroup>
<workgroup>Real-Time Media Congestion Avoidance Techniques
(rmcat)</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>I-D</keyword>
<abstract>
<t>This document motivates a new service that the Internet could provide
to eventually replace best efforts for all traffic: Low Latency, Low
Loss, Scalable throughput (L4S). It is becoming common for all (or most)
applications being run by a user at any one time to require low latency,
but the only solution the IETF can offer for ultra-low queuing latency
is Diffserv, which only offers low latency for some packets at the
expense of others. Diffserv has also proved hard to deploy widely
end-to-end. </t>
<t>In contrast, a zero-config incrementally deployable solution has been
demonstrated that keeps average queuing delay under a millisecond for
<spanx style="emph">all</spanx> applications even under very heavy load;
and it keeps congestion loss to zero. At the same time it solves the
long-running problem with the scalability of TCP throughput. Even with a
high capacity broadband access, the resulting performance under load is
remarkably and consistently improved for applications such as
interactive video, conversational video, voice, Web, gaming, instant
messaging, remote desktop and cloud-based apps. This document explains
the underlying problems that have been preventing the Internet from
enjoying such performance improvements. It then outlines the parts
necessary for a solution and the steps that will be needed to
standardize them.</t>
</abstract>
</front>
<middle>
<section anchor="l4sid_intro" title="Introduction">
<section title="The Application Performance Problem">
<t>It is increasingly common for <spanx style="emph">all</spanx> of a
user's applications at any one time to require low delay: interactive
Web, Web services, voice, conversational video, interactive video,
instant messaging, online gaming, remote desktop and cloud-based
applications. In the last decade or so, much has been done to reduce
propagation delay by placing caches or servers closer to users.
However, queuing remains a major, albeit intermittent, component of
latency. Low loss is also important because, for interactive
applications, losses translate into delays.</t>
<t>It has been demonstrated that, once access network bit rate reaches
levels now common in the developed world, increasing capacity offers
diminishing returns if latency (delay) is not addressed.
Differentiated services (Diffserv) offers Expedited Forwarding <xref
target="RFC3246"/> for some packets at the expense of others, but this
is not applicable when all (or most) of a user's applications require
low latency.</t>
<t>Therefore, the goal is an Internet service with ultra-Low queueing
Latency, ultra-Low Loss and Scalable throughput (L4S) - for all
traffic. Having motivated the goal of 'L4S for all', this document
enumerates the problems that have to be overcome to reach it.</t>
<t>It must be said that queuing delay only degrades performance
infrequently <xref target="Hohlfeld14"/>. It only occurs when a large
enough capacity-seeking (e.g. TCP) flow is running alongside the
user's traffic in the bottleneck link, which is typically in the
access network. Or when the low latency application is itself a large
capacity-seeking flow (e.g. interactive video). At these times, the
performance improvement must be so remarkable that network operators
will be motivated to deploy it.</t>
</section>
<section title="The Technology Problem">
<t>Active Queue Management (AQM) is part of the solution to queuing
under load. AQM improves performance for all traffic, but there is a
limit to how much queuing delay can be reduced by solely changing the
network; without addressing the root of the problem.</t>
<t>The root of the problem is the presence of standard TCP congestion
control (Reno <xref target="RFC5681"/>) or compatible variants (e.g.
TCP Cubic <xref target="I-D.ietf-tcpm-cubic"/>). We shall call this
family of congestion controls 'Classic' TCP. It has been demonstrated
that if the sending host replaces Classic TCP with a 'Scalable'
alternative, when a suitable AQM is deployed in the network the
performance under load of all the above interactive applications can
be stunningly improved - even in comparison to a state-of-the-art AQM
such as fq_CoDel <xref target="I-D.ietf-aqm-fq-codel"/> or
PIE <xref target="I-D.ietf-aqm-pie"/>.</t>
<t>It has been convincingly demonstrated <xref target="DCttH15"/> that
it is possible to deploy such an L4S service alongside the existing
best efforts service so that all of a user's applications can shift to
it when their stack is updated. Access networks are typically designed
with one link as the bottleneck for each site (which might be a home,
small enterprise or mobile device), so deployment at a single node
should give nearly all the benefit. Although the main incremental
deployment problem has been solved, and the remaining work seems
straightforward, there may need to be changes in approach during the
process of engineering a complete solution.</t>
<t>There are three main parts to the L4S approach (illustrated in Fig
{ToDo: ASCII art of slide 9 from
https://riteproject.files.wordpress.com/2015/10/1604-l4s-bar-bof.pdf}):<list
style="numbers">
<t>The L4S service needs to be isolated from the queuing latency
of the Classic service. However, the two must be able to freely
share a common pool of capacity. There is no way to predict how
many flows at any one time might use each service and capacity in
access networks is too scarce to partition into two. The Dual
Queue Coupled AQM is an example of such a 'semi-permeable'
membrane <xref target="I-D.briscoe-aqm-dualq-coupled"/>. Per-flow
queuing such as in <xref target="I-D.ietf-aqm-fq-codel"/> could be
used, but it is rather overkill, which brings disadvantages (see
<xref target="l4sps_why-not"/>).</t>
<t>An identifier is needed to so that L4S and Classic packets can
be classified into their separate treatments. <xref
target="I-D.briscoe-tsvwg-ecn-l4s-id"/> considers various
alternative identifiers, and concludes that all alternatives
involve compromises, but the ECT(1) codepoint of the ECN field is
a workable solution.</t>
<t>Scalable congestion controls already exist. They solve the
scaling problem with TCP first pointed out in <xref
target="RFC3649"/>. The one used most widely (in controlled
environments) is Data Centre TCP (DCTCP <xref
target="I-D.ietf-tcpm-dctcp"/>), which has been implemented and
deployed in Windows Server Editions (since 2012), in Linux and in
FreeBSD. Although DCTCP as-is 'works' well over the public
Internet, most implementations lack certain safety features that
will be necessary once it is used outside controlled environments
like data centres (see later). A similar scalable congestion
control will also need to be transplanted into protocols other
than TCP (SCTP, RTP/RTCP, RMCAT, etc.)</t>
</list></t>
</section>
<section anchor="l4sid_Terminology" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/>. In this document, these words will appear with
that interpretation only when in ALL CAPS. Lower case uses of these
words are not to be interpreted as carrying RFC-2119 significance.</t>
<t><list style="hanging">
<t hangText="Classic service:">The 'Classic' service is intended
for all the behaviours that currently co-exist with TCP Reno (e.g.
TCP Cubic, Compound, SCTP, etc).</t>
<t
hangText="Low-Latency, Low-Loss and Scalable (L4S) service:">The
'L4S' service is intended for traffic from scalable TCP algorithms
such as Data Centre TCP. But it is also more general—it will
allow a set of congestion controls with similar scaling properties
to DCTCP (e.g. Relentless <xref target="Mathis09"/>) to
evolve.<vspace blankLines="1"/>Both Classic and L4S services can
cope with a proportion of unresponsive or less-responsive traffic
as well (e.g. DNS, VoIP, etc).</t>
<t hangText="Scalable Congestion Control:">A congestion control
where flow rate is inversely proportional to the level of
congestion signals. Then, as flow rate scales, the number of
congestion signals per round trip remains invariant, maintaining
the same degree of control. With Classic congestion controls such
as TCP Reno and Cubic, as capacity increases enable higher flow
rates, the number of round trips between signals becomes very
large, so control of queuing and/or utilization becomes very
slack.</t>
<t hangText="Classic ECN:">The original Explicit Congestion
Notification (ECN) protocol <xref target="RFC3168"/>.</t>
</list></t>
</section>
<section title="The Standardization Problem">
<t><list counter="0" style="numbers">
<t>The first step will be to articulate the structure and
interworking requirements of the set of parts that would satisfy
the overall application performance requirements.</t>
</list>Then specific interworking aspects of the following three
components parts will need to be defined:<list style="numbers">
<t>The L4S service needs to be isolated from the queuing latency
of the Classic service. However, the two must be able to freely
share a common pool of capacity. There is no way to predict how
many flows at any one time might use each service and capacity in
access networks is too scarce to partition into two. The Dual
Queue Coupled AQM is an example of such a 'semi-permeable'
membrane <xref target="I-D.briscoe-aqm-dualq-coupled"/>. Per-flow
queuing such as in <xref target="I-D.ietf-aqm-fq-codel"/> could be
used, but it has disadvantages, not least that thousands of queues
are not needed if two are sufficient.</t>
<t>Identifier<list style="letters">
<t><xref target="I-D.briscoe-tsvwg-ecn-l4s-id"/> recommends
ECT(1) is used as the identifier to classify L4S and Classic
packets into their separate treatments, as required by <xref
target="RFC4774"/>. The draft also points out that the
experimental assignment of this codepoint as an ECN nonce
<xref target="RFC3540"/> will need to be made obsolete (it was
never deployed, and it offers no security benefit now that
deployment is optional).</t>
<t>An essential aspect of a scalable congestion control is the
use of Explicit Congestion Notification (ECN <xref
target="RFC3168"/>). 'Classic' ECN requires an ECN signal to
be treated the same as a drop, both when it is generated in
the network and when it is responded to by hosts. A separate
queue for L4S allows the network to support two separate
meanings for ECN. And break from this 'same as drop'
constraint is an essential feature of a scalable congestion
control as well.</t>
</list></t>
<t>Scalable congestion controls<list style="letters">
<t>Data Centre TCP is being documented in the TCPM WG as an
informational record of the protocol currently in use <xref
target="I-D.ietf-tcpm-dctcp"/>. It will be necessary to define
a number of safety features for a variant usable on the public
Internet. A draft list of these, known as the TCP Prague
requirements, has been drawn up (see <xref
target="l4sps_tcp-prague-reqs"/>).</t>
<t>Transport protocols other than TCP use various congestion
controls designed to be friendly with Classic TCP. It will be
necessary to implement scalable variants of each of these
transport behaviours before they can use the L4S service, by
sending packets with the ECT(1) identifier. The following
standards track RFCs currently define these protocols: ECN in
TCP <xref target="RFC3168"/>, in SCTP <xref
target="RFC4960"/>, in RTP <xref target="RFC6679"/>, and in
DCCP <xref target="RFC4340"/>.</t>
<t>For the case of TCP, the feedback protocol for ECN is too
tightly coupled to Classic ECN to be usable for a scalable
TCP. Therefore, the implementation of TCP receivers will have
to be upgraded <xref target="RFC7560"/>. Work to standardize
more accurate ECN feedback for TCP (AccECN <xref
target="I-D.ietf-tcpm-accurate-ecn"/>) is already in
progress.</t>
</list></t>
</list></t>
<t/>
</section>
</section>
<section title="Rationale">
<t/>
<section title="Why These Primary Components?">
<t>{ToDo: /Why/ the various elements are necessary:}</t>
<t>ECN rather than drop</t>
<t>Packet identifier (pretty obvious why)</t>
<t>Scalable congestion notification (host behaviour)</t>
<t>Semi-permeable membrane (network behaviour)</t>
<t>{We will probably move some of the text in the bullets under "The
Technology Problem" to here, e.g. why you need capacity shared across
the semi-permeable membrane.}</t>
</section>
<section anchor="l4sps_why-not" title="Why Not Alternative Approaches?">
<t>All the following approaches address some part of the same problem
space as L4S. In each case, it is shown that L4S complements them or
improves on them, rather than being a mutually exclusive
alternative:<list style="hanging">
<t hangText="Diffserv:">Diffserv addresses the problem of
bandwidth apportionment for important traffic as well as queuing
latency for delay-sensitive traffic. L4S solely addresses the
problem of queuing latency. Diffserv will still be necessary where
important traffic requires priority (e.g. for commercial reasons,
or for protection of critical infrastructure traffic).
Nonetheless, if there are Diffserv classes for important traffic,
the L4S approach can provide low latency for <spanx style="emph">all</spanx>
traffic within each Diffserv class (including the case where there
is only one Diffserv class).<vspace blankLines="1"/>Also, as
already explained, Diffserv only works for a small subset of the
traffic on a link. It is not applicable when all the applications
in use at one time at a single site (home, small business or
mobile device) require low latency. Also, because L4S is for all
traffic, it needs none of the management baggage (traffic
policing, traffic contracts) associated with favouring some
packets over others. This baggage has held Diffserv back from
widespread end-to-end deployment.</t>
<t hangText="State-of-the-art AQMs:">AQMs such as PIE and fq_CoDel
give a significant reduction in queuing delay relative to no AQM
at all. The L4S work is intended to complement these AQMs, and we
definitely do not want to distract from the need to deploy them as
widely as possible. Nonetheless, without addressing the large
saw-toothing rate variations of Classic congestion controls, they
cannot reduce queuing delay too far without significantly reducing
link utilization. The L4S approach resolves this tension by
ensuring hosts can minimize the sawtoothing.</t>
<t hangText="Per-flow queuing:">Similarly per-flow queuing is not
incompatible with the L4S approach. However, one queue for every
flow can be thought of as overkill compared to the minimum of two
queues for all traffic needed for the L4S approach. The overkill
of per-flow queuing has side-effects:<list style="letters">
<t>fq makes high performance networking equipment costly
(processing and memory) - in contrast dual queue code can be
very simple;</t>
<t>fq requires packet inspection into the end-to-end transport
layer, which doesn't sit well alongside encryption for privacy
- in contrast a dual queue, which only operates at the IP
layer;</t>
<t>fq has to take control of the decisions over which flows
are scheduled when - in contrast, in the L4S approach the
sender still controls the relative rate of each flow dependent
on the needs of each application.</t>
</list></t>
<t hangText="Alternative Back-off ECN (ABE):">Yet again, L4S is
not an alternative to ABE but a complement. ABE alters the host
behaviour in response to ECN marking to utilize a link better and
give ECN flows a faster throughput, but it assumes the network
still treats ECN and drop the same. Therefore ABE exploits any
lower queuing delay that AQMs can provide. But as explained above,
AQMs still cannot reduce queuing delay too far without losing link
utilization (for other non-ABE flows).</t>
</list></t>
</section>
</section>
<section title="Opportunities">
<t>A transport layer that solves the current latency issues will provide
new service, product and application opportunities.</t>
<t>If applications can rely on minimal queues in the network, they can
focus on reducing their own latency by only minimizing the application
send queue. Following existing applications will immediately experience
a better quality of experience in the best effort class: <list>
<t>Gaming</t>
<t>VoIP</t>
<t>Video conferencing</t>
<t>Web browsing</t>
<t>(Adaptive) Video Streaming</t>
</list></t>
<t>The lower transport layer latency will also allow more interactive
application functions offloading to the cloud. If last-minute
interactions need to be done locally, more data must be send over the
link. When all interactive processing can be done in the cloud, only the
info to be rendered to the end user can be sent. It will allow
applications such as: <list>
<t>Cloud based interactive video</t>
<t>Cloud based virtual and augmented reality</t>
</list></t>
<t>Also lower network layers can finally be further optimized for low
latency and stable throughput. Today it is not cost efficient, as the
largest part of the traffic (classic best effort) needs to allow "big"
queues anyway (up to several 100s of milliseconds) to make classic
congestion control work correctly. While technology is known and
feasible to support low latency with reliable throughput (even mobile),
it is today not considered as economically relevant, as best effort can
absorb any burst, delay or throughput variations without end-users
experiencing any difference from the normal tay-to-day operation due to
congestion control limitations.</t>
<section title="Use Cases">
<t>{ToDo: Just bullets below - text to be added by those interested in
various use-cases}</t>
<t>Different types of access network: DSL, cable, mobile</t>
<t>The challenges and opportunities with radio links: cellular,
Wifi</t>
<t>Private networks of heterogeneous data centres (DC interconnect,
multi-tenant cloud, etc)</t>
<t>Different types of transport/app: elastic (TCP/SCTP); real-time
(RTP, RMCAT); query (DNS/LDAP).</t>
<t>Avoiding reliance on middleboxes to enable encryption/privacy
(because the L4S approach does not look deeper than IP in the
network).</t>
</section>
</section>
<section anchor="l4sid_IANA" title="IANA Considerations">
<t>This specification contains no IANA considerations.</t>
</section>
<section anchor="l4sid_Security_Considerations"
title="Security Considerations">
<section title="Traffic (Non-)Policing">
<t>Because the L4S service can serve all traffic that is using the
capacity of a link, it should not be necessary to police access to the
L4S service. In contrast, Diffserv has to use traffic policers to
limit how much traffic can access each service, otherwise it doesn't
work, In turn, traffic policers require traffic contracts between
users and networks and between networks. Because L4S will lack all
this management complexity, it is more likely to work end-to-end.</t>
<t>During early deployment (and perhaps always), some networks will
not offer the L4S service. These networks do not need to police or
re-mark L4S traffic - they just forward it unchanged as best efforts
traffic, as they would already forward traffic with ECT(1) today. At a
bottleneck, such networks will introduce some queuing and dropping.
When the scalable congestion controll detects a drop it has to respond
as if it is a Classic congestion control, and there will then be no
interworking problems.</t>
<t>Certain network operators might choose to restict access to the L4S
class, perhaps only to customers who have paid a premium. In the
packet classifer, they could identify such customers using some other
field (e.g. source address range), and just ignoring the L4S
identifier for non-paying customers. This will ensure that the L4S
identifier survives end-to-end even though the service does not have
to be supported at every hop. Such arrangements would only require
simple registered/not-registered packet classification, rather than
the complex application-specific traffic contracts of Diffserv.</t>
</section>
<section title="'Latency Friendliness'">
<t>The L4S service does rely on self-constraint - not in terms of
limiting capacity usage, but in terms of limiting burstiness. It is
believed that standardisation of dynamic behaviour (cf. TCP
slow-start) and self-interest will be sufficient to prevent transports
from sending excessive bursts of L4S traffic, given the application's
own latency will suffer most from such behaviour.</t>
<t>Whether burst policing becomes necessary remains to be seen.
Without it, there will be potential for attacks on the low latency of
the L4S service. However it may only be necessary to apply such
policing reactively, e.g. punitively targeted at any deployments of
new bursty malware.</t>
</section>
<section title="ECN Integrity">
<t>{ToDo: Paraphrase discussion from ecn-l4s-id}</t>
</section>
</section>
<section title="Acknowledgements">
<t/>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
&RFC2119;
&RFC3168;
&RFC4774;
&RFC6679;
</references>
<references title="Informative References">
&RFC3540;
&RFC3246;
&RFC3649;
&RFC4340;
&RFC4960;
&RFC5681;
&RFC7560;
&I-D.ietf-tcpm-accurate-ecn;
&I-D.ietf-aqm-pie;
&I-D.ietf-aqm-fq-codel;
&I-D.moncaster-tcpm-rcv-cheat;
&RFC7713;
&I-D.briscoe-aqm-dualq-coupled;
&I-D.briscoe-tsvwg-ecn-l4s-id;
&I-D.stewart-tsvwg-sctpecn;
&I-D.ietf-tcpm-dctcp;
&I-D.ietf-tcpm-cubic;
<reference anchor="Hohlfeld14">
<front>
<title>A QoE Perspective on Sizing Network Buffers</title>
<author fullname="Oliver Hohlfeld" initials="O." surname="Hohlfeld ">
<organization/>
</author>
<author fullname="Enric Pujol" initials="E." surname="Pujol">
<organization/>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<author fullname="Florin Ciucu" initials="F." surname="Ciucu">
<organization/>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<author fullname="Anja Feldmann" initials="A." surname="Feldmann">
<organization/>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<author fullname="Paul Barford" initials="P." surname="Barford">
<organization/>
<address>
<postal>
<street/>
<city/>
<region/>
<code/>
<country/>
</postal>
<phone/>
<facsimile/>
<email/>
<uri/>
</address>
</author>
<date month="November" year="2014"/>
</front>
<seriesInfo name="Proc. ACM Internet Measurement Conf (IMC'14)"
value="hmm"/>
<format target="http://doi.acm.org/10.1145/2663716.2663730" type="PDF"/>
</reference>
<reference anchor="Mathis09"
target="http://www.hpcc.jp/pfldnet2009/Program_files/1569198525.pdf">
<front>
<title>Relentless Congestion Control</title>
<author fullname="Matt Mathis" initials="M." surname="Mathis">
<organization>PSC</organization>
</author>
<date month="May" year="2009"/>
</front>
<seriesInfo name="PFLDNeT'09" value=""/>
<format target="http://www.hpcc.jp/pfldnet2009/Program_files/1569198525.pdf"
type="PDF"/>
</reference>
<!--{ToDo: DCttH ref will need to be updated, once stable}-->
<reference anchor="DCttH15"
target="http://www.bobbriscoe.net/projects/latency/dctth_preprint.pdf">
<front>
<title>'Data Centre to the Home': Ultra-Low Latency for All</title>
<author fullname="Koen De Schepper" initials="K."
surname="De Schepper">
<organization>Bell Labs</organization>
</author>
<author fullname="Olga Bondarenko" initials="O."
surname="Bondarenko">
<organization>Simula Research Lab</organization>
</author>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe">
<organization>BT</organization>
</author>
<author fullname="Ing-jyh Tsang" initials="I." surname="Tsang">
<organization>Bell Labs</organization>
</author>
<date year="2015"/>
</front>
<annotation>(Under submission)</annotation>
</reference>
</references>
<section anchor="l4sps_tcp-prague-reqs"
title="The "TCP Prague Requirements"">
<t>This list of requirements was produced at an ad hoc meeting during
IETF-94 in Prague. The list prioritised features that would need to be
added to DCTCP to make it safe for use on the public Internet alongside
existing non-DCTCP traffic. It also includes features to improve the
performance of DCTCP in the wider range of conditions found on the
public Internet.</t>
<t>The table is too wide for the ASCII draft format, so it been split
into two, with a common column of row index numbers on the left.</t>
<texttable>
<ttcol>#</ttcol>
<ttcol>Requirement</ttcol>
<ttcol>Reference</ttcol>
<c>0</c>
<c>ARCHITECTURE</c>
<c/>
<c>1</c>
<c>L4S IDENTIFIER</c>
<c><xref target="I-D.briscoe-tsvwg-ecn-l4s-id"/></c>
<c>2</c>
<c>DUAL QUEUE AQM</c>
<c><xref target="I-D.briscoe-aqm-dualq-coupled"/></c>
<c/>
<c>SCALABLE TRANSPORT SAFETY ADDITIONS</c>
<c/>
<c>3-1</c>
<c>Fall back to Reno/Cubic on loss</c>
<c><xref target="I-D.ietf-tcpm-dctcp"/></c>
<c>3-2</c>
<c>TCP ECN Feedback</c>
<c><xref target="I-D.ietf-tcpm-accurate-ecn"/></c>
<c>3-4</c>
<c>Scaling TCP's Congestion Window for Small Round Trip Times</c>
<c/>
<c>3-5</c>
<c>Reduce RTT-dependence</c>
<c/>
<c>3-6</c>
<c>Smooth ECN feedback over own RTT</c>
<c/>
<c>3-7</c>
<c>Fall back to Reno/Cubic if classic ECN bottleneck detected</c>
<c/>
<c/>
<c>SCALABLE TRANSPORT PERFORMANCE ENHANCEMENTS</c>
<c/>
<c>3-8</c>
<c>Faster-than-additive increase</c>
<c/>
<c>3-9</c>
<c>Less drastic exit from slow-start</c>
<c/>
</texttable>
<texttable>
<ttcol>#</ttcol>
<ttcol>WG</ttcol>
<ttcol>TCP</ttcol>
<ttcol>DCTCP</ttcol>
<ttcol>DCTCP-bis</ttcol>
<ttcol>TCP Prague</ttcol>
<ttcol>SCTP Prague</ttcol>
<ttcol>RMCAT Prague</ttcol>
<c>0</c>
<c>tsvwg?</c>
<c>Y</c>
<c>Y</c>
<c>Y</c>
<c>Y</c>
<c>Y</c>
<c>Y</c>
<c>1</c>
<c>tsvwg?</c>
<c/>
<c/>
<c>Y</c>
<c>Y</c>
<c>Y</c>
<c>Y</c>
<c>2</c>
<c>aqm?</c>
<c>n/a</c>
<c>n/a</c>
<c>n/a</c>
<c>n/a</c>
<c>n/a</c>
<c>n/a</c>
<c/>
<c/>
<c/>
<c/>
<c/>
<c/>
<c/>
<c/>
<c>3-1</c>
<c>tcpm</c>
<c/>
<c>Y</c>
<c>Y</c>
<c>Y</c>
<c>Y</c>
<c>Y</c>
<c>3-2</c>
<c>tcpm</c>
<c>Y</c>
<c>Y</c>
<c>Y</c>
<c>Y</c>
<c>n/a</c>
<c>n/a</c>
<c>3-4</c>
<c>tcpm</c>
<c>Y</c>
<c>Y</c>
<c>Y</c>
<c>Y</c>
<c>Y</c>
<c>?</c>
<c>3-5</c>
<c>tcpm/ iccrg?</c>
<c/>
<c/>
<c>Y</c>
<c>Y</c>
<c>Y</c>
<c>?</c>
<c>3-6</c>
<c>tcpm/ iccrg?</c>
<c/>
<c>?</c>
<c>Y</c>
<c>Y</c>
<c>Y</c>
<c>?</c>
<c>3-7</c>
<c>tcpm/ iccrg?</c>
<c/>
<c/>
<c/>
<c>Y</c>
<c>Y</c>
<c>?</c>
<c/>
<c/>
<c/>
<c/>
<c/>
<c/>
<c/>
<c/>
<c>3-8</c>
<c>tcpm/ iccrg?</c>
<c/>
<c/>
<c>Y</c>
<c>Y</c>
<c>Y</c>
<c>?</c>
<c>3-9</c>
<c>tcpm/ iccrg?</c>
<c/>
<c/>
<c>Y</c>
<c>Y</c>
<c>Y</c>
<c>?</c>
</texttable>
</section>
<!-- <section title="Change Log (to be Deleted before Publication)">
<t>A detailed version history can be accessed at
<http://datatracker.ietf.org/doc/draft-briscoe-aqm-ecn-roadmap/history/></t>
<t><list style="hanging">
<t hangText="From briscoe-...-00 to briscoe-...-01:">Technical
changes:<list style="symbols">
<t/>
</list>Editorial changes:<list style="symbols">
<t/>
</list></t>
</list></t>
</section>
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 17:01:10 |