One document matched: draft-moncaster-conex-concepts-uses-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<?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="no" ?> <!-- Default compact="no" Start sections on new pages -->
<?rfc strict="no" ?> <!-- Default strict="no" Don't check I-D nits -->
<?rfc rfcedstyle="yes" ?> <!-- Default rfcedstyle="yes" attempt to closely follow finer details from the latest observable RFC-Editor style -->
<?rfc linkmailto="yes" ?> <!-- Default linkmailto="yes" generate mailto: URL, as appropriate -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"
[
<!ENTITY RFC2309 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2309.xml'>
<!ENTITY RFC3168 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3168.xml'>
]>
<rfc category="info" ipr='trust200902' docName="draft-moncaster-conex-concepts-uses-00">
<front>
<title abbrev="ConEx Mechanism">ConEx Concepts and Use Cases</title>
<author fullname="Bob Briscoe" initials="B." 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 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>
<author initials="T." surname="Moncaster" fullname="Toby Moncaster" role="editor">
<organization>Moncaster.com</organization>
<address>
<postal>
<street>Layer Marney</street>
<city>Colchester</city>
<code>CO5 9UZ</code>
<country>UK</country>
</postal>
<email>toby@moncaster.com</email>
</address>
</author>
<author initials="J." surname="Leslie" fullname="John Leslie" role="editor">
<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>
<date day="1" month="July" year="2010"/>
<area>Transport Area</area>
<workgroup>CONEX</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t> Internet Service Providers (ISPs) are facing problems where congestion
prevents full utilization of the path between sender and receiver at today's
"broadband" speeds. ISPs desire to control the congestion, which often appears
to be caused by a small number of users consuming a large amount of bandwidth.
Building out more capacity along all of the path to handle this congestion can
be expensive; and network operators have sought other ways to manage congestion.
The current mechanisms all suffer from difficulty measuring the congestion (as
distinguished from the total traffic). </t>
<t> The ConEx Working Group is designing a mechanism to make congestion along any
path visible at the Internet Layer. This document discusses this mechanism. </t>
</abstract>
</front>
<middle>
<!-- ====================================================================== -->
<section title="Introduction">
<t> The growth of "always on" broadband connections, coupled with the steady
increase in access speeds <xref target="OfCom"></xref>, has meant network operators are increasingly
facing problems with congestion. But congestion results from sharing network
capacity with others, not merely from using it. In general, today's "DSL"
and cable-internet users cannot "cause" congestion in the absence of
competing traffic. (Wireless ISPs and cellular internet have different
tradeoffs which we will not discuss here.) </t>
<t> Actual congestion generally results from the interaction of traffic from
an ISPs own subscribers with traffic from other users. The tools currently
available don't allow an operator to identify the causes of the congestion
and so leave them powerless to properly control it. </t>
<t> While building out more capacity to handle increased traffic is always
good, the expense and lead-time can be prohibitive, especially for network
operators that charge flat-rate feeds to subscribers and are thus unable
to charge heavier users more for causing more congestion <xref target="BB-incentive"></xref>. For an operator
facing congestion caused by other operators' networks, building out its
own capacity is unlikely to solve the congestion problem. Operators are
thus facing increased pressure to find effective solutions to dealing
with high-consuming users. </t>
<t> The growth of "scavenger-class" services helps to reduce congestion,
but actually make the ISPs problem less tractable. These are services
where participating users are not at all interested in paying more, but
wish to make good use of the capacity of the path. Thus, users of such
services may show very heavy total traffic up until the moment congestion
is detected (at the Transport Layer), but immediately back off. ISP
monitoring (at the Internet Layer) cannot detect this congestion avoidance
if the congestion in question is in a different domain further along the
path; and must treat such users as congestion-causing users. </t>
<t>We propose that Internet Protocol (IP) packets have two "congestion"
fields. The exact protocol details of these fields are for another
document, but we expect them to provide measures of "congestion so far"
and "congestion still expected". </t>
<vspace blankLines="8" />
<t>
Changes from previous drafts (to be removed by the RFC Editor):
<list style="hanging">
<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 <xref target="conex-uses-mechanism"></xref>. 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>
<!-- ====================================================================== -->
<section title="Definitions">
<t> Since ConEx expects to build on Explicit Congestion Notification (ECN)
<xref target="RFC3168"></xref>, we use the term "congestion" in a manner
consistent with ECN, namely that congestion occurs before any packet is
dropped. </t>
<t> We define six specific terms carefully:
<list style="hanging">
<t hangText="Congestion:"> Congestion is a measure of the probability that a
given packet will be ECN-marked or dropped as it traverses the network.
At any given router it is a function of the queue state at that router.
Congestion is added in a combinatorial manner, that is, routers ignore
the congestion a packet has already seen when they decide whether to
mark it or not. </t>
<t hangText="Congestion Volume:"> Congestion volume is defined
as the congestion a packet experiences, multiplied by the size of that packet.
See <xref target="Fairer-faster"></xref>. </t>
<t hangText="Upstream Congestion:"> 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 the source of the
packet and that point. </t>
<t hangText="Downstream Congestion:"> 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 its destination.</t>
<t hangText="Ingress Router:"> The Ingress Router is the first router a
packet traverses that is outside its own network. In a domestic network
that will be the first router downstream from the home access equipment.
In a commercial network it may be the first router downstream of the
firewall. </t>
<t hangText="Egress Router:"> The Egress Router is the last router a packet
traverses before it enters the destination network. </t>
</list>
</t>
</section>
<!-- ====================================================================== -->
<section title="Existing Approaches to Congestion Management">
<t>Initial attempts to capture congestion situations have usually focused on
the peak hours and aimed at rate limiting heavy users during that time. For
example, users who have consumed a certain amount of bandwidth during the
last 24 hours got elected as those who get their traffic shaped if the
total amount of traffic reaches a congestion situation in certain nodes
within the operator's network. </t>
<t>All of the 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 manages 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 user 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 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>
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). However such techniques rely on voluntary, altruistic action
by end users and their application providers. ISPs can neither enforce
their use nor avoid penalizing them for congestion they avoid. </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, but not beyond. This new capability would enable an
ISP to give incentives for the use of LEDBAT-like applications whilst
restricting inappropriate uses of traditional 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, 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 ISPs 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>
<!-- ====================================================================== -->
<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
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> Alas, this is not enough - ECN only allows downstream nodes to measure the
congestion so far for any flow. This can help hold a 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, for which
you need additional information that is still concealed from the network. </t>
</section>
<!-- ====================================================================== -->
<section title="A Possible Congestion Exposure Mechanism" anchor="conex-uses-mechanism">
<t> One possible protocol is based on a concept known as re-feedback
<xref target="Re-Feedback"></xref>, and builds on existing active queue
management techniques like RED <xref target="RFC2309"></xref> and ECN
<xref target="RFC3168"></xref> that network elements can already use to
measure and expose congestion. The protocol is described in more detail in
<xref target="Fairer-faster"></xref>, but we summarise it below.</t>
<t> In this protocol packets have two Congestion fields in their IP header:
<list style="symbols">
<t> A congestion experienced field to record the Upstream Congestion level
along the path. Routers indicate their current congestion level by
updating this field in every packet. As the packet traverses the network
it builds up a record of the overall congestion along its path in this
field. This data is sent back to the sender who uses it to determine its
transmission rate. </t>
<t> A whole-path congestion field that uses re-feedback to record the total
congestion expected along the path. The sender does this by re-inserting
the current Congestion level for the path into this field for every packet
it transmits. </t>
</list>
Thus at any node downstream of the sender you can see the Upstream
Congestion for the packet and the whole path congestion (with a time lag of
one round-trip-time (RTT)) 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 information symmetry between users and network providers. </t>
<!--- <t> The actual implementation will depend on the Internet Protocol version;
and may or may not be limited to a single bit per field. For a single-bit
value, the value will need to be aggregated (over one or more flows) to
give the proper (scalar). </t> --->
</section>
<!-- ====================================================================== -->
<section title="ConEx Use Cases" anchor="conex-uses-cases">
<t> ConEx is a simple concept that has revolutionary implications. It is that rare
thing — a truly disruptive technology, and as such it is hard to
imagine the variety of uses it may be put to. However there are several obvious
use cases that come to mind with a little thought. The authors aren't claiming
all of these have equal merit, nor are we claiming ConEx is the only conceivable
solution to achieve these. But these use cases represent a consensus among
people that have been working on this approach for some years. </t>
<t> In the following use cases we are assuming the most abstract version of the
ConEx mechanism, namely that every packet carries two congestion fields, one for
upstream congestion and one for downstream. At every node that is congested the
upstream congestion value will be incremented in some manner and the downstream
congestion value will be decremented. Assuming there is accurate feedback in the
system then the aim should be for the downstream value to be zero or slightly
positive by the time the packet reaches its destination. </t>
<t> If ConEx information is to be useful it has to be accurate (within the
limitations of the available feedback). This raises three issues that need to be
addressed:
<list style="hanging">
<t hangText="Distinguishing ConEx traffic from non-ConEx traffic:">
An ISP may reasonably choose to do nothing different with ConEx traffic.
Alternatively they might want to incentivise it in order to give it marginally better
service. IN that case it will be necessary to distinguish ConEx traffic from non-ConEx traffic.
On one level this seems pretty easy — ConEx traffic will have
the downstream congestion field in every packet. However in practise it may not
be as simple as this as the protocol may use a unary encoding (where the congestion value
is encoded across several packets). </t>
<t hangText="Over-declaring congestion:">
ConEx relies on the sender accurately declaring the congestion they expect to
see. During TCP slow-start a sender is unable to predict the level of congestion
they will experience and it is advisable to declare that expect to see some
congestion on the first packet. However, if any host or router marks more than
a small fraction of total traffic, downstream routers are less likely to trust
its congestion markings. We do not initially propose any mechanism to deal with
this issue. </t>
<t hangText="Under-declaring congestion:">
ConEx requires the sender to set the downstream congestion field in each packet
to their best estimate of what they expect the whole path congestion to be. If
this expected congestion level is to be used for traffic management (see use
cases) then it benefits the user to under-declare. Mechanisms are needed to
prevent this happening. </t>
<t> There are three approaches that may work (individually or in combination):
<list style="symbols">
<t> An ingress router can monitor a user's feedback to see what their reported
congestion level actually is. </t>
<t> A ConEx-aware router can drop any packet with a downstream-congestion value
of zero or less if that router is even slightly congested. </t>
<t> An egress router can actively monitor some or all flows to check that they
are complying with the requirement that the downstream congestion value should
be zero or (slightly positive) when it reaches the egress. </t>
</list>
</t>
</list>
</t>
<t> At any point of congestion, it is reasonable to treat ConEx-marked traffic
differently:
<list style="symbols">
<t> non-ConEx traffic will mostly be dropped (as now); </t>
<t> ConEx-marked traffic which has exhausted its congestion allowance will (all)
be dropped; </t>
</list>
</t>
<section title="Ingress policing for traffic management" anchor="conex-uses-policing">
<t> Currently many ISPs impose some form of traffic management at peak hours. This
is a simple economic necessity — the only reason the Internet works
as a commercial concern is that ISPs are able to rely on statistical multiplexing
to share their expensive core network between large numbers of customers. In order
to ensure all customers get some chance to access the network, the "heaviest"
customers will be subjected to some form of traffic management at peak times
(typically a rate cap for certain types of traffic) <xref target="Fair-use"></xref>. Often this traffic
management is done with expensive flow aware devices such as DPI boxes or flow-aware
routers. </t>
<t> ConEx enables a new approach that requires simple per-user policing at the ingress.
As described above, every packet a user sends should declare the total congestion
that the sender expects that packet to encounter on its journey through the network.
This allows the overall Congestion Volume to be calculated. In effect this is a measure of how much
traffic was sent that was above the instantaneous transmission capacity of the
network. By extension the congestion rate would be the transmission rate multiplied
by the congestion level. A 1 Gbps router that is 0.1% congested implies that there is
1 Mbps of excess traffic at that point in time. </t>
<t> At the Ingress Router an ISP can police the amount of congestion a user is causing
by limiting the congestion volume they send into the network. One system that
achieves this is described in <xref target="Policing-freedom"></xref>.
This uses a modified token bucket to limit the congestion rate being sent rather
than the overall rate. Effectively the Ingress Router is now acting as a ConEx policer.
Such ingress policing is relatively simple as it requires no
flow state. Furthermore, unlike many mechanisms, it treats all a user's packets
equally. </t>
</section>
<section title="ConEx to incentivise scavenger transports"anchor="conex-uses-scavenge">
<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.
One solution being actively explored is LEDBAT which proposes a new congestion
control algorithm that is less aggressive in seeking out bandwidth than TCP. </t>
<t> At present most ISPs assume a strong correlation between the volume of a flow
and the impact that flow causes in the network. This assumption has been eroded
by the growth of interactive streaming which behaves in an inelastic manner.
Assuming the end-user is using ConEx marking on all traffic and that LEDBAT
leads to the expected low level of congestion and the ingress ISP has deployed
a ConEx-aware ingress policer, then the LEDBAT will not be penalised since it
will be causing less congestion. (If LEDBAT is not ConEx-marking traffic then
the ISP will be forced to guess the congestion, probably based on the total
volume). </t>
<t> If the ISP 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. 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 maximises 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 title="ConEx to mitigate DDoS" anchor="conex-uses-ddos">
<t> DDoS relies on subverting innocent end users and getting them to send flood
traffic to a given destination. This is intended to cause a rapid increase in
congestion in the immediate vicinity of that destination. If it fails to do this
then it can't be called Denial of Service. If the ingress ISP has deployed ConEx
aware policers <xref target="conex-uses-policing"></xref>, that ISP will limit how much DDoS traffic enters the 'net. If the
compromised user tries to use the 'net during the DDoS attack, they will quickly
become aware that something is wrong, and their ISP can show the evidence that
their computer has become zombified. </t>
</section>
<section title="ConEx as a form of differential QoS" anchor="conex-uses-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 low 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. Assuming the ingress ISP has deployed
ConEx-aware ingress policing then the only control on a user's traffic is
dependent on the congestion that user has caused. If they want to prioritise some
traffic over other traffic then they can allow that traffic to generate more
congestion. The price to pay will be to reduce the congestion that their other
traffic causes. </t>
</section>
<section title="Other issues">
<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>
</section>
</section>
<!-- ====================================================================== -->
<section title="Security Considerations">
<t> This document proposes a mechanism tagging onto Explicit Congestion Notification
<xref target="RFC3168"/>, and inherits the security issues listed therein. The
additional issues from Congestion Expected markings relate to the degree of trust
each forwarding point places in Congestion Expected 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="symbols">
<t> 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> 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 my 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> 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 excessive 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>
<!-- ====================================================================== -->
<section title="IANA Considerations">
<t>This document does not require actions by IANA.</t>
</section>
<!-- ====================================================================== -->
<section title="Acknowledgments">
<t> The authors would like to thank Contributing Authors Bernard Aboba,
João Taveira Araújo, Louise Burness, Alissa Cooper,
Philip Eardley, Michael Menth, and Hannes Tschofenig for their inputs to
this document. </t>
</section>
<!-- ====================================================================== -->
</middle>
<back>
<references title="Normative References"> &RFC3168;
</references>
<references title="Informative References"> &RFC2309;
<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 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>
<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="22" year="2010" />
- <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-ietf-ledbat-congestion-01" />
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-ledbat-congestion-01.txt" />
</reference>
<reference anchor="Savage">
<front>
<title>TCP Congestion Control with a Misbehaving Receiver</title>
<author initials="S." surname="Savage" fullname="S. Savage">
<organization />
</author>
<author initials="D." surname="Wetherall" fullname="D. Wetherall">
<organization />
</author>
<author initials="T." surname="Anderson" fullname="T. Anderson">
<organization />
</author>
<date year="1999"/>
</front>
<seriesInfo name="ACM SIGCOMM Computer Communication Review" value=""></seriesInfo>
<format type="PDF" target="http://www.cs.ucsd.edu/~savage/papers/CCR99.pdf"></format>
</reference>
<reference anchor="KGao">
<front>
<title> Incrementally Deployable Prevention to TCP Attack with Misbehaving Receivers </title>
<author initials="K." surname="Gao" fullname="Kun Gar">
<organization> Computer Science Department, Carnegie Mellon University </organization>
</author>
<author initials="C. C." surname="Wang" fullname="Chengwen Chris Wang">
<organization> Computer Science Department, Carnegie Mellon University</organization>
</author>
<date month="December" day="14" year="2004"/>
</front>
<format type="PDF" target="http://www.cs.cmu.edu/~kgao/course/15744/network.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 type="PDF" target="http://cfp.mit.edu/docs/incentive-wp-sept2005.pdf" />
</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="Fair-use">
<front>
<title>Truth about 'fair usage' broadband</title>
<author>
<organization> Broadband Choices </organization>
</author>
<date year="2009"/>
</front>
<format type="HTML" target="http://www.broadbandchoices.co.uk/fair-usage-broadband.html"></format>
</reference>
<reference anchor="Fairer-faster">
<front>
<title>A Fairer Faster Internet Protocol</title>
<author initials="B" surname="Briscoe" fullname="Bob Briscoe">
<organization />
</author>
<date month="December" year="2008"/>
</front>
<seriesInfo name="IEEE Spectrum" value="Dec 2008 pp38-43"></seriesInfo>
<format type="HTML" target="http://spectrum.ieee.org/telecom/standards/a-fairer-faster-internet-protocol"></format>
</reference>
<reference anchor='Policing-freedom'>
<front>
<title>Policing Freedom to Use the Internet Resource Pool</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="T" surname="Moncaster" fullname="Toby Moncaster">
<organization>BT</organization>
</author>
<date month='December' day="4" year='2008' />
</front>
<seriesInfo name="RE-Arch 2008 hosted at the 2008 CoNEXT conference" value="" />
<format type='PDF' target='http://portal.acm.org/ft_gateway.cfm?id=1544083&type=pdf&coll=GUIDE&dl=GUIDE&CFID=94433196&CFTOKEN=11585540' />
</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 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>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 19:47:51 |