One document matched: draft-ietf-conex-concepts-uses-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<!-- Default toc="no" No Table of Contents -->
<?rfc symrefs="yes" ?>
<!-- Default symrefs="no" Don't use anchors, but use numbers for refs -->
<?rfc sortrefs="yes" ?>
<!-- Default sortrefs="no" Don't sort references into order -->
<?rfc compact="yes" ?>
<!-- Default compact="no" Start sections on new pages -->
<?rfc strict="no" ?>
<!-- Default strict="no" Don't check I-D nits -->
<?rfc rfcedstyle="yes" ?>
<!-- Default rfcedstyle="yes" attempt to closely follow finer details from the latest observable RFC-Editor style -->
<?rfc linkmailto="yes" ?>
<!-- Default linkmailto="yes" generate mailto: URL, as appropriate -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY I-D.ietf-conex-abstract-mech PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-conex-abstract-mech.xml">
<!ENTITY I-D.ietf-conex-destopt PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-conex-destopt.xml">
<!ENTITY I-D.ietf-conex-tcp-modifications PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-conex-tcp-modifications.xml">
<!ENTITY I-D.briscoe-conex-initial-deploy PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.briscoe-conex-initial-deploy.xml">
<!ENTITY I-D.ietf-conex-mobile PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-conex-mobile.xml">
<!ENTITY I-D.briscoe-conex-data-centre PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.briscoe-conex-data-centre.xml">
<!ENTITY I-D.ietf-ledbat-congestion PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ledbat-congestion.xml">
]>
<rfc category="info" docName="draft-ietf-conex-concepts-uses-05"
ipr="trust200902">
<front>
<title abbrev="ConEx Concepts & Use Cases">ConEx Concepts and Use
Cases</title>
<author fullname="Bob Briscoe" initials="B." role="editor"
surname="Briscoe">
<organization>BT</organization>
<address>
<postal>
<street>B54/77, Adastral Park</street>
<street>Martlesham Heath</street>
<city>Ipswich</city>
<code>IP5 3RE</code>
<country>UK</country>
</postal>
<phone>+44 1473 645196</phone>
<email>bob.briscoe@bt.com</email>
<uri>http://bobbriscoe.net/</uri>
</address>
</author>
<author fullname="Richard Woundy" initials="R." role="editor"
surname="Woundy">
<organization>Comcast</organization>
<address>
<postal>
<street>1701 John F Kennedy Boulevard</street>
<city>Philadelphia</city>
<code>19103</code>
<region>PA</region>
<country>US</country>
</postal>
<email>richard_woundy@cable.comcast.com</email>
<uri>http://www.comcast.com</uri>
</address>
</author>
<author fullname="Alissa Cooper" initials="A." role="editor"
surname="Cooper">
<organization>CDT</organization>
<address>
<postal>
<street>1634 Eye St. NW, Suite 1100</street>
<city>Washington</city>
<code>20006</code>
<region>DC</region>
<country>US</country>
</postal>
<email>acooper@cdt.org</email>
</address>
</author>
<date year="2012" />
<area>Transport Area</area>
<workgroup>ConEx</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document provides the entry point to the set of documentation
about the Congestion Exposure (ConEx) protocol. It explains the
motivation for including a ConEx marking at the IP layer: to expose
information about congestion to network nodes. Although such information
may have a number of uses, this document focuses on how the information
communicated by the ConEx marking can serve as the basis for
significantly more efficient and effective traffic management than what
exists on the Internet today.</t>
</abstract>
</front>
<middle>
<!-- ====================================================================== -->
<section anchor="conex-uses-intro" title="Introduction">
<t>The power of Internet technology comes from multiplexing shared
capacity with packets rather than circuits. Network operators aim to
provide sufficient shared capacity, but when too much packet load meets
too little shared capacity, congestion results. Congestion appears as
either increased delay, dropped packets or packets explicitly marked
with Explicit Congestion Notification (ECN) markings <xref
target="RFC3168"></xref>. As described in <xref
target="conex-uses_Fig_ConEx_Placement"></xref>, congestion control
currently relies on the transport receiver detecting these 'Congestion
Signals' and informing the transport sender in 'Congestion Feedback
Signals.' The sender is then expected to reduce its rate in
response.</t>
<t>This document provides the entry point to the set of documentation
about the Congestion Exposure (ConEx) protocol. It focuses on the
motivation for including a ConEx marking at the IP layer. (A companion
document, <xref target="I-D.ietf-conex-abstract-mech"></xref>, focuses
on the mechanics of the protocol.) Briefly, the idea is for the sender
to continually signal expected congestion in the headers of any data it
sends. To a first approximation, the sender does this by relaying the
'Congestion Feedback Signals' back into the IP layer. They then travel
unchanged across the network to the receiver (shown as
'IP-Layer-ConEx-Signals' in <xref
target="conex-uses_Fig_ConEx_Placement"></xref>). This enables IP layer
devices on the path to see information about the whole path
congestion.</t>
<figure anchor="conex-uses_Fig_ConEx_Placement"
title="The ConEx Protocol in the Internet Architecture">
<!--0 1 2 3 4 5 6 7
123456789012345678901234567890123456789012345678901234567890123456789012 -->
<artwork><![CDATA[
,---------. ,---------.
|Transport| |Transport|
| Sender | . |Receiver |
| | /|___________________________________________| |
| ,-<---------------Congestion-Feedback-Signals--<--------. |
| | |/ | | |
| | |\ Transport Layer Feedback Flow | | |
| | | \ ___________________________________________| | |
| | | \| | | |
| | | ' ,-----------. . | | |
| | |_____________| |_______________|\ | | |
| | | IP Layer | | Data Flow \ | | |
| | | |(Congested)| \ | | |
| | | | Network |--Congestion-Signals--->-' |
| | | | Device | \| |
| | | | | /| |
| `----------->--(new)-IP-Layer-ConEx-Signals-------->| |
| | | | / | |
| |_____________| |_______________ / | |
| | | | |/ | |
`---------' `-----------' ' `---------'
]]></artwork>
</figure>
<t>One of the key benefits of exposing this congestion information at
the IP layer is that it makes the information available to network
operators for use as input into their traffic management procedures. A
ConEx-enabled sender signals expected whole path congestion, which is
approximately the congestion at least a round trip time earlier as
reported by the receiver to the sender (<xref
target="conex-uses_Fig_ConEx_Placement"></xref>). The ConEx signal is a
mark in the IP header that is easy for any IP device to read. Therefore
a node performing traffic management can count congestion as easily as
it might count data volume today by simply counting the volume of
packets with ConEx markings.</t>
<t>ConEx-based traffic management can make highly efficient use of
capacity. In times of no congestion, all traffic management restraints
can be removed, leaving the network's full capacity available to all its
users. If some users on the network cause disproportionate congestion,
the traffic management function can learn about this and directly limit
those users' traffic in order to protect the service of other users
sharing the same capacity. ConEx-based traffic management thus presents
a step change in terms of the options available to network operators for
managing traffic on their networks.</t>
<t>The remainder of this document explains the concepts behind ConEx and
how exposing congestion can significantly improve Internet traffic
management, among other benefits. <xref target="concepts"></xref>
introduces a number of concepts that are fundamental to understanding
how ConEx-based traffic management works. <xref
target="traffic-management"></xref> shows how ConEx can be used for
traffic management, discusses additional benefits from such usage, and
compares ConEx-based traffic management to existing traffic management
approaches. <xref target="other-use-cases"></xref> discusses other
related use cases. <xref target="deployments"></xref> briefly discusses
deployment arrangements. The final sections are standard RFC back
matter.</t>
<t>The remainder of the core ConEx document suite consists of:</t>
<t><list>
<t><xref target="I-D.ietf-conex-abstract-mech"></xref>, which
provides an abstract encoding of ConEx signals, explains the ConEx
audit and security mechanisms, and describes incremental deployment
features;</t>
<t><xref target="I-D.ietf-conex-destopt"></xref>, which specifies
the IPv6 destination option encoding for ConEx;</t>
<t><xref target="I-D.ietf-conex-tcp-modifications"></xref>, which
specifies TCP sender modifications for use of ConEx;</t>
<t>and the following documents, which describe some feasible
scenarios for deploying ConEx:<list>
<t><xref target="I-D.briscoe-conex-initial-deploy"></xref>,
which describes a scenario around a fixed broadband access
network;</t>
<t><xref target="I-D.ietf-conex-mobile"></xref>, which describes
a scenario around a mobile communications provider;</t>
<t><xref target="I-D.briscoe-conex-data-centre"></xref>, which
describes how ConEx could be used for performance isolation
between tenants of a data centre.</t>
</list></t>
</list></t>
</section>
<!-- ====================================================================== -->
<section anchor="concepts" title="Concepts">
<t>ConEx relies on a precise definition of congestion and a number of
newer concepts that are introduced in this
section. Definitions are summarized in <xref target="definitions" />.</t>
<section anchor="congestion" title="Congestion">
<t>Despite its central role in network control and management,
congestion is a remarkably difficult concept to define. Experts in
different disciplines and with different perspectives define
congestion in a variety of ways <xref target="Bauer09"></xref>.</t>
<t>The definition used for the purposes of ConEx is expressed as the
probability of packet loss (or the probability of packet marking if
ECN is in use). This definition focuses on how congestion is measured,
rather than describing congestion as a condition or state.</t>
</section>
<section anchor="congestion-volume" title="Congestion-Volume">
<t>The metric that ConEx exposes is congestion-volume: the volume of
bytes dropped or ECN-marked in a given period of time. Counting
congestion-volume allows each user to be held responsible for his or
her contribution to congestion. Congestion-volume can only be a
property of traffic, whereas congestion can be a property of traffic
or a property of a link or a path.</t>
<t>To understand congestion-volume, consider a simple example. Imagine
Alice sends 1GB of a file while the loss-probability is a constant
0.2%. Her contribution to congestion -- her congestion-volume -- is
1GB x 0.2% = 2MB. If she then sends another 3GB of the file while the
loss-probability is 0.1%, this adds 3MB to her congestion-volume. Her
total contribution to congestion is then 2MB+3MB = 5MB.</t>
<t>Fortunately, measuring Alice's congestion-volume on a real network
does not require the kind of arithmetic shown above because
congestion-volume can be directly measured by counting the total
volume of Alice's traffic that gets discarded or ECN-marked. (A queue
with varying percentage loss does these multiplications and additions
inherently.) With ConEx, network operators can count congestion-volume
using techniques very similar to those they use for counting
volume.</t>
</section>
<section anchor="upstream-downstream-congestion"
title="Rest-of-Path Congestion">
<t>At a particular measurement point within a network, "rest-of-path
congestion" (also known as "downstream congestion") is the level of
congestion that a traffic flow is expected to experience between the
measurement point and its final destination. "Upstream congestion" is
the congestion experienced up to the measurement point.</t>
<t>If traffic is ECN-capable, ECN signals monitored in the middle of a
network will indicate the congestion experienced so far on the path
(upstream congestion). In contrast, the ConEx signals inserted into IP
headers as shown in <xref
target="conex-uses_Fig_ConEx_Placement"></xref> indicate the
congestion along a whole path from transport source to transport
destination. Therefore if a measurement point detects both of these
signals, it can subtract the level of ECN (upstream congestion) from
the level of ConEx (whole path) to derive a measure of the congestion
that packets are likely to experience between the monitoring point and
their destination (rest-of-path congestion). A measurement point can calculate this measurement in the aggregate, across all flows.</t>
<t>A network monitor can usually accurately measure upstream congestion only if the traffic it observes is ECN-capable. <xref
target="I-D.ietf-conex-abstract-mech"></xref> has further discussion
of the constraints around the network's ability to measure upstream
and rest-of-path congestion in these circumstances. However, there are a number of intial deployment
arrangements that benefit from ConEx but work without ECN (see <xref
target="deployments"></xref>).</t>
</section>
<section anchor="definitions" title="Definitions">
<t><list style="hanging">
<t hangText="Congestion:">In general, congestion occurs when any
user's traffic suffers loss, ECN marking, or increased delay as a
result of one or more network resources becoming overloaded. For
the purposes of ConEx, congestion is measured using the concrete
signals provided by loss and ECN markings (delay is not
considered). Congestion is measured as the probability of loss or
the probability of ECN marking, usually expressed as a
dimensionless percentage.</t>
<t hangText="Congestion-volume:">For any granularity of traffic
(packet, flow, aggregate, link, etc.), the volume of bytes dropped
or ECN-marked in a given period of time. Conceptually, data volume
multiplied by the congestion each packet of the volume
experienced. Usually expressed in bytes (or MB or GB).</t>
<t hangText="Congestion policer:">A logical entity that allows a
network operator to monitor each user's congestion-volume and
enforce congestion-volume limits (discussed in <xref
target="using-conex"></xref>).</t>
<t
hangText="Rest-of-path congestion (or downstream congestion):">The
congestion a flow of traffic is expected to experience on the
remainder of its path. In other words, at a measurement point in
the network, the rest-of-path congestion is the congestion the
traffic flow has yet to experience as it travels from that point
to the receiver. This is usually expressed as a dimensionless percentage.</t>
<t hangText="Upstream congestion:">The accumulated congestion
experienced by a traffic flow thus far, relative to a point along
its path. In other words, at a measurement point in the network
the upstream congestion is the accumulated congestion the traffic
flow has experienced as it travels from the sender to that point.
At the receiver this is equivalent to the end-to-end congestion
level that (usually) is reported back to the sender. This is usually expressed as
a dimensionless percentage.</t>
<t hangText="Network operators (or providers):">Operator of a
residential, commercial, enterprise, campus or other network.</t>
<t hangText="User:">The contractual entity that represents an
individual, household, business, or institution that uses the
service of a network operator. There is no implication that the
contract has to be commercial; for instance, the users of a
university or enterprise network service could be students or
employees who do not pay for access but may be required to comply
with some form of contract or acceptable use policy. There is also
no implication that every user is an end user. Where two networks
form a customer-provider relationship, the term user applies to
the customer network.</t>
</list></t>
<t><xref target="I-D.ietf-conex-abstract-mech"></xref> gives further
definitions for aspects of ConEx related to protocol mechanisms.</t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="traffic-management"
title="Core Use Case: Informing Traffic Management">
<t>This section explains how ConEx could be used as the basis for
traffic management, highlights additional benefits derived from having
ConEx-aware nodes on the network, and compares ConEx-based traffic
management to existing approaches.</t>
<section anchor="using-conex" title="Use Case Description">
<t>One of the key benefits that ConEx can deliver is in helping
network operators to improve how they manage traffic on their
networks. Consider the common case of a commercial broadband network
where a relatively small number of users place disproportionate demand
on network resources, at times resulting in congestion. The network
operator seeks a way to manage traffic such that the traffic that
contributes more to congestion bears more of the brunt of the
management.</t>
<t>Assuming ConEx signals are visible at the IP layer, the network
operator can accomplish this by placing a congestion policer at an
enforcement point within the network and configuring it with a traffic
management policy that monitors each user's contribution to
congestion. As described in <xref
target="I-D.ietf-conex-abstract-mech"></xref> and elaborated in <xref
target="CongPol"></xref>, one way to implement a congestion policer is
in a similar way to a bit-rate policer, except that it monitors
congestion-volume (based on IP layer ConEx signals) rather than
bit-rate. When implemented as a token bucket, the tokens provide users
with the right to cause bits of congestion-volume, rather than to send
bits of data volume. The fill rate represents each user's
congestion-volume quota.</t>
<t>The congestion policer monitors the ConEx signals of the traffic
entering the network. As long as the network remains uncongested and
users stay within their quotas, no action is taken. When the network
becomes congested and a user exhausts his quota, some action is taken
against the traffic that breached the quota in accordance with the
network operator's traffic management policy. For example, the traffic
may be dropped, delayed, or marked with a lower QoS class. In this
way, traffic is managed according to its contribution to congestion --
not some application- or flow-specific policy -- and is not managed at
all during times of no congestion.</t>
<t>As an example of how a network operator might employ a ConEx-based
traffic management system, consider a typical DSL network architecture
(as elaborated in <xref target="TR-059"></xref> and <xref
target="TR-101"></xref>). Traffic is routed from regional and global
IP networks to an operator-controlled IP node, the Broadband Remote
Access Server (BRAS). From the BRAS, traffic is delivered to access
nodes. The BRAS carries enhanced functionality including IP QoS and
traffic management capabilities.</t>
<t>By deploying a congestion policer at the BRAS location, the network
operator can measure the congestion-volume created by users within the
access nodes and police misbehaving users before their traffic affects
others on the access network. The policer would be provisioned with a
traffic management policy, perhaps directing the BRAS to drop packets
from users that exceed their congestion-volume quotas during times of
congestion. Those users' apps would be likely to react in the typical
way to drops, backing off (assuming at least some use TCP), and
thereby lowering the users' congestion-volumes back within the quota
limits. If none of a user's apps responds, the policer would continue
to increase focused drops and effectively enforce its own congestion
control.</t>
</section>
<section anchor="additional-benefits" title="Additional Benefits">
<t>The ConEx-based approach to traffic management has a number of
benefits in addition to efficient management of traffic. It provides
incentives for users to make use of "scavenger" transport protocols,
such as <xref target="I-D.ietf-ledbat-congestion"></xref>, that
provide ways for bulk-transfer applications to rapidly yield when
interactive applications require capacity (thereby "scavenging"
remaining bandwidth). With a congestion policer in place as described
in <xref target="using-conex"></xref>, users of these protocols will
be less likely to run afoul of the network operator's traffic
management policy than those whose bulk-transfer applications generate
the same volume of traffic without being sensitive to congestion. In
short, two users who produce similar traffic volumes over the same
time interval may produce different congestion-volumes if one of them
is using a scavenger transport protocol and the other is not; in that
situation the scavenger user's traffic is less likely to be managed by
the network operator.</t>
<t>ConEx-based traffic management also makes it possible for a user to
control the relative performance among its own traffic flows. If a
user wants some flows to have more bandwidth than others, it can
reduce the rate of some traffic so that it consumes less
congestion-volume "budget", leaving more congestion-volume "budget" for the
user to "spend" on making other traffic go faster. This approach is
most relevant if congestion is signalled by ECN, because no impairment
due to loss is involved and delay can remain low.</t>
</section>
<section anchor="comparison" title="Comparison with Existing Approaches">
<t>A variety of approaches already exist for network operators to
manage congestion, traffic, and the disproportionate usage of scarce
capacity by a small number of users. Common approaches can be
categorized as rate-based, volume-based, or application-based.</t>
<t>Rate-based approaches constrain the traffic rate per user or per
network. A user's peak and average (or "committed") rate may be
limited. These approaches have the potential to either over- or
under-constrain the network, suppressing rates even when the network
is uncongested or not suppressing them enough during heavy usage
periods.</t>
<t>Round-robin scheduling and fair queuing were developed to address
these problems. They equalize relative rates between active users (or
flows) at a known bottleneck. The bit-rate allocated to any one user
depends on the number of active users at each instant. The drawback of
these approaches is that they favor heavy users over light users over
time, because they do not have any memory of usage. Heavy users will
be active at every instant whereas light users will only occupy their
share of the link occassionally, but bit-rate is shared instant by
instant.</t>
<t>Volume-based approaches measure the overall volume of traffic a
user sends (and/or receives) over time. Users may be subject to an
absolute volume cap (for example, 10GB per month) or the "heaviest"
users may be sanctioned in some other manner. Many providers use
monthly volume limits and count volume regardless of whether the
network is congested or not, creating the potential for over- or
under-constraining problems, as with the original rate-based
approaches.</t>
<t>ConEx-based approaches, by comparison, only react during times of
congestion and in proportion to each user's congestion contribution,
making more efficient use of capacity and more proportionate
management decisions.</t>
<t>Unlike ConEx-based approaches, neither rate-based nor volume-based
approaches provide incentives for applications to use scavenger
transport protocols. They may even penalize users of applications that
employ scavenger transports for the large amount of volume they send,
rather than rewarding them for carefully avoiding congestion while
sending it. While the volume-based approach described in Comcast's
Protocol-Agnostic Congestion Management System <xref
target="RFC6057"></xref> aims to overcome the over/under-constraining
problem by only measuring volume and triggering traffic management
action during periods of high utilization, it still does not provide
incentives to use scavenger transports because congestion-causing
volume cannot be distinguished from volume overall. ConEx provides
this ability.</t>
<t>Application-based approaches use deep packet inspection or other
techniques to determine what application a given traffic flow is
associated with. Network operators may then use this information to
rate-limit or otherwise sanction certain applications, in some cases
only during peak hours. These approaches suffer from being at odds
with IPsec and some application-layer encryption, and they may raise
additional policy concerns. In contrast, ConEx offers an
application-agnostic metric to serve as the basis for traffic
management decisions.</t>
<t>The existing types of approaches share a further limitation that
ConEx can help to overcome: performance uncertainty. Flat-rate pricing
plans are popular because users appreciate the certainty of having
their monthly bill amount remain the same for each billing period,
allowing them to plan their costs accordingly. But while flat-rate
pricing avoids billing uncertainty, it creates performance
uncertainty: users cannot know whether the performance of their
connections is being altered or degraded based on how the network
operator is attempting to manage congestion. By exposing congestion
information at the IP layer, ConEx instead provides a metric that can
serve as an open, transparent basis for traffic management policies
that both providers and their customers can measure and verify. It can
be used to reduce the performance uncertainty that some users
currently experience.</t>
</section>
</section>
<section anchor="other-use-cases" title="Other Use Cases">
<t>ConEx information can be put to a number of uses other than informing
traffic management. These include:</t>
<t><list style="hanging">
<t hangText="Informing inter-operator contracts:">ConEx information
is made visible to every IP node, including border nodes between
networks. Network operators can use ConEx combined with ECN markings
to measure how much traffic from each network contributes to
congestion in the other. As such, congestion-volume could be
included as a metric in inter-operator contracts, just as volume or
bit-rate are included today. This would not be an initial deployment
scenario, unless ECN became widely deployed.</t>
<t hangText="Enabling more efficient capacity provisioning:"><xref
target="additional-benefits"></xref> explained how operators can use
ConEx-based traffic management to encourage use of scavenger
transport protocols, which significantly improves the performance of
interactive applications while still allowing heavy users to
transfer high volumes. Here we explain how this can also benefit
network operators.<vspace blankLines="1" />Today, when loss, delay
or averaged utilization exceeds a certain threshold, some operators
just buy more capacity without attempting to manage the traffic.
Other operators prefer to limit a minority of heavy users at peak
times, but they still eventually buy more capacity when utilization
rises.<vspace blankLines="1" />With ConEx-based traffic management,
a network operator should be able to provision capacity more
efficiently. An operator could benefit from this in a variety of
ways. For example, the operator could add capacity as it would do
without ConEx, but deliver better quality of service for its users.
Or the operator could delay adding capacity while delivering similar
quality of service to what it currently provides.</t>
</list></t>
</section>
<!-- ====================================================================== -->
<section anchor="deployments" title="Deployment Arrangements">
<t>ConEx is designed so that it can be incrementally deployed in the
Internet and still be valuable for early adopters. As long as some
senders are ConEx-enabled, a network on the path can unilaterally use
ConEx-aware policy devices for traffic management; no changes to network
forwarding elements are needed and ConEx still works if there are other
networks on the path that are unaware of ConEx marks.</t>
<t>The above two steps seem to represent a stand-off where neither step
is useful until the other has made the first move: i) some sending hosts
must be modifed to give information to the network and ii) a network
must deploy policy devices to monitor this information and act on it.
Nonetheless, the developer of a scavenger transport protocol like LEDBAT
does stand to benefit from deploying ConEx. In this case the developer
makes the first move, expecting it will prompt at least some networks to
move in response, using the ConEx information to reward users of the
scavenger transport protocol.</t>
<t>On the host side, we have already shown (<xref
target="conex-uses_Fig_ConEx_Placement"></xref>) how the sender
piggy-backs ConEx signals on normal data packets to re-insert feedback
about packet drops (and/or ECN) back into the IP layer. In the case of
TCP, <xref target="I-D.ietf-conex-tcp-modifications"></xref> proposes
the required sender modifications. ConEx works with any TCP receiver as
long as it uses SACK, which most do. There is a receiver optimisation
<xref target="I-D.tcpm-accurate-ecn"></xref> that improves ConEx
precision when using ECN, but ConEx can still use ECN without it. Networks can make use of ConEx even if the implementations of some of the transport protocols on a host do not support ConEx (e.g. the implementation of DNS over UDP
might not support ConEx, while perhaps RTP over UDP and TCP will).</t>
<t>On the network side the provider solely needs to place ConEx
congestion policers at each ingress to its network, in a similar
arrangement to the edge-policed architecture of Diffserv <xref
target="RFC2475"></xref>.</t>
<t>A sender can choose whether to send packets that support ConEx or
packets that don't. ConEx-enabled packets bring information to the
policer about congestion expected on the rest of the path beyond the
policer. Packets that do not support ConEx bring no such information.
Therefore the network will tend to conservatively rate-limit
non-ConEx-enabled packets in order to manage the unknown risk of
congestion. In contrast, a network doesn't normally need to rate-limit
ConEx-enabled packets unless they reveal a persistently high
contribution to congestion. This natural tendency for networks to favour senders that provide
ConEx information reinforces ConEx deployment.</t>
<t>Feasible initial
deployment scenarios exist for a broadband access network <xref target="I-D.briscoe-conex-initial-deploy"></xref>, a
mobile communications network <xref
target="I-D.ietf-conex-mobile"></xref>, and a multi-tenant data centre
<xref target="I-D.briscoe-conex-data-centre"></xref>. The first
two of these scenarios are believed to work well without ECN support, while the data center scenario works best with ECN (where it may be more likely for ECN to be deployed in the future).</t>
<t>The above gives only the most salient aspects of ConEx deployment.
For further detail, <xref target="I-D.ietf-conex-abstract-mech"></xref>
describes the incremental deployment features of the ConEx protocol and
the components that need to be deployed for ConEx to work.</t>
</section>
<section anchor="experimental" title="Experimental Considerations">
<t>ConEx is initially designed as an experimental protocol because it
makes an ambitious change at the interoperability (IP) layer, so no
amount of careful design can foresee all the potential feature
interactions with other uses of IP. This section identifies a number of
questions that would be useful to answer through well-designed
experiments:<list style="symbols">
<t>Are the compromises that were made in order to fit the ConEx encoding into IP (for example, that the initial design was
solely for IPv6 and not for IPv4, and that the encoding has limited visibility when tunnelled <xref
target="I-D.ietf-conex-destopt"></xref>) the right ones?</t>
<t>Is it possible to combine techniques for distinguishing self-congestion from shared
congestion with ConEx-based traffic management such that users are not penalized for congestion that does not impact others on the network? Are other
techniques needed?</t>
<t>If ECN deployment remains patchy, are the proposed initial ConEx
deployment scenarios (<xref target="deployments"></xref>) still
useful enough to kick-start deployment? Is audit effective
when based on loss at a primary bottleneck? Can rest-of-path
congestion be approximated accurately enough without ECN? Are there other useful deployment scenarios?</t>
<t>In practice, how does traffic management using ConEx compare with
traditional techniques (<xref target="comparison"></xref>)? Does it
give the benefits claimed in <xref target="using-conex"></xref> and
<xref target="additional-benefits"></xref>?</t>
<t>Approaches are proposed for congestion policing of ConEx traffic
alongside existing management (or lack thereof) of non-ConEx traffic, including UDP traffic <xref
target="I-D.ietf-conex-abstract-mech"></xref>. Are they
strategy-proof against users selectively using both? Are there
better transition strategies?</t>
<t>Audit devices have been designed and implemented to assure ConEx
signal integrity <xref
target="I-D.ietf-conex-abstract-mech"></xref>. Do they achieve
minimal false hits and false misses in a wide range of traffic
scenarios? Are there new attacks? Are there better audit designs to
defend against these?</t>
</list></t>
<t>ConEx is intended to be a generative technology that might be used
for unexpected purposes unforeseen by the designers. Therefore this list
of experimental considerations is not intended to be exhaustive.</t>
</section>
<!-- ====================================================================== -->
<section title="Security Considerations">
<t>This document does not specify a mechanism, it merely motivates
congestion exposure at the IP layer. Therefore security considerations
are described in the companion document that gives an abstract
description of the ConEx protocol and the components that would use it
<xref target="I-D.ietf-conex-abstract-mech"></xref>.</t>
</section>
<!-- ====================================================================== -->
<section title="IANA Considerations">
<t>This document does not require actions by IANA.</t>
</section>
<!-- ====================================================================== -->
<section title="Acknowledgments">
<t>Bob Briscoe was partly funded by Trilogy, a research project
(ICT-216372) supported by the European Community under its Seventh
Framework Programme. The views expressed here are those of the author
only.</t>
<t>The authors would like to thank the many people that have commented
on this document: Bernard Aboba, Mikael Abrahamsson, João Taveira
Araújo, Marcelo Bagnulo Braun, Steve Bauer, Caitlin Bestler,
Steven Blake, Louise Burness, Ken Carlberg, Nandita Dukkipati, Dave
McDysan, Wes Eddy, Matthew Ford, Ingemar Johansson, Georgios
Karagiannis, Mirja Kuehlewind, Dirk Kutscher, Zhu Lei, Kevin Mason, Matt
Mathis, Michael Menth, Chris Morrow, Tim Shepard, Hannes Tschofenig and
Stuart Venters. Please accept our apologies if your name has been missed
off this list.</t>
<section title="Contributors">
<t>Philip Eardley and Andrea Soppera made helpful text contributions
to this document.</t>
<t>The following co-edited this document through most of its life:</t>
<figure>
<artwork><![CDATA[
Toby Moncaster
Computer Laboratory
William Gates Building
JJ Thomson Avenue
Cambridge, CB3 0FD
UK
EMail: toby.moncaster@cl.cam.ac.uk
John Leslie
JLC.net
10 Souhegan Street
Milford, NH 03055
US
EMail: john@jlc.net
]]></artwork>
</figure>
</section>
</section>
<!-- ====================================================================== -->
</middle>
<back>
<references title="Informative References">
<?rfc include='reference.RFC.2475.xml'?>
<?rfc include='reference.RFC.3168.xml'?>
<?rfc include='reference.RFC.6057.xml'?>
&I-D.ietf-conex-abstract-mech;
<reference anchor="I-D.tcpm-accurate-ecn">
<front>
<title>Accurate ECN Feedback Option in TCP</title>
<author fullname="Mirja Kuehlewind" initials="M"
surname="Kuehlewind">
<organization></organization>
</author>
<author fullname="Richard Scheffenegger" initials="R"
surname="Scheffenegger">
<organization></organization>
</author>
<date day="13" month="July" year="2012" />
<abstract>
<t>This document specifies an TCP option to get accurate Explicit
Congestion Notification (ECN) feedback from the receiver. ECN is
an IP/TCP mechanism where network nodes can mark IP packets
instead of dropping them to indicate congestion to the end-points.
An ECN- capable receiver will feedback this information to the
sender. ECN is specified for TCP in such a way that only one
feedback signal can be transmitted per Round-Trip Time (RTT).
Recently new TCP mechanisms like ConEx or DCTCP need more accurate
feedback information in the case where more than one marking is
received in one RTT. This TCP extension can be used in addition to
the classic ECN as well as with a more accurate ECN scheme
recently proposed which reuses the ECN bit in the TCP header.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-kuehlewind-tcpm-accurate-ecn-option-01" />
<format target="http://www.ietf.org/internet-drafts/draft-kuehlewind-tcpm-accurate-ecn-option-01.txt"
type="TXT" />
</reference>
&I-D.briscoe-conex-initial-deploy;
&I-D.ietf-conex-mobile;
<reference anchor="I-D.briscoe-conex-data-centre">
<front>
<title>Network Performance Isolation in Data Centres using
Congestion Exposure (ConEx)</title>
<author fullname="Bob Briscoe" initials="B" surname="Briscoe">
<organization></organization>
</author>
<author fullname="Murari Sridharan" initials="M" surname="Sridharan">
<organization></organization>
</author>
<date day="9" month="July" year="2012" />
<abstract>
<t>This document describes how a multi-tenant data centre operator
can isolate tenants from network performance degradation due to
each other's usage, but without losing the multiplexing benefits
of a LAN- style network where anyone can use any amount of any
resource. Zero per-tenant configuration and no implementation
change is required on network equipment. Instead the solution is
implemented with a simple change to the hypervisor (or container)
on each physical server, beneath the tenant's virtual machines.
These collectively enforce a very simple distributed contract - a
single network allowance that each tenant can allocate among their
virtual machines. The solution is simplest and most efficient
using layer-3 switches that support explicit congestion
notification (ECN) and if the sending operating system supports
congestion exposure (ConEx). Nonetheless, an arrangement is
described so that the operator can unilaterally deploy a complete
solution while operating systems are being incrementally upgraded
to support ConEx.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-briscoe-conex-data-centre-00" />
<format target="http://www.ietf.org/internet-drafts/draft-briscoe-conex-data-centre-00.txt"
type="TXT" />
</reference>
&I-D.ietf-conex-tcp-modifications;
&I-D.ietf-conex-destopt;
&I-D.ietf-ledbat-congestion;
<reference anchor="CongPol">
<front>
<title>Policing Freedom to Use the Internet Resource Pool</title>
<author fullname="Bob Briscoe" initials="B" surname="Briscoe">
<organization>BT & UCL</organization>
</author>
<author fullname="Arnaud Jacquet" initials="A" surname="Jacquet">
<organization>BT</organization>
</author>
<author fullname="Toby Moncaster" initials="T" surname="Moncaster">
<organization>BT</organization>
</author>
<date day="4" month="December" year="2008" />
</front>
<seriesInfo name="RE-Arch 2008 hosted at the 2008 CoNEXT conference"
value="" />
<format target="http://portal.acm.org/ft_gateway.cfm?id=1544083&type=pdf&coll=GUIDE&dl=GUIDE&CFID=94433196&CFTOKEN=11585540"
type="PDF" />
</reference>
<reference anchor="Bauer09">
<front>
<title>The Evolution of Internet Congestion</title>
<author fullname="Steven Bauer" initials="S" surname="Bauer">
<organization>MIT</organization>
</author>
<author fullname="David Clark" initials="D" surname="Clark">
<organization>MIT</organization>
</author>
<author fullname="William Lehr" initials="W" surname="Lehr">
<organization>MIT</organization>
</author>
<date year="2009" />
</front>
<format target="http://mitas.csail.mit.edu/papers/Bauer_Clark_Lehr_2009.pdf"
type="PDF" />
</reference>
<reference anchor="TR-059">
<front>
<title>DSL Forum Technical Report TR-059: Requirements for the
Support of QoS-Enabled IP Services</title>
<author fullname="Tom Anschutz" initials="T." role="editor"
surname="Anschutz">
<organization>BellSouth Telecommunications</organization>
</author>
<date month="September" year="2003" />
</front>
<format target="http://www.broadband-forum.org/technical/download/TR-059.pdf"
type="PDF" />
</reference>
<reference anchor="TR-101">
<front>
<title>DSL Forum Technical Report TR-101: Migration to
Ethernet-Based DSL Aggregation</title>
<author fullname="Amit Cohen" initials="A." role="editor"
surname="Cohen">
<organization>ECI Telecom</organization>
</author>
<author fullname="Ed Shrum" initials="E." role="editor"
surname="Schrum">
<organization>BellSouth Telecommunications</organization>
</author>
<date month="April" year="2006" />
</front>
<format target="http://www.broadband-forum.org/technical/download/TR-101.pdf"
type="PDF" />
</reference>
</references>
<!-- ====================================================================== -->
<!--
<section title="Changes from previous drafts (to be removed by the RFC Editor)">
<t><list style="hanging">
<t
hangText="From draft-ietf-conex-concepts-uses-02 to -03:">Reorganization
and re-write of most sections.</t>
<t hangText="From draft-ietf-conex-concepts-uses-01 to -02:">New
Abstract & Introduction. Concepts and Misconceptions sections
added around definitions. Minor clarifications to Existing Traffic
Management and Use-Cases sections, with Other use Cases Added.
Deployment Arrangements Section added.</t>
<t hangText="From draft-ietf-conex-concepts-uses-00 to -01:"></t>
<t>Added section on timescales: Section 6</t>
<t>Revised introduction to clarify congestion definitions</t>
<t>Changed source for congestion definition in <xref
target="concepts"></xref></t>
<t>Other minor changes</t>
<t
hangText="From draft-moncaster-conex-concepts-uses-02 to draft-ietf-conex-concepts-uses-00 (per decisions of working group):"></t>
<t>Removed section on DDoS mitigation use case.</t>
<t>Removed appendix on ConEx Architectural Elements. PLEASE NOTE:
Alignment of terminology with the Abstract Mechanism draft has been
deferred to the next version.</t>
<t
hangText="From draft-moncaster-conex-concepts-uses-01 to draft-moncaster-conex-concepts-uses-02:"></t>
<t>Updated document to take account of the new Abstract Mechanism
draft <xref target="ConEx-Abstract-Mech"></xref>.</t>
<t>Updated the definitions section.</t>
<t>Removed sections on Requirements and Mechanism.</t>
<t>Moved section on ConEx Architectural Elements to appendix.</t>
<t>Minor changes throughout.</t>
<t
hangText="From draft-moncaster-conex-concepts-uses-00 to draft-moncaster-conex-concepts-uses-01:"></t>
<t>Changed end of Abstract to better reflect new title</t>
<t>Created new section describing the architectural elements of
ConEx. Added Edge Monitors and Border Monitors (other elements are
Ingress, Egress and Border Policers).</t>
<t>Extensive re-write of use cases partly in response to suggestions
from Dirk Kutscher</t>
<t>Improved layout of <xref target="concepts"></xref> and added
definitions of Whole Path Congestion, ConEx-Enabled and ECN-Enabled.
Re-wrote definition of Congestion Volume. Renamed Ingress and Egress
Router to Ingress and Egress Node as these nodes may not actually be
routers.</t>
<t>Improved document structure. Merged sections on Exposing
Congestion and ECN.</t>
<t>Added new section on ConEx requirements with a ConEx Issues
subsection. Text for these came from the start of the old ConEx Use
Cases section</t>
<t>Added a sub-section on Partial vs Full Deployment (Section
5.5)</t>
<t>Added a discussion on ConEx as a Business Secret</t>
<t
hangText="From draft-conex-mechanism-00 to draft-moncaster-conex-concepts-uses-00:"></t>
<t>Changed filename to draft-moncaster-conex-concepts-uses.</t>
<t>Changed title to ConEx Concepts and Use Cases.</t>
<t>Chose uniform capitalization of ConEx.</t>
<t>Moved definition of Congestion Volume to list of definitions.</t>
<t>Clarified mechanism section. Changed section title.</t>
<t>Modified text relating to conex-aware policing and policers
(which are NOT defined terms).</t>
<t>Re-worded bullet on distinguishing ConEx and non-ConEx traffic in
use cases section.</t>
</list></t>
</section>
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:56:35 |