One document matched: draft-moncaster-congestion-exposure-problem-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >
<rfc ipr="trust200902" docName="draft-moncaster-congestion-exposure-problem-01" category="info">
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!-- Alterations to I-D/RFC boilerplate -->
<?rfc private="" ?> <!-- Default private="" Produce an internal memo 2.5pp shorter than an I-D or RFC -->
<?rfc topblock="yes" ?> <!-- Default topblock="yes" put the famous header block on the first page -->
<?rfc footer="" ?> <!-- Default footer="Expires <date>" override the center footer string -->
<?rfc header="" ?> <!-- Default header="Internet-Draft" override the leftmost header string -->
<?rfc authorship="yes" ?> <!-- Default authorship="yes" Render authors' addresses section -->
<?rfc rfcprocack="yes" ?> <!-- Default rfcprocack="no" add a short sentence acknowledging xml2rfc -->
<?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 -->
<!-- IETF process -->
<?rfc iprnotified="no" ?> <!-- Default iprnotified="no" I haven't disclosed existence of IPR to IETF -->
<!-- ToC format -->
<?rfc toc="yes" ?> <!-- Default toc="no" No Table of Contents -->
<?rfc tocappendix="yes" ?> <!-- Default tocappendix="yes" control whether the word `Appendix' appears in the table-of-content -->
<?rfc tocdepth="3" ?> <!-- Default tocdepth="3" if toc is "yes", then this determines the depth of the table-of-contents -->
<?rfc tocindent="yes" ?> <!-- Default tocindent="yes" if toc is "yes", indent subsections in the table-of-contents -->
<?rfc tocnarrow="yes" ?> <!-- Default tocnarrow="yes" affects horizontal spacing in the table-of-content -->
<?rfc tocompact="yes" ?> <!-- Default tocompact="yes" if toc is "yes", then setting this to "no" will make it a little less compact -->
<!-- Cross referencing, footnotes, comments -->
<?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 comments="no" ?> <!-- Default comments="no" Don't render comments -->
<?rfc inline="no" ?> <!-- Default inline="no" if comments is "yes", then render comments inline; otherwise render them in an `Editorial Comments' section -->
<?rfc editing="no" ?> <!-- Default editing="no" Don't insert editing marks for ease of discussing draft versions -->
<!-- Pagination control -->
<?rfc compact="yes"?> <!-- Default compact="no" Start sections on new pages -->
<?rfc subcompact="no"?> <!-- Default subcompact="(as compact setting)" yes/no is not quite as compact as yes/yes -->
<?rfc autobreaks="yes" ?> <!-- Default autobreaks="yes" avoid widows and orphans (not perfect) -->
<!-- HTML formatting control -->
<?rfc emoticonic="yes" ?> <!-- Default emoticonic="no" Doesn't prettify HTML format -->
<?rfc background="" ?> <!-- Default background="" when producing a html file, use this image -->
<?rfc useobject="no" ?> <!-- Default useobject="no" use <object> not <src> when outputting HTML -->
<?rfc linkmailto="yes" ?> <!-- Default linkmailto="yes" generate mailto: URL, as appropriate -->
<front>
<title abbrev="Congestion Exposure Problem">
The Need for Congestion Exposure in the Internet
</title>
<author initials="T." surname="Moncaster" fullname="Toby Moncaster" role="editor">
<organization>BT</organization>
<address>
<postal>
<street>B54/70, Adastral Park</street>
<street>Martlesham Heath</street>
<city>Ipswich</city>
<code>IP5 3RE</code>
<country>UK</country>
</postal>
<phone>+44 7918 901170</phone>
<email>toby.moncaster@bt.com</email>
</address>
</author>
<author initials="L." surname="Krug" fullname="Louise Krug">
<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>
<email>louise.burness@bt.com</email>
</address>
</author>
<author initials="M." surname="Menth" fullname="Michael Menth">
<organization>University of Wuerzburg</organization>
<address>
<postal>
<street>room B206, Institute of Computer Science</street>
<street>Am Hubland</street>
<city> Wuerzburg</city>
<code>D-97074</code>
<country>Germany</country>
</postal>
<phone>+49 931 888 6644</phone>
<email>menth@informatik.uni-wuerzburg.de</email>
</address>
</author>
<author initials="J." surname="Araújo" fullname="João Taveira Araújo">
<organization>UCL</organization>
<address>
<postal>
<street>GS206 Department of Electronic and Electrical Engineering </street>
<street>Torrington Place </street>
<city> London </city>
<code>WC1E 7JE</code>
<country>UK</country>
</postal>
<email> j.araujo@ee.ucl.ac.uk</email>
</address>
</author>
<author initials="S." surname="Blake" fullname="Steven Blake">
<organization>Extreme Networks</organization>
<address>
<postal>
<street>Pamlico Building One, Suite 100</street>
<street>3306/08 E. NC Hwy 54</street>
<code>RTP, NC 27709</code>
<country>US</country>
</postal>
<email>sblake@extremenetworks.com </email>
</address>
</author>
<author initials="R." surname="Woundy" fullname="Richard 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>
<date day="15" month="October" year="2009"></date>
<area>Transport</area>
<workgroup>Congestion Exposure</workgroup>
<!-- ================================================================ -->
<abstract>
<t>
The success of the Internet is largely down to the elegant manner in which it
shares capacity amongst all users while avoiding congestion collapse. However
this relies on the cooperation of all end users to work efficiently.
Increasingly a small minority of users are able to grab larger and larger
shares of the network leading ISPs to impose arbitrary controls on traffic.
These controls set ISPs on a direct collision course with their customers and
the regulators.
</t>
<t>
The root of the problem lies in the fact the ISPs are unable to see the most
important information about the traffic – namely the amount of congestion
that traffic is going to cause in the network. We propose congestion exposure
as a possible solution. Every packet will carry an accurate prediction of the
congestion it expects to cause downstream. This memo sets out the motivations
for congestion exposure and introduces a strawman protocol designed to achieve
congestion exposure.
</t>
</abstract>
<!-- ================================================================ -->
</front>
<middle>
<!-- ================================================================ -->
<section anchor="cong_exp_prob_intro" title="Introduction">
<t>
The Internet has grown from humble origins to become a global phenomenon with
billions of end-users able to share the network and exchange data and more.
One of the key elements in this success has been the use of distributed algorithms
such as TCP that share capacity while avoiding congestion collapse. These algorithms
rely on the end-users altruistically reducing their transmission rate in response
to any congestion they see.
</t>
<t>
In recent years ISPs have seen small minority of customers taking a large share of
the network by using protocols that open multiple simultaneous TCP connections and
by remaining connected for hours or even days at a time. This issue first came to
the fore with the advent of “always on” broadband connections. Frequently peer to
peer protocols have been held responsible <xref target="RFC5594"></xref> but streaming video
traffic is becoming increasingly significant. In order to improve the network experience for the
majority of their customers, many ISPs have imposed controls on how their network’s
capacity is shared. Approaches include volume counting or charging, and application
rate limiting. Typically these traffic controls, whilst not impacting most customers,
set a restriction on a customer’s level of network usage, as defined in a “fair usage
policy”.
</t>
<t>
We believe that such traffic controls 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 amount of congestion – congestion means that your traffic impacts other users,
and conversely that their traffic impacts you. So if there is little other traffic
there should be no restriction on the amount a user can send; restrictions should only
apply when others are sending a lot of traffic such that there is congestion. In fact
some of the current work at the IETF <xref target="LEDBAT"></xref> and IRTF <xref target="CC-open-research"></xref> already reflect
this thinking. For example, a LEDBAT user reduces their transmission rate when they
detect an increase in end-to-end delay (as a measure of incipient congestion). However,
these techniques at the moment rely on voluntary, altruistic action by end users.
ISPs cannot enforce their use. This leads to our second point.
</t>
<t>
We believe that congestion needs to be visible to network nodes and not just to the
end hosts as is the case today. By this we mean that a network can detect how much
congestion traffic causes between a point in the network and the destination
(“rest-of-path congestion”). This capability is new; today a network can only
detect how much congestion traffic has suffered between the source and a point in the
network. Such a capability enables an ISP to give incentives for the use, without
restrictions, of LEDBAT-like applications whilst perhaps restricting TCP and UDP ones.
</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, where it is accessible
by any application or transport protocol. 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.
One use of this information would be to measure the congestion attributable to a given
application or user and thereby incentivise the use of protocols such as <xref target="LEDBAT"></xref>
which aim to reduce the congestion caused by bulk data transfers. {ToDo}It is possible to
imagine many other ways to use the exposed congestion information [maybe a forward ref?].
</t>
<section anchor="cong_exp_definitions" title="Definitions">
<t>
Throughout this document we use two terms that need to be carefully defined to avoid ambiguity:
<list style="hanging">
<t hangtext="Upstream Congestion"> Upstream congestion is defined as the congestion
that has already been experienced by a packet as it travels along its path. In other words at
any point on the path it is the congestion between that point and the source of the packet.</t>
<t hangtext="Downstream Congestion"> Downstream congestion is defined as the congestion
that a packet still has to experience on the remainder of its path. In other words at any
point it is the congestion still to be experienced as the packet travels between that point
and ts destination.</t>
</list>
</t>
</section>
</section>
<!-- ================================================================ -->
<section anchor="cong_exp_prob_problem" title="The Problem">
<t>
ISPs are facing a quandary – traffic is growing rapidly yet they know that any increases in
capacity will be of most benefit to the most aggressive users. At the same time, traffic
patterns are changing significantly <xref target="Cisco-VNI"></xref> and all the while increasing competition is
squeezing their profit margins. Faced with these problems, some ISPs are seeking to reduce
what they regard as "heavy usage" in order to improve the service experienced by the majority
of their customers.</t>
<section anchor="cong_exp_impact" title="The Impact of Congestion">
<t>
As the Internet has grown, access rates have lagged behind those in the core. However over recent
years this has started to change. Increasingly large numbers of
people now access the network via broadband connections and the speed
they can get is steadily increasing. Alongside this have gone
significant changes in traffic patterns. We have been through a boom
in large-scale data transfer by peer to peer networks and now are
seeing an even larger boom in streaming media with applications such
as the BBC iPlayer becoming increasingly popular. The main effect of
this has been that users now routinely see their network connections
running slow in the evenings <xref target="OfCom"></xref>.
</t>
</section>
<section anchor="cong_exp_visibility" title="Making Congestion Visible">
<t>
Unfortunately ISPs are only able to see limited information about the
traffic they forward. As we will see in section 3 they are forced to use
the only information they do have available which leads to myopic control
that has scant regard for the actual impact of the traffic or the underlying network
conditions. All their approaches are flawed because they measure the wrong
metric. The volume or rate of a given flow doesn’t directly affect other users,
but the congestion the flow causes does. This can be seen with a simple illustration.
A 5Mbps flow in an otherwise empty 10Mbps bottleneck causes no congestion and so
affects no other users. By contrast a 1Mbps flow entering a 10Mbps bottleneck that
is already fully occupied causes significant congestion and impacts every other user
sharing that bottleneck. So the real problem that needs to be addressed is how to
close this information gap. How can we expose congestion at the IP layer so that it
can be used as the basis for measuring the impact of any traffic on the network
as a whole?
</t>
</section>
<section anchor="cong_exp_ECN" title="ECN - a Step in the Right Directions">
<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 discard (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>
The choice of two ECT code-points in the ECN field <xref target="RFC3168"></xref>
permitted future flexibility, optionally allowing the sender to
encode the experimental ECN nonce <xref target="RFC3540"></xref> in the packet stream.
This mechanism has since been included in the specifications of DCCP
<xref target="RFC4340"></xref>. The ECN nonce is an elegant scheme that allows the sender
to detect if someone in the feedback loop - the receiver especially -
tries to claim no congestion was experienced when in fact congestion
led to packet drops or ECN marks. For each packet it sends, the
sender chooses between the two ECT codepoints in a pseudo-random
sequence. Then, whenever the network marks a packet with CE, if the
receiver wants to deny congestion happened, she has to guess which
ECT codepoint was overwritten. She has only a 50:50 chance of being
correct each time she denies a congestion mark or a drop, which ultimately will give her away.
</t>
<t>
So Is ECN the Solution? Alas not - ECN does allow downstream nodes to measure the
upstream congestion for any flow, but this is not enough. What is needed is knowledge of the
downstream congestion level for which you need additional information
that is still concealed from the network by design.
</t>
</section>
</section>
<!-- ================================================================ -->
<section anchor="cong_exp_prob_existing" title="Existing Approaches to Traffic Control">
<t>
Existing approaches intended to address the problems outlined above can be broadly divided into two groups - those that passively monitor
traffic and can thus measure the apparent impact of a given flow of packets and those that can actively discriminate against certain
packets, flows, applications or users based on various characteristics or metrics.
</t>
<section anchor="cong_exp_prob_passive" title="Passive Measurement">
<t>
Passive measurement of traffic relies on using the information that can be measured directly or is revealed in the IP header
of the packet. Architecturally, passive measurement is best since it fits with the idea of the hourglass design of the Internet
<xref target="RFC3439"></xref>. This asserts that "the complexity of the Internet belongs at the edges, and the IP layer of the Internet
should remain as simple as possible."
</t>
<section anchor="cong_exp_prob_volume" title="Volume Accounting">
<t>
Volume accounting is a passive technique that is often used to discriminate between users. The volume of traffic sent by a given
user or network is one of the easiest pieces of information to monitor in a network. Measuring the size of every packet and adding them up is a simple
operation and to make it even easier, every IP packet carries its overall size in the header. Consequently this has long been a favoured measure used by
operators to control their customers.
</t>
<t>
The precise manner in which this volume information is used may vary. Typically ISPs may impose an overall volume cap on their customers (perhaps 10Gbytes a
month). Alternatively they may decide that only a minority of heavy users are affected in some fashion.
</t>
</section>
<section anchor="cong_exp_prob_rate" title="Rate Measurement">
<t>
Traffic rates are often used as the basis of accounting at borders between ISPs. For instance a contract might specify a charge based on the
95th percentile of the peak rate of traffic crossing the border every month. Such bulk rate measurements are relatively easy to make.
With a little extra effort it is possible to measure the rate of a given flow by using the 3-tuple of source and destination IP address and protocol
number.
</t>
</section>
</section>
<section anchor="cong_exp_prob_actively" title="Active Discrimination">
<t>
<xref target="RFC5290"></xref> seeks to reinforce <xref target="RFC3439"></xref> by stating that "...differential treatment of traffic can clearly be useful..."
but adding that such techniques are only useful "...as *adjuncts* to simple best-effort traffic, not as *replacements* of simple best-effort traffic." We fully agree with the
authors that the network should be built on the concept of simple best effort traffic. However, as this section shows,
a number of approaches have emerged over recent years that explicitly differentiate between different traffic types, applications
and even users.
</t>
<section anchor="cong_exp_prob_rate-lmits" title="Bottleneck Rate Policing">
<t>
Bottleneck rate policers such as <xref target="XCHOKe"></xref> and <xref target="pBox"></xref>
have been proposed as approaches for rate policing traffic. But they must be deployed at bottlenecks in order to work.
Unfortunately, a large proportion of traffic traverses at least two bottlenecks which limits the utility of this
approach. Such rate policers also make an assumption about what constitutes acceptable behaviour. If these
bottleneck policers were widely deployed, the Internet would find itself with one universal rate adaptation
policy embedded throughout the network. With TCP's congestion control algorithm approaching its scalability
limits as the network bandwidth continues to increase, new algorithms are being developed for high-speed
congestion control. Embedding assumptions about acceptable rate adaptation would make evolution to such
new algorithms extremely painful.
</t>
</section>
<section anchor="cong_exp_prob_dpi" title="DPI and Application Rate Policing">
<t>
Some operators use deep packet inspection (DPI) and traffic analysis to identify certain applications
believed to have an excessive impact on the network. These so-called heavy applications are generally
things like peer-to-peer or streaming video. Having identified a flow as belonging to a heavy application,
the operator is able to use standard Diffserv <xref target="RFC2475"></xref> approaches such as policing
and traffic shaping to limit the throughput given to that flow. This has fuelled the on-going battle
between application developers and DPI vendors. When operators first started to limit the throughput of P2P,
it soon became common knowledge that turning on encryption could boost your throughput. The DPI vendors
then improved their equipment so that it could identify P2P traffic by the pattern of packets it sends.
This risks becoming an endless vicious cycle - an arms race that neither side can win. Furthermore such
techniques may put the operator in direct conflict with the customers, regulators and content providers.
</t>
</section>
</section>
</section>
<!-- ================================================================ -->
<section anchor="cong_exp_prob_timing" title="Why Now?">
<t>
Congestion has long been the key metric for deciding how fast a flow can safely send traffic.
Since the late 1990s it has also been recognised as a key metric for measuring the impact of
traffic across the network <xref target="Kelly"></xref>. The IETF is keen to encourage
techniques that reduce congestion. For instance the <xref target="LEDBAT"></xref> working group
focuses on broadly applicable techniques that allow large amounts of data to be transmitted
without substantially affecting the delays experienced by other users and applications, thus
reducing the congestion that traffic is causing.
</t>
<t>
But users will only want to take advantage of such techniques if they actually improve their
performance. As long as ISPs continue to use rate and volume as the key metrics for determining
when to control traffic there is no incentive to use LEDBAT or other protocols that reduce
congestion. We believe that congestion exposure gives ISPs the information they need to be
able to discriminate in favour of such low-congestion transports.
</t>
</section>
<!-- ================================================================ -->
<section anchor="cong_exp_prob_requirements" title="Requirements for a Solution">
<t>
This section lists the main requirements for any solution to this problem. We believe that a
solution that meets most of these requirements is likely to be better than one that doesn't.
<list style="symbols">
<t>Allow both upstream and downstream congestion to be visible at the IP layer -- visibility at the IP layer allows congestion to be monitored in the heart of
the network without deploying complicated and intrusive equipment such as DPI boxes. This gives several advantages:</t>
<list style="numbers">
<t>It enables policing of flows based on the congestion they are actually going to cause in the network.</t>
<t>It allows the flow of congestion across ISP borders to be monitored.</t>
<t>It supports a diversity of intra-domain and inter-domain congestion management practices. </t>
</list>
<t>Support the widest possible range of transport protocols for the widest range of data types
(elastic, inelastic, real-time, background, etc) -- don't force a "universal rate adaptable policy"
such as TCP-friendliness <xref target="RFC3448"></xref>.</t>
<t>Be responsive to real-time congestion in the network.</t>
<t>Avoid making assumptions about the behavior of specific applications (e.g. be application agnostic).</t>
<t>Allow incremental deployment of the solution and ideally permit permanent partial deployment to increase chances of successful deployment.</t>
<t>Support integrity of congestion notifications, thus making it hard for a user or network to distort the congestion signal.</t>
<t>Be robust in the face of DoS attacks aimed at either congestion exposure itself, or at the network elements
implementing congestion exposure.</t>
</list>
Many of these requirements are by no means unique to the problem of congestion exposure. Incremental deployment for instance is a critical requirement for any
new protocol that affects something as fundamental as IP. Being robust under attack is also a pre-requisite for any protocol to succeed in the real Internet
and this is covered in more detail in <xref target="cong_exp_prob_security"></xref>.
</t>
</section>
<!-- ================================================================ -->
<section anchor="cong_exp_prob_strawman" title="A Strawman Congestion Exposure Protocol">
<t>
In this section we are going to explore a simple strawman protocol that would solve the congestion exposure problem. This protocol
neatly illustrates how a solution might work. A practical implementation of this protocol has been produced and both simulations and
real-life testing show that it works. The protocol is based on a concept known as re-feedback <xref target="Re-fb"></xref> and assumes that routers
can measure their congestion level precisely.
</t>
<t>
Re-feedback, standing for re-inserted feedback, is a system designed to allow end-hosts to reveal to the network information
they have received via conventional feedback (for instance RTT or congestion level).
</t>
<t>
In our strawman protocol we imagine that packets have two "congestion" fields in their IP header. One field records the upstream congestion level
and routers indicate their current congestion level by changing this field in every packet. So as the packet traverses
the network it builds up a record of the overall congestion along its path in this field. This data is then sent back to the sender who uses
it to determine its transmission rate. Using re-feedback the sender now inserts this congestion value in the second whole path congestion
field on every packet it sends out. Thus at any node downstream of the sender you can see the upstream congestion for the packet (the congestion thus far), the whole
path congestion (with a time lag of 1RTT) and can calculate the downstream congestion by subtracting one from the other. </t>
<t>
So congestion exposure can be achieved by coupling congestion notification from routers with
the re-insertion of this information by the sender. This establishes an information symmetry between users
and network providers which opens the door for the evolution of new congestion responses which are not bounded to a "universal rate
adaptation policy".
</t>
</section>
<!-- ================================================================ -->
<section anchor="cong_exp_prob_uses" title="Use Cases">
<t>
Once downstream congestion information is revealed in the IP header it can be used for a number of purposes. Precise details
of how the information might be used are beyond the scope of this document but this section will give an overview
of some possible uses.
</t>
<t>
It allows an ISP to accurately identify which traffic is having the greatest impact on the network and eitehr police
directly on that basis or use it to determine which users should be policed. It can form the basis of inter-domain
contracts between operators. It could even be used as the basis for inter-domain routing, thus encouraging operators
to invest appropriately in improving their infrastructure.
</t>
<t>
From Rich Woundy: "I would add a section about use cases. The primary use case would seem to be an "incentive environment that ensures
optimal sharing of capacity", although that could use a better title. Other use cases may include "DDoS mitigation",
"end-to-end QoS", "traffic engineering", and "inter-provider service monitoring". (You can see I am stealing liberally
from the motivation draft here. We'll have to see whether the other use cases are "core" to this group, or "freebies"
that come along with re-ECN as a particular protocol.)"
</t>
<t>
My take on this is we need to concentrate on one or two major use cases. The most obvious one is using this to control user-behaviour and
encourage the use of "congestion friendly" protocols such as LEDBAT.
{Comments from Louise Krug} simply say that operators MUST turn off any kind of rate limitation for ledbat traffic and what
they might mean for the amount of bandwidth they see compared to a throttled customer? YOu could then extend that to say how
it leads to better QoS differentiation under the assumption that there is a broad traffic mix any way? Not sure how much detail
you want to go into here though?
</t>
</section>
<!-- ================================================================ -->
<section title="IANA Considerations">
<t>This document makes no request to IANA.
</t>
</section>
<!-- ================================================================ -->
<section anchor="cong_exp_prob_security" title="Security Considerations">
<t>
This section needs to briefly cover the obvious security aspects of any congestion exposure scheme: Source address spoofing, DoS,
integrity of signals, honesty. It might also be the place to mention the possible reluctance to reveal too much information
to the whole network (some ISPs view congestion level as a commerically sensitive concept). It needs to concentrate on two things in particular:
DoS attacks that seek to corrupt the congestion information and how to ensure the honest declaration of information (both by
the network and by the end-user).
</t>
</section>
<!-- ================================================================ -->
<section anchor="cong_exp_prob_Conclusions" title="Conclusions">
<t>
Congestion exposure is the idea that traffic itself indicates to all nodes on its path how much
congestion it causes on the entire path. It is useful for network operators to police flows only
if they really cause congestion in the Internet instead of doing blind rate capping independently
of the congestion situation. This change would give incentives to users to adopt new transport
protocols such as LEDBAT which try to avoid congestion more than TCP does. Requirements for
congestion exposure in the IP header were summarized, one technical solution was presented, and
additional use cases for congestion exposure were discussed.
</t>
</section>
<!-- ================================================================ -->
<section anchor="cong_exp_prob_Acknowledgements" title="Acknowledgements">
<t>
A number of people have provided text and comments for this memo. The document is being produced in support of a
BoF on Congestion Exposure as discussed extensively on the <re-ecn@ietf.org> mailing list.
</t>
<!-- ================================================================ -->
</section>
</middle>
<back>
<!-- ================================================================ -->
<references title="Informative References">
<reference anchor="LEDBAT">
- <front>
<title>Low Extra Delay Background Transport (LEDBAT)</title>
- <author initials="S" surname="Shalunov" fullname="Stanislav Shalunov">
<organization />
</author>
<date month="March" day="4" year="2009" />
- <abstract>
<t>LEDBAT is an alternative experimental congestion control algorithm. LEDBAT enables an advanced
networking application to minimize the extra delay it induces in the bottleneck while saturating
the bottleneck. It thus implements an end-to-end version of scavenger service. LEDBAT has been
been implemented in BitTorrent DNA, as the exclusive congestion control mechanism, and in uTorrent,
as an experimental mechanism, and deployed in the wild with favorable results.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-shalunov-ledbat-congestion-00" />
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-shalunov-ledbat-congestion-00.txt" />
</reference>
<?rfc include="reference.RFC.2309" ?>
<?rfc include="reference.RFC.2475" ?>
<?rfc include="reference.RFC.3168" ?>
<?rfc include="reference.RFC.3439" ?>
<?rfc include="reference.RFC.3448" ?>
<?rfc include="reference.RFC.3540" ?>
<?rfc include="reference.RFC.4340" ?>
<?rfc include="reference.RFC.5290" ?>
<?rfc include="reference.RFC.5594" ?>
<reference anchor="XCHOKe" target="http://www.cc.gatech.edu/~akumar/xchoke.pdf">
<front>
<title>
XCHOKe: Malicious Source Control for Congestion Avoidance at Internet Gateways
</title>
<author initials="P" surname="Chhabra" fullname="Parminder Chhabra">
<organization>HP, Cupertino</organization>
</author>
<author initials="S" surname="Chuig" fullname="Shobhit Chuig">
<organization>Stanford</organization> </author>
<author initials="A" surname="Goel" fullname="Anurag Goel">
<organization>IIT Delhi</organization>
</author>
<author initials="A" surname="John" fullname="Ajita John">
<organization>DSET Corp</organization>
</author>
<author initials="A" surname="Kumar" fullname="Abhishek Kumar">
<organization>Georgia Tech</organization>
</author>
<author initials="H" surname="Saran" fullname="Huzur Saran">
<organization>IIT Delhi</organization>
</author>
<author initials="R" surname="Shorey" fullname="Rajeev Shorey">
<organization>IBM-IRL</organization>
</author>
<date month="November" year="2002" />
</front>
<seriesInfo name="Proceedings of IEEE International Conference on Network Protocols (ICNP-02)" value="" />
<format type='PDF'
target='http://www.cc.gatech.edu/~akumar/xchoke.pdf' />
</reference>
<reference anchor="pBox" target="http://www.aciri.org/floyd/end2end-paper.html">
<front>
<title>
Promoting the Use of End-to-End Congestion Control in the Internet
</title>
<author initials="S" surname="Floyd" fullname="Sally Floyd">
<organization>ICSI Center for Internet Research</organization>
</author>
<author initials="K" surname="Fall" fullname="Kevin Fall">
<organization>Intel</organization>
</author>
<date month="August" year="1999" />
</front>
<seriesInfo name="IEEE/ACM Transactions on Networking" value="7(4) 458--472" />
<format type='PDF'
target='http://www.icir.org/floyd/papers/collapse.may99.pdf' />
</reference>
<reference anchor="Re-fb" target="http://www.acm.org/sigs/sigcomm/sigcomm2005/techprog.html#session8">
<front>
<title>
Policing Congestion Response in an Internetwork Using Re-Feedback
</title>
<author initials="B" surname="Briscoe" fullname="Bob Briscoe">
<organization>BT & UCL</organization>
</author>
<author initials="A" surname="Jacquet" fullname="Arnaud Jacquet">
<organization>BT</organization>
</author>
<author initials="C" surname="Di Cairano-Gilfedder" fullname="Carla Di Cairano-Gilfedder">
<organization>BT</organization>
</author>
<author initials="A" surname="Salvatori" fullname="Alessandro Salvatori">
<organization>Eurécom & BT</organization>
</author>
<author initials="A" surname="Soppera" fullname="Andrea Soppera">
<organization>BT</organization>
</author>
<author initials="M" surname="Koyabe" fullname="Martin Koyabe">
<organization>BT</organization>
</author>
<date month="August" year="2005" />
</front>
<seriesInfo name="ACM SIGCOMM CCR" value="35(4)277--288" />
<format type='PDF'
target='http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/2020comms/refb/refb_sigcomm05.pdf' />
</reference>
<?xml version='1.0' encoding='UTF-8'?>
<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 initials="F.P" surname="Kelly" fullname="Frank P. Kelly">
<organization>Cam Uni</organization>
</author>
<author initials="A.K" surname="Maulloo" fullname="Aman K. Maulloo">
<organization>Cam Uni</organization>
</author>
<author initials="D.K.H" surname="Tan" fullname="David K. H. 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 type='PDF'
target='http://www.statslab.cam.ac.uk/~frank/rate.html' />
</reference>
<reference anchor='Fairness'>
<front>
<title>Problem Statement: Transport Protocols Don't Have To Do Fairness</title>
<author initials='B' surname='Briscoe' fullname='Bob Briscoe'>
<organization />
</author>
<author initials='T' surname='Moncaster' fullname='T Moncaster'>
<organization />
</author>
<author initials='A' surname='Burness' fullname='Anne-Louise Burness'>
<organization />
</author>
<date month='July' day='14' year='2008' />
<abstract><t>The Internet is an amazing achievement - any of the thousand million hosts can freely use any of the resources
anywhere on the public network. At least that was the original theory. Recently issues with how these resources are shared
among these hosts have come to the fore. Applications are innocently exploring the limits of protocol design to get larger
shares of available bandwidth. Increasingly we are seeing ISPs imposing restrictions on heavier usage in order to try to
preserve the level of service they can offer to lighter customers. We believe that these are symptoms of an underlying problem:
fair resource sharing is an issue that can only be resolved at run-time, but for years attempts have been made to solve it at
design time. In this document we show that fairness is not the preserve of transport protocols, rather the design of such
protocols should be such that fairness can be controlled between users and ISPs at run-time.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-briscoe-tsvwg-relax-fairness-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-relax-fairness-01.txt' />
</reference>
<reference anchor='CC-open-research'>
<front>
<title>Open Research Issues in Internet Congestion Control</title>
<author initials='M' surname='Welzl' fullname='Michael Welzl'>
<organization />
</author>
<author initials='M' surname='Scharf' fullname='Michael Scharf'>
<organization />
</author>
<author initials='B' surname='Briscoe' fullname='Bob Briscoe'>
<organization />
</author>
<author initials='D' surname='Papadimitriou' fullname='Dimitri Papadimitriou'>
<organization />
</author>
<date month='September' day='3' year='2009' />
<abstract><t>This document describes some of the open problems in Internet congestion control that are known today.
This includes several new challenges that are becoming important as the network grows, as well as some issues that
have been known for many years. These challenges are generally considered to be open research topics that may
require more study or application of innovative techniques before Internet-scale solutions can be confidently
engineered and deployed.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-irtf-iccrg-welzl-congestion-control-open-research-05' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-irtf-iccrg-welzl-congestion-control-open-research-05.txt' />
</reference>
<reference anchor='OfCom'>
<front>
<title>UK Broadband Speeds 2008: Research report</title>
<author >
<organization> Ofcom: Office of Communications</organization>
</author>
<date month='January' year='2009' />
</front>
<format type='PDF' target='http://www.ofcom.org.uk/research/telecoms/reports/bbspeed_jan09/bbspeed_jan09.pdf' />
</reference>
<reference anchor='Cisco-VNI'>
<front>
<title>Cisco Visual Networking Index: Forecast and Methodology, 2008–2013</title>
<author >
<organization> Cisco Systems, inc.</organization>
</author>
<date month='June' day="9" year='2009' />
</front>
<format type='PDF' target='http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/white_paper_c11-481360.pdf' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:18:56 |