One document matched: draft-briscoe-conex-initial-deploy-03.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-03"
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="16" month="July" year="2012" />
<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 (currently only specified for IPv6
<xref target="conex-destopt"></xref>, although a possible way to
fit ConEx into the IPv4 header has been described <xref
target="intarea-ipv4-id-reuse"></xref>)</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 (using
information from the ConEx wire protocol)</t>
<t>Congestion Policers (using rest-of-path congestion
monitoring)</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>
<t>The goal of all these ConEx elements for this scenario is to expose
information about congestion on the whole-path to a
congestion-policer. A congestion-policer is nearly identical to a
traditional token-bucket-based bit-rate policer except the tokens it
fills with arrive at a rate that represents the volume of congestion
that the customer is allowed to contribute to over time and tokens
drain from the bucket at a rate dependent on the ConEx signals
representing rest-of-path congestion. <xref target="CongPol"></xref>
introduces congestion-policing and <xref
target="conex-concepts-uses"></xref> explains the benefits of policing
based on congestion-volume compared to methods like weighted
round-robin traditionally used in a BRAS.</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
residential access network scenario, for traffic from a home this
is the first IP-aware node after the home access equipment. For
Internet access from 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>, <xref target="TR-101"></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. Nonetheless,
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>In particular, high volume sources have the most incentive to
deploy ConEx. This is because high volume sources (e.g. video
download sites or peer-to-peer file-sharing) can gain by
implementing a low 'weight' end-to-end transport (i.e. a less
aggressive response to congestion than other transports). Then,
although they send a large amount of volume, they need not
contribute significantly to congestion. If the ISP currently limits
data volume, or offers chargeable tiers based on data volume, such
customers stand to gain considerably if they can encourage the ISP
to limit usage based on congestion-volume instead of volume. </t>
<t><xref target="idepl_Fig_weighted"></xref> explains why this is
the case. The plots show bit-rate on the vertical axis and time
horizontally. A file transfer (e.g. the one labelled from customer
'b') is given a simplified representation as a rectangle, implying
it runs at a set rate for a time, then completes. The maximum height
of each plot represents the maximum capacity of the shared link
across the backhaul network, which is typically the bottleneck in a
broadband network. The hatched regions represent unused capacity.
'c' represents the high volume source that we intend to show has an
incentive to deploy ConEx.</t>
<t>In the upper half of the figure, customers 'b' & 'c' both use
transports with equal weights, which is why they are shown with
equal rates when they both compete for the capacity of the line. 'c'
sends larger files than 'b', so when 'b' completes each of its file,
'c' can use the full capacity of the line until 'b' starts the next
file. In the lower half of the figure, 'c' uses a less aggressive
(lower weight) transport, so whenever 'b' sends a file, 'c' yields
more of its rate. This allows 'b' to complete its transfer earlier,
so that 'c' can take up the full rate earlier. 'b' sends the same
volume files (same area in the graph), just faster and therefore
they complete sooner (tall & thin instead of shorter and wider).
As a result, 'c' hardly finishes any later than in the upper
diagram. However, 'c' will have contributed much less to congestion,
and 'b' completes the majority of its file transfers much faster.
'b' has also contributed less to congestion.</t>
<t>As we have said, customer 'c' in particular stands to gain if the
ISP bases usage-limits (or usage charges) on congestion-volume
rather than volume. The ISP also has a strong incentive to reward
customers like 'c', because they make the network performance appear
far better than before for customer's like 'b' (e.g. short Web
transfers). However, the network cannot make this move until
customers like 'c' expose congestion information (ConEx) that the
ISP can use in its traffic management or contracts.</t>
<figure anchor="idepl_Fig_weighted"
title="Weighted congestion controls with equal weights (upper) and unequal (lower)">
<artwork><![CDATA[
^ bit-rate
|
|---------------------------------------------------.--,--.--,-------
| |/\| |\/|
| c |\/| b|/\| c
|------. ,-----. ,-----. ,-----. ,-----. ,-----./\| |\/| ,----
| b | | b | | b | | b | | b | | b |\/| |/\| | b
| | | | | | | | | | | |/\| |\/| |
+------'--'-----'--'-----'--'-----'--'-----'--'-----'--'--'--'--'---->
time
^ bit-rate
|
|---------------------------------------------------.--,--.--,-------
|---. ,---. ,---. ,---. ,---. ,---. |/\| |\/| ,---.
| | | | | | c | | | | | | |\/| b|/\| c| |
| | | | | | | | | | | | |/\| |\/| | |
| b | | b | | b | | b | | b | | b | |\/| |/\| | b |
| | | | | | | | | | | | |/\| |\/| | |
+---'-----'---'----'---'----'---'----'---'----'---'-'--'--'--'--'---'>
time
]]></artwork>
</figure>
<t>Of course, in reality there would be more than two customers. But
this would mean that short transfers like 'b' stand to gain even
more, as multiple larger files would be yielding at once.</t>
<t>We should point out that not all high-volume customers will be
prepared to temporarily shift their usage out of the way as shown
— real-time video for instance would still use a higher weight
(more aggressive) so as to ensure timely delivery. However, high
volume applications with elastic (non-real-time) requirements are
also common (e.g. video streaming, software downloads, etc)</t>
<t>We should also point out that a transport that is less agressive
against other customers is similar but not quite the same as LEDBAT
<xref target="ledbat-congestion"></xref>. LEDBAT does indeed yield
more to other flows during congestion, but it is designed to only do
this if the contention for resources is at a slow link, such as the
customer's own home router. If the contention is at a fast link,
such as a BRAS, LEDBAT is designed not to yield. This is because
ISPs currently give no reward to a transport that minimises
congestion to others — because they do not have the congestion
information to be able to.</t>
</section>
</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>This document has introduced how congestion policing could be
deployed at the broadband remote access servers in a typical broadband
access network. Congestion policing uses ConEx markings introduced by
data sources and packets discarded by the BRAS to determine rest-of-path
congestion, and police traffic accordingly. </t>
<t>It has been shown that high-volume elastic data sources have a strong
incentive to deploy ConEx speculatively in the expectation that they
will be able to encourage their ISPs to account for their usage by
congestion-volume, not volume. They can use a less aggressive transport
and prove that they are contributing little to congestion despite
sending a lot of volume. ISPs also have a strong incentive to use this
ConEx information to encourage their elastic high-volume customers to
use less agressive transports, given they improve the performance of all
the other customers. </t>
<t>Without ConEx information, ISPs can only use volume as a metric of
usage, which prevents the above virtuous circle from forming, perversely
discouraging high-volume elastic customers from such friendly
behaviour.</t>
</section>
<!-- ====================================================================== -->
<section title="Acknowledgments">
<t></t>
</section>
<!-- ====================================================================== -->
<section anchor="idepl_Comments_Solicited" title="Comments Solicited">
<t>Comments and questions are encouraged and very welcome. They can be
addressed to the IETF Congestion Exposure (ConEx) working group's
mailing list <conex@ietf.org>, and/or to the authors.</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="16" month="July" year="2012" />
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-conex-abstract-mech-05" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-conex-abstract-mech-05.txt"
type="TXT" />
</reference>
<reference anchor="conex-concepts-uses">
<front>
<title>ConEx Concepts and Use Cases</title>
<author fullname="Bob Briscoe" initials="B" surname="Briscoe">
<organization></organization>
</author>
<author fullname="Richard Woundy" initials="R" surname="Woundy">
<organization></organization>
</author>
<author fullname="Alissa Cooper" initials="A" surname="Cooper">
<organization></organization>
</author>
<date day="2" month="March" year="2012" />
<abstract>
<t>This document provides the entry point to the set of
documentation about the Congestion Exposure (ConEx) protocol. It
explains the motivation for including a ConEx marking at the IP
layer: to expose information about congestion to network nodes.
Although such information may have a number of uses, this document
focuses on how the information communicated by the ConEx marking
can serve as the basis for significantly more efficient and
effective traffic management than what exists on the Internet
today.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-conex-concepts-uses-04" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-conex-concepts-uses-04.txt"
type="TXT" />
</reference>
<reference anchor="conex-destopt">
<front>
<title>IPv6 Destination Option for Conex</title>
<author fullname="Suresh Krishnan" initials="S" surname="Krishnan">
<organization></organization>
</author>
<author fullname="Mirja Kuehlewind" initials="M"
surname="Kuehlewind">
<organization></organization>
</author>
<author fullname="Carlos Ucendo" initials="C" surname="Ucendo">
<organization></organization>
</author>
<date day="12" month="March" year="2012" />
<abstract>
<t>Conex is a mechanism by which senders inform the network about
the congestion encountered by packets earlier in the same flow.
This document specifies an IPv6 destination option that is capable
of carrying conex markings in IPv6 datagrams.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-conex-destopt-02" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-conex-destopt-012txt"
type="TXT" />
</reference>
<reference anchor="intarea-ipv4-id-reuse">
<front>
<title>Reusing the IPv4 Identification Field in Atomic
Packets</title>
<author fullname="Bob Briscoe" initials="B" surname="Briscoe">
<organization></organization>
</author>
<date day="12" month="March" year="2012" />
<abstract>
<t>This specification takes a new approach to extensibility that
is both principled and a hack. It builds on recent moves to
formalise the increasingly common practice where fragmentation in
IPv4 more closely matches that of IPv6. The large majority of IPv4
packets are now 'atomic', meaning indivisible. In such packets,
the 16 bits of the IPv4 Identification (IPv4 ID) field are
redundant and could be freed up for the Internet community to put
to other uses, at least within the constraints imposed by their
original use for reassembly. This specification defines the
process for redefining the semantics of these bits. It uses the
previously reserved control flag in the IPv4 header to indicate
that these 16 bits have new semantics. Great care is taken
throughout to ease incremental deployment, even in the presence of
middleboxes that incorrectly discard or normalise packets that
have the reserved control flag set.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-briscoe-intarea-ipv4-id-reuse-01" />
<format target="http://www.ietf.org/internet-drafts/draft-briscoe-intarea-ipv4-id-reuse-01.txt"
type="TXT" />
</reference>
<reference anchor="ledbat-congestion">
<front>
<title>Low Extra Delay Background Transport (LEDBAT)</title>
<author fullname="Greg Hazel" initials="G" surname="Hazel">
<organization></organization>
</author>
<author fullname="Janardhan Iyengar" initials="J" surname="Iyengar">
<organization></organization>
</author>
<author fullname="Mirja Kuehlewind" initials="M"
surname="Kuehlewind">
<organization></organization>
</author>
<author fullname="Stanislav Shalunov" initials="S"
surname="Shalunov">
<organization></organization>
</author>
<date day="31" month="October" year="2011" />
<abstract>
<t>LEDBAT is an experimental delay-based congestion control
algorithm that attempts to utilize the available bandwidth on an
end-to-end path while limiting the consequent increase in queueing
delay on the path. LEDBAT uses changes in one-way delay
measurements to limit congestion that the flow itself induces in
the network. LEDBAT is designed for use by background
bulk-transfer applications; it is designed to be no more
aggressive than TCP congestion control and to yield in the
presence of any competing flows when latency builds, thus limiting
interference with the network performance of the competing
flows.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft"
value="draft-ietf-ledbat-congestion-09" />
<format target="http://www.ietf.org/internet-drafts/draft-ietf-ledbat-congestion-09.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="TR-101">
<front>
<title>Migration to Ethernet-Based DSL Aggregation</title>
<author fullname="Amit Cohen" initials="A." role="editor"
surname="Cohen">
<organization>ECI Telecom</organization>
</author>
<author fullname="Ed Shrum" initials="E." role="editor"
surname="Shrum">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date month="April" year="2006" />
</front>
<format target="http://www.broadband-forum.org/technical/download/TR-101.pdf"
type="PDF" />
</reference>
<reference anchor="CongPol"
target="http://bobbriscoe.net/projects/refb/#polfree">
<front>
<title>Policing Freedom to Use the Internet Resource Pool</title>
<author fullname="Arnaud Jacquet" initials="A" surname="Jacquet">
<organization>BT</organization>
</author>
<author fullname="Bob Briscoe" initials="B" surname="Briscoe">
<organization>BT & UCL</organization>
</author>
<author fullname="Toby Moncaster" initials="T" surname="Moncaster">
<organization>BT</organization>
</author>
<date month="December" year="2008" />
</front>
<seriesInfo name="Proc ACM Workshop on Re-Architecting the Internet (ReArch'08)"
value="" />
<format target="http://www.bobbriscoe.net/projects/2020comms/refb/policer_rearch08.pdf"
type="PDF" />
</reference>
</references>
<section title="Summary of Changes between Drafts">
<t>Detailed changes are available from
http://tools.ietf.org/html/draft-briscoe-conex-initial-deploy</t>
<t><list style="hanging">
<t hangText="From draft-briscoe-02 to draft-briscoe-03:"><list
style="symbols">
<t>Removed Mobile and Data Centre scenarios, making this draft
solely cover the receiving access network scenario. It then
becomes a 'sibling' of the drafts on these two subjects, rather
than a 'parent'</t>
<t>Consequently Dirk Kutscher is no longer a co-author</t>
<t>Included more comprehensive background information on
ConEx</t>
<t>Completed Incentives section</t>
<t>Updated refs</t>
</list></t>
<t hangText="From draft-briscoe-01 to draft-briscoe-02:"><list
style="symbols">
<t>Added Mobile Scenario section, and Dirk Kutscher as
co-author;</t>
</list></t>
<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:00 |