One document matched: draft-moncaster-conex-concepts-uses-02.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<?rfc toc="yes" ?> <!-- Default toc="no" No Table of Contents -->
<?rfc symrefs="yes" ?> <!-- Default symrefs="no" Don't use anchors, but use numbers for refs -->
<?rfc sortrefs="yes" ?> <!-- Default sortrefs="no" Don't sort references into order -->
<?rfc compact="yes" ?> <!-- Default compact="no" Start sections on new pages -->
<?rfc strict="no" ?> <!-- Default strict="no" Don't check I-D nits -->
<?rfc rfcedstyle="yes" ?> <!-- Default rfcedstyle="yes" attempt to closely follow finer details from the latest observable RFC-Editor style -->
<?rfc linkmailto="yes" ?> <!-- Default linkmailto="yes" generate mailto: URL, as appropriate -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"
[
<!ENTITY RFC2309 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2309.xml'>
<!ENTITY RFC3168 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3168.xml'>
]>
<rfc category="info" ipr='trust200902' docName="draft-moncaster-conex-concepts-uses-02">
<front>
<title abbrev="ConEx Mechanism">ConEx Concepts and Use Cases</title>
<author fullname="Bob Briscoe" initials="B." surname="Briscoe">
<organization>BT</organization>
<address>
<postal>
<street>B54/77, Adastral Park</street>
<street>Martlesham Heath</street>
<city>Ipswich</city>
<code>IP5 3RE</code>
<country>UK</country>
</postal>
<phone>+44 1473 645196</phone>
<email>bob.briscoe@bt.com</email>
<uri>http://bobbriscoe.net/</uri>
</address>
</author>
<author initials="R." surname="Woundy" fullname="Richard Woundy">
<organization>Comcast</organization>
<address>
<postal>
<street>Comcast Cable Communications</street>
<street>27 Industrial Avenue</street>
<city> Chelmsford</city>
<code>01824</code>
<region>MA</region>
<country>US</country>
</postal>
<email>richard_woundy@cable.comcast.com</email>
<uri>http://www.comcast.com</uri>
</address>
</author>
<author initials="T." surname="Moncaster" fullname="Toby Moncaster" role="editor">
<organization>Moncaster.com</organization>
<address>
<postal>
<street>Dukes</street>
<street>Layer Marney</street>
<city>Colchester</city>
<code>CO5 9UZ</code>
<country>UK</country>
</postal>
<email>toby@moncaster.com</email>
</address>
</author>
<author initials="J." surname="Leslie" fullname="John Leslie" role="editor">
<organization>JLC.net</organization>
<address>
<postal>
<street>10 Souhegan Street</street>
<city> Milford</city>
<code>03055</code>
<region>NH</region>
<country>US</country>
</postal>
<email>john@jlc.net</email>
</address>
</author>
<date day="25" month="October" year="2010"/>
<area>Transport Area</area>
<workgroup>CONEX</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t> 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). </t>
<t> 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. </t>
</abstract>
</front>
<middle>
<!-- ====================================================================== -->
<section title="Introduction">
<t> The growth of "always on" broadband connections, coupled with the steady
increase in access speeds <xref target="OfCom"></xref>, 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.) </t>
<t> 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. </t>
<t> While building out more capacity to handle increased traffic is always
good, the expense and lead-time can be prohibitive, especially for network
operators that charge flat-rate feeds to subscribers and are thus unable
to charge heavier users more for causing more congestion <xref target="BB-incentive"></xref>. For an operator
facing congestion caused by other operators' networks, building out its
own capacity is unlikely to solve the congestion problem. Operators are
thus facing increased pressure to find effective solutions to dealing
with the increasing bandwidth demands of all users. </t>
<t> The growth of "scavenger" behaviour (e.g. <xref target="LEDBAT"></xref>) 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. </t>
<t>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
<xref target="ConEx-Abstract-Mech"></xref> for further details.</t>
<vspace blankLines="8" />
<t>
Changes from previous drafts (to be removed by the RFC Editor):
<list style="hanging">
<t hangText="From -01 to -02:"> </t>
<t>Updated document to take account of the new Abstract Mechanism draft <xref target="ConEx-Abstract-Mech"></xref>.
PLEASE NOTE: As that draft develops, it is envisaged that more material will be able to be removed from this
document, leaving this document free to concentrate on actual use cases for ConEx.</t>
<t>Updated the definitions section.</t>
<t>Removed sections on Requirements and Mechanism. </t>
<t>Moved section on ConEx Architectural Elements to appendix.</t>
<t>Minor changes throughout.</t>
<t hangText="From -00 to -01:"> </t>
<t>Changed end of Abstract to better reflect new title </t>
<t>Created new section describing the architectural elements of ConEx <xref target="conex-uses-arch"></xref>. Added
Edge Monitors and Border Monitors (other elements are Ingress, Egress and Border Policers).</t>
<t>Extensive re-write of <xref target="conex-uses-cases"></xref> partly in response to suggestions from Dirk Kutscher </t>
<t>Improved layout of <xref target="conex-uses-defs"></xref> and added definitions of Whole Path Congestion, ConEx-Enabled and ECN-Enabled.
Re-wrote definition of Congestion Volume.
Renamed Ingress and Egress Router to Ingress and Egress Node as these nodes may not actually be routers.</t>
<t>Improved document structure. Merged sections on Exposing Congestion and ECN. </t>
<t>Added new section on ConEx requirements with a ConEx Issues
subsection. Text for these came from the start of the old ConEx Use Cases section </t>
<t>Added a sub-section on Partial vs Full Deployment <xref target="conex-uses-deployment"></xref> </t>
<t>Added a discussion on ConEx as a Business Secret <xref target="conex-uses-secret"></xref> </t>
<t hangText="From draft-conex-mechanism-00 to draft-moncaster-conex-concepts-uses-00:"> </t>
<t>Changed filename to draft-moncaster-conex-concepts-uses.</t>
<t>Changed title to ConEx Concepts and Use Cases.</t>
<t>Chose uniform capitalisation of ConEx.</t>
<t>Moved definition of Congestion Volume to list of definitions.</t>
<t>Clarified mechanism section. Changed section title.</t>
<t>Modified text relating to conex-aware policing and policers (which are NOT defined terms). </t>
<t>Re-worded bullet on distinguishing ConEx and non-ConEx traffic in <xref target="conex-uses-cases"></xref>. </t>
</list>
</t>
</section>
<!-- ====================================================================== -->
<section title="Definitions" anchor="conex-uses-defs">
<t> 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 <xref target="ConEx-Abstract-Mech"></xref>.
<list style="hanging">
<t hangText="Congestion:"> Congestion is a measure of the probability that a packet
will be marked or dropped as it traverses a queue. </t>
<t hangText="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.</t>
<t hangText="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. </t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="Downstream Congestion:">the level of congestion a flow of traffic
is expected to experience on the remainder of its path. In other words, at any point the
Downstream Congestion is the level of congestion the traffic flow is yet to experience
as it travels from that point to the receiver.</t>
<t hangText="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. </t>
<t hangText="Egress:"> the last node a packet
traverses before reaching the receiver's network. </t>
<t hangText="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.</t>
</list>
</t>
</section>
<!-- ====================================================================== -->
<section title="Congestion Management">
<t>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.</t>
<t>Any network that is persistently highly congested is inefficient. However the
total absence of congestion is equally bad as it means 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.</t>
<t>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.</t>
<section title="Existing Approaches">
<t>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:
<list style="symbols">
<t>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.</t>
<t>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. </t>
</list>
Higher layer approaches include:
<list style="symbols">
<t>Bottleneck rate policing — bottleneck flow rate policers aim to share the available
capacity at a given bottleneck between all concurrent users.</t>
<t>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.</t>
</list>
</t>
<t>All of these current approaches suffer from some general limitations. First,
they introduce performance uncertainty. Flat-rate pricing plans are popular
because users appreciate the certainty of having their monthly bill amount
remain the same for each billing period, allowing them to plan their costs
accordingly. But while flat-rate pricing avoids billing uncertainty, it
creates performance uncertainty: users cannot know whether the performance
of their connection is being altered or degraded based on how the network
operator manages congestion. </t>
<t>Second, none of the approaches is able to make use of what may be the most
important factor in managing congestion: the amount that a given endpoint
contributes to congestion on the network. This information simply is not
available to network nodes, and neither volume nor rate nor application
usage is an adequate proxy for congestion volume, because none of these
metrics measures a user or network's actual contribution to congestion on
the network. </t>
<t> Finally, none of these solutions accounts for inter-network congestion.
Mechanisms may exist that allow an operator to identify and mitigate
congestion in their own network, but the design of the Internet means that
only the end-hosts have full visibility of congestion information along the
whole path. ConEx allows this information to be visible to everyone on the
path and thus allows operators to make better-informed decisions about
controlling traffic. </t>
</section>
</section>
<!-- ====================================================================== -->
<section title="Exposing Congestion">
<t> We argue that current traffic-control mechanisms seek to control the
wrong quantity. What matters in the network is neither the volume of
traffic nor the rate of traffic: it is the contribution to congestion over
time — congestion means that your traffic impacts other users,
and conversely that their traffic impacts you. So if there is no congestion
there need not be any restriction on the amount a user can send;
restrictions only need to apply when others are sending traffic such that
there is congestion. </t>
<t> For example, an application intending to transfer large amounts of data
could use a congestion control mechanism like <xref target="LEDBAT"></xref>
to reduce its transmission rate before any competing TCP flows do, by
detecting an increase in end-to-end delay (as a measure of impending
congestion). However such techniques rely on voluntary, altruistic action
by end users and their application providers. Operators can neither enforce
their use nor avoid penalizing them for congestion they avoid. </t>
<t> The Internet was designed so that end-hosts detect and control congestion.
We argue that congestion needs to be visible to network nodes as well, not
just to the end hosts. More specifically, a network needs to be able to
measure how much congestion any particular traffic expects to cause between
the monitoring point in the network and the destination ("rest-of-path
congestion"). This would be a new capability. Today a network can use
Explicit Congestion Notification (ECN) <xref target="RFC3168"></xref> to
detect how much congestion the traffic has suffered between the source and
a monitoring point, but not beyond. This new capability would enable an
ISP to give incentives for the use of LEDBAT-like applications that seek to
minimise congestion in the network whilst restricting inappropriate uses
of traditional TCP and UDP applications. </t>
<t> So we propose a new approach which we call Congestion Exposure. We
propose that congestion information should be made visible at the IP
layer, so that any network node can measure the contribution to congestion
of an aggregate of traffic as easily as straight volume can be measured
today. Once the information is exposed in this way, it is then
possible to use it to measure the true impact of any traffic on the
network. </t>
<t> In general, congestion exposure gives operators a principled way to hold their
customers accountable for the impact on others of their network usage and
reward them for choosing congestion-sensitive applications. </t>
<section title="ECN - a Step in the Right Direction">
<t> Explicit Congestion Notification <xref target="RFC3168"></xref> allows
routers to explicitly tell end-hosts that they are approaching the point of
congestion. ECN builds on Active Queue Mechanisms such as random early
discard (RED) <xref target="RFC2309"></xref> by allowing the router to mark
a packet with a Congestion Experienced (CE) codepoint, rather than dropping
it. The probability of a packet being marked increases with the length of
the queue and thus the rate of CE marks is a guide to the level of congestion
at that queue. This CE codepoint travels forward through the network to the
receiver which then informs the sender that it has seen congestion. The
sender is then required to respond as if it had experienced a packet loss.
Because the CE codepoint is visible in the IP layer, this approach reveals
the upstream congestion level for a packet.</t>
<t> Alas, this is not enough - ECN 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. </t>
<t> What is needed is knowledge of the downstream congestion level, for which
you need additional information that is still concealed from the network. </t>
</section>
</section>
<!-- ====================================================================== -->
<!-- ====================================================================== -->
<!-- ====================================================================== -->
<section title="ConEx Use Cases" anchor="conex-uses-cases">
<t> This section sets out some of the use cases for ConEx. These use cases rely on some
of the conceptual elements described in <xref target="ConEx-Abstract-Mech"></xref> and
<xref target="conex-uses-arch"></xref>. 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.
</t>
<section title="ConEx as a basis for traffic management" anchor="conex-uses-traff-man">
<t> 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) <xref target="Fair-use"></xref>. Often this traffic
management is done with expensive flow aware devices such as DPI boxes or flow-aware
routers. </t>
<t> ConEx 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 <xref target="Policing-freedom"></xref> 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.</t>
</section>
<section title="ConEx to incentivise scavenger transports"anchor="conex-uses-scavenge">
<t> Recent work proposes a new approach for QoS where traffic is provided with a less
than best effort or "scavenger" quality of service. The idea is that low priority
but high volume traffic such as OS updates, P2P file transfers and view-later TV
programs should be allowed to use any spare network capacity, but should rapidly
get out of the way if a higher priority or interactive application starts up.
One solution being actively explored is LEDBAT which proposes a new congestion
control algorithm that is less aggressive in seeking out bandwidth than TCP. </t>
<t> At present most operators assume a strong correlation between the volume of a flow
and the impact that flow causes in the network. This assumption has been eroded
by the growth of interactive streaming which behaves in an inelastic manner 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.</t>
<t> If the ISP has deployed a ConEx-aware Ingress Policer then they are able to
incentivise the use of LEDBAT because a user will be policed according to the
overall congestion volume their traffic generates, not the rate or data volume. If all background file
transfers are only generating a low level of congestion, then the sender has
more "congestion budget" to "spend" on their interactive applications. It can
be shown <xref target="Kelly"></xref> that this approach improves social welfare — in
other words if you limit the congestion that all users can generate then
everyone benefits from a better service. </t>
</section>
<section title="ConEx to mitigate DDoS" anchor="conex-uses-ddos">
<t> DDoS relies on subverting innocent end users and getting them to send flood
traffic to a given destination. This is intended to cause a rapid increase in
congestion in the immediate vicinity of that destination. If it fails to do this
then it can't be called Denial of Service. If the ingress ISP has deployed Ingress Policers,
that ISP will effectively limit how much DDoS traffic enters the 'net. If any ISP along the path has
deployed Border Monitors then they will be able to detect a sharp rise in Congestion Volume and if
they have Border Policers they will be able to "turn off" this traffic. If
the 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. </t>
<t>
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 <xref target="Malice"></xref>.
</t>
</section>
<section title="Accounting for Congestion Volume" anchor="conex-congest-account">
<t>
Accountability was one of the original design goals for the Internet <xref target="Design-Philosophy"></xref>. 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.</t>
<t>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.
</t>
</section>
<section title="ConEx as a form of differential QoS" anchor="conex-uses-qos">
<t> Most QoS approaches require the active participation of routers to control the
delay and loss characteristics for the traffic. For real-time interactive traffic
it is clear that low delay (and predictable jitter) are critical, and thus these probably
always need different treatment at a router. However if low loss is the issue
then ConEx offers an alternative approach.</t>
<t>Assuming the ingress ISP has deployed a ConEx Ingress Policer, then the only control
on a user's traffic is dependent on the congestion that user has caused. Likewise, if
they are receiving traffic through a ConEx Egress Policer then their ISP will impose
traffic controls (prioritisation, rate limiting, etc) based on the congestion they have caused.
If an end-user (be they the receiver or sender) wants to prioritise some
traffic over other traffic then they can allow that traffic to generate or cause more
congestion. The price they will pay will be to reduce the congestion that their other
traffic causes. </t>
<t> Streaming video content-delivery is a good candidate for such ConEx-mediated QoS. Such traffic
can tolerate moderately high delays, but there are strong economic pressures to maintain
a high enough data rate (as that will directly influence the Quality of Experience the
end-user receives. This approach removes the need for bandwidth brokers to establish QoS
sessions, by removing the need to coordinate requests from multiple sources to pre-allocate
bandwidth, as well as to coordinate which allocations to revoke when bandwidth predictions
turn out to be wrong. There is also no need to "rate-police" at the boundaries on a per-flow basis,
removing the need to keep per-flow state (which in turn makes this approach more scalable).</t>
</section>
<section title="Partial vs. Full Deployment" anchor="conex-uses-deployment">
<t>In a fully-deployed ConEx-enabled internet, <xref target="QoS-Models"></xref> 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. </t>
<t>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.
</t>
<t>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.
</t>
<t>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.</t>
<t> 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. </t>
<t> 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. </t>
</section>
</section>
<section title="Other issues">
<section title="Congestion as a Commercial Secret" anchor="conex-uses-secret">
<t>
Network operators have long viewed the congestion levels in their
network as a business secret. In some ways this harks back to the days
of fixed-line telecommunications where congestion manifested as failed
connections or dropped calls. But even in modern data-centric packet
networks congestion is viewed as a secret not to be shared with
competitors. It can be debated whether this view is sensible, but it
may make operators uneasy about deploying ConEx. The following two
examples highlight some of the arguments used:
<list style="symbols">
<t>An ISP buys backhaul capacity from an operator. Most operators want their
customers to get a decent service and so they want the backhaul to be
relatively uncongested. If there is competition, operators will seek
to reassure their customers (the operators) that their network is not congested in
order to attract their custom. Some operators may
see ConEx as a threat since it will enable those operators to see the actual congestion
in their network. On the other hand, operators with low congestion
could use ConEx to show how well their network performs, and so might have
an incentive to enable it.</t>
<t>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.</t>
</list>
Of course some might say that the idea of keeping congestion secret is silly. After
all, end-hosts already have knowledge of the congestion throughout the network, albeit only
along specific paths, and operators can work out that there is persistent congestion as their
customers will be suffering degraded network performance.
</t>
</section>
<section title="Information Security">
<t> make a source believe it has seen more congestion than it has </t>
<t> hijack a user's identity and make it appear they are dishonest at an egress
policer </t>
<t> clear or otherwise tamper with the ConEx markings </t>
<t> ... </t>
<t>{ToDo} Write these up properly...</t>
</section>
</section>
<!-- ====================================================================== -->
<section title="Security Considerations">
<t> This document proposes a mechanism tagging onto Explicit Congestion Notification
<xref target="RFC3168"/>, and inherits the security issues listed therein. The
additional issues from ConEx markings relate to the degree of trust
each forwarding point places in the ConEx markings it receives, which is
a business decision mostly orthogonal to the markings themselves. </t>
<t> One expected use of exposed congestion information is to hold the end-to-end
transport and the network accountable to each other. The network cannot be relied
on to report information to the receiver against its interest, and the same applies
for the information the receiver feeds back to the sender, and that the sender
reports back to the network. Looking at each in turn:
<list style="hanging">
<t hangText="The Network"> In general it is not in any network's interest to under-declare
congestion since this will have potentially negative consequences for all users
of that network. It may be in its interest to over-declare congestion if, for
instance, it wishes to force traffic to move away to a different network or
simply to reduce the amount of traffic it is carrying. Congestion Exposure
itself won't significantly alter the incentives for and against honest
declaration of congestion by a network, but we can imagine applications of
Congestion Exposure that will change these incentives. There is a perception
among network operators that their level of congestion is a business secret.
Today, congestion is one of the worst-kept secrets a network has, because
end-hosts can see congestion better than network operators can. Congestion
Exposure will enable network operators to pinpoint whether congestion is on
one side or the other of any border. It is conceivable that forwarders with
underprovisioned networks may try to obstruct deployment of Congestion
Exposure. </t>
<t hangText="The Receiver"> Receivers generally have an incentive to under-declare
congestion since they generally wish to receive the data from the sender as
rapidly as possible. <xref target="Savage"></xref> explains how a receiver can
significantly improve their throughput my failing to declare congestion. This
is a problem with or without Congestion Exposure. <xref target="KGao"></xref>
explains one possible technique to encourage receiver's to be honest in their
declaration of congestion.</t>
<t hangText="The Sender"> One proposed mechanism for Congestion Exposure deployment adds
a requirement for a sender to advise the network how much congestion it has
suffered or caused. Although most senders currently respond to congestion
they are informed of, one use of exposed congestion information might be to
encourage sources of persistent congestion to back off more aggressively.
Then clearly there may be an incentive for the sender to under-declare
congestion. This will be a particular problem with sources of flooding
attacks. "Policing" mechanisms have been proposed to deal with this. </t>
</list>
In addition there are potential problems from source spoofing. A malicious
sender can pretend to be another user by spoofing the source address.
Congestion Exposure allows for "Policers" and "Traffic Shapers" so as to be
robust against injection of false congestion information into the forward
path. </t>
</section>
<!-- ====================================================================== -->
<section title="IANA Considerations">
<t>This document does not require actions by IANA.</t>
</section>
<!-- ====================================================================== -->
<section title="Acknowledgments">
<t>Bob Briscoe is partly funded by Trilogy, a research project
(ICT-216372) supported by the European Community under its Seventh Framework Programme.
The views expressed here are those of the author only.</t>
<t> The authors would like to thank Contributing Authors Bernard Aboba,
João Taveira Araújo, Louise Burness, Alissa Cooper,
Philip Eardley, Michael Menth, and Hannes Tschofenig for their inputs to
this document. Useful feedback was also provided by Dirk Kutscher.</t>
</section>
<!-- ====================================================================== -->
</middle>
<back>
<references title="Normative References">
&RFC3168;
</references>
<references title="Informative References">
&RFC2309;
<?rfc include="reference.I-D.briscoe-tsvwg-re-ecn-tcp-motivation" ?>
<reference anchor="Re-Feedback" target="http://www.acm.org/sigs/sigcomm/sigcomm2005/techprog.html#session8">
<front>
<title> Policing Congestion Response in an Internetwork Using Re-Feedback </title>
<author initials="B" surname="Briscoe" fullname="Bob Briscoe">
<organization>BT & UCL</organization>
</author>
<author initials="A" surname="Jacquet" fullname="Arnaud Jacquet">
<organization>BT</organization>
</author>
<author initials="C" surname="Di Cairano-Gilfedder" fullname="Carla Di Cairano-Gilfedder">
<organization>BT</organization>
</author>
<author initials="A" surname="Salvatori" fullname="Alessandro Salvatori">
<organization>Eurécom & BT</organization>
</author>
<author initials="A" surname="Soppera" fullname="Andrea Soppera">
<organization>BT</organization>
</author>
<author initials="M" surname="Koyabe" fullname="Martin Koyabe">
<organization>BT</organization>
</author>
<date month="August" year="2005" />
</front>
<seriesInfo name="ACM SIGCOMM CCR" value="35(4)277—288" />
<format type='PDF' target='http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/2020comms/refb/refb_sigcomm05.pdf' />
</reference>
<reference anchor="LEDBAT">
- <front>
<title>Low Extra Delay Background Transport (LEDBAT)</title>
- <author initials="S" surname="Shalunov" fullname="Stanislav Shalunov">
<organization />
</author>
<date month="March" day="22" year="2010" />
- <abstract>
<t>LEDBAT is an alternative experimental congestion control algorithm. LEDBAT enables an advanced
networking application to minimize the extra delay it induces in the bottleneck while saturating the
bottleneck. It thus implements an end-to-end version of scavenger service. LEDBAT has been been
implemented in BitTorrent DNA, as the exclusive congestion control mechanism, and in uTorrent, as
an experimental mechanism, and deployed in the wild with favorable results.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-ledbat-congestion-01" />
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-ledbat-congestion-01.txt" />
</reference>
<reference anchor="Savage">
<front>
<title>TCP Congestion Control with a Misbehaving Receiver</title>
<author initials="S." surname="Savage" fullname="S. Savage">
<organization />
</author>
<author initials="D." surname="Wetherall" fullname="D. Wetherall">
<organization />
</author>
<author initials="T." surname="Anderson" fullname="T. Anderson">
<organization />
</author>
<date year="1999"/>
</front>
<seriesInfo name="ACM SIGCOMM Computer Communication Review" value=""></seriesInfo>
<format type="PDF" target="http://www.cs.ucsd.edu/~savage/papers/CCR99.pdf"></format>
</reference>
<reference anchor="KGao">
<front>
<title> Incrementally Deployable Prevention to TCP Attack with Misbehaving Receivers </title>
<author initials="K." surname="Gao" fullname="Kun Gar">
<organization> Computer Science Department, Carnegie Mellon University </organization>
</author>
<author initials="C. C." surname="Wang" fullname="Chengwen Chris Wang">
<organization> Computer Science Department, Carnegie Mellon University</organization>
</author>
<date month="December" day="14" year="2004"/>
</front>
<format type="PDF" target="http://www.cs.cmu.edu/~kgao/course/15744/network.pdf"/>
</reference>
<reference anchor="BB-incentive">
<front>
<title>The Broadband Incentive Problem</title>
<author><organization>MIT Communications Futures Program (CFP) </organization>
</author>
<author><organization>Cambridge University Communications Research Network</organization>
</author>
<date month="September" year="2005" />
</front>
<format type="PDF" target="http://cfp.mit.edu/docs/incentive-wp-sept2005.pdf" />
</reference>
<reference anchor='OfCom'>
<front>
<title>UK Broadband Speeds 2008: Research report</title>
<author >
<organization> Ofcom: Office of Communications</organization>
</author>
<date month='January' year='2009' />
</front>
<format type='PDF' target='http://www.ofcom.org.uk/research/telecoms/reports/bbspeed_jan09/bbspeed_jan09.pdf' />
</reference>
<reference anchor="Fair-use">
<front>
<title>Truth about 'fair usage' broadband</title>
<author>
<organization> Broadband Choices </organization>
</author>
<date year="2009"/>
</front>
<format type="HTML" target="http://www.broadbandchoices.co.uk/fair-usage-broadband.html"></format>
</reference>
<reference anchor="Fairer-faster">
<front>
<title>A Fairer Faster Internet Protocol</title>
<author initials="B" surname="Briscoe" fullname="Bob Briscoe">
<organization />
</author>
<date month="December" year="2008"/>
</front>
<seriesInfo name="IEEE Spectrum" value="Dec 2008 pp38-43"></seriesInfo>
<format type="HTML" target="http://spectrum.ieee.org/telecom/standards/a-fairer-faster-internet-protocol"></format>
</reference>
<reference anchor='Policing-freedom'>
<front>
<title>Policing Freedom to Use the Internet Resource Pool</title>
<author initials="B" surname="Briscoe" fullname="Bob Briscoe">
<organization>BT & UCL</organization>
</author>
<author initials="A" surname="Jacquet" fullname="Arnaud Jacquet">
<organization>BT</organization>
</author>
<author initials="T" surname="Moncaster" fullname="Toby Moncaster">
<organization>BT</organization>
</author>
<date month='December' day="4" year='2008' />
</front>
<seriesInfo name="RE-Arch 2008 hosted at the 2008 CoNEXT conference" value="" />
<format type='PDF' target='http://portal.acm.org/ft_gateway.cfm?id=1544083&type=pdf&coll=GUIDE&dl=GUIDE&CFID=94433196&CFTOKEN=11585540' />
</reference>
<reference anchor="Kelly" target="http://www.statslab.cam.ac.uk/~frank/rate.html">
<front>
<title>
Rate control for communication networks: shadow prices, proportional fairness and stability
</title>
<author initials="F.P" surname="Kelly" fullname="Frank P. Kelly">
<organization>Cam Uni</organization>
</author>
<author initials="A.K" surname="Maulloo" fullname="Aman K. Maulloo">
<organization>Cam Uni</organization>
</author>
<author initials="D.K.H" surname="Tan" fullname="David K. H. Tan">
<organization>Cam Uni</organization>
</author>
<date month="" year="1998" />
</front>
<seriesInfo name="Journal of the Operational Research Society" value="49(3) 237--252" />
<format type='PDF'
target='http://www.statslab.cam.ac.uk/~frank/rate.html' />
</reference>
<reference anchor="Malice" target="http://wesii.econinfosec.org/draft.php?paper_id=19">
<front>
<title>
Using Self Interest to Prevent Malice; Fixing the Denial of Service Flaw of the Internet
</title>
<author initials="B" surname="Briscoe" fullname="Bob Briscoe">
<organization>BT & UCL</organization>
</author>
<date year="2006" />
</front>
<seriesInfo name="WESII - Workshop on the Economics of Securing the Information Infrastructure" value="2006" />
<format type='PDF'
target='http://wesii.econinfosec.org/draft.php?paper_id=19' />
</reference>
<reference anchor="Design-Philosophy" >
<front>
<title>
The Design Philosophy of the DARPA Internet Protocols
</title>
<author initials="D.D." surname="Clarke" fullname="David D. Clarke">
<organization>MIT</organization>
</author>
<date year="1988" />
</front>
<format type='PDF'
target="http://groups.csail.mit.edu/ana/Publications/PubPDFs/The%20design%20philosophy%20of%20the%20DARPA%20internet%20protocols.pdf" />
</reference>
<reference anchor="QoS-Models" >
<front>
<title>
Commercial Models for IP Quality of Service Interconnect
</title>
<author initials="B" surname="Briscoe" fullname="Bob Briscoe">
<organization>BT & UCL</organization>
</author>
<author initials="S" surname="Rudkin" fullname="Steve Rudkin">
<organization>BT</organization>
</author>
<date month="April" year="2005" />
</front>
<seriesInfo name="BTTJ Special Edition on IP Quality of Service" value="vol 23 (2)"/>
<format type='PDF' target="http://bobbriscoe.net/projects/ipe2eqos/gqs/papers/ixqos_bttj05.pdf" />
</reference>
<reference anchor="re-ecn-motive">
- <front>
<title>Re-ECN: A Framework for adding Congestion Accountability to TCP/IP</title>
- <author initials="B" surname="Briscoe" fullname="Bob Briscoe">
<organization />
</author>
- <author initials="A" surname="Jacquet" fullname="Arnaud Jacquet">
<organization />
</author>
- <author initials="T" surname="Moncaster" fullname="T Moncaster">
<organization />
</author>
- <author initials="A" surname="Smith" fullname="Alan Smith">
<organization />
</author>
<date month="September" day="18" year="2009" />
-
</front>
<seriesInfo name="Internet-Draft" value="draft-briscoe-tsvwg-re-ecn-tcp-motivation-01" />
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-re-ecn-tcp-motivation-01.txt" />
</reference>
<reference anchor="Padhye">
- <front>
<title>Modeling TCP Throughput: A Simple Model and its Empirical Validation</title>
- <author initials="J" surname="Padhye" fullname="Jitendra Padhye">
<organization />
</author>
- <author initials="V" surname="Firoiu" fullname="Vicotor Firoiu">
<organization />
</author>
- <author initials="D" surname="Towsley" fullname="Don Towsley">
<organization />
</author>
- <author initials="J" surname="Kurose" fullname="Jim Kurose">
<organization />
</author>
<date month="May" day="30" year="1998" />
- </front>
<seriesInfo name="ACM SIGCOMM Computer Communications Review" value="Vol 28(4), pages 303-314" />
<format type="PDF" target="http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.143.9137&rep=rep1&type=pdf" />
</reference>
<reference anchor="ConEx-Abstract-Mech">
<front>
<title>Congestion Exposure (ConEx) Concepts and Abstract Mechanism</title>
- <author initials="B" surname="Briscoe" fullname="Bob Briscoe">
<organization />
</author>
<date month="October" day="18" year="2010" />
- <abstract>
<t>This document describes an abstract mechanism by which senders inform the network about the congestion
encountered by packets earlier in the same flow. Today, the network may signal congestion to the receiver
by ECN markings or by dropping packets, and the receiver may pass this information back to the sender in
transport-layer feedback. The mechanism to be developed by the ConEx WG will enable the sender to also
relay this congestion information back into the network in- band at the IP layer, such that the total level
of congestion is visible to all IP devices along the path, from where it could, for example, be provided as
input to traffic management.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-mathis-conex-abstract-mech-00" />
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-mathis-conex-abstract-mech-00.txt" />
</reference>
</references>
<section title="ConEx Architectural Elements" anchor="conex-uses-arch">
<t> ConEx is a simple concept that has revolutionary implications. It is that rare
thing — a truly disruptive technology, and as such it is hard to
imagine the variety of uses it may be put to. Before even thinking what it might be used
for we need to address the issue of how it can be used. This section describes
four architectural elements that can be placed in the network and which utilise
ConEx information to monitor or control traffic flows.
</t>
<t> In the following we are assuming the most abstract version of the
ConEx mechanism, namely that every packet carries two congestion fields, one for
upstream congestion and one for downstream. <xref target="ConEx-Abstract-Mech"></xref>
outlines one possible approach for this.</t>
<section title="ConEx Monitoring" anchor="conex-uses-monitor">
<t> One of the most useful things ConEx provides is the ability to monitor (and control) the
amount of congestion entering or leaving a network. With ConEx, each packet carries
sufficient information to work out the Upstream, Downstream and Total Congestion Volume
that packet is responsible for. This allows the overall Congestion Volume to be calculated at any point in the network.
In effect this gives a measure of how much excess traffic has been sent that was above the instantaneous
transmission capacity of the network. A 1 Gbps router that is 0.1% congested
implies that there is 1 Mbps of excess traffic at that point in time.</t>
<t>
The figure below shows 2 conceptual pieces of network equipment that utilise ConEx
information in order to monitor the flow of congestion through the network. The Border
Monitor sits at the border between two networks, while the Edge Monitor sits at the Ingress
or Egress to the Internetwork.
</t>
<figure anchor="simple_monitor_diag" title="Ingress, egress and border monitors">
<artwork><![CDATA[
,---. ,---.
,-----. / \ ,------. / \ ,------. ,-----.
| Src |--( Net A )-| B.M. |-( Net B )--| E.M. |--| Dst |
'-----` \ / '------` \ / '------` '-----`
'---` ^ '---` ^
Border Monitor Edge Monitor
NB, the Edge Monitor could also be at the Src end of the network
]]></artwork>
</figure>
<t>Note: In the tables below, ConEx-Enabled is as defined
in <xref target="conex-uses-defs"></xref> and ECN-enabled means any router that fully
enables Explicit Congestion Notification (ECN) as defined in
<xref target="RFC3168"></xref> and any relevant updates to that standard. </t>
<section title="Edge Monitoring">
<texttable anchor="conex-uses-edge-tab" title="Requirements for Edge Monitoring">
<ttcol align="center">Network Element</ttcol>
<ttcol align="center">ECN-Enabled?</ttcol>
<ttcol align="center">ConEx-Enabled?</ttcol>
<ttcol align="center">Notes</ttcol>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Sender</c>
<c>Yes, if ECN is used as basis for congestion signal</c>
<c>Yes, must be sending ConEx information</c>
<c>Must be receiving congestion feedback</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Sender's Network</c>
<c>ECN would be beneficial</c>
<c>Should understand ConEx markings</c>
<c>NB, it doesn't have to be fully ConEx-Enabled</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Core Network</c>
<c>ECN would be beneficial</c>
<c>Needn't understand ConEx</c>
<c>ConEx markings must get through the network</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Receiver's Network</c>
<c>ECN would be beneficial</c>
<c>Should understand ConEx markings</c>
<c>Deosn't have to be fully ConEx-Enabled</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Receiver</c>
<c>Only needed if network is ECN-Enabled</c>
<c>Should understand ConEx</c>
<c>Has to feedback the congestion it sees (either ECN or drop)</c>
</texttable>
<t>Edge Monitors are ideally positioned to verify the accuracy of ConEx 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.</t>
</section>
<section title="Border Monitoring">
<texttable anchor="conex-uses-bdr-mon-tab" title="Requirements for Border Monitoring">
<ttcol align="center">Network Element</ttcol>
<ttcol align="center">ECN-Enabled?</ttcol>
<ttcol align="center">ConEx-Enabled?</ttcol>
<ttcol align="center">Notes</ttcol>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Sender</c>
<c>Must be ECN-enabled if any of the network is</c>
<c>Yes, must be sending ConEx information</c>
<c>Must receive accurate congestion feedback</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Sender's Network</c>
<c>ECN should be enabled</c>
<c>Should understand ConEx markings</c>
<c>Ideally would be ConEx-Enabled</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Core Network</c>
<c>ECN should be enabled</c>
<c>Should understand ConEx markings</c>
<c>Ideally would be ConEx-Enabled</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Receiver's Network</c>
<c>ECN should be enabled</c>
<c>Should understand ConEx markings</c>
<c>Ideally would be ConEx-Enabled</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Receiver</c>
<c>Must be ECN-enabled if any of the network is</c>
<c>Must be ConEx enabled</c>
<c>Receiver has to feedback the congestion it sees</c>
</texttable>
<t>
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.</t>
</section>
</section>
<section title="ConEx Policing" anchor="conex-uses-policing">
<t>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 <xref target="Policing-freedom"></xref> and <xref target="re-ecn-motive"></xref>,
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.
</t>
<figure anchor="simple_police_diag" title="Ingress, egress and border policers">
<artwork><![CDATA[
,---. ,---.
+-----+ +------+ / \ +------+ / \ +------+ +-----+
| Src |--| I.P. |--( Net A )-| B.P. |-( Net B )--| E.P. |--| Dst |
+-----+ +------+ \ / +------+ \ / +------+ +-----+
^ '---` ^ '---` ^
Ingress Policer Border Policer Egress Policer
]]></artwork>
</figure>
<section title="Egress Policing">
<texttable anchor="conex-uses-egr-pol-tab" title="Egress Policer Requirements">
<ttcol align="center">Network Element</ttcol>
<ttcol align="center">ECN-Enabled?</ttcol>
<ttcol align="center">ConEx-Enabled?</ttcol>
<ttcol align="center">Notes</ttcol>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Sender</c>
<c>The sender should be ECN-enabled if any of the network is</c>
<c>Must be ConEx-Enabled</c>
<c>Must be receiving congestion feedback</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Sender's Network</c>
<c>ECN is optional but beneficial</c>
<c>ConEx is optional</c>
<c>ConEx would enable them to do Ingress Policing (see later)</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Core Network</c>
<c>ECN is optional but beneficial</c>
<c>Not needed</c>
<c>ConEx marks must survive crossing the network</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Receiver's Network</c>
<c>ECN is optional but beneficial</c>
<c>Must fully understand ConEx</c>
<c>Each receiver needs an Egress Policer</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Receiver</c>
<c>Should be ECN-enabled if any of the network is</c>
<c>Should understand ConEx</c>
<c>Must feedback the congestion it sees. ConEx may have a compatibility
mode if the receiver is not ConEx-Enabled</c>
</texttable>
<t>
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.
</t>
</section>
<section title="Ingress Policing">
<texttable anchor="conex-uses-ingr-pol-tab" title="Ingress Policer Requirements">
<ttcol align="center">Network Element</ttcol>
<ttcol align="center">ECN-Enabled?</ttcol>
<ttcol align="center">ConEx-Enabled?</ttcol>
<ttcol align="center">Notes</ttcol>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Sender</c>
<c>Should be ECN-enabled</c>
<c>Must be ConEx-enabled</c>
<c>Must be receiving congestion feedback</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Sender's Network</c>
<c>ECN is optional but beneficial</c>
<c>Must understand ConEx</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Core Network</c>
<c>ECN is optional but beneficial</c>
<c>Needn't understand ConEx</c>
<c>ConEx markings must survive crossing the network</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Receiver's Network</c>
<c>ECN is optional but beneficial</c>
<c>Needn't understand ConEx</c>
<c>ConEx markings must survive crossing the network</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Receiver</c>
<c>Should be ECN-enabled if any of the network is</c>
<c>Should be ConEx-Enabled</c>
<c>Must feedback the congestion it sees. ConEx may have a compatibility
mode if the receiver is not ConEx-Enabled</c>
</texttable>
<t>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 <xref target="Policing-freedom"></xref>.
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. </t>
</section>
<section title="Border Policing">
<texttable anchor="conex-uses-bdr-pol-tab" title="Border Policer Requirements">
<ttcol align="center">Network Element</ttcol>
<ttcol align="center">ECN-Enabled?</ttcol>
<ttcol align="center">ConEx-Enabled?</ttcol>
<ttcol align="center">Notes</ttcol>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Sender</c>
<c>ECN should be enabled</c>
<c>Must be ConEx-enabled</c>
<c>Must receive accurate congestion feedback</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Sender's Network</c>
<c>ECN is optional but beneficial</c>
<c>Must be ConEx-enabled</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Core Network</c>
<c>ECN is optional but beneficial</c>
<c>Should be ConEx-Enabled</c>
<c>Must be ConEx-Enabled if it is doing the policing. At a minimum
must pass ConEx markings unaltered</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Receiver's Network</c>
<c>ECN is optional but beneficial</c>
<c>Should be ConEx-Enabled</c>
<c>At a minimum must pass ConEx markings unaltered</c>
<c></c>
<c></c>
<c></c>
<c></c>
<c>Receiver</c>
<c>Should be ECN-Enabled if any of the network is</c>
<c>Should be ConEx-Enabled</c>
<c>Must feedback the congestion it sees. ConEx may have a compatibility
mode if the receiver is not ConEx-Enabled</c>
</texttable>
<t>
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 <xref target="conex-uses-ddos"></xref>).
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)</t>
</section>
</section>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 19:44:08 |