One document matched: draft-ietf-conex-concepts-uses-00.txt
CONEX B. Briscoe
Internet-Draft BT
Intended status: Informational R. Woundy
Expires: May 19, 2011 Comcast
T. Moncaster, Ed.
Moncaster.com
J. Leslie, Ed.
JLC.net
November 15, 2010
ConEx Concepts and Use Cases
draft-ietf-conex-concepts-uses-00
Abstract
Internet Service Providers (operators) are facing problems where
localized congestion prevents full utilization of the path between
sender and receiver at today's "broadband" speeds. Operators desire
to control this 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 may not result in improvements for
all users so 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).
The ConEx Working Group is designing a mechanism to make congestion
along any path visible at the Internet Layer. This document
describes example cases where this mechanism would be useful.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 19, 2011.
Briscoe, et al. Expires May 19, 2011 [Page 1]
Internet-Draft ConEx Mechanism November 2010
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Congestion Management . . . . . . . . . . . . . . . . . . . . 6
3.1. Existing Approaches . . . . . . . . . . . . . . . . . . . 7
4. Exposing Congestion . . . . . . . . . . . . . . . . . . . . . 8
4.1. ECN - a Step in the Right Direction . . . . . . . . . . . 9
5. ConEx Use Cases . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. ConEx as a basis for traffic management . . . . . . . . . 10
5.2. ConEx to incentivise scavenger transports . . . . . . . . 10
5.3. Accounting for Congestion Volume . . . . . . . . . . . . . 11
5.4. ConEx as a form of differential QoS . . . . . . . . . . . 11
5.5. Partial vs. Full Deployment . . . . . . . . . . . . . . . 12
6. Other issues . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Congestion as a Commercial Secret . . . . . . . . . . . . 13
6.2. Information Security . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . . 16
Briscoe, et al. Expires May 19, 2011 [Page 2]
Internet-Draft ConEx Mechanism November 2010
1. Introduction
The growth of "always on" broadband connections, coupled with the
steady increase in access speeds [OfCom], have caused unforeseen
problems for network operators and users alike. Users are
increasingly seeing congestion at peak times and changes in usage
patterns (with the growth of real-time streaming) simply serve to
exacerbate this. Operators want all their users to see a good
service but are unable to see where congestion problems originate.
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 operators and cellular internet have different tradeoffs
which we will not discuss here.)
Congestion generally results from the interaction of traffic from one
network operator's users with traffic from other users. The tools
currently available don't allow an operator to identify which traffic
contributes most to the congestion and so they are powerless to
properly control it.
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 [BB-incentive]. 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 the
increasing bandwidth demands of all users.
The growth of "scavenger" behaviour (e.g. [LEDBAT]) helps to reduce
congestion, but can actually make the problem less tractable. These
users are trying to make good use of the capacity of the path while
minimising their own costs. Thus, users of such services may show
very heavy total traffic up until the moment congestion is detected
(at the Transport Layer), but then will immediately back off.
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.
The ConEx working group proposes that Internet Protocol (IP) packets
will carry additional ConEx information. The exact protocol details
are not described in this document, but the ConEx information will be
sufficient to allow any node in the network to see how much
congestion is attributable to a given traffic flow. See
[ConEx-Abstract-Mech] for further details.
Briscoe, et al. Expires May 19, 2011 [Page 3]
Internet-Draft ConEx Mechanism November 2010
Changes from previous drafts (to be removed by the RFC Editor):
From draft-moncaster-conex-concepts-uses-02 to
draft-ietf-conex-concepts-uses-00 (per decisions of working group):
Removed section on DDoS mitigation use case.
Removed appendix on ConEx Architectural Elements. PLEASE NOTE:
Alignment of terminology with the Abstract Mechanism draft has
been deferred to the next version.
From draft-moncaster-conex-concepts-uses-01 to
draft-moncaster-conex-concepts-uses-02:
Updated document to take account of the new Abstract Mechanism
draft [ConEx-Abstract-Mech].
Updated the definitions section.
Removed sections on Requirements and Mechanism.
Moved section on ConEx Architectural Elements to appendix.
Minor changes throughout.
From draft-moncaster-conex-concepts-uses-00 to
draft-moncaster-conex-concepts-uses-01:
Changed end of Abstract to better reflect new title
Created new section describing the architectural elements of
ConEx. Added Edge Monitors and Border Monitors (other elements
are Ingress, Egress and Border Policers).
Extensive re-write of Section 5 partly in response to suggestions
from Dirk Kutscher
Improved layout of Section 2 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.
Improved document structure. Merged sections on Exposing
Congestion and ECN.
Briscoe, et al. Expires May 19, 2011 [Page 4]
Internet-Draft ConEx Mechanism November 2010
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
Added a sub-section on Partial vs Full Deployment Section 5.5
Added a discussion on ConEx as a Business Secret Section 6.1
From draft-conex-mechanism-00 to
draft-moncaster-conex-concepts-uses-00:
Changed filename to draft-moncaster-conex-concepts-uses.
Changed title to ConEx Concepts and Use Cases.
Chose uniform capitalisation of ConEx.
Moved definition of Congestion Volume to list of definitions.
Clarified mechanism section. Changed section title.
Modified text relating to conex-aware policing and policers (which
are NOT defined terms).
Re-worded bullet on distinguishing ConEx and non-ConEx traffic in
Section 5.
2. Definitions
In this section we define a number of terms that are used throughout
the document. The key definition is that of congestion, which has a
number of meanings depending on context. The definition we use in
this document is based on the definition in [Padhye] where congestion
is viewed as a probability that a packet will be dropped. This list
of definitions is supplementary to that in [ConEx-Abstract-Mech].
Congestion: Congestion is a measure of the probability that a packet
will be marked or dropped as it traverses a queue.
flow: a series of packets from a single sender to a single receiver
that are treated by that sender as belonging to a single stream
for the purposes of congestion control. NB in general this is not
the same as the aggregate of all traffic between the sender and
receiver.
Briscoe, et al. Expires May 19, 2011 [Page 5]
Internet-Draft ConEx Mechanism November 2010
Congestion-rate: For any granularity of traffic (packet, flow,
aggregate, etc.), the instantaneous rate of traffic discarded or
marked due to congestion. Conceptually, the instantaneous bit-
rate of the traffic multiplied by the instantaneous congestion it
is experiencing.
Congestion-volume: For any granularity of traffic (packet, flow,
aggregate, etc.), the volume of bytes dropped or marked in a given
period of time. Conceptually, congestion-rate multipled by time.
Upstream Congestion: the accumulated level of congestion experienced
by a traffic flow thus far 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.
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.
Ingress: the first 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.
Egress: the last node a packet traverses before reaching the
receiver's network.
ConEx-enabled: Any piece of equipment (end-system, router, tunnel
end-point, firewall, policer, etc) that complies with the core
ConEx protocol, which is to be defined by the ConEx working group.
By extension a ConEx-enabled network is a network whose edge nodes
are all ConEx-enabled.
3. Congestion Management
Since 1988 the Internet architecture has made congestion management
the responsibility of the end-systems. The network signals
congestion to the receiver, the receiver feeds this back to the
sender and the sender is expected to try and reduce the traffic it
sends.
Any network that is persistently highly congested is inefficient.
However the total absence of congestion is equally bad as it means
Briscoe, et al. Expires May 19, 2011 [Page 6]
Internet-Draft ConEx Mechanism November 2010
there is spare capacity in the network that hasn't been used. The
long-standing aim of congestion control has been to find the point
where these two things are in balance.
Over recent years, some network operators have come to the view that
end-system congestion management is insufficient. Because of the
heuristics used by TCP, a relatively small number of end-machines can
get a disproportionately high share of network resources. They have
sought to "correct" this perceived problem by using middleboxes that
try and reduce traffic that is causing congestion or by artificially
starving some traffic classes to create stronger congestion signals.
3.1. Existing Approaches
The authors have chosen not to exhaustively list current approaches
to congestion management. Broadly these approaches 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:
o Volume accounting -- the overall volume of traffic a given user or
network sends is measured. Users may be subject to an absolute
volume cap (e.g. 10Gbytes per month) or the "heaviest" users may
be sanctioned in some manner.
o Rate measurement -- the traffic rate per user or per network can
be measured. The absolute rate a given user sends at may be
limited at peak hours or the average rate may be used as the basis
for inter-network billing.
Higher layer approaches include:
o Bottleneck rate policing -- bottleneck flow rate policers aim to
share the available capacity at a given bottleneck between all
concurrent users.
o DPI and application rate policing -- deep packet inspection and
other techniques can be used to determine what application a given
traffic flow is associated with. Operators may then use this
information to rate-limit or otherwise sanction certain
applications at peak hours.
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
Briscoe, et al. Expires May 19, 2011 [Page 7]
Internet-Draft ConEx Mechanism November 2010
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.
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.
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.
4. Exposing Congestion
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.
For example, an application intending to transfer large amounts of
data could use a congestion control mechanism like [LEDBAT] 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. Operators can
neither enforce their use nor avoid penalizing them for congestion
they avoid.
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
Briscoe, et al. Expires May 19, 2011 [Page 8]
Internet-Draft ConEx Mechanism November 2010
would be a new capability. Today a network can use Explicit
Congestion Notification (ECN) [RFC3168] 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 that seek to
minimise congestion in the network whilst restricting inappropriate
uses of traditional TCP and UDP applications.
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.
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.
4.1. ECN - a Step in the Right Direction
Explicit Congestion Notification [RFC3168] 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) [RFC2309] 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.
Alas, this is not enough - ECN gives downstream nodes an idea of 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.
What is needed is knowledge of the downstream congestion level, for
which you need additional information that is still concealed from
Briscoe, et al. Expires May 19, 2011 [Page 9]
Internet-Draft ConEx Mechanism November 2010
the network.
5. ConEx Use Cases
This section sets out some of the use cases for ConEx. These use
cases rely on some of the conceptual elements described in
[ConEx-Abstract-Mech]. The authors don't claim this is an exhaustive
list of use cases, nor that these have equal merit. In most cases
ConEx is not the only solution to achieve these. But these use cases
represent a consensus among people that have been working on this
approach for some years.
5.1. ConEx as a basis for traffic management
Currently many operators 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 operators 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)
[Fair-use]. Often this traffic management is done with expensive
flow aware devices such as DPI boxes or flow-aware routers.
ConEx offers a better approach that will actually target the users
that are causing the congestion. By using Ingress or Egress
Policers, an ISP can identify which users 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 [Policing-freedom] is one interesting approach that
gives the user a congestion volume limit. So long as they stay
within their limit then their traffic is unaffected. Once they
exceed that limit then their traffic will be blocked temporarily.
5.2. ConEx to incentivise scavenger transports
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.
At present most operators assume a strong correlation between the
Briscoe, et al. Expires May 19, 2011 [Page 10]
Internet-Draft ConEx Mechanism November 2010
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 and hence can cause
high congestion at relatively low data volumes. Currently LEDBAT-
like transports get no incentive from the ISP since they still
transfer large volumes of data and may reach high transfer speeds if
the network is uncongested. Consequently the only current incentive
for LEDBAT is that it can reduce self-congestion effects.
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,
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 [Kelly] 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.
5.3. Accounting for Congestion Volume
Accountability was one of the original design goals for the Internet
[Design-Philosophy]. At the time it was ranked low because the
network was non-commercial and it was assumed users had the best
interests of the network at heart. Nowadays users generally treat
the network as a commodity and the Internet has become highly
commercialised. This causes problems for operators and others which
they have tried to solve and often leads to a tragedy of the commons
where users end up fighting each other for scarce peak capacity.
The most elegant solution would be to introduce an Internet-wide
system of accountability where every actor in the network is held to
account for the impact they have on others. If Policers are placed
at every Network Ingress or Egress and Border Monitors at every
border, then you have the basis for a system of congestion
accounting. Simply by controlling the overall Congestion Volume each
end-system or stub-network can send you ensure everyone gets a better
service.
5.4. ConEx as a form of differential QoS
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.
Briscoe, et al. Expires May 19, 2011 [Page 11]
Internet-Draft ConEx Mechanism November 2010
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.
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).
5.5. Partial vs. Full Deployment
In a fully-deployed ConEx-enabled internet, [QoS-Models] shows that
ISP settlements based on congestion volume can allocate money to
where upgrades are needed. Fully-deployed implies that ConEx-marked
packets which have not exhausted their expected congestion would go
through a congested path in preference to non-ConEx packets, with
money changing hands to justify that priority.
In a partial deployment, routers that ignore ConEx markings and let
them pass unaltered are no problem unless they become congested and
drop packets. Since ConEx incentivises the use of lower congestion
transports, such congestion drops should anyway become rare events.
ConEx-unaware routers that do drop ConEx-marked packets would cause a
problem so to minimise this risk ConEx should be designed such that
ConEx packets will appear valid to any node they traverse. Failing
that it could be possible to bypass such nodes with a tunnel.
If any network is not ConEx enabled then the sender and receiver have
to rely on ECN-marking or packet drops to establish the congestion
level. If the receiver isn't ConEx-enabled then there needs to be
some form of compatibility mode. Even in such partial deployments
the end-users and access networks will benefit from ConEx. This will
put create incentives for ConEx to be more widely adopted as access
networks put pressure on their backhaul providers to use congestion
Briscoe, et al. Expires May 19, 2011 [Page 12]
Internet-Draft ConEx Mechanism November 2010
as the basis of their interconnect agreement.
The actual charge per unit of congestion would be specified in an
interconnection agreement, with economic pressure driving that charge
downward to the cost to upgrade whenever alternative paths are
available. That charge would most likely be invisible to the
majority of users. Instead such users will have a contractual
allowance to cause congestion, and would see packets dropped when
that allowance is depleted.
Once an Autonomous System (AS) agrees to pay any congestion charges
to any other AS it forwards to, it has an economic incentive to
increase congestion-so-far marking for any congestion within its
network. Failure to do this quickly becomes a significant cost,
giving it an incentive to turn on such marking.
End users (or the writers of the applications they use) will be given
an incentive to use a congestion control that back off more
aggressively than TCP for any elastic traffic. Indeed they will
actually have an incentive to use fully weighted congestion controls
that allow traffic to cause congestion in proportion to its priority.
Traffic which backs off more aggressively than TCP will see
congestion charges remain the same (or even drop) as congestion
increases; traffic which backs off less aggressively will see charges
rise, but the user may be prepared to accept this if it is high-
priority traffic; traffic which backs off not at all will see charges
rise dramatically.
6. Other issues
6.1. Congestion as a Commercial Secret
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:
o 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
Briscoe, et al. Expires May 19, 2011 [Page 13]
Internet-Draft ConEx Mechanism November 2010
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.
o Operators 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.
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.
6.2. Information Security
make a source believe it has seen more congestion than it has
hijack a user's identity and make it appear they are dishonest at an
egress policer
clear or otherwise tamper with the ConEx markings
...
{ToDo} Write these up properly...
7. Security Considerations
This document proposes a mechanism tagging onto Explicit Congestion
Notification [RFC3168], 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.
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:
Briscoe, et al. Expires May 19, 2011 [Page 14]
Internet-Draft ConEx Mechanism November 2010
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.
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. [Savage] explains how a receiver
can significantly improve their throughput my failing to declare
congestion. This is a problem with or without Congestion
Exposure. [KGao] explains one possible technique to encourage
receiver's to be honest in their declaration of congestion.
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.
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.
8. IANA Considerations
This document does not require actions by IANA.
Briscoe, et al. Expires May 19, 2011 [Page 15]
Internet-Draft ConEx Mechanism November 2010
9. Acknowledgments
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.
The authors would like to thank Contributing Authors Bernard Aboba,
Joao Taveira Araujo, Louise Burness, Alissa Cooper, Philip Eardley,
Michael Menth, and Hannes Tschofenig for their inputs to this
document. Useful feedback was also provided by Dirk Kutscher.
10. References
10.1. Normative References
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black,
"The Addition of Explicit Congestion
Notification (ECN) to IP", RFC 3168,
September 2001.
10.2. Informative References
[BB-incentive] MIT Communications Futures Program (CFP) and
Cambridge University Communications Research
Network, "The Broadband Incentive Problem",
September 2005.
[ConEx-Abstract-Mech] Briscoe, B., "Congestion Exposure (ConEx)
Concepts and Abstract Mechanism",
draft-mathis-conex-abstract-mech-00 (work in
progress), October 2010.
[Design-Philosophy] Clarke, D., "The Design Philosophy of the
DARPA Internet Protocols", 1988.
[Fair-use] Broadband Choices, "Truth about 'fair usage'
broadband", 2009.
[Fairer-faster] Briscoe, B., "A Fairer Faster Internet
Protocol", IEEE Spectrum Dec 2008 pp38-43,
December 2008.
[KGao] Gao, K. and C. Wang, "Incrementally Deployable
Prevention to TCP Attack with Misbehaving
Receivers", December 2004.
[Kelly] Kelly, F., Maulloo, A., and D. Tan, "Rate
Briscoe, et al. Expires May 19, 2011 [Page 16]
Internet-Draft ConEx Mechanism November 2010
control for communication networks: shadow
prices, proportional fairness and stability",
Journal of the Operational Research
Society 49(3) 237--252, 1998, <http://
www.statslab.cam.ac.uk/~frank/rate.html>.
[LEDBAT] Shalunov, S., "Low Extra Delay Background
Transport (LEDBAT)",
draft-ietf-ledbat-congestion-01 (work in
progress), March 2010.
[Malice] Briscoe, B., "Using Self Interest to Prevent
Malice; Fixing the Denial of Service Flaw of
the Internet", WESII - Workshop on the
Economics of Securing the Information
Infrastructure 2006, 2006, <http://
wesii.econinfosec.org/draft.php?paper_id=19>.
[OfCom] Ofcom: Office of Communications, "UK Broadband
Speeds 2008: Research report", January 2009.
[Padhye] Padhye, J., Firoiu, V., Towsley, D., and J.
Kurose, "Modeling TCP Throughput: A Simple
Model and its Empirical Validation", ACM
SIGCOMM Computer Communications Review Vol
28(4), pages 303-314, May 1998.
[Policing-freedom] Briscoe, B., Jacquet, A., and T. Moncaster,
"Policing Freedom to Use the Internet Resource
Pool", RE-Arch 2008 hosted at the 2008 CoNEXT
conference , December 2008.
[QoS-Models] Briscoe, B. and S. Rudkin, "Commercial Models
for IP Quality of Service Interconnect", BTTJ
Special Edition on IP Quality of Service vol
23 (2), April 2005.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie,
B., Deering, S., Estrin, D., Floyd, S.,
Jacobson, V., Minshall, G., Partridge, C.,
Peterson, L., Ramakrishnan, K., Shenker, S.,
Wroclawski, J., and L. Zhang, "Recommendations
on Queue Management and Congestion Avoidance
in the Internet", RFC 2309, April 1998.
[Re-Feedback] Briscoe, B., Jacquet, A., Di Cairano-
Gilfedder, C., Salvatori, A., Soppera, A., and
M. Koyabe, "Policing Congestion Response in an
Briscoe, et al. Expires May 19, 2011 [Page 17]
Internet-Draft ConEx Mechanism November 2010
Internetwork Using Re-Feedback", ACM SIGCOMM
CCR 35(4)277--288, August 2005, <http://
www.acm.org/sigs/sigcomm/sigcomm2005/
techprog.html#session8>.
[Savage] Savage, S., Wetherall, D., and T. Anderson,
"TCP Congestion Control with a Misbehaving
Receiver", ACM SIGCOMM Computer Communication
Review , 1999.
[re-ecn-motive] Briscoe, B., Jacquet, A., Moncaster, T., and
A. Smith, "Re-ECN: A Framework for adding
Congestion Accountability to TCP/IP",
draft-briscoe-tsvwg-re-ecn-tcp-motivation-02
(work in progress), October 2010.
Authors' Addresses
Bob Briscoe
BT
B54/77, Adastral Park
Martlesham Heath
Ipswich IP5 3RE
UK
Phone: +44 1473 645196
EMail: bob.briscoe@bt.com
URI: http://bobbriscoe.net/
Richard Woundy
Comcast
Comcast Cable Communications
27 Industrial Avenue
Chelmsford, MA 01824
US
EMail: richard_woundy@cable.comcast.com
URI: http://www.comcast.com
Briscoe, et al. Expires May 19, 2011 [Page 18]
Internet-Draft ConEx Mechanism November 2010
Toby Moncaster (editor)
Moncaster.com
Dukes
Layer Marney
Colchester CO5 9UZ
UK
EMail: toby@moncaster.com
John Leslie (editor)
JLC.net
10 Souhegan Street
Milford, NH 03055
US
EMail: john@jlc.net
Briscoe, et al. Expires May 19, 2011 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-23 09:56:59 |