One document matched: draft-briscoe-conex-initial-deploy-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?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">
<rfc category="info" docName="draft-briscoe-conex-initial-deploy-01"
ipr="trust200902">
<front>
<title abbrev="Initial ConEx Deployment Examples">Initial Congestion
Exposure (ConEx) Deployment Examples</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>
<date day="24" month="November" year="2011" />
<area>Transport Area</area>
<workgroup>ConEx</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document gives examples of how ConEx deployment might get
started, focusing on unilateral deployment by a single network.</t>
</abstract>
</front>
<middle>
<!-- ====================================================================== -->
<section anchor="conex-uses-intro" title="Introduction">
<t>This document gives examples of how ConEx deployment might get
started, focusing on unilateral deployment by a single network.</t>
<t></t>
</section>
<!--====================================================================== -->
<section title="Recap: Incremental Deployment Features of the ConEx Protocol">
<t>The ConEx mechanism document <xref
target="ConEx-Abstract-Mech"></xref> goes to great lengths to design for
incremental deployment in all the respects below. It should be referred
to for precise details on each of these points:<list style="symbols">
<t>The ConEx mechanism is essentially a change to the source, in
order to re-insert congestion feedback into the network.</t>
<t>Source-host-only deployment is possible without any negotiation
required, and individual transport protocol implementations within a
source host can be updated separately.</t>
<t>Receiver modification may optionally improve ConEx for some
transport protocols with feedback limitations (TCP being the main
example), but it is not a necessity</t>
<t>Proxies for the source and/or receiver are feasible (though not
necessarily straightforward)</t>
<t>Queues and network forwarding do not require any modification for
ConEx.</t>
<t>ECN is not required in the network for ConEx. If some network
nodes support ECN, it can be used by ConEx.</t>
<t>ECN is not required at the receiver for ConEx. The sender should
nonetheless attempt to negotiate ECN-usage with the receiver, given
some aspects of ConEx work better the more ECN is deployed,
particularly auditing and border measurement.</t>
<t>Given ConEx exposes information for IP-layer policy devices to
use, the design does not preclude possible innovative uses of ConEx
information by other IP-layer devices, e.g. forwarding itself</t>
<t>Packets indicate whether or not they support ConEx.</t>
</list></t>
</section>
<!-- ====================================================================== -->
<section title="ConEx Components">
<t></t>
<section title="Recap of Basic ConEx Components">
<t><xref target="ConEx-Abstract-Mech"></xref> introduces the following
components:<list style="symbols">
<t>The ConEx Wire Protocol</t>
<t>Forwarding devices (unmodified)</t>
<t>Sender (modified for ConEx)</t>
<t>Receiver (optionally modified)</t>
<t>Audit</t>
<t>Policy Devices:<list style="symbols">
<t>Rest-of-Path Congestion Monitoring Devices</t>
<t>Congestion Policers</t>
</list></t>
</list><xref target="ConEx-Abstract-Mech"></xref> should be referred
to for definitions of each of these components and further
explanation.</t>
</section>
<section anchor="conex-uses-deploy-concepts"
title="Per-Network Deployment Concepts">
<t>Network deployment-related definitions:<list style="hanging">
<t hangText="Internet Ingress:">The first IP 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="Internet Egress:">The last IP node a packet traverses
before reaching the receiver's network.</t>
<t hangText="ConEx-Enabled Network:">A network whose edge nodes
implement ConEx policy functions.</t>
</list></t>
<t>Each network can unilaterally choose to use any ConEx information
given by those sources using ConEx, independently of whether other
networks use it.</t>
<t>Typically, a network will use ConEx information by deploying a
policy function at the ingress edge of its network to monitor arriving
traffic and to act in some way on the congestion information in those
packets that are ConEx-enabled. Actions might include policing,
altering the class of service, or re-routing. Alternatively, less
direct actions via a management system might include triggering
capacity upgrades, triggering penalty clauses in contracts or levying
charges between networks based on ConEx measurements.</t>
<t>Typically, a network using ConEx info will deploy a ConEx policy
function near the ingress edge and a ConEx audit function near the
egress edge. The segment of the path between a ConEx policy function
and a ConEx audit function can be considered to be a ConEx-protected
segment of the path. Assuming a network covers all its ingresses and
egresses with policy functions and audit functions respectively, the
network within this ring will be a ConEx-protected network.</t>
<t>Of course, because each edge device usually serves as both an
ingress and an egress, the two functions are both likely to be present
in each edge device.</t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="conex-uses-deployments"
title="Example Initial Deployment Arrangements">
<t>In all the deployment scenarios below, we assume that deployment
starts with some data sources being modified with ConEx code. The
rationale for this is that the developer of a scavenger transport
protocol like LEDBAT has a strong incentive to tell the network how
little congestion it is causing despite sending large volumes of data.
In this case the developer makes the first move expecting it will prompt
at least some networks to move in response—so that they use the
ConEx information to reward users of the scavenger protocol.</t>
<section anchor="conex-uses-single-net-scenario"
title="Single Receiving Network Scenario">
<t>The name 'Receiving Network' for this scenario merely emphasises
that most data is arriving from connected networks and data centres
and being consumed by residential customers on this access network.
Some data is of course also travelling in the other direction.</t>
<figure anchor="Fig_1RNet_Scenario"
title="Single Receiving Network Scenario">
<artwork><![CDATA[ DSLAMs __
/|/ ,-.Home-a
__/__| |-----( )
,-----. / \ | |--- `-'
,---. / \ ,------P/ \|\__
/ \ ' Core '/| BRAS | __
( Peer )-->-|P | '------' /|/
\ / | | _____| |---
'---` ' '\,------./ | |---
\ M / |BRAS | \|\__
`-----' '------A\ __
| P| \ /|/
/|\ /|\ \__\_| |--- ,-.
,---. ,---. / | |-----( )
/Data \ / \ \|\__ `-'Home-b
( Centre) ( CDN )
\ / \ / Access Network
'---` '---` <------------->
]]></artwork>
<postamble>P=Congestion-Policer; M=Congestion-Monitor; A=Audit
function</postamble>
</figure>
<t>Figure <xref target="Fig_1RNet_Scenario"></xref> is an attempt to
show the salient features of a ConEx deployment in a typical broadband
access provider's network (within the constraints of ASCII art).
Broadband remote access servers (BRASs) control access to the core
network from the access network and vice versa. Home networks (and
small businesses) connect to the access network, but only two are
shown.</t>
<t>In this diagram, all data is travelling towards the access network
of Home-b, from the Peer network, the Data centre, the CDN and Home-a.
Data actually travels in both directions on all links, but only one
direction is shown.</t>
<t>The data centre, core and access network are all run by the same
network operator, but each is the responsibility of a different
department with internal accounting between them. The content
distribution network (CDN) is operated by a third party CDN provider,
and of course the peer network is also operated by a third party.</t>
<t>This operator of the data centre, core and access network is the
only one in the diagram to have deployed ConEx monitoring and policy
devices at the edges of its network. However, it has not enabled ECN
on any of its network elements and neither has any other network in
the diagram. The operator has deployed a congestion policing function
(P) on the provider-edge router where the peer attaches to its core,
on the BRAS where the CDN attaches and on the other BRAS where each of
the residential customers like Home-a attach. On the provider-edge
router where the data centre attaches it has deployed a congestion
monitoring function (M). Each of these policing and monitoring
functions handles the aggregate of all traffic traversing it, for all
destinations.</t>
<t>The operator has deployed an audit function on each logical output
port of the BRAS for each end-customer site like Home-b. The Audit
function handles the aggregate of all traffic for that end-customer
from all sources. For traffic in the opposite direction (e.g. from
Home-b to Home-a, there would be equivalent policing (P) and audit (A)
functions in the converse locations to those shown.</t>
<t>Some content sources in the CDN and in the data centre are using
the ConEx protocol, but others are not. There is a similar situation
for hosts attached to the Peer network and hosts in home networks like
Home-a: some are sending ConEx packets at least for bulk data
transports, while others are not.</t>
<section title="ConEx Functions in the Single Receiving Network Scenario">
<t>Within the BRAS there are logical ports that model the rate of
each access line from the DSLAM to each home network <xref
target="TR-059"></xref>. They are fed by a shared queue that models
the rate of the downstream link from the BRAS to the DSLAM
(sometimes called the backhaul network). If there is congestion
anywhere in the set of networks in Figure <xref
target="Fig_1RNet_Scenario"></xref> it is nearly always:<list
style="symbols">
<t>either self-congestion in the queues into the logical ports
representing the access lines</t>
<t>or shared congestion in the shared queue on the BRAS that
feeds them.</t>
</list>Any ConEx sources sending data through this BRAS will
receive feedback about these losses from the destination and
re-insert it as ConEx markings into the data. <xref
target="Fig_Ex_Plot_Loss"></xref> shows an example plot of the loss
levels that might be seen at different monitoring points along a
path between the data centre and home-b, for instance. The top half
of the figure shows the loss probability within the BRAS consists of
0.1% at the shared queue and 0.2% self-congestion in the logical
output port that models the access line, making 0.3% in total. This
upper diagram also shows whole path congestion as signalled by the
ConEx sender, which remains unchanged along the whole path at
0.3%.</t>
<t>The lower half of the figure shows (downstream congestion) =
(whole path) - (upstream congestion). Upstream congestion can only
be monitored locally where the loss actually happens (within the
BRAS output queues). Nonetheless, given there is rarely loss
anywhere else but within the BRAS, this limitation is not
significant in this scenario. The lower half of the figure also
shows the location of the policing and audit functions. Policing
anywhere within or upstream ofthe BRAS will be based on the
downstream congestion level of 0.3%. While Auditing within the BRAS
but after all the queues can check that the whole path congestion
signalled by ConEx is no less than the loss levels experienced
within the BRAS itself.</t>
<figure anchor="Fig_Ex_Plot_Loss"
title="Example plot of loss levels along a path">
<artwork><![CDATA[
Data centre-->|<--core-->|<------BRAS--------->|<--Home--
| |
^loss |<-Shared->|<-Access->|
|probability backhaul
|
0.3%|- - - - - - - - - - - - - - - - - - - - +-----------------
| whole path congestion |
| |
| |upstream
0.1%| +---------+congestion
| |
-O==============================+----------------------------->
monitoring point
^loss
|probability Policing Audit
| | |
| V |
0.3%|----------------O-------------+ |
| |downstream |
0.2%| +---------+ |
| congestion| |
| | |
| | V
-O----------------------------------------+====O============-->
monitoring point
]]></artwork>
</figure>
<t></t>
</section>
<section title="Incentives to Unilaterally Deploy ConEx in a Receiving Network">
<t>Even a sending application that is modified to use ConEx can
choose whether to send ConEx or Not-ConEx packets. Nonethelss, ConEx
packets bring information to a policer about congestion expected on
the rest of the path beyond the policer. Not-ConEx packets bring no
such information. Therefore a network that has deployed ConEx
policers will tend to rate-limit not-ConEx packets conservatively in
order to manage the unknown risk of congestion. In contrast, a
network doesn't normally need to rate-limit ConEx-enabled packets
unless they reveal a persistently high contribution to congestion.
This natural tendency for networks to favour senders that provide
ConEx information encourages senders to choose to use the ConEx
protocol whenever they can.</t>
<t>{ToDo: complete this section}</t>
</section>
</section>
<section anchor="conex-uses-other-deployments"
title="Mobile Network Scenario">
<t>Placeholder for summary of the scenario in a mobile network
described in <xref target="conex-mobile"></xref></t>
<t>In mobile networks, both mobile terminals and mobile network
equipment are standardised by the 3GPP. If the 3GPP were to adopt the
ConEx protocol, it might mandate ConEx implementation for compliant
equipment.</t>
<t>{ToDo: Describe how a central traffic management box can arrange to
remotely view upstream congestion as it would be seen from the
interface with the mobile terminal.}</t>
</section>
<section title="Scenario Internal to a Multi-Tenant Data Centre">
<t>A number of companies offer hosting of virtual machines on their
data centre infrastructure—so-called infrastructure as a service
(IaaS). A set amount of processing power, memory, storage and network
are offered. Although processing power, memory and storage are
relatively simple to allocate on the 'pay as you go' basis that has
become common, the network is less easy to allocate given it is a
naturally distributed system.</t>
<t>{ToDo: Complete this section.}</t>
</section>
</section>
<!-- ====================================================================== -->
<section title="Security Considerations"></section>
<!-- ====================================================================== -->
<section title="IANA Considerations">
<t>This document does not require actions by IANA.</t>
</section>
<!-- ====================================================================== -->
<section title="Conclusions">
<t>{ToDo}</t>
<t></t>
</section>
<!-- ====================================================================== -->
<section title="Acknowledgments">
<t></t>
</section>
<!-- ====================================================================== -->
</middle>
<back>
<references title="Informative References">
<reference anchor="ConEx-Abstract-Mech">
<front>
<title>Congestion Exposure (ConEx) Concepts and Abstract
Mechanism</title>
<author fullname="Matt Mathis" initials="M" surname="Mathis">
<organization>Google</organization>
</author>
<author fullname="Bob Briscoe" initials="B" surname="Briscoe">
<organization>BT</organization>
</author>
<date day="31" month="October" year="2011" />
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-conex-abstract-mech-03" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-conex-abstract-mech-03.txt"
type="TXT" />
</reference>
<reference anchor="conex-mobile">
<front>
<title>Mobile Communication Congestion Exposure Scenario</title>
<author fullname="Dirk Kutscher" initials="D" surname="Kutscher">
<organization></organization>
</author>
<author fullname="Faisal Mir" initials="F" surname="Mir">
<organization></organization>
</author>
<author fullname="Rolf Winter" initials="R" surname="Winter">
<organization></organization>
</author>
<author fullname="Suresh Krishnan" initials="S" surname="Krishnan">
<organization></organization>
</author>
<author fullname="Ying Zhang" initials="Y" surname="Zhang">
<organization></organization>
</author>
<date day="7" month="March" year="2011" />
<abstract>
<t>This memo describes a mobile communications use case for
congestion exposure (CONEX) with a particular focus on mobile
communication networks such as 3GPP LTE. The draft describes the
architecture of these networks (access and core networks), current
QoS mechanisms and then discusses how congestion exposure concepts
could be applied. Based on this, this memo suggests a set of
requirements for CONEX mechanisms that particularly apply to
mobile networks.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-kutscher-conex-mobile-00" />
<format target="http://www.ietf.org/internet-drafts/draft-kutscher-conex-mobile-00.txt"
type="TXT" />
</reference>
<reference anchor="TR-059">
<front>
<title>DSL Forum Technical Report TR-059: Requirements for the
Support of QoS-Enabled IP Services</title>
<author fullname="Tom Anschutz" initials="T." role="editor"
surname="Anschutz">
<organization>BellSouth Telecommunications</organization>
</author>
<date month="September" year="2003" />
</front>
<format target="http://www.broadband-forum.org/technical/download/TR-059.pdf"
type="PDF" />
</reference>
<reference anchor="Seawall"
target="http://research.microsoft.com/en-us/projects/seawall/">
<front>
<title>Seawall: Performance Isolation in Cloud Datacenter
Networks</title>
<author fullname="Alan Shieh" initials="A" surname="Shieh">
<organization>Microsoft and Cornell Uni</organization>
</author>
<author fullname="Srikanth Kandula" initials="S" surname="Kandula">
<organization>Microsoft</organization>
</author>
<author fullname="Albert Greenberg" initials="A" surname="Greenberg">
<organization>Microsoft</organization>
</author>
<author fullname="Changhoon Kim" initials="C" surname="Kim">
<organization>Microsoft</organization>
</author>
<date month="June" year="2010" />
</front>
<seriesInfo name="Proc 2nd USENIX Workshop on Hot Topics in Cloud Computing"
value="" />
<format target="http://www.usenix.org/event/nsdi11/tech/full_papers/Shieh.pdf"
type="PDF" />
</reference>
</references>
<section title="Summary of Changes between Drafts">
<t>Detailed changes are available from
http://tools.ietf.org/id/draft-briscoe-conex-initial-deploy-00.txt</t>
<t><list style="hanging">
<t hangText="From draft-briscoe-00 to draft-briscoe-01:">Re-issued
without textual change. Merely re-submitted to correct a processing
error causing the whole text of draft-00 to be duplicated within the
file.</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 13:58:01 |