< draft-moncaster-conex-concepts-uses-00.txt   draft-moncaster-conex-concepts-uses-01.txt >
CONEX B. Briscoe CONEX B. Briscoe
Internet-Draft BT Internet-Draft BT
Intended status: Informational R. Woundy Intended status: Informational R. Woundy
Expires: January 2, 2011 Comcast Expires: January 13, 2011 Comcast
T. Moncaster, Ed. T. Moncaster, Ed.
Moncaster.com Moncaster.com
J. Leslie, Ed. J. Leslie, Ed.
JLC.net JLC.net
July 1, 2010 July 12, 2010
ConEx Concepts and Use Cases ConEx Concepts and Use Cases
draft-moncaster-conex-concepts-uses-00 draft-moncaster-conex-concepts-uses-01
Abstract Abstract
Internet Service Providers (ISPs) are facing problems where Internet Service Providers (ISPs) are facing problems where localized
congestion prevents full utilization of the path between sender and congestion prevents full utilization of the path between sender and
receiver at today's "broadband" speeds. ISPs desire to control the receiver at today's "broadband" speeds. ISPs desire to control this
congestion, which often appears to be caused by a small number of congestion, which often appears to be caused by a small number of
users consuming a large amount of bandwidth. Building out more users consuming a large amount of bandwidth. Building out more
capacity along all of the path to handle this congestion can be capacity along all of the path to handle this congestion can be
expensive; and network operators have sought other ways to manage expensive and may not result in improvements for all users so network
congestion. The current mechanisms all suffer from difficulty operators have sought other ways to manage congestion. The current
measuring the congestion (as distinguished from the total traffic). 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 The ConEx Working Group is designing a mechanism to make congestion
along any path visible at the Internet Layer. This document along any path visible at the Internet Layer. This document
discusses this mechanism. describes example cases where this mechanism would be useful.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 2, 2011. This Internet-Draft will expire on January 13, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 19 skipping to change at page 3, line 7
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Existing Approaches to Congestion Management . . . . . . . . . 6 3. Existing Approaches to Congestion Management . . . . . . . . . 7
4. Exposing Congestion . . . . . . . . . . . . . . . . . . . . . 7 4. Exposing Congestion . . . . . . . . . . . . . . . . . . . . . 8
5. ECN - a Step in the Right Direction . . . . . . . . . . . . . 8 4.1. ECN - a Step in the Right Direction . . . . . . . . . . . 9
6. A Possible Congestion Exposure Mechanism . . . . . . . . . . . 9 5. Requirements for ConEx . . . . . . . . . . . . . . . . . . . . 10
7. ConEx Use Cases . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. ConEx Issues . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Ingress policing for traffic management . . . . . . . . . 11 6. A Possible Congestion Exposure Mechanism . . . . . . . . . . . 11
7.2. ConEx to incentivise scavenger transports . . . . . . . . 12 7. ConEx Architectural Elements . . . . . . . . . . . . . . . . . 12
7.3. ConEx to mitigate DDoS . . . . . . . . . . . . . . . . . . 13 7.1. ConEx Monitoring . . . . . . . . . . . . . . . . . . . . . 13
7.4. ConEx as a form of differential QoS . . . . . . . . . . . 13 7.1.1. Edge Monitoring . . . . . . . . . . . . . . . . . . . 13
7.5. Other issues . . . . . . . . . . . . . . . . . . . . . . . 13 7.1.2. Border Monitoring . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7.2. ConEx Policing . . . . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7.2.1. Egress Policing . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 7.2.2. Ingress Policing . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.2.3. Border Policing . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8. ConEx Use Cases . . . . . . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . . 18 8.1. ConEx as a basis for traffic management . . . . . . . . . 19
8.2. ConEx to incentivise scavenger transports . . . . . . . . 19
8.3. ConEx to mitigate DDoS . . . . . . . . . . . . . . . . . . 20
8.4. Accounting for Congestion Volume . . . . . . . . . . . . . 20
8.5. ConEx as a form of differential QoS . . . . . . . . . . . 21
8.6. Partial vs. Full Deployment . . . . . . . . . . . . . . . 22
9. Other issues . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Congestion as a Commercial Secret . . . . . . . . . . . . 23
9.2. Information Security . . . . . . . . . . . . . . . . . . . 24
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
13.1. Normative References . . . . . . . . . . . . . . . . . . . 25
13.2. Informative References . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
The growth of "always on" broadband connections, coupled with the The growth of "always on" broadband connections, coupled with the
steady increase in access speeds [OfCom], has meant network operators steady increase in access speeds [OfCom], have caused unforeseen
are increasingly facing problems with congestion. But congestion problems for network operators and users alike. Users are
results from sharing network capacity with others, not merely from increasingly seeing congestion at peak times and changes in usage
using it. In general, today's "DSL" and cable-internet users cannot patterns (with the growth of real-time streaming) simply serve to
"cause" congestion in the absence of competing traffic. (Wireless exacerbate this. Operators want all their users to see a good
ISPs and cellular internet have different tradeoffs which we will not service but are unable to see where congestion problems originate.
discuss here.) 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.)
Actual congestion generally results from the interaction of traffic Congestion generally results from the interaction of traffic from an
from an ISPs own subscribers with traffic from other users. The ISPs own subscribers with traffic from other users. The tools
tools currently available don't allow an operator to identify the currently available don't allow an operator to identify which traffic
causes of the congestion and so leave them powerless to properly contributes most to the congestion and so they are powerless to
control it. properly control it.
While building out more capacity to handle increased traffic is While building out more capacity to handle increased traffic is
always good, the expense and lead-time can be prohibitive, especially always good, the expense and lead-time can be prohibitive, especially
for network operators that charge flat-rate feeds to subscribers and for network operators that charge flat-rate feeds to subscribers and
are thus unable to charge heavier users more for causing more are thus unable to charge heavier users more for causing more
congestion [BB-incentive]. For an operator facing congestion caused congestion [BB-incentive]. For an operator facing congestion caused
by other operators' networks, building out its own capacity is by other operators' networks, building out its own capacity is
unlikely to solve the congestion problem. Operators are thus facing unlikely to solve the congestion problem. Operators are thus facing
increased pressure to find effective solutions to dealing with high- increased pressure to find effective solutions to dealing with the
consuming users. increasing bandwidth demands of all users.
The growth of "scavenger-class" services helps to reduce congestion, The growth of "scavenger" behaviour (e.g. [LEDBAT]) helps to reduce
but actually make the ISPs problem less tractable. These are congestion, but can actually make the ISPs problem less tractable.
services where participating users are not at all interested in These users are trying to make good use of the capacity of the path
paying more, but wish to make good use of the capacity of the path. while minimising their own costs. Thus, users of such services may
Thus, users of such services may show very heavy total traffic up show very heavy total traffic up until the moment congestion is
until the moment congestion is detected (at the Transport Layer), but detected (at the Transport Layer), but then will immediately back
immediately back off. ISP monitoring (at the Internet Layer) cannot off. ISP monitoring (at the Internet Layer) cannot detect this
detect this congestion avoidance if the congestion in question is in congestion avoidance if the congestion in question is in a different
a different domain further along the path; and must treat such users domain further along the path; and must treat such users as
as congestion-causing users. congestion-causing users.
We propose that Internet Protocol (IP) packets have two "congestion" The ConEx working group proposes that Internet Protocol (IP) packets
fields. The exact protocol details of these fields are for another have two "congestion" fields. The exact protocol details of these
document, but we expect them to provide measures of "congestion so fields are for another document, but we expect them to provide
far" and "congestion still expected". measures of "congestion so far" and "congestion still expected".
Changes from previous drafts (to be removed by the RFC Editor): Changes from previous drafts (to be removed by the RFC Editor):
From -00 to -01:
Changed end of Abstract to better reflect new title
Created new section describing the architectural elements of ConEx
Section 7. Added Edge Monitors and Border Monitors (other
elements are Ingress, Egress and Border Policers).
Extensive re-write of Section 8 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.
Added new section on ConEx requirements Section 5 with a ConEx
Issues subsection Section 5.1. Text for these came from the start
of the old ConEx Use Cases section
Added a sub-section on Partial vs Full Deployment Section 8.6
Added a discussion on ConEx as a Business Secret Section 9.1
From draft-conex-mechanism-00 to From draft-conex-mechanism-00 to
draft-moncaster-conex-concepts-uses-00: draft-moncaster-conex-concepts-uses-00:
Changed filename to draft-moncaster-conex-concepts-uses. Changed filename to draft-moncaster-conex-concepts-uses.
Changed title to ConEx Concepts and Use Cases. Changed title to ConEx Concepts and Use Cases.
Chose uniform capitalisation of ConEx. Chose uniform capitalisation of ConEx.
Moved definition of Congestion Volume to list of definitions. Moved definition of Congestion Volume to list of definitions.
Clarified Section 6. Changed section title. Clarified Section 6. Changed section title.
Modified text relating to conex-aware policing and policers (which Modified text relating to conex-aware policing and policers (which
are NOT defined terms). are NOT defined terms).
Re-worded bullet on distinguishing ConEx and non-ConEx traffic in Re-worded bullet on distinguishing ConEx and non-ConEx traffic in
Section 7. Section 8.
2. Definitions 2. Definitions
Since ConEx expects to build on Explicit Congestion Notification ConEx expects to build on Explicit Congestion Notification (ECN)
(ECN) [RFC3168], we use the term "congestion" in a manner consistent [RFC3168] where it is available. Hence we use the term "congestion"
with ECN, namely that congestion occurs before any packet is dropped. in a manner consistent with ECN, namely that congestion occurs before
any packet is dropped. In this section we define a number of terms
We define six specific terms carefully: that are used throughout the document.
Congestion: Congestion is a measure of the probability that a given Congestion: Congestion is a measure of the probability that a given
packet will be ECN-marked or dropped as it traverses the network. 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 At any given router it is a function of the queue state at that
router. Congestion is added in a combinatorial manner, that is, router. Congestion is added in a combinatorial manner, that is,
routers ignore the congestion a packet has already seen when they routers ignore the congestion a packet has already seen when they
decide whether to mark it or not. decide whether to mark it or not.
Congestion Volume: Congestion volume is defined as the congestion a Congestion Volume: Congestion volume is defined as the congestion a
packet experiences, multiplied by the size of that packet. See packet experiences, multiplied by the size of that packet. It can
[Fairer-faster]. be expressed as the volume of bytes that have been ECN-marked or
dropped. By extension, the Congestion Rate would be the
transmission rate multiplied by the congestion level.
Upstream Congestion: The congestion that has already been Upstream Congestion: The congestion that has already been
experienced by a packet as it travels along its path. In other 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 words at any point on the path, it is the congestion between the
source of the packet and that point. source of the packet and that point.
Downstream Congestion: The congestion that a packet still has to Downstream Congestion: The congestion that a packet still has to
experience on the remainder of its path. In other words at any experience on the remainder of its path. In other words at any
point it is the congestion still to be experienced as the packet point it is the congestion still to be experienced as the packet
travels between that point and its destination. travels between that point and its destination.
Ingress Router: The Ingress Router is the first router a packet Whole Path Congestion: The total congestion that a packet
traverses that is outside its own network. In a domestic network experiences between the ingress to the network and the egress.
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.
Egress Router: The Egress Router is the last router a packet Network Ingress: The Network Ingress is 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 a business network it may be the first
router downstream of the firewall.
Network Egress: The Network Egress is the last node a packet
traverses before it enters the destination network. traverses before it enters the destination network.
ConEx-Enabled: Any piece of equipment (end-system, router, tunnel
end-point, firewall, policer, etc) that fully implements the ConEx
protocol.
ECN-enabled: Any router that fully enables Explicit Congestion
Notification (ECN) as defined in [RFC3168] and any relevant
updates to that standard.
3. Existing Approaches to Congestion Management 3. Existing Approaches to Congestion Management
Initial attempts to capture congestion situations have usually A number of ISPs already use some form of traffic management.
focused on the peak hours and aimed at rate limiting heavy users Generally this is an attempt to control the peak-time congestion
during that time. For example, users who have consumed a certain within their network and to better apportion shared network resources
amount of bandwidth during the last 24 hours got elected as those who between customers. Even ISPs that don't impose such traffic
get their traffic shaped if the total amount of traffic reaches a management (such as those in Germany) may have caps on the capacity
congestion situation in certain nodes within the operator's network. they allow for Best Effort traffic in their backhaul.
All of the current approaches suffer from some general limitations. These attempts to control congestion have usually focused on the peak
hours and aim to rate limit heavy users during that time. For
example, users who have consumed a certain amount of bandwidth during
the last 24 hours may be elected to have their traffic shaped once
the total traffic reaches a given level in certain nodes within the
operator's network.
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. ISPs 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 First, they introduce performance uncertainty. Flat-rate pricing
plans are popular because users appreciate the certainty of having plans are popular because users appreciate the certainty of having
their monthly bill amount remain the same for each billing period, their monthly bill amount remain the same for each billing period,
allowing them to plan their costs accordingly. But while flat-rate allowing them to plan their costs accordingly. But while flat-rate
pricing avoids billing uncertainty, it creates performance pricing avoids billing uncertainty, it creates performance
uncertainty: users cannot know whether the performance of their uncertainty: users cannot know whether the performance of their
connection is being altered or degraded based on how the network connection is being altered or degraded based on how the network
operator manages congestion. operator manages congestion.
Second, none of the approaches is able to make use of what may be the Second, none of the approaches is able to make use of what may be the
skipping to change at page 7, line 35 skipping to change at page 9, line 19
The Internet was designed so that end-hosts detect and control The Internet was designed so that end-hosts detect and control
congestion. We argue that congestion needs to be visible to network congestion. We argue that congestion needs to be visible to network
nodes as well, not just to the end hosts. More specifically, a nodes as well, not just to the end hosts. More specifically, a
network needs to be able to measure how much congestion any network needs to be able to measure how much congestion any
particular traffic expects to cause between the monitoring point in particular traffic expects to cause between the monitoring point in
the network and the destination ("rest-of-path congestion"). This the network and the destination ("rest-of-path congestion"). This
would be a new capability. Today a network can use Explicit would be a new capability. Today a network can use Explicit
Congestion Notification (ECN) [RFC3168] to detect how much congestion Congestion Notification (ECN) [RFC3168] to detect how much congestion
the traffic has suffered between the source and a monitoring point, the traffic has suffered between the source and a monitoring point,
but not beyond. This new capability would enable an ISP to give but not beyond. This new capability would enable an ISP to give
incentives for the use of LEDBAT-like applications whilst restricting incentives for the use of LEDBAT-like applications that seek to
inappropriate uses of traditional TCP and UDP ones. 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 So we propose a new approach which we call Congestion Exposure. We
propose that congestion information should be made visible at the IP propose that congestion information should be made visible at the IP
layer, so that any network node can measure the contribution to layer, so that any network node can measure the contribution to
congestion of an aggregate of traffic as easily as straight volume congestion of an aggregate of traffic as easily as straight volume
can be measured today. Once the information is exposed in this way, 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 it is then possible to use it to measure the true impact of any
traffic on the network. traffic on the network.
In general, congestion exposure gives ISPs a principled way to hold In general, congestion exposure gives ISPs a principled way to hold
their customers accountable for the impact on others of their network their customers accountable for the impact on others of their network
usage and reward them for choosing congestion-sensitive applications. usage and reward them for choosing congestion-sensitive applications.
5. ECN - a Step in the Right Direction 4.1. ECN - a Step in the Right Direction
Explicit Congestion Notification [RFC3168] allows routers to Explicit Congestion Notification [RFC3168] allows routers to
explicitly tell end-hosts that they are approaching the point of explicitly tell end-hosts that they are approaching the point of
congestion. ECN builds on Active Queue Mechanisms such as random congestion. ECN builds on Active Queue Mechanisms such as random
early discard (RED) [RFC2309] by allowing the router to mark a packet early discard (RED) [RFC2309] by allowing the router to mark a packet
with a Congestion Experienced (CE) codepoint, rather than dropping with a Congestion Experienced (CE) codepoint, rather than dropping
it. The probability of a packet being marked increases with the 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 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 level of congestion at that queue. This CE codepoint travels forward
through the network to the receiver which then informs the sender through the network to the receiver which then informs the sender
that it has seen congestion. The sender is then required to respond 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 as if it had experienced a packet loss. Because the CE codepoint is
visible in the IP layer, this approach reveals the upstream visible in the IP layer, this approach reveals the upstream
congestion level for a packet. congestion level for a packet.
Alas, this is not enough - ECN only allows downstream nodes to Alas, this is not enough - ECN gives downstream nodes an idea of the
measure the congestion so far for any flow. This can help hold a congestion so far for any flow. This can help hold a receiver
receiver accountable for the congestion caused by incoming traffic. accountable for the congestion caused by incoming traffic. But a
But a receiver can only indirectly influence incoming congestion, by receiver can only indirectly influence incoming congestion, by
politely asking the sender to control it. A receiver cannot make a politely asking the sender to control it. A receiver cannot make a
sender install an adaptive codec, or install LEDBAT instead of TCP sender install an adaptive codec, or install LEDBAT instead of TCP
congestion-control. And a receiver cannot cause an attacker to stop congestion-control. And a receiver cannot cause an attacker to stop
flooding it with traffic. flooding it with traffic.
What is needed is knowledge of the downstream congestion level, for What is needed is knowledge of the downstream congestion level, for
which you need additional information that is still concealed from which you need additional information that is still concealed from
the network. the network.
5. Requirements for ConEx
This document is intended to highlight some of the possible uses for
a congestion exposure mechanism such as the one being proposed by the
ConEx working group. The actual ConEx mechanism will be defined in
another document.
In this section we set out some basic requirements for any ConEx
mechanism. We are not saying this is an exhaustive list of those
requirements. This list is simply to allow readers to make a
realistic assessment of the feasibility and utility of the use cases
set out in Section 8.
The three key requirements are
1. Timeliness of information. The limitations of current network
design gives a minimum delay of 1 round trip time (RTT) for
congestion information to circulate the network. It is important
that the conex mechanism operates on similar timescales to ensure
the congestion information it exposes is as up to date as
possible. Stale congestion information is useless since
congestion levels can fluctuate widely over relatively short
timescales.
2. Accuracy of information. In order to be useful, congestion
information has to be sufficiently accurate for the purposes for
which it is to be used. In general the main purposes are
monitoring congestion and controlling congestion. As a minimum,
conex should equal the accuracy required for current TCP
implementations. A unary signal such as that provided by ECN is
sufficient though a more precise signal may be desirable.
3. Visibility of information. In order to be useful conex
information should be visible at every point in the network. In
today's networks that means it must be visible at the IP layer.
5.1. ConEx Issues
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:
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.
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 it is important to
be cautious when over-declaring congestion lest you erode trust in
the system. We do not initially propose any mechanism to deal
with this issue.
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.
There are three approaches that may work (individually or in
combination):
* An ingress router can monitor a user's feedback to see what
their reported congestion level actually is.
* If the congestion field carries the actual congestion value
then a ConEx-Enabled Policer could potentially drop any packet
with a downstream-congestion value of zero or less.
* 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.
6. A Possible Congestion Exposure Mechanism 6. A Possible Congestion Exposure Mechanism
One possible protocol is based on a concept known as re-feedback One possible protocol is based on a concept known as re-feedback
[Re-Feedback], and builds on existing active queue management [Re-Feedback], and builds on existing active queue management
techniques like RED [RFC2309] and ECN [RFC3168] that network elements techniques like RED [RFC2309] and ECN [RFC3168] that network elements
can already use to measure and expose congestion. The protocol is can already use to measure and expose congestion. The protocol is
described in more detail in [Fairer-faster], but we summarise it described in more detail in [Fairer-faster], but we summarise it
below. below.
In this protocol packets have two Congestion fields in their IP In this protocol packets have two Congestion fields in their IP
header: header:
o A congestion experienced field to record the Upstream Congestion o An Upstream Congestion field to record the congestion already
level along the path. Routers indicate their current congestion experienced along the path. Routers indicate their current
level by updating this field in every packet. As the packet congestion level by updating this field in every packet. As the
traverses the network it builds up a record of the overall packet traverses the network it builds up a record of the overall
congestion along its path in this field. This data is sent back congestion along its path in this field. This data is sent back
to the sender who uses it to determine its transmission rate. to the sender who uses it to determine its transmission rate.
This can be achieved by using the existing ECN field [RFC3168].
o A whole-path congestion field that uses re-feedback to record the o A whole-path congestion field that uses re-feedback to record the
total congestion expected along the path. The sender does this by total congestion expected along the path. The sender does this by
re-inserting the current Congestion level for the path into this re-inserting the current Congestion level for the path into this
field for every packet it transmits. field for every packet it transmits.
Thus at any node downstream of the sender you can see the Upstream 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 Congestion for the packet and the whole path congestion (with a time
lag of one round-trip-time (RTT)) and can calculate the Downstream lag of one round-trip-time (RTT)) and can calculate the Downstream
Congestion by subtracting one from the other. Congestion by subtracting the Upstream from the Whole Path
Congestion.
So congestion exposure can be achieved by coupling congestion So congestion exposure can be achieved by coupling congestion
notification from routers with the re-insertion of this information notification from routers with the re-insertion of this information
by the sender. This establishes information symmetry between users by the sender. This establishes information symmetry between users
and network providers. and network providers.
7. ConEx Use Cases 7. ConEx Architectural Elements
ConEx is a simple concept that has revolutionary implications. It is ConEx is a simple concept that has revolutionary implications. It is
that rare thing -- a truly disruptive technology, and as such 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 hard to imagine the variety of uses it may be put to. Before even
are several obvious use cases that come to mind with a little thinking what it might be used for we need to address the issue of
thought. The authors aren't claiming all of these have equal merit, how it can be used. This section describes four architectural
nor are we claiming ConEx is the only conceivable solution to achieve elements that can be placed in the network and which utilise ConEx
these. But these use cases represent a consensus among people that information to monitor or control traffic flows.
have been working on this approach for some years.
In the following use cases we are assuming the most abstract version In the following we are assuming the most abstract version of the
of the ConEx mechanism, namely that every packet carries two ConEx mechanism, namely that every packet carries two congestion
congestion fields, one for upstream congestion and one for fields, one for upstream congestion and one for downstream.
downstream. At every node that is congested the upstream congestion Section 6 outlines one possible approach for this.
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.
If ConEx information is to be useful it has to be accurate (within 7.1. ConEx Monitoring
the limitations of the available feedback). This raises three issues
that need to be addressed:
Distinguishing ConEx traffic from non-ConEx traffic: An ISP may One of the most useful things ConEx provides is the ability to
reasonably choose to do nothing different with ConEx traffic. monitor (and control) the amount of congestion entering or leaving a
Alternatively they might want to incentivise it in order to give network. With ConEx, each packet carries sufficient information to
it marginally better service. IN that case it will be necessary work out the Upstream, Downstream and Total Congestion Volume that
to distinguish ConEx traffic from non-ConEx traffic. On one level packet is responsible for. This allows the overall Congestion Volume
this seems pretty easy -- ConEx traffic will have the downstream to be calculated at any point in the network. In effect this gives a
congestion field in every packet. However in practise it may not measure of how much excess traffic has been sent that was above the
be as simple as this as the protocol may use a unary encoding instantaneous transmission capacity of the network. A 1 Gbps router
(where the congestion value is encoded across several packets). that is 0.1% congested implies that there is 1 Mbps of excess traffic
at that point in time.
Over-declaring congestion: ConEx relies on the sender accurately The figure below shows 2 conceptual pieces of network equipment that
declaring the congestion they expect to see. During TCP slow- utilise ConEx information in order to monitor the flow of congestion
start a sender is unable to predict the level of congestion they through the network. The Border Monitor sits at the border between
will experience and it is advisable to declare that expect to see two networks, while the Edge Monitor sits at the ingress or egress to
some congestion on the first packet. However, if any host or the Internetwork.
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.
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 | Src |--( Net A )-| B.M. |-( Net B )--| E.M. |--| Dst |
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. Border Monitor Edge Monitor
NB, the Edge Monitor could also be at the Src end of the network
There are three approaches that may work (individually or in Figure 1: Ingress, egress and border monitors
combination):
* An ingress router can monitor a user's feedback to see what Note: In the tables below ECN-enabled and ConEx-Enabled are as
their reported congestion level actually is. defined in Section 2.
* A ConEx-aware router can drop any packet with a downstream- 7.1.1. Edge Monitoring
congestion value of zero or less if that router is even +------------+----------------+----------------+--------------------+
slightly congested. | Network | ECN-Enabled? | ConEx-Enabled? | Notes |
| Element | | | |
+------------+----------------+----------------+--------------------+
| Sender | Yes, if ECN is | Yes, must be | Must be receiving |
| | used as basis | sending ConEx | congestion |
| | for congestion | information | feedback |
| | signal | | |
| Sender's | ECN would be | Should | NB, it doesn't |
| Network | beneficial | understand | have to be fully |
| | | ConEx markings | ConEx-Enabled |
| Core | ECN would be | Needn't | ConEx markings |
| Network | beneficial | understand | must get through |
| | | ConEx | the network |
| Receiver's | ECN would be | Should | Deosn't have to be |
| Network | beneficial | understand | fully |
| | | ConEx markings | ConEx-Enabled |
| Receiver | Only needed if | Should | Has to feedback |
| | network is | understand | the congestion it |
| | ECN-Enabled | ConEx | sees (either ECN |
| | | | or drop) |
+------------+----------------+----------------+--------------------+
* An egress router can actively monitor some or all flows to Table 1: Requirements for Edge Monitoring
check that they are complying with the requirement that the
downstream congestion value should be zero or (slightly
positive) when it reaches the egress.
At any point of congestion, it is reasonable to treat ConEx-marked Edge Monitors are ideally positioned to verify the accuracy of ConEx
traffic differently: markings. If there is an imbalance between the expected congestion
and the actual congestion then this will show up at the egress. Edge
Monitors can also be used by an operator to measure the service a
given customer is receiving by monitoring how much congestion their
traffic is causing. This may allow them to take pre-emptive action
if they detect any anomalies.
o non-ConEx traffic will mostly be dropped (as now); 7.1.2. Border Monitoring
o ConEx-marked traffic which has exhausted its congestion allowance +------------+-----------------+-----------------+------------------+
will (all) be dropped; | Network | ECN-Enabled? | ConEx-Enabled? | Notes |
| Element | | | |
+------------+-----------------+-----------------+------------------+
| Sender | Must be | Yes, must be | Must receive |
| | ECN-enabled if | sending ConEx | accurate |
| | any of the | information | congestion |
| | network is | | feedback |
| Sender's | ECN should be | Should | Ideally would be |
| Network | enabled | understand | ConEx-Enabled |
| | | ConEx markings | |
| Core | ECN should be | Should | Ideally would be |
| Network | enabled | understand | ConEx-Enabled |
| | | ConEx markings | |
| Receiver's | ECN should be | Should | Ideally would be |
| Network | enabled | understand | ConEx-Enabled |
| | | ConEx markings | |
| Receiver | Must be | Must be ConEx | Receiver has to |
| | ECN-enabled if | enabled | feedback the |
| | any of the | | congestion it |
| | network is | | sees |
+------------+-----------------+-----------------+------------------+
7.1. Ingress policing for traffic management Table 2: Requirements for Border Monitoring
At any border between 2 networks, the operator can see the total
Congestion Volume that is being forwarded into its network by the
neighbouring network. A Border Monitor is able to measure the bulk
congestion markings and establish the flow of Congestion Volume each
way across the border. This could be used as the basis for inter-
network settlements. It also provides information to target upgrades
to where they are actually needed and might help to identify network
problems. Border Monitoring really needs the majority of the network
to be ECN-Enabled in order to provide the necessary Upstream
Congestion signal. Clearly the greatest benefit comes when there is
also ConEx deployment in the nnetwork. However, as long as the
sender is sending accurate ConEx information and the majority of the
network is ECN-enabled, border monitoring will work.
7.2. ConEx Policing
As shown above, ConEx gives an easy method of measuring Congestion
Volume. This information can be used as a control metric for making
traffic management decisions (such as deciding which traffic to
prioritise) or to identify and block sources of persistent and
damaging congestion. Simple policer mechanisms, such as those
described in [Policing-freedom] and [re-ecn-motive], can control the
overall congestion volume traversing a network. Ingress Policing
typically happens at the Ingress Node, Egress Policing typically
happens at the Egress Node and Border Policing can happen at any
border between two networks. The current charter concentrates on use
cases employing Egress Policers.
,---. ,---.
+-----+ +------+ / \ +------+ / \ +------+ +-----+
| Src |--| I.P. |--( Net A )-| B.P. |-( Net B )--| E.P. |--| Dst |
+-----+ +------+ \ / +------+ \ / +------+ +-----+
^ '---` ^ '---` ^
Ingress Policer Border Policer Egress Policer
Figure 2: Ingress, egress and border policers
7.2.1. Egress Policing
+------------+--------------+----------------+----------------------+
| Network | ECN-Enabled? | ConEx-Enabled? | Notes |
| Element | | | |
+------------+--------------+----------------+----------------------+
| Sender | The sender | Must be | Must be receiving |
| | should be | ConEx-Enabled | congestion feedback |
| | ECN-enabled | | |
| | if any of | | |
| | the network | | |
| | is | | |
| Sender's | ECN is | ConEx is | ConEx would enable |
| Network | optional but | optional | them to do Ingress |
| | beneficial | | Policing (see later) |
| Core | ECN is | Not needed | ConEx marks must |
| Network | optional but | | survive crossing the |
| | beneficial | | network |
| Receiver's | ECN is | Must fully | Each receiver needs |
| Network | optional but | understand | an Egress Policer |
| | beneficial | ConEx | |
| Receiver | Should be | Should | Must feedback the |
| | ECN-enabled | understand | congestion it sees. |
| | if any of | ConEx | ConEx may have a |
| | the network | | compatibility mode |
| | is | | if the receiver is |
| | | | not ConEx-Enabled |
+------------+--------------+----------------+----------------------+
Table 3: Egress Policer Requirements
An Egress Policer allows an ISP to monitor the Congestion Volume a
user's traffic has caused throughout the network, and then use this
to prioritise the traffic accordingly. By itself, such a policer
cannot tell how much of this congestion was caused in the ISP's own
network, but it will identify which users are the "heaviest" in terms
of the congestion they have caused. Assuming the ConEx information
is accurate then the Egress Policer will be able to see how much
congestion exists between it and the final destination (what you
might call "last-mile" congestion). There are a number of strategies
that could be used to determine how traffic is treated by an Egress
Policer. Obviously traffic that is not ConEx enabled needs to
receive some form of "default" treatment. Traffic that is ConEx
enabled may have under-declared congestion in which case it would be
reasonable to give it a low scheduling priority. Traffic that
appears to be over-declaring congestion may be simply a result of
especially high "last-mile" congestion, in which case the ISP may
want to upgrade the access capacity, or may want to try and reduce
the volume of traffic. Where the ISP knows what the "last-mile"
congestion is (for instance if it is able to measure several users
sharing that same capacity) then any remaining over-declared
congestion might be seen as a signal that the sender wishes to
prioritise this traffic.
7.2.2. Ingress Policing
+------------+--------------+----------------+----------------------+
| Network | ECN-Enabled? | ConEx-Enabled? | Notes |
| Element | | | |
+------------+--------------+----------------+----------------------+
| Sender | Should be | Must be | Must be receiving |
| | ECN-enabled | ConEx-enabled | congestion feedback |
| Sender's | ECN is | Must | |
| Network | optional but | understand | |
| | beneficial | ConEx | |
| Core | ECN is | Needn't | ConEx markings must |
| Network | optional but | understand | survive crossing the |
| | beneficial | ConEx | network |
| Receiver's | ECN is | Needn't | ConEx markings must |
| Network | optional but | understand | survive crossing the |
| | beneficial | ConEx | network |
| Receiver | Should be | Should be | Must feedback the |
| | ECN-enabled | ConEx-Enabled | congestion it sees. |
| | if any of | | ConEx may have a |
| | the network | | compatibility mode |
| | is | | if the receiver is |
| | | | not ConEx-Enabled |
+------------+--------------+----------------+----------------------+
Table 4: Ingress Policer Requirements
At the Network Ingress, 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
[Policing-freedom]. This uses a modified token bucket to limit the
congestion rate being sent rather than the overall rate. Such
ingress policing is relatively simple as it requires no flow state.
Furthermore, unlike many mechanisms, it treats all a user's packets
equally.
7.2.3. Border Policing
+------------+--------------+----------------+----------------------+
| Network | ECN-Enabled? | ConEx-Enabled? | Notes |
| Element | | | |
+------------+--------------+----------------+----------------------+
| Sender | ECN should | Must be | Must receive |
| | be enabled | ConEx-enabled | accurate congestion |
| | | | feedback |
| Sender's | ECN is | Must be | |
| Network | optional but | ConEx-enabled | |
| | beneficial | | |
| Core | ECN is | Should be | Must be |
| Network | optional but | ConEx-Enabled | ConEx-Enabled if it |
| | beneficial | | is doing the |
| | | | policing. At a |
| | | | minimum must pass |
| | | | ConEx markings |
| | | | unaltered |
| Receiver's | ECN is | Should be | At a minimum must |
| Network | optional but | ConEx-Enabled | pass ConEx markings |
| | beneficial | | unaltered |
| Receiver | Should be | Should be | Must feedback the |
| | ECN-Enabled | ConEx-Enabled | congestion it sees. |
| | if any of | | ConEx may have a |
| | the network | | compatibility mode |
| | is | | if the receiver is |
| | | | not ConEx-Enabled |
+------------+--------------+----------------+----------------------+
Table 5: Border Policer Requirements
A Border Policer will allow an operator to directly control the
congestion that it allows into its network. Normally we would expect
the controls to be related to some form of contractual obligation
between the two parties. However, such Policing could also be used
to mitigate some effects of Distributed Denial of Service (see
Section 8.3). In effect a Border Policer encourages the network
upstream to take responsibility for congestion it will cause
downstream and could be seen as an incentive for that network to
participate in ConEx (e.g. install Ingress Policers)
8. ConEx Use Cases
This section sets out some of the use cases for ConEx. These use
cases rely on some of the conceptual network elements (policers and
monitors) described in Section 7 above. 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.
8.1. ConEx as a basis for traffic management
Currently many ISPs impose some form of traffic management at peak Currently many ISPs impose some form of traffic management at peak
hours. This is a simple economic necessity -- the only reason the hours. This is a simple economic necessity -- the only reason the
Internet works as a commercial concern is that ISPs are able to rely Internet works as a commercial concern is that ISPs are able to rely
on statistical multiplexing to share their expensive core network on statistical multiplexing to share their expensive core network
between large numbers of customers. In order to ensure all customers between large numbers of customers. In order to ensure all customers
get some chance to access the network, the "heaviest" customers will get some chance to access the network, the "heaviest" customers will
be subjected to some form of traffic management at peak times be subjected to some form of traffic management at peak times
(typically a rate cap for certain types of traffic) [Fair-use]. (typically a rate cap for certain types of traffic) [Fair-use].
Often this traffic management is done with expensive flow aware Often this traffic management is done with expensive flow aware
devices such as DPI boxes or flow-aware routers. devices such as DPI boxes or flow-aware routers.
ConEx enables a new approach that requires simple per-user policing ConEx offers a better approach that will actually target the users
at the ingress. As described above, every packet a user sends should that are causing the congestion. By using Ingress or Egress
declare the total congestion that the sender expects that packet to Policers, an ISP can identify which users are causing the greatest
encounter on its journey through the network. This allows the Congestion Volume throughout the network. This can then be used as
overall Congestion Volume to be calculated. In effect this is a the basis for traffic management decisions. The Ingress Policer
measure of how much traffic was sent that was above the instantaneous described in [Policing-freedom] is one interesting approach that
transmission capacity of the network. By extension the congestion gives the user a congestion volume limit. So long as they stay
rate would be the transmission rate multiplied by the congestion within their limit then their traffic is unaffected. Once they
level. A 1 Gbps router that is 0.1% congested implies that there is exceed that limit then their traffic will be blocked temporarily.
1 Mbps of excess traffic at that point in time.
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
[Policing-freedom]. 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.
7.2. ConEx to incentivise scavenger transports 8.2. ConEx to incentivise scavenger transports
Recent work proposes a new approach for QoS where traffic is provided Recent work proposes a new approach for QoS where traffic is provided
with a less than best effort or "scavenger" quality of service. The 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, 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 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 use any spare network capacity, but should rapidly get out of the way
if a higher priority or interactive application starts up. One if a higher priority or interactive application starts up. One
solution being actively explored is LEDBAT which proposes a new solution being actively explored is LEDBAT which proposes a new
congestion control algorithm that is less aggressive in seeking out congestion control algorithm that is less aggressive in seeking out
bandwidth than TCP. bandwidth than TCP.
At present most ISPs assume a strong correlation between the volume At present most ISPs assume a strong correlation between the volume
of a flow and the impact that flow causes in the network. This of a flow and the impact that flow causes in the network. This
assumption has been eroded by the growth of interactive streaming assumption has been eroded by the growth of interactive streaming
which behaves in an inelastic manner. Assuming the end-user is using which behaves in an inelastic manner and hence can cause high
ConEx marking on all traffic and that LEDBAT leads to the expected congestion at relatively low data volumes. Currently LEDBAT-like
low level of congestion and the ingress ISP has deployed a ConEx- transports get no incentive from the ISP since they still transfer
aware ingress policer, then the LEDBAT will not be penalised since it large volumes of data and may reach high transfer speeds if the
will be causing less congestion. (If LEDBAT is not ConEx-marking network is uncongested. Consequently the only current incentive for
traffic then the ISP will be forced to guess the congestion, probably LEDBAT is that it can reduce self-congestion effects.
based on the total volume).
If the ISP has deployed a ConEx-aware ingress policer then they are 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 able to incentivise the use of LEDBAT because a user will be policed
according to the overall congestion volume their traffic generates. according to the overall congestion volume their traffic generates,
If all background file transfers are only generating a low level of not the rate or data volume. If all background file transfers are
congestion then the sender has more "congestion budget" to "spend" on only generating a low level of congestion, then the sender has more
their interactive applications. It can be shown [Kelly] that this "congestion budget" to "spend" on their interactive applications. It
approach maximises social welfare -- in other words if you limit the can be shown [Kelly] that this approach improves social welfare -- in
congestion that all users can generate then everyone benefits from a other words if you limit the congestion that all users can generate
better service. then everyone benefits from a better service.
7.3. ConEx to mitigate DDoS 8.3. ConEx to mitigate DDoS
DDoS relies on subverting innocent end users and getting them to send DDoS relies on subverting innocent end users and getting them to send
flood traffic to a given destination. This is intended to cause a flood traffic to a given destination. This is intended to cause a
rapid increase in congestion in the immediate vicinity of that rapid increase in congestion in the immediate vicinity of that
destination. If it fails to do this then it can't be called Denial 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 of Service. If the ingress ISP has deployed Ingress Policers, that
Section 7.1, that ISP will limit how much DDoS traffic enters the ISP will effectively limit how much DDoS traffic enters the 'net. If
'net. If the compromised user tries to use the 'net during the DDoS any ISP along the path has deployed Border Monitors then they will be
attack, they will quickly become aware that something is wrong, and able to detect a sharp rise in Congestion Volume and if they have
their ISP can show the evidence that their computer has become Border Policers they will be able to "turn off" this traffic. If the
zombified. victim of the DDoS attack is behind an Egress Monitor then their ISP
will be able to detect which traffic is causing problems. 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.
7.4. ConEx as a form of differential QoS DDoS is a genuine problem and so far there is no perfect solution.
ConEx does serve to raise the bar somewhat and can avoid the need for
some of the more draconian measures that are currently used to
control DDoS. More details of this can be found in [Malice].
8.4. 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 ISPs 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.
8.5. ConEx as a form of differential QoS
Most QoS approaches require the active participation of routers to Most QoS approaches require the active participation of routers to
control the delay and loss characteristics for the traffic. For control the delay and loss characteristics for the traffic. For
real-time interactive traffic it is clear that low delay and low real-time interactive traffic it is clear that low delay (and
jitter are critical and thus these probably always need different predictable jitter) are critical, and thus these probably always need
treatment at a router. However if low loss is the issue then ConEx different treatment at a router. However if low loss is the issue
offers an alternative approach. Assuming the ingress ISP has then ConEx offers an alternative approach.
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.
7.5. Other issues 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).
8.6. 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
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.
9. Other issues
9.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 ISPs 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 ISPs) 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 ISPs to see the actual congestion in their network. On the
other hand, operators with low congestion could use ConEx to show
how well their network performs, and so might have an incentive to
enable it.
o ISPs would like to be part of the lucrative content provision
market. Currently the ISP can gain a competitive edge as it can
put its own content in a higher QoS class, whereas traffic from
content providers has to use the Best Effort class. The ISP may
take the view that if they can conceal the congestion level in
their Best Effort class this will make it harder for the content
provider to maintain a good level of QoS. But in reality the
Content Provider will just use the feedback mechanisms in
streaming protocols such as Adobe Flash to monitor the congestion.
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 ISPs can work out that there is persistent congestion as their
customers will be suffering degraded network performance.
9.2. Information Security
make a source believe it has seen more congestion than it has 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 hijack a user's identity and make it appear they are dishonest at an
egress policer egress policer
clear or otherwise tamper with the ConEx markings clear or otherwise tamper with the ConEx markings
... ...
8. Security Considerations {ToDo} Write these up properly...
10. Security Considerations
This document proposes a mechanism tagging onto Explicit Congestion This document proposes a mechanism tagging onto Explicit Congestion
Notification [RFC3168], and inherits the security issues listed Notification [RFC3168], and inherits the security issues listed
therein. The additional issues from Congestion Expected markings therein. The additional issues from ConEx markings relate to the
relate to the degree of trust each forwarding point places in degree of trust each forwarding point places in the ConEx markings it
Congestion Expected markings it receives, which is a business receives, which is a business decision mostly orthogonal to the
decision mostly orthogonal to the markings themselves. markings themselves.
One expected use of exposed congestion information is to hold the One expected use of exposed congestion information is to hold the
end-to-end transport and the network accountable to each other. The end-to-end transport and the network accountable to each other. The
network cannot be relied on to report information to the receiver network cannot be relied on to report information to the receiver
against its interest, and the same applies for the information the against its interest, and the same applies for the information the
receiver feeds back to the sender, and that the sender reports back receiver feeds back to the sender, and that the sender reports back
to the network. Looking at each in turn: to the network. Looking at each in turn:
o The Network. In general it is not in any network's interest to The Network In general it is not in any network's interest to under-
under-declare congestion since this will have potentially negative declare congestion since this will have potentially negative
consequences for all users of that network. It may be in its consequences for all users of that network. It may be in its
interest to over-declare congestion if, for instance, it wishes to interest to over-declare congestion if, for instance, it wishes to
force traffic to move away to a different network or simply to force traffic to move away to a different network or simply to
reduce the amount of traffic it is carrying. Congestion Exposure reduce the amount of traffic it is carrying. Congestion Exposure
itself won't significantly alter the incentives for and against itself won't significantly alter the incentives for and against
honest declaration of congestion by a network, but we can imagine honest declaration of congestion by a network, but we can imagine
applications of Congestion Exposure that will change these applications of Congestion Exposure that will change these
incentives. There is a perception among network operators that incentives. There is a perception among network operators that
their level of congestion is a business secret. Today, congestion their level of congestion is a business secret. Today, congestion
is one of the worst-kept secrets a network has, because end-hosts is one of the worst-kept secrets a network has, because end-hosts
can see congestion better than network operators can. Congestion can see congestion better than network operators can. Congestion
Exposure will enable network operators to pinpoint whether Exposure will enable network operators to pinpoint whether
congestion is on one side or the other of any border. It is congestion is on one side or the other of any border. It is
conceivable that forwarders with underprovisioned networks may try conceivable that forwarders with underprovisioned networks may try
to obstruct deployment of Congestion Exposure. to obstruct deployment of Congestion Exposure.
o The Receiver. Receivers generally have an incentive to under- The Receiver Receivers generally have an incentive to under-declare
declare congestion since they generally wish to receive the data congestion since they generally wish to receive the data from the
from the sender as rapidly as possible. [Savage] explains how a sender as rapidly as possible. [Savage] explains how a receiver
receiver can significantly improve their throughput my failing to can significantly improve their throughput my failing to declare
declare congestion. This is a problem with or without Congestion congestion. This is a problem with or without Congestion
Exposure. [KGao] explains one possible technique to encourage Exposure. [KGao] explains one possible technique to encourage
receiver's to be honest in their declaration of congestion. receiver's to be honest in their declaration of congestion.
o The Sender. One proposed mechanism for Congestion Exposure The Sender One proposed mechanism for Congestion Exposure deployment
deployment adds a requirement for a sender to advise the network adds a requirement for a sender to advise the network how much
how much congestion it has suffered or caused. Although most congestion it has suffered or caused. Although most senders
senders currently respond to congestion they are informed of, one currently respond to congestion they are informed of, one use of
use of exposed congestion information might be to encourage exposed congestion information might be to encourage sources of
sources of excessive congestion to back off more aggressively. persistent congestion to back off more aggressively. Then clearly
there may be an incentive for the sender to under-declare
Then clearly there may be an incentive for the sender to under- congestion. This will be a particular problem with sources of
declare congestion. This will be a particular problem with flooding attacks. "Policing" mechanisms have been proposed to
sources of flooding attacks. "Policing" mechanisms have been deal with this.
proposed to deal with this.
In addition there are potential problems from source spoofing. A In addition there are potential problems from source spoofing. A
malicious sender can pretend to be another user by spoofing the malicious sender can pretend to be another user by spoofing the
source address. Congestion Exposure allows for "Policers" and source address. Congestion Exposure allows for "Policers" and
"Traffic Shapers" so as to be robust against injection of false "Traffic Shapers" so as to be robust against injection of false
congestion information into the forward path. congestion information into the forward path.
9. IANA Considerations 11. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
10. Acknowledgments 12. 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, The authors would like to thank Contributing Authors Bernard Aboba,
Joao Taveira Araujo, Louise Burness, Alissa Cooper, Philip Eardley, Joao Taveira Araujo, Louise Burness, Alissa Cooper, Philip Eardley,
Michael Menth, and Hannes Tschofenig for their inputs to this Michael Menth, and Hannes Tschofenig for their inputs to this
document. document. Useful feedback was also provided by Dirk Kutscher.
11. References 13. References
11.1. Normative References 13.1. Normative References
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The [RFC3168] Ramakrishnan, K., Floyd,
Addition of Explicit Congestion Notification S., and D. Black, "The
(ECN) to IP", RFC 3168, September 2001. Addition of Explicit
Congestion Notification
(ECN) to IP", RFC 3168,
September 2001.
11.2. Informative References 13.2. Informative References
[BB-incentive] MIT Communications Futures Program (CFP) and [BB-incentive] MIT Communications Futures
Cambridge University Communications Research Program (CFP) and
Network, "The Broadband Incentive Problem", Cambridge University
September 2005. Communications Research
Network, "The Broadband
Incentive Problem",
September 2005.
[Fair-use] Broadband Choices, "Truth about 'fair usage' [Design-Philosophy] Clarke, D., "The Design
broadband", 2009. Philosophy of the DARPA
Internet Protocols", 1988.
[Fairer-faster] Briscoe, B., "A Fairer Faster Internet Protocol", [Fair-use] Broadband Choices, "Truth
IEEE Spectrum Dec 2008 pp38-43, December 2008. about 'fair usage'
broadband", 2009.
[KGao] Gao, K. and C. Wang, "Incrementally Deployable [Fairer-faster] Briscoe, B., "A Fairer
Prevention to TCP Attack with Misbehaving Faster Internet Protocol",
Receivers", December 2004. IEEE Spectrum Dec 2008
pp38-43, December 2008.
[Kelly] Kelly, F., Maulloo, A., and D. Tan, "Rate control [I-D.briscoe-tsvwg-re-ecn-tcp-motivation] Briscoe, B., Jacquet, A.,
for communication networks: shadow prices, Moncaster, T., and A.
proportional fairness and stability", Journal of Smith, "Re-ECN: A
the Operational Research Society 49(3) 237--252, Framework for adding
1998, Congestion Accountability
<http://www.statslab.cam.ac.uk/~frank/rate.html>. to TCP/IP", draft-briscoe-
tsvwg-re-ecn-tcp-
motivation-01 (work in
progress), September 2009.
[LEDBAT] Shalunov, S., "Low Extra Delay Background [KGao] Gao, K. and C. Wang,
Transport (LEDBAT)", "Incrementally Deployable
draft-ietf-ledbat-congestion-01 (work in Prevention to TCP Attack
progress), March 2010. with Misbehaving
Receivers", December 2004.
[OfCom] Ofcom: Office of Communications, "UK Broadband [Kelly] Kelly, F., Maulloo, A.,
Speeds 2008: Research report", January 2009. and D. Tan, "Rate 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>.
[Policing-freedom] Briscoe, B., Jacquet, A., and T. Moncaster, [LEDBAT] Shalunov, S., "Low Extra
"Policing Freedom to Use the Internet Resource Delay Background Transport
Pool", RE-Arch 2008 hosted at the 2008 CoNEXT (LEDBAT)", draft-ietf-
conference , December 2008. ledbat-congestion-01 (work
in progress), March 2010.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., [Malice] Briscoe, B., "Using Self
Deering, S., Estrin, D., Floyd, S., Jacobson, V., Interest to Prevent
Minshall, G., Partridge, C., Peterson, L., Malice; Fixing the Denial
Ramakrishnan, K., Shenker, S., Wroclawski, J., of Service Flaw of the
and L. Zhang, "Recommendations on Queue Internet", WESII -
Management and Congestion Avoidance in the Workshop on the Economics
Internet", RFC 2309, April 1998. of Securing the
Information
Infrastructure 2006, 2006,
<http://
wesii.econinfosec.org/
draft.php?paper_id=19>.
[Re-Feedback] Briscoe, B., Jacquet, A., Di Cairano-Gilfedder, [OfCom] Ofcom: Office of
C., Salvatori, A., Soppera, A., and M. Koyabe, Communications, "UK
"Policing Congestion Response in an Internetwork Broadband Speeds 2008:
Using Re-Feedback", ACM SIGCOMM CCR 35(4)277-- Research report",
288, August 2005, <http://www.acm.org/sigs/ January 2009.
sigcomm/sigcomm2005/techprog.html#session8>.
[Savage] Savage, S., Wetherall, D., and T. Anderson, "TCP [Policing-freedom] Briscoe, B., Jacquet, A.,
Congestion Control with a Misbehaving Receiver", and T. Moncaster,
ACM SIGCOMM Computer Communication Review , 1999. "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
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-01 (work in
progress), September 2009.
Authors' Addresses Authors' Addresses
Bob Briscoe Bob Briscoe
BT BT
B54/77, Adastral Park B54/77, Adastral Park
Martlesham Heath Martlesham Heath
Ipswich IP5 3RE Ipswich IP5 3RE
UK UK
skipping to change at page 20, line 30 skipping to change at page 29, line 30
Comcast Cable Communications Comcast Cable Communications
27 Industrial Avenue 27 Industrial Avenue
Chelmsford, MA 01824 Chelmsford, MA 01824
US US
EMail: richard_woundy@cable.comcast.com EMail: richard_woundy@cable.comcast.com
URI: http://www.comcast.com URI: http://www.comcast.com
Toby Moncaster (editor) Toby Moncaster (editor)
Moncaster.com Moncaster.com
Dukes
Layer Marney Layer Marney
Colchester CO5 9UZ Colchester CO5 9UZ
UK UK
EMail: toby@moncaster.com EMail: toby@moncaster.com
John Leslie (editor) John Leslie (editor)
JLC.net JLC.net
10 Souhegan Street 10 Souhegan Street
Milford, NH 03055 Milford, NH 03055
 End of changes. 79 change blocks. 
277 lines changed or deleted 887 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/