One document matched: draft-ietf-conex-concepts-uses-02.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">
<rfc category="info" docName="draft-ietf-conex-concepts-uses-02"
ipr="trust200902">
<front>
<title abbrev="ConEx Concepts & Use Cases">ConEx Concepts and Use
Cases</title>
<!--
<author fullname="Toby Moncaster" initials="T." surname="Moncaster">
<organization>Moncaster Internet Consulting</organization>
<address>
<postal>
<street>Dukes</street>
<street>Layer Marney</street>
<city>Colchester</city>
<code>CO5 9UZ</code>
<country>UK</country>
</postal>
<email>toby@moncaster.com</email>
</address>
</author>
<author fullname="John Leslie" initials="J." surname="Leslie">
<organization>JLC.net</organization>
<address>
<postal>
<street>10 Souhegan Street</street>
<city>Milford</city>
<code>03055</code>
<region>NH</region>
<country>US</country>
</postal>
<email>john@jlc.net</email>
</address>
</author>
-->
<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>Comcast Cable Communications</street>
<street>27 Industrial Avenue</street>
<city>Chelmsford</city>
<code>01824</code>
<region>MA</region>
<country>US</country>
</postal>
<email>richard_woundy@cable.comcast.com</email>
<uri>http://www.comcast.com</uri>
</address>
</author>
<!--
<author fullname="Dave McDysan" initials="D." surname="McDysan">
<organization>Verizon</organization>
<address>
<postal>
<street>22001 Loudon County Pkwy</street>
<city>Ashburn</city>
<code>20147</code>
<region>VA</region>
<country>US</country>
</postal>
<email>dave.mcdysan@verizon.com</email>
</address>
</author>
-->
<date day="11" month="July" year="2011" />
<area>Transport Area</area>
<workgroup>ConEx</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document provides the entry point to the set of documentation on
a new Congestion Exposure (ConEx) protocol. It motivates a new ConEx
field at the IP layer, focusing on the 'why' rather than the 'how'. In
the absence of such a protocol, traffic is subjected to numerous traffic
management checks and limits as it crosses the Internet. The purpose of
this protocol is to expose congestion to network operators, so that they
have no need to intervene at all when there is no congestion, and so
they have exactly the right information when there is congestion. Then
it will at least be possible for traffic management to be
application-neutral, openly transparent and free of unnecessary
restraints. Although traffic management is the focus of this document,
it also briefly introduces a number of other important potential uses
for ConEx, demonstrating its role as a generative technology and
justifying its placement in the IP layer.</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 usually
provide sufficient shared capacity, but whenever too much packet load
meets too little shared capacity, congestion results. Congestion appears
as either increased delay, missing packets or packets explicitly marked
with ECN <xref target="RFC3168"></xref>. Referring to <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 meant to reduce its rate in response.</t>
<t>This document provides the entry point to the set of documentation on
Congestion Exposure (ConEx). It motivates a new ConEx field at the IP
layer, focusing on the 'why' rather than the 'how'. A companion document
about the ConEx protocol mechanism gives the 'how' <xref
target="ConEx-Abstract-Mech"></xref>. 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>). Certain IP layer
devices can then use this new information, for example as input to
traffic management.</t>
<figure anchor="conex-uses_Fig_ConEx_Placement"
title="Where the ConEx Protocol Fits 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>Current traffic management solutions limit traffic based on either
bit-rate or volume. For instance, weighted fair queuing (based on <xref
target="RFC0970"></xref>) shares out bit-rate when a link is congested.
However it fails to consider how much of the time a consumer keeps the
link busy, which is the main factor that determines everyone else's
bit-rate. To try to address this issue, many network operators have
introduced volume limits. However, these tend to be either not strict
enough during congested periods, or unnecessarily strict when traffic is
light.</t>
<t>Because each solution only partially addresses the problem, operators
keep adding more solutions. So a data path across the Internet often
encounters numerous blockages and throttles in each network it crosses.
This clutter is actually a symptom of a deeper underlying problem:
neither bit-rate nor volume is the right metric.</t>
<t>Traffic management would be so much better (and simpler) if
congestion were visible in packets. Then, whenever congestion was not
present, all restraints could be removed, leaving the full capacity
available to everyone. But if some excessive users were causing a lot of
congestion, the traffic management function would know and be able to
directly limit their traffic, in order to protect the service of other
users sharing the same capacity.</t>
<t>ConEx exposes exactly the right information for this, in the IP
layer. It reveals a consumer's overall contribution to congestion, which
is a direct measure of how much one user affects others. ConEx makes
this easy to measure—as easy as counting straight volume, except
you only count the volume of packets with ConEx markings. With the right
metric visible, traffic management would only have to be done once on a
path because it would be done well.</t>
<t>In the absence of the right metric, some operators have deployed deep
packet inspection (DPI) equipment; not just in the public Internet but
also in enterprise and campus networks. Their main aim has been to
identify and limit specific types of application that they associate
with heavy usage.<!--Quite apart from the architectural and neutrality issues raised by such technology,
its applicability is declining anyway.
In recent years, video traffic has overtaken peer-to-peer filesharing as the predominant type of traffic.
But even those operators who have been limiting peer-to-peer have no wish to limit certain types of video application.--></t>
<t>With ConEx, a network operator can manage traffic without dipping
into the higher layers, because ConEx makes the relevant bulk congestion
information accessible at the IP layer. This solves two problems that
have made DPI controversial: traffic management can be
application-neutral and compatible with IPsec encryption.</t>
<t>Also, because ConEx information is added explicitly at the IP layer,
it is visible to provider and consumer alike. Therefore traffic
contracts or acceptable use policies can be based on a quantifiable
metric that is open and transparent to both parties, so that it will be
sufficient to manage traffic without extra non-transparent wriggle-room
and caveats.</t>
<t>To summarise so far, ConEx is designed to make it simple to do
traffic management that is transparent, neutral and free of unnecessary
restraints. Although it is not our place to make a network provider meet
these requirements, ConEx is designed to make this the simplest service
to provide.</t>
<t>{ToDo: review this para when done and shorten} This introduction has
focused on traffic management as the main use for ConEx. However, ConEx
is intended as a generative technology, with a wider range of potential
uses. The document structure reflects this. <xref
target="conex-uses-traffic-mgmt"></xref> overviews existing approaches
to traffic management and <xref
target="conex-uses-exposing_congestion"></xref> explains why exposing
congestion would address their limitations. <xref
target="conex-uses-cases"></xref> introduces the main use-cases for
ConEx: traffic management, incentivising scavenger transports and
intra-class quality of service as well as briefly mentioning others.
Then <xref target="conex-uses-deployments"></xref> presents how how the
above use-cases might drive deployment of ConEx. Finally, <xref
target="conex-uses-issues"></xref> discusses a number of potential
issues (and non-issues) that are often raised about ConEx, before the
usual tailpiece sections in conclusion.</t>
<t>But before all this, <xref target="conex-uses-defs"></xref>
introduces the basic concepts necessary to understand ConEx, as well as
dispelling a number of common misconceptions.</t>
</section>
<!-- ====================================================================== -->
<section anchor="conex-uses-defs" title="Concepts">
<t>Despite its central role in network control and management,
congestion is a remarkably hard concept to define. <xref
target="Bauer09"></xref> provides a good academic background. For the
purposes of ConEx, the definition below focuses on how congestion would
be measured, rather than precisely what it is. Our definition of
congestion is then equivalent to the loss probability (or the marking
probability if ECN is used).</t>
<t>ConEx is essentially about accountability for congestion (or blame in
crude language). The blame for congestion lies equally between too
little capacity and too much traffic. On the capacity side, congestion
itself measures how badly the network provider is to blame. On the
traffic side, in a shared network, the blame is split among all the
users. Congestion-volume measures how much of each user's traffic is to
blame for the congestion. Note that congestion-volume is a property of
traffic, whereas congestion is a property of a link or a path.</t>
<t>Congestion-volume is a relatively newly defined metric that is
central to ConEx. To grasp an intuitive feel for what congestion-volume
measures, some network operators give you an allowance and only count
data volume during the peak period against it. This is equivalent to
counting your congestion-volume by assuming that congestion is 100%
during the peak period and 0% otherwise.</t>
<t>The congestion-volume metric is more refined but broadly equivalent
to the above time-of-day volume example and still as simple to measure.
Imagine Alice sends 1GB while the loss-probability is a constant 0.2%.
Then her contribution to congestion (or congestion-volume) is 1GB x 0.2%
= 2MB. If she then sends 3GB while congestion is 0.1%, this adds 3MB to
her congestion-volume. Her total contribution to congestion is then
2MB+3MB = 5MB.</t>
<t>To measure Alice's congestion-volume no-one has to do all these
multiplications and additions. It is simply a matter of counting the
total volume of Alice's traffic that was discarded (a queue with a
percentage loss involves multiplication inherently).</t>
<t>Finally, there is yet another way to cut the blame for congestion.
Recall that the level of congestion itself measures the provider's
blame. However, in an internetwork there are multiple providers. If a
data centre network with zero congestion is connected to an access
network and sends traffic over a link with 0.4% loss probability, then
clearly all the blame for congestion lies with the access network.
However, at another time, there might be 0.1% congestion across the data
centre and 0.7% across the access, making 0.8% end-to-end congestion
across the path.</t>
<t>In order to apportion blame accordingly, ConEx information is placed
in the IP layer so that a simple border meter can see how much of the
congestion is on one side or other, termed upstream and downstream
congestion.</t>
<t>If A and B are connected within a chain of more than two networks, A
attributes all congestion beyond B to B, and vice versa. As far as A is
concerned, B chooses who to route to, so B takes responsibility for its
choices.</t>
<section title="Definitions">
<t><list style="hanging">
<t hangText="Congestion:">Congestion occurs when any user's
traffic suffers increased delay, loss or ECN marking as a result
of one or more network resources becoming overloaded. For the
purposes of ConEx, the focus is on concrete signals of congestion
(ECN and loss), therefore delay is set to one side. Congestion is
measured as the probability of loss or the probability of ECN
marking, usually expressed as dimensionless percentages.</t>
<t hangText="Congestion-volume:">For any granularity of traffic
(packet, flow, aggregate, link, etc.), the volume of bytes dropped
or marked in a given period of time. Conceptually, data volume
multiplied by the instantaneous congestion each packet of the
volume experienced. Usually expressed in bytes (or MB, GB, of
course).</t>
<t hangText="Congestion-rate:">For any granularity of traffic
(packet, flow, aggregate, link, etc.), the instantaneous rate of
traffic discarded or marked due to congestion. Conceptually, the
instantaneous bit-rate of the traffic weighted by the
instantaneous congestion it experiences. Usually expressed in
b/s.</t>
<t hangText="Upstream Congestion:">The accumulated level of
congestion experienced by a traffic flow thus far, relative to a
point along its path. In other words, at any point the Upstream
Congestion is the accmulated level of 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.</t>
<t hangText="Downstream Congestion:">The level of congestion a
flow of traffic is expected to experience on the remainder of its
path. In other words, at any point the Downstream Congestion is
the level of congestion the traffic flow is yet to experience as
it travels from that point to the receiver. Aka. Rest-of-Path
Congestion.</t>
<t hangText="Network provider:">(also 'operator'): the term is not
confined to Internet service providers (ISPs) who run commercial
public networks but is also intended to generalise to operators of
enterprise, campus and other networks.</t>
<t hangText="Consumer:">A general term representing the
contractual entity such as a user or business or institution that
uses the service of a network provider. There is no implication
that the contract has to be commercial; for instance the consumers
of a University or enterprise network service would be students or
employees and they might well be required to comply with some form
of contract or acceptable use policy. There is also no implication
that the consumer is necessarily an end-consumer. Where two
networks form a customer-provider relationship, the term consumer
is also intended to cover the customer network.</t>
</list></t>
<t><xref target="ConEx-Abstract-Mech"></xref> gives further
definitions for aspects of ConEx to do with protocol mechanisms.</t>
</section>
<section title="Non-Goals of ConEx and Common Misconceptions">
<t>Congestion exposure is about the transport sender exposing
congestion to the network, not the other way round. That would not
make sense given by design the transport endpoints handle congestion
in the TCP/IP protocol suite.</t>
<t>Nonetheless, it is a non-goal for IP layer devices to use this
ConEx information to do fine-grained congestion control. That is still
best done at the transport sender. There is also no expectation that
the information will be used by every IP router and forwarding device.
More likely, specific ConEx-based functions like traffic management
will be added to edge routers. This in turn should incentivize
end-system transports to be more careful about congesting others.</t>
<t>Note that good behaviour at individual flow granularity is the
intended outcome, not the forcing function—it is the end, not
the means. Enforcing per-flow compliance to the TCP congestion
response (or any per-flow rate enforcement) is a non-goal:<list
style="symbols">
<t>It used to be commonly believed that TCP-friendliness was
critical to fairness on the Internet. However, no congestion
control algorithm can determine how much data an application
transfers, or how many flows it opens, or which congestion control
algorithm an application uses, or how many applications the user
runs, or how many users are active at once. These factors all have
a stronger impact on how great a share of a link is available for
any particular data transfer. To achieve fairness at this broader
granularity (between users, homes, sites or whole networks)
requires that individual flows in the same bottleneck will
sometimes be very unequal.</t>
<t>If the network forced everything to be TCP-friendly, some
important applications would not work. Worse still, this would
prevent deployment of higher performance replacements to TCP. It
is important to allow give and take between one user's flows: some
can be more aggressive than TCP and others less, e.g. long
transfers, following the example of LEDBAT <xref
target="LEDBAT"></xref> (see <xref
target="conex-uses-scavenge"></xref>).</t>
</list>Therefore, network enforcement of per-flow fairness is not
only a non-goal, it would be a harmful goal in many respects.</t>
<t>Capacity provisioning is another area of confusion in relation to
ConEx. Congestion-based traffic management is not an alternative to
good capacity provisioning. Either or both can be good practice
depending on the situation, and ConEx can provide a useful metric for
both (see <xref target="conex-uses-other"></xref>).</t>
<t>Any network that is persistently highly congested is inefficient.
However, the total absence of congestion from <spanx style="emph">all</spanx>
parts of a network is equally inefficient. If an end-to-end transport
protocol cannot go fast enough to find a bottleneck somewhere along
the path—typically in an access network—it is probably
broken. The long-standing aim of congestion control has been to find
the healthy point of balance with a low level of congestion <spanx
style="emph">somewhere </spanx>on the path. Just to be clear though,
zero congestion somewhere else (e.g. the core) is also perfectly
healthy.</t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="conex-uses-traffic-mgmt" title="Traffic Management">
<t>Since 1988 congestion management has been the responsibility of the
end-systems in the Internet architecture. The network signals congestion
to the receiver, the receiver feeds this back to the sender and the
sender is expected to reduce the traffic it sends.</t>
<t>Nonetheless, since at least when Nagle proposed fair queuing in 1985
<xref target="RFC0970"></xref>, it has been recognised that end-systems
alone cannot be entrusted with sharing out capacity between
themselves.</t>
<t>Since then capacity has been shared by a mix of traffic management
approaches, partly network-based (weighted round-robin scheduling,
weighted fair queuing, etc) and partly host-based (TCP). However, in
recent years, network operators became concerned that a relatively small
number of end-machines were consuming a disproportionately high share of
network resources. This is actually because both TCP and all the
traditional network-based approaches only share out a bottleneck at each
instant. They fail to take account of how much of the time a consumer is
keeping the link busy, which is the main factor that determines everyone
else's bit-rate.</t>
<t>As a result, some network operators introduced additional limits
based on data volume transferred over time. These also were generally
too blunt an instrument, because they counted volume whether or not it
was sent at a congested time that would limit other users. Some
operators have therefore tried to address this perceived problem by
introducing further traffic management boxes that artificially starve
certain types of traffic that they associate with heavy usage.</t>
<section anchor="conex-uses-Existing"
title="Existing Approaches to Traffic Management">
<t>Beyond this brief history, the authors have chosen not to
exhaustively list current approaches to traffic management. Broadly
they can be divided into those that happen at Layer 3 of the OSI model
and those that use information gathered from higher layers. In general
these approaches attempt to find a "proxy" measure for congestion.
Layer 3 approaches include: <list style="symbols">
<t>Rate-based — the traffic rate per user or per network is
constrained. The absolute rate a given consumer sends at may be
limited, perhaps more at peak hours, or relative rates per
consumer are equalised at a known bottleneck. The average rate or
more typically the 95th percentile taken over periods of a few
minutes is also commonly used as the basis for inter-network
billing.</t>
<t>Volume accounting — the overall volume of traffic a given
consumer sends (and/or receives) is measured. Consumers may be
subject to an absolute volume cap (e.g. 10Gbytes per month) or the
"heaviest" users may be sanctioned in some other manner.</t>
</list> Higher layer approaches include: <list style="symbols">
<t>Bottleneck per-flow rate policing — bottleneck flow rate
policers (e.g. approximate fair dropping or AFD) aim to share the
available capacity at a given bottleneck between all concurrent
flows.</t>
<t>DPI and application rate policing — in some regions of
the world and particularly in mobile networks, deep packet
inspection and other techniques are used to determine what
application a given traffic flow is associated with <xref
target="Fair-use"></xref>. Operators may then use this information
to rate-limit or otherwise sanction certain applications,
typically at peak hours.</t>
</list></t>
<t>All of these current approaches suffer from some general
limitations. First, they introduce 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
connection is being altered or degraded based on how the network
operator is attempting to manage congestion.</t>
<t>Second, none of the approaches is able to make use of what may be
the most important factor in managing congestion: the amount that a
given endpoint contributes to congestion on the network. This
information simply is not available to network nodes, and neither
volume nor rate nor application usage is an adequate proxy for
congestion-volume, because none of these metrics measures a consumer's
or network's actual contribution to congestion on the network.</t>
<t>Finally, none of these solutions accounts for inter-network
congestion. Mechanisms may exist that allow an operator to identify
and mitigate congestion in their own network, but the design of the
Internet means that only the end-hosts have full visibility of
congestion information along the whole path. ConEx allows this
information to be visible to everyone on the path and thus allows
operators to make better-informed decisions about controlling
traffic.</t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="conex-uses-exposing_congestion"
title="Exposing Congestion">
<t>We argue that current traffic-control mechanisms seek to control the
wrong quantity. What matters in the network is neither the volume of
traffic nor the rate of traffic: it is the contribution to congestion
over time — congestion means that your traffic impacts other
users, and conversely that their traffic impacts you. So if there is no
congestion there need not be any restriction on the amount a user can
send; restrictions only need to apply when others are sending traffic
such that there is congestion.</t>
<t>For example, an application intending to transfer large amounts of
data could use a congestion control mechanism like <xref
target="LEDBAT"></xref> (Low Extra Delay BAckground Transport) to reduce
its transmission rate before any competing TCP flows do, by detecting an
increase in end-to-end delay (as a measure of impending congestion).
Currently, such techniques rely on voluntary, altruistic action by end
users and their application providers. Operators cannot encourage their
use, and worse, they penalize such applications for the large amount of
volume they send rather than rewarding them for carefully avoiding
congestion while sending it.</t>
<t>The Internet was designed so that end-hosts detect and control
congestion. We argue that congestion needs to be visible to network
nodes as well, not just to the end hosts. More specifically, a network
needs to be able to measure how much congestion any particular traffic
expects to cause between the monitoring point in the network and the
destination ("rest-of-path congestion"). This would be a new capability.
Today a network can use Explicit Congestion Notification (ECN) <xref
target="RFC3168"></xref> to detect how much congestion the traffic has
suffered between the source and a monitoring point ("upstream
congestion"), but not beyond. This new capability would enable an ISP to
give incentives for the use of LEDBAT-like applications that seek to
minimise congestion in the network whilst also being able to determine
if excessive use of traditional UDP or even TCP applications was
contributing excessively to congestion.</t>
<t>So we propose a new approach which we call Congestion Exposure. We
propose that congestion information should be made visible at the IP
layer, so that any network node can measure the contribution to
congestion of an aggregate of traffic as easily as straight volume can
be measured today. Once the information is exposed in this way, it is
then possible to use it to measure the true impact of any traffic on the
network.</t>
<t>In general, congestion exposure gives operators a principled way to
hold their customers accountable for the impact on others of their
network usage and reward them for choosing congestion-sensitive
applications.</t>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<section title="ECN - a Step in the Right Direction">
<t>Explicit Congestion Notification <xref target="RFC3168"></xref>
allows routers to explicitly tell end-hosts that they are approaching
the point of congestion. ECN builds on Active Queue Mechanisms such as
random early detection (RED) <xref target="RFC2309"></xref> by
allowing the router to mark a packet with a Congestion Experienced
(CE) codepoint, rather than dropping it. The probability of a packet
being marked increases with the length of the queue and thus the rate
of CE marks is a guide to the level of congestion at that queue. This
CE codepoint travels forward through the network to the receiver which
then informs the sender that it has seen congestion. The sender is
then required to respond as if it had experienced a packet loss.
Because the CE codepoint is visible in the IP layer, this approach
reveals the upstream congestion level for a packet.</t>
<t>Alas, this is not enough - ECN gives a network node an idea of the
congestion experienced on the path up to that node. If this network
node were near a receiver, it could help hold that receiver
accountable for the congestion caused by incoming traffic. But a
receiver can only indirectly influence incoming congestion, by
politely asking the sender to control it. A receiver cannot make a
sender install an adaptive codec, or install LEDBAT instead of TCP
congestion-control. And a receiver cannot cause an attacker to stop
flooding it with traffic.</t>
<t>What is needed is knowledge of the downstream congestion level
relative to the node in the network that is measuring it. That is, the
congestion expected from that point along the rest of the path to the
receiver. This requires additional information that is still concealed
from the network, but which ConEx is designed to reveal.</t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="conex-uses-cases" title="ConEx Use Cases">
<t>This section sets out some of the potentially most important use
cases for ConEx. These use cases rely on some of the components
described in <xref target="ConEx-Abstract-Mech"></xref>. The authors
don't claim this is an exhaustive list of use cases, nor that they have
equal merit. But these use cases represent a consensus among people that
have been working on this approach for some years.</t>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<section anchor="conex-uses-traff-man"
title="Inform the Operator's Traffic Management">
<t>Currently many operators impose some form of traffic management.
They consider this as an economic necessity particularly at peak
hours— the only reason their networks work as a commercial
concern is that they can rely on statistical multiplexing to share
their expensive network between large numbers of customers. In order
to ensure all customers get decent performance from the network, they
subject the "heaviest" customers to some form of traffic management
(see <xref format="title" target="conex-uses-Existing"></xref> in
<xref target="conex-uses-Existing"></xref>). Often multiple approaches
are added on top of each other, including resorting to expensive flow
aware devices such as DPI boxes or flow-aware routers. This is
probably a sign that none of the approaches are really addressing the
problem properly.</t>
<t>ConEx offers a better approach that will actually target the
traffic from consumers that contribute most to any congestion, and
otherwise stand aside without intervening. By using Ingress or Egress
Policers, an operator can identify which consumers are causing the
greatest congestion-volume throughout the network. This can then be
used as the basis for traffic management decisions. The Ingress
Policer described in <xref target="Policing-freedom"></xref> is one
interesting approach that gives the consumer a congestion-volume
allowance as the fill-rate of a token-bucket, but where the tokens
give the right to cause bits of congestion-volume, rather than to send
bits of data-volume. So long as consumers stay within their limit,
then their traffic is unaffected. Once they exceed that limit then
their traffic will be slowed temporarily.</t>
</section>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<section anchor="conex-uses-scavenge"
title="Consequence: Incentivise Scavenger Transports">
<t>Recent work proposes a new approach for QoS where traffic is
provided with a less than best effort or "scavenger" quality of
service. The idea is that low priority but high volume traffic such as
OS updates, P2P file transfers and view-later TV programs should be
allowed to use any spare network capacity, but should rapidly get out
of the way if a higher priority or interactive application starts up.
To a degree, this facility can be provided in the network. Low Extra
Delay BAckground Transport <xref target="LEDBAT"></xref> is an example
of a new type of solution being actively explored which proposes that
hosts can provide this scavenger service for themselves using a new
congestion control algorithm. LEDBAT yields when seeking out bandwidth
if it detects that delay is rising, and other similar protocols share
capacity less aggressively when competing with protocols like TCP.</t>
<t>At present most operators assume a strong correlation between the
volume of a flow and the impact that flow causes in the network. This
assumption can fail badly for protocols like LEDBAT that transfer
large volumes of data but yield if congestion approaches. At the other
extreme, this assumption is eroded by unresponsive interactive
streaming which is unresponsive to congestion (inelastic) and hence
can cause high congestion at relatively low data volumes. LEDBAT-like
transports can transfer large volumes of data and may reach high
transfer speeds if the network is uncongested. Therefore network
operators who use volume or bit-rate to judge the impact of traffic on
their network give these protocols no encouragement, when they ought
to welcome them. Consequently the only current incentive for LEDBAT is
that it can reduce self-congestion effects (see <xref
target="conex-uses-self-congestion"></xref>).</t>
<t>If the network operator has deployed a ConEx-aware Ingress Policer
then they are able to incentivise the use of LEDBAT because a user
will be policed according to the overall congestion-volume their
traffic generates, not the rate or data volume. If all background file
transfers are only generating a low level of congestion, then the
sender has more "congestion budget" to "spend" on their interactive
applications. It can be shown <xref target="Kelly"></xref> that this
approach improves social welfare—in other words if you limit the
congestion that all users can generate then everyone benefits from a
better service.</t>
</section>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<section anchor="conex-uses-qos"
title="Consequence: User-Controlled Intra-Class Quality of Service (QoS)">
<t>Most QoS approaches require the active participation of routers to
control the delay and loss characteristics for the traffic. For
real-time interactive traffic it is clear that low delay (and
predictable jitter) are critical, and thus these probably always need
different treatment at a router. However if low loss is the issue then
ConEx offers an alternative approach.</t>
<t>Assuming the ingress ISP has deployed a ConEx Ingress Policer, then
the only control on a user's traffic is dependent on the congestion
that user has caused. Likewise, if they are receiving traffic through
a ConEx Egress Policer then their ISP will impose traffic controls
(prioritisation, rate limiting, etc) based on the congestion they have
caused. If an end-user (be they the receiver or sender) wants to
prioritise some traffic over other traffic then they can allow that
traffic to generate or cause more congestion. The price they will pay
will be to reduce the congestion that their other traffic causes.</t>
<t>Streaming video content-delivery is a good candidate for such
ConEx-mediated QoS. Such traffic can tolerate moderately high delays,
but there are strong economic pressures to maintain a high enough data
rate (as that will directly influence the Quality of Experience the
end-user receives. This approach removes the need for bandwidth
brokers to establish QoS sessions, by removing the need to coordinate
requests from multiple sources to pre-allocate bandwidth, as well as
to coordinate which allocations to revoke when bandwidth predictions
turn out to be wrong. There is also no need to "rate-police" at the
boundaries on a per-flow basis, removing the need to keep per-flow
state (which in turn makes this approach more scalable).</t>
</section>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<section anchor="conex-uses-other" title="Other Use-Cases">
<t><list style="hanging">
<t
hangText="Another Consequence: Preventing Congestion Collapse:">The
Internet is no less vulnerable to congestion collapses now than it
was in the 1980s <xref target="RFC3714"></xref>. Under extreme
congestion, ConEx-based traffic management would automatically
override host congestion control and prevent congestion collapse.
Without visibility of congestion, other traffic management
approaches do not have this property.</t>
<t hangText="Inform Inter-Operator Contracts:">Just as ConEx can
inform a bulk traffic policer of the congestion-volume a
particular end-consumer causes, it can also inform a border meter
of the total congestion-volume one network sends into the next. If
ConEx made such information available, it is likely that operators
would build it into the traffic contracts in their interconnection
arrangements.</t>
<t hangText="Inform Capacity Provisioning:">{ToDo:}</t>
</list></t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="conex-uses-deployments" title="Deployment Arrangements">
<t>This document is about concepts and use-cases, not mechanism.
However, in order to describe how the above use-cases would be deployed,
a high-level understanding of ConEx mechanism is first given below.</t>
<section title="Incremental Deployment Features of the Protocol Mechanism">
<t>The ConEx mechanism document <xref
target="ConEx-Abstract-Mech"></xref> goes to great lengths to design
for incremental deployment in all the respects below. It should be
referred to for precise details on each of these points:<list
style="symbols">
<t>The ConEx mechanism is essentially a change to the source, in
order to re-insert congestion feedback into the network (<xref
target="conex-uses_Fig_ConEx_Placement"></xref>).</t>
<t>Source-host-only deployment is possible without any negotiation
required, and individual transport protocol implementations within
a source host can be updated separately.</t>
<t>Receiver modification may optionally improve ConEx for some
transport protocols with feedback limitations (TCP being the main
example), but it is not a necessity</t>
<t>Proxies for the source and/or receiver are feasible (though not
necessarily straightforward)</t>
<t>Queues and network forwarding do not require any modification
for ConEx.</t>
<t>ECN is not required in the network for ConEx. If some network
nodes support ECN, it can be used by ConEx.</t>
<t>ECN is not required at the receiver for ConEx. The sender
should nonetheless attempt to negotiate ECN-usage with the
receiver, given some aspects of ConEx work better the more ECN is
deployed, particularly auditing and border measurement.</t>
<t>Given ConEx exposes information for IP-layer policy devices to
use, the design does not preclude possible innovative uses of
ConEx information by other IP-layer devices, e.g. forwarding
itself</t>
<t>Packets indicate whether or not they support ConEx.</t>
</list></t>
</section>
<section anchor="conex-uses-deploy-concepts"
title="Per-Network Deployment Concepts">
<t>Network deployment-related definitions:<list style="hanging">
<t hangText="Internet Ingress:">The first IP node a packet
traverses that is outside the source's own network. In a domestic
network that will be the first node downstream from the home
access equipment. In an enterprise network this is the provider
edge router.</t>
<t hangText="Internet Egress:">The last IP node a packet traverses
before reaching the receiver's network.</t>
<t hangText="ConEx-Enabled Network:">A network whose edge nodes
implement ConEx policy functions.</t>
</list></t>
<t>Each network can unilaterally choose to use any ConEx information
given by those sources using ConEx, independently of whether other
networks use it.</t>
<t>Typically, a network will use ConEx information by deploying a
policy function at the ingress edge of its network to monitor arriving
traffic and to act in some way on the congestion information in those
packets that are ConEx-enabled. Actions might include policing,
altering the class of service, or re-routing. Alternatively, less
direct actions via a management system might include triggering
capacity upgrades, triggering penalty clauses in contracts or levying
charges between networks based on ConEx measurements.</t>
<t>{ToDO: I need to sleep, so I'll resort to bullets for the
rest...}</t>
<t>Audit: what it is (checks ConEx info is never less than actual
congestion so far on the path). If ConEx protocol is adhered to, there
should be no place in a network where this is not true, so audit can
be placed wherever most convenient. But most useful placement is after
the likely congestion locations, ideally as close to the egress as
possible.</t>
<t>Typically, a network using ConEx info will deploy a ConEx policy
function near the ingress edge and a ConEx audit function near the
egress edge. The segment of the path between a ConEx policy function
and a ConEx audit function can be considered to be a ConEx-protected
segment of the path. And assuming a network covers all its ingresses
and egresses with policy functions and audit functions respectively,
the network within this ring will be a ConEx-protected network.</t>
<t>Of course, because each edge device usually serves as both an
ingress and an egress, the two functions are both likely to be present
in each edge device.</t>
<t>[Plan view diagram of a ConEx-protected segment and ConEx-protected
network here?]</t>
<t>[We might have to explain the concept of non-negativity of
congestion earlier in the doc, so we can use it here. Could also
require one of those staircase diags I used in re-ECN, but that assume
ECN and ConEx - I'd rather focus on drop-only cases.]</t>
<t>Sources can choose not to send ConEx-enabled packets. Networks are
expected to make it in senders' interests to expose congestion
information in packets by treating ConEx-enabled packets better (in
some sense) than non-ConEx packets.</t>
<t>Prior to ConEx, networks have generally place constraints on
incoming traffic to reduce the chances of it causing congestion. For
ConEx-enabled traffic, networks can remove these pessimistic
constraints and solely apply constraints when the ConEx information
indicates traffic is contributing to congestion.</t>
</section>
<section anchor="conex-uses-single-net-scenario"
title="Single Receiving Network Scenario">
<t>Charter scenario [Description, picture and some deployment
incentive text]</t>
<t>Focusing on first step: why OS developers of senders would
implement and why users would send ConEx. Then, once info is there,
why network would use it.</t>
</section>
<section anchor="conex-uses-other-deployments"
title="Other Initial Deployment Scenarios">
<t><list style="symbols">
<t>Mobile: <xref target="conex-mobile"></xref> Couple of sentence
description (characterised by terminals and network standards all
co-ordinated.)</t>
<t>Data Centre: Brief description. (Happens because under one
authority)</t>
</list></t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="conex-uses-issues" title="Potential Issues or Non-Issues">
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<section anchor="conex-uses-secret"
title="Congestion as a Commercial Secret">
<t>Network operators have long viewed the congestion levels in their
network as a business secret. In some ways this harks back to the days
of fixed-line telecommunications where congestion manifested as failed
connections or dropped calls. But even in modern data-centric packet
networks congestion is viewed as a secret not to be shared with
competitors. It can be debated whether this view is sensible, but it
may make operators uneasy about deploying ConEx. The following two
examples highlight some of the arguments used: <list style="symbols">
<t>An ISP buys backhaul capacity from an operator. Most operators
want their customers to get a decent service and so they want the
backhaul to be relatively uncongested. If there is competition,
operators will seek to reassure their customers (the operators)
that their network is not congested in order to attract their
custom. Some operators may see ConEx as a threat since it will
enable those operators to see the actual congestion in their
network. On the other hand, operators with low congestion could
use ConEx to show how well their network performs, and so might
have an incentive to enable it.</t>
<t>ISPs would like to be part of the lucrative content provision
market. Currently the ISP can gain a competitive edge as it can
put its own content in a higher QoS class, whereas traffic from
content providers has to use the Best Effort class. The ISP may
take the view that if they can conceal the congestion level in
their Best Effort class this will make it harder for the content
provider to maintain a good level of QoS. But in reality the
Content Provider will just use the feedback mechanisms in
streaming protocols such as Adobe Flash to monitor the
congestion.</t>
</list> Of course some might say that the idea of keeping congestion
secret is silly. After all, end-hosts already have knowledge of the
congestion throughout the network, albeit only along specific paths,
and operators can work out that there is persistent congestion as
their customers will be suffering degraded network performance.</t>
</section>
<!-- = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = -->
<section anchor="conex-uses-self-congestion" title="Self Congestion">
<t>{ToDo: The following para has been moved here from the
Introduction. Re-phrase as an issue}</t>
<t>Congestion takes two distinct forms. The first results from the
interaction of traffic from one set of users with traffic from other
users, causing in a reduction in service (a cost) for all of them. the
second, often referred to as "self-congestion", occurs when an
increase in traffic from a single user causes that user to suffer a
worse service (for instance because their traffic is being "shaped" by
their ISP, or because they have an excessively large buffer in their
home router). ConEx is principally interested in the first form of
congestion since it involves informing those other users of the impact
you expect to have on them.</t>
<t></t>
</section>
</section>
<!-- ====================================================================== -->
<section title="Security Considerations">
<t>This document proposes a mechanism tagging onto Explicit Congestion
Notification <xref target="RFC3168"></xref>, and inherits the security
issues listed therein. The additional issues from ConEx markings relate
to the degree of trust each forwarding point places in the ConEx
markings it receives, which is a business decision mostly orthogonal to
the markings themselves.</t>
<t>One expected use of exposed congestion information is to hold the
end-to-end transport and the network accountable to each other. The
network cannot be relied on to report information to the receiver
against its interest, and the same applies for the information the
receiver feeds back to the sender, and that the sender reports back to
the network. Looking at each in turn: <list style="hanging">
<t hangText="The Network">In general it is not in any network's
interest to under-declare congestion since this will have
potentially negative consequences for all users of that network. It
may be in its interest to over-declare congestion if, for instance,
it wishes to force traffic to move away to a different network or
simply to reduce the amount of traffic it is carrying. Congestion
Exposure itself won't significantly alter the incentives for and
against honest declaration of congestion by a network, but we can
imagine applications of Congestion Exposure that will change these
incentives. There is a perception among network operators that their
level of congestion is a business secret. Today, congestion is one
of the worst-kept secrets a network has, because end-hosts can see
congestion better than network operators can. Congestion Exposure
will enable network operators to pinpoint whether congestion is on
one side or the other of any border. It is conceivable that
forwarders with underprovisioned networks may try to obstruct
deployment of Congestion Exposure.</t>
<t hangText="The Receiver">Receivers generally have an incentive to
under-declare congestion since they generally wish to receive the
data from the sender as rapidly as possible. <xref
target="Savage"></xref> explains how a receiver can significantly
improve their throughput by failing to declare congestion. This is a
problem with or without Congestion Exposure. <xref
target="KGao"></xref> explains one possible technique to encourage
receiver's to be honest in their declaration of congestion.</t>
<t hangText="The Sender">One proposed mechanism for Congestion
Exposure deployment adds a requirement for a sender to advise the
network how much congestion it has suffered or caused. Although most
senders currently respond to congestion they are informed of, one
use of exposed congestion information might be to encourage sources
of persistent congestion to back off more aggressively. Then clearly
there may be an incentive for the sender to under-declare
congestion. This will be a particular problem with sources of
flooding attacks. "Policing" mechanisms have been proposed to deal
with this.</t>
</list> In addition there are potential problems from source spoofing.
A malicious sender can pretend to be another user by spoofing the source
address. Congestion Exposure allows for "Policers" and "Traffic Shapers"
so as to be robust against injection of false congestion information
into the forward path.</t>
<section title="Information Security">
<t>make a source believe it has seen more congestion than it has</t>
<t>hijack a user's identity and make it appear they are dishonest at
an egress policer</t>
<t>clear or otherwise tamper with the ConEx markings</t>
<t>...</t>
<t>{ToDo} Write these up properly...</t>
</section>
</section>
<!-- ====================================================================== -->
<section title="IANA Considerations">
<t>This document does not require actions by IANA.</t>
</section>
<!-- ====================================================================== -->
<section title="Conclusions">
<t>{ToDo}</t>
<t></t>
</section>
<!-- ====================================================================== -->
<section title="Acknowledgments">
<t>Bob Briscoe is 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, Alissa Cooper, Nandita
Dukkipati, Philip Eardley, Wes Eddy, Matthew Ford, Ingemar Johansson,
Georgios Karagiannis, Mirja Kuehlewind, Dirk Kutscher, Zhu Lei, Kevin
Mason, Matt Mathis, David McDysan, 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>The following co-edited this document through most of its life:</t>
<figure>
<artwork><![CDATA[
Toby Moncaster
Moncaster Internet Consulting
Dukes
Layer Marney
Colchester CO5 9UZ
UK
EMail: toby@moncaster.com
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.0970'?>
<?rfc include='reference.RFC.2309'?>
<?rfc include='reference.RFC.3168'?>
<?rfc include='reference.RFC.3714'?>
<?rfc include='reference.RFC.6077'?>
<!-- <reference anchor="Re-Feedback"
target="http://www.acm.org/sigs/sigcomm/sigcomm2005/techprog.html#session8">
<front>
<title>Policing Congestion Response in an Internetwork Using
Re-Feedback</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="Carla Di Cairano-Gilfedder" initials="C"
surname="Di Cairano-Gilfedder">
<organization>BT</organization>
</author>
<author fullname="Alessandro Salvatori" initials="A"
surname="Salvatori">
<organization>Eurécom & BT</organization>
</author>
<author fullname="Andrea Soppera" initials="A" surname="Soppera">
<organization>BT</organization>
</author>
<author fullname="Martin Koyabe" initials="M" surname="Koyabe">
<organization>BT</organization>
</author>
<date month="August" year="2005" />
</front>
<seriesInfo name="ACM SIGCOMM CCR" value="35(4)277—288" />
<format target="http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/2020comms/refb/refb_sigcomm05.pdf"
type="PDF" />
</reference>
-->
<reference anchor="LEDBAT">
<front>
<title>Low Extra Delay Background Transport (LEDBAT)</title>
<author fullname="Stanislav Shalunov" initials="S"
surname="Shalunov">
<organization></organization>
</author>
<author fullname="Greg Hazel" initials="G" surname="Hazel">
<organization></organization>
</author>
<author fullname="Janardhan Iyengar" initials="J" surname="Iyengar">
<organization></organization>
</author>
<author fullname="Mirja Kuehlewind" initials="M"
surname="Kuehlewind">
<organization></organization>
</author>
<date day="31" month="May" year="2011" />
<abstract>
<t>LEDBAT is an experimental delay-based congestion control
algorithm that attempts to utilize the available bandwidth on an
end-to-end path while limiting the consequent increase in queueing
delay on the path. LEDBAT uses changes in one-way delay
measurements to limit congestion that the flow itself induces in
the network. LEDBAT is designed for use by background
bulk-transfer applications; it is designed to be no more
aggressive than TCP congestion control and to yield in the
presence of any competing TCP flows, thus limiting interference
with the network performance of the competing flows.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-ledbat-congestion-06" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-ledbat-congestion-06.txt"
type="TXT" />
</reference>
<reference anchor="Savage">
<front>
<title>TCP Congestion Control with a Misbehaving Receiver</title>
<author fullname="S. Savage" initials="S." surname="Savage">
<organization></organization>
</author>
<author fullname="D. Wetherall" initials="D." surname="Wetherall">
<organization></organization>
</author>
<author fullname="T. Anderson" initials="T." surname="Anderson">
<organization></organization>
</author>
<date year="1999" />
</front>
<seriesInfo name="ACM SIGCOMM Computer Communication Review" value="" />
<format target="http://www.cs.ucsd.edu/~savage/papers/CCR99.pdf"
type="PDF" />
</reference>
<reference anchor="KGao">
<front>
<title>Incrementally Deployable Prevention to TCP Attack with
Misbehaving Receivers</title>
<author fullname="Kun Gar" initials="K." surname="Gao">
<organization>Computer Science Department, Carnegie Mellon
University</organization>
</author>
<author fullname="Chengwen Chris Wang" initials="C. C."
surname="Wang">
<organization>Computer Science Department, Carnegie Mellon
University</organization>
</author>
<date day="14" month="December" year="2004" />
</front>
<format target="http://www.cs.cmu.edu/~kgao/course/15744/network.pdf"
type="PDF" />
</reference>
<!--
<reference anchor="BB-incentive">
<front>
<title>The Broadband Incentive Problem</title>
<author>
<organization>MIT Communications Futures Program
(CFP)</organization>
</author>
<author>
<organization>Cambridge University Communications Research
Network</organization>
</author>
<date month="September" year="2005" />
</front>
<format target="http://cfp.mit.edu/docs/incentive-wp-sept2005.pdf"
type="PDF" />
</reference>
-->
<reference anchor="Fair-use">
<front>
<title>Truth about 'fair usage' broadband</title>
<author>
<organization>Broadband Choices</organization>
</author>
<date year="2009" />
</front>
<format target="http://www.broadbandchoices.co.uk/fair-usage-broadband.html"
type="HTML" />
</reference>
<!-- <reference anchor="Fairer-faster">
<front>
<title>A Fairer Faster Internet Protocol</title>
<author fullname="Bob Briscoe" initials="B" surname="Briscoe">
<organization></organization>
</author>
<date month="December" year="2008" />
</front>
<seriesInfo name="IEEE Spectrum" value="Dec 2008 pp38-43" />
<format target="http://spectrum.ieee.org/telecom/standards/a-fairer-faster-internet-protocol"
type="HTML" />
</reference>
-->
<reference anchor="Policing-freedom">
<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="Kelly"
target="http://www.statslab.cam.ac.uk/~frank/rate.html">
<front>
<title>Rate control for communication networks: shadow prices,
proportional fairness and stability</title>
<author fullname="Frank P. Kelly" initials="F.P" surname="Kelly">
<organization>Cam Uni</organization>
</author>
<author fullname="Aman K. Maulloo" initials="A.K" surname="Maulloo">
<organization>Cam Uni</organization>
</author>
<author fullname="David K. H. Tan" initials="D.K.H" surname="Tan">
<organization>Cam Uni</organization>
</author>
<date month="" year="1998" />
</front>
<seriesInfo name="Journal of the Operational Research Society"
value="49(3) 237--252" />
<format target="http://www.statslab.cam.ac.uk/~frank/rate.html"
type="PDF" />
</reference>
<!-- <reference anchor="Malice"
target="http://wesii.econinfosec.org/draft.php?paper_id=19">
<front>
<title>Using Self Interest to Prevent Malice; Fixing the Denial of
Service Flaw of the Internet</title>
<author fullname="Bob Briscoe" initials="B" surname="Briscoe">
<organization>BT & UCL</organization>
</author>
<date year="2006" />
</front>
<seriesInfo name="WESII - Workshop on the Economics of Securing the Information Infrastructure"
value="2006" />
<format target="http://wesii.econinfosec.org/draft.php?paper_id=19"
type="PDF" />
</reference>
-->
<!-- <reference anchor="Design-Philosophy">
<front>
<title>The Design Philosophy of the DARPA Internet Protocols</title>
<author fullname="David D. Clark" initials="D.D." surname="Clark">
<organization>MIT</organization>
</author>
<date year="1988" />
</front>
<format target="http://groups.csail.mit.edu/ana/Publications/PubPDFs/The%20design%20philosophy%20of%20the%20DARPA%20internet%20protocols.pdf"
type="PDF" />
</reference>
-->
<!-- <reference anchor="QoS-Models">
<front>
<title>Commercial Models for IP Quality of Service
Interconnect</title>
<author fullname="Bob Briscoe" initials="B" surname="Briscoe">
<organization>BT & UCL</organization>
</author>
<author fullname="Steve Rudkin" initials="S" surname="Rudkin">
<organization>BT</organization>
</author>
<date month="April" year="2005" />
</front>
<seriesInfo name="BTTJ Special Edition on IP Quality of Service"
value="vol 23 (2)" />
<format target="http://bobbriscoe.net/projects/ipe2eqos/gqs/papers/ixqos_bttj05.pdf"
type="PDF" />
</reference>
-->
<!-- <reference anchor="re-ecn-motive">
<front>
<title>Re-ECN: A Framework for adding Congestion Accountability to
TCP/IP</title>
<author fullname="Bob Briscoe" initials="B" surname="Briscoe">
<organization></organization>
</author>
<author fullname="Arnaud Jacquet" initials="A" surname="Jacquet">
<organization></organization>
</author>
<author fullname="Toby Moncaster" initials="T" surname="Moncaster">
<organization></organization>
</author>
<author fullname="Alan Smith" initials="A" surname="Smith">
<organization></organization>
</author>
<date month="October" year="2010" />
</front>
<seriesInfo name="Internet-Draft"
value="draft-briscoe-tsvwg-re-ecn-tcp-motivation-02" />
<format target="http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-re-ecn-tcp-motivation-02.txt"
type="TXT" />
</reference>
-->
<!-- <reference anchor="Padhye">
<front>
<title>Modeling TCP Throughput: A Simple Model and its Empirical
Validation</title>
<author fullname="Jitendra Padhye" initials="J" surname="Padhye">
<organization></organization>
</author>
<author fullname="Vicotor Firoiu" initials="V" surname="Firoiu">
<organization></organization>
</author>
<author fullname="Don Towsley" initials="D" surname="Towsley">
<organization></organization>
</author>
<author fullname="Jim Kurose" initials="J" surname="Kurose">
<organization></organization>
</author>
<date day="30" month="May" year="1998" />
</front>
<seriesInfo name="ACM SIGCOMM Computer Communications Review"
value="Vol 28(4), pages 303-314" />
<format target="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.143.9137&rep=rep1&type=pdf"
type="PDF" />
</reference>
-->
<reference anchor="ConEx-Abstract-Mech">
<front>
<title>Congestion Exposure (ConEx) Concepts and Abstract
Mechanism</title>
<author fullname="Matt Mathis" initials="M" surname="Mathis">
<organization>Google</organization>
</author>
<author fullname="Bob Briscoe" initials="B" surname="Briscoe">
<organization>BT</organization>
</author>
<date day="11" month="July" year="2011" />
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-conex-abstract-mech-02" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-conex-abstract-mech-00.txt"
type="TXT" />
</reference>
<reference anchor="conex-mobile">
<front>
<title>Mobile Communication Congestion Exposure Scenario</title>
<author fullname="Dirk Kutscher" initials="D" surname="Kutscher">
<organization></organization>
</author>
<author fullname="Faisal Mir" initials="F" surname="Mir">
<organization></organization>
</author>
<author fullname="Rolf Winter" initials="R" surname="Winter">
<organization></organization>
</author>
<author fullname="Suresh Krishnan" initials="S" surname="Krishnan">
<organization></organization>
</author>
<author fullname="Ying Zhang" initials="Y" surname="Zhang">
<organization></organization>
</author>
<date day="7" month="March" year="2011" />
<abstract>
<t>This memo describes a mobile communications use case for
congestion exposure (CONEX) with a particular focus on mobile
communication networks such as 3GPP LTE. The draft describes the
architecture of these networks (access and core networks), current
QoS mechanisms and then discusses how congestion exposure concepts
could be applied. Based on this, this memo suggests a set of
requirements for CONEX mechanisms that particularly apply to
mobile networks.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-kutscher-conex-mobile-00" />
<format target="http://www.ietf.org/internet-drafts/draft-kutscher-conex-mobile-00.txt"
type="TXT" />
</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="Varian">
<front>
<title>Congestion pricing principles</title>
<author fullname="Hal Varian" initials="H" surname="Varian">
<organization>Google</organization>
</author>
<date day="29" month="July" year="2010" />
</front>
<seriesInfo name="Technical Plenary" value="78th IETF Meeting" />
</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-01 to -02:">New
Abstract & Introduction. Concepts and Misconceptions sections
added around defintions. 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="conex-uses-defs"></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 <xref target="conex-uses-cases"></xref>
partly in response to suggestions from Dirk Kutscher</t>
<t>Improved layout of <xref target="conex-uses-defs"></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 <xref
target="conex-uses-secret"></xref></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 capitalisation 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
<xref target="conex-uses-cases"></xref>.</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:50:52 |