GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6789

Internet Engineering Task Force (IETF) B. Briscoe, Ed. Request for Comments: 6789 BT Category: Informational R. Woundy, Ed. ISSN: 2070-1721 Comcast

                                                        A. Cooper, Ed.
                                                                   CDT
                                                         December 2012
         Congestion Exposure (ConEx) Concepts and Use Cases

Abstract

 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.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6789.

Briscoe, et al. Informational [Page 1] RFC 6789 ConEx Concepts and Use Cases December 2012

Copyright Notice

 Copyright (c) 2012 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
 2.  Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.1.  Congestion . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.2.  Congestion-Volume  . . . . . . . . . . . . . . . . . . . .  5
   2.3.  Rest-of-Path Congestion  . . . . . . . . . . . . . . . . .  6
   2.4.  Definitions  . . . . . . . . . . . . . . . . . . . . . . .  6
 3.  Core Use Case: Informing Traffic Management  . . . . . . . . .  7
   3.1.  Use Case Description . . . . . . . . . . . . . . . . . . .  7
   3.2.  Additional Benefits  . . . . . . . . . . . . . . . . . . .  9
   3.3.  Comparison with Existing Approaches  . . . . . . . . . . .  9
 4.  Other Use Cases  . . . . . . . . . . . . . . . . . . . . . . . 11
 5.  Deployment Arrangements  . . . . . . . . . . . . . . . . . . . 12
 6.  Experimental Considerations  . . . . . . . . . . . . . . . . . 13
 7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
 8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
 9.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
 10. Informative References . . . . . . . . . . . . . . . . . . . . 15

1. Introduction

 The power of Internet technology comes from multiplexing shared
 capacity with packets rather than circuits.  Network operators aim to
 provide sufficient shared capacity, but when too much packet load
 meets too little shared capacity, congestion results.  Congestion
 appears as either increased delay, dropped packets, or packets
 explicitly marked with Explicit Congestion Notification (ECN)
 markings [RFC3168].  As described in Figure 1, congestion control
 currently relies on the transport receiver detecting these
 'Congestion Signals' and informing the transport sender in
 'Congestion Feedback Signals'.  The sender is then expected to reduce
 its rate in response.

Briscoe, et al. Informational [Page 2] RFC 6789 ConEx Concepts and Use Cases December 2012

 This document provides the entry point to the set of documentation
 about the Congestion Exposure (ConEx) protocol.  It focuses on the
 motivation for including a ConEx marking at the IP layer.  (A
 companion document, [CONEX-ABS], focuses on the mechanics of the
 protocol.)  Briefly, the idea is for the sender to continually signal
 expected congestion in the headers of any data it sends.  To a first
 approximation, the sender does this by relaying the 'Congestion
 Feedback Signals' back into the IP layer.  They then travel unchanged
 across the network to the receiver (shown as 'IP-Layer-ConEx-Signals'
 in Figure 1).  This enables IP-layer devices on the path to see
 information about the whole-path congestion.
 ,---------.                                               ,---------.
 |Transport|                                               |Transport|
 | Sender  |   .                                           |Receiver |
 |         |  /|___________________________________________|         |
 |     ,-<---------------Congestion-Feedback-Signals--<--------.     |
 |     |   |/                                              |   |     |
 |     |   |\           Transport Layer Feedback Flow      |   |     |
 |     |   | \  ___________________________________________|   |     |
 |     |   |  \|                                           |   |     |
 |     |   |   '         ,-----------.               .     |   |     |
 |     |   |_____________|           |_______________|\    |   |     |
 |     |   |    IP Layer |           |  Data Flow      \   |   |     |
 |     |   |             |(Congested)|                  \  |   |     |
 |     |   |             |  Network  |--Congestion-Signals--->-'     |
 |     |   |             |  Device   |                    \|         |
 |     |   |             |           |                    /|         |
 |     `----------->--(new)-IP-Layer-ConEx-Signals-------->|         |
 |         |             |           |                  /  |         |
 |         |_____________|           |_______________  /   |         |
 |         |             |           |               |/    |         |
 `---------'             `-----------'               '     `---------'
       Figure 1: The ConEx Protocol in the Internet Architecture
 One of the key benefits of exposing this congestion information at
 the IP layer is that it makes the information available to network
 operators for use as input into their traffic management procedures.
 A ConEx-enabled sender signals expected whole-path congestion, which
 is approximately the congestion at least a round-trip time earlier as
 reported by the receiver to the sender (Figure 1).  The ConEx signal
 is a mark in the IP header that is easy for any IP device to read.
 Therefore, a node performing traffic management can count congestion
 as easily as it might count data volume today by simply counting the
 volume of packets with ConEx markings.

Briscoe, et al. Informational [Page 3] RFC 6789 ConEx Concepts and Use Cases December 2012

 ConEx-based traffic management can make highly efficient use of
 capacity.  In times of no congestion, all traffic management
 restraints can be removed, leaving the network's full capacity
 available to all its users.  If some users on the network cause
 disproportionate congestion, the traffic management function can
 learn about this and directly limit those users' traffic in order to
 protect the service of other users sharing the same capacity.  ConEx-
 based traffic management thus presents a step change in terms of the
 options available to network operators for managing traffic on their
 networks.
 The remainder of this document explains the concepts behind ConEx and
 how exposing congestion can significantly improve Internet traffic
 management, among other benefits.  Section 2 introduces a number of
 concepts that are fundamental to understanding how ConEx-based
 traffic management works.  Section 3 shows how ConEx can be used for
 traffic management, discusses additional benefits from such usage,
 and compares ConEx-based traffic management to existing traffic
 management approaches.  Section 4 discusses other related use cases.
 Section 5 briefly discusses deployment arrangements.  Section 6
 suggests open issues that experiments in the use of ConEx could
 usefully be designed to answer.  The final sections are standard RFC
 back matter.
 The remainder of the core ConEx document suite consists of:
    [CONEX-ABS], which provides an abstract encoding of ConEx signals,
    explains the ConEx audit and security mechanisms, and describes
    incremental deployment features;
    [CONEX-DESTOPT], which specifies the IPv6 destination option
    encoding for ConEx;
    [TCP-MOD], which specifies TCP-sender modifications for use of
    ConEx;
    and the following documents, which describe some feasible
    scenarios for deploying ConEx:
       [CONEX-DEPLOY], which describes a scenario around a fixed
       broadband access network;
       [CONEX-MOBILE], which describes a scenario around a mobile
       communications provider;
       [CONEX-DATA], which describes how ConEx could be used for
       performance isolation between tenants of a data centre.

Briscoe, et al. Informational [Page 4] RFC 6789 ConEx Concepts and Use Cases December 2012

2. Concepts

 ConEx relies on a precise definition of congestion and a number of
 newer concepts that are introduced in this section.  Definitions are
 summarized in Section 2.4.

2.1. Congestion

 Despite its central role in network control and management,
 congestion is a remarkably difficult concept to define.  Experts in
 different disciplines and with different perspectives define
 congestion in a variety of ways [Bauer09].
 The definition used for the purposes of ConEx is expressed as the
 probability of packet loss (or the probability of packet marking if
 ECN is in use).  This definition focuses on how congestion is
 measured, rather than describing congestion as a condition or state.

2.2. Congestion-Volume

 The metric that ConEx exposes is congestion-volume: the volume of
 bytes dropped or ECN-marked in a given period of time.  Counting
 congestion-volume allows each user to be held responsible for his or
 her contribution to congestion.  Congestion-volume can only be a
 property of traffic, whereas congestion can be a property of traffic
 or a property of a link or a path.
 To understand congestion-volume, consider a simple example.  Imagine
 Alice sends 1 GB of a file while the loss-probability is a constant
 0.2%.  Her contribution to congestion -- her congestion-volume -- is
 1 GB x 0.2% = 2 MB.  If she then sends another 3 GB of the file while
 the loss-probability is 0.1%, this adds 3 MB to her congestion-
 volume.  Her total contribution to congestion is then 2 MB + 3 MB = 5
 MB.
 Fortunately, measuring Alice's congestion-volume on a real network
 does not require the kind of arithmetic shown above, because
 congestion-volume can be directly measured by counting the total
 volume of Alice's traffic that gets discarded or ECN-marked.  (A
 queue with varying percentage loss does these multiplications and
 additions inherently.)  With ConEx, network operators can count
 congestion-volume using techniques very similar to those they use for
 counting volume.

Briscoe, et al. Informational [Page 5] RFC 6789 ConEx Concepts and Use Cases December 2012

2.3. Rest-of-Path Congestion

 At a particular measurement point within a network, "rest-of-path
 congestion" (also known as "downstream congestion") is the level of
 congestion that a traffic flow is expected to experience between the
 measurement point and its final destination.  "Upstream congestion"
 is the congestion experienced up to the measurement point.
 If traffic is ECN-capable, ECN signals monitored in the middle of a
 network will indicate the congestion experienced so far on the path
 (upstream congestion).  In contrast, the ConEx signals inserted into
 IP headers as shown in Figure 1 indicate the congestion along a whole
 path from transport source to transport destination.  Therefore, if a
 measurement point detects both of these signals, it can subtract the
 level of ECN (upstream congestion) from the level of ConEx (whole
 path) to derive a measure of the congestion that packets are likely
 to experience between the monitoring point and their destination
 (rest-of-path congestion).  A measurement point can calculate this
 measurement in the aggregate, across all flows.
 A network monitor can usually accurately measure upstream congestion
 only if the traffic it observes is ECN-capable.  [CONEX-ABS] further
 discusses the constraints around the network's ability to measure
 upstream and rest-of-path congestion in these circumstances.
 However, there are a number of initial deployment arrangements that
 benefit from ConEx but work without ECN (see Section 5).

2.4. Definitions

 Congestion:  In general, congestion occurs when any user's traffic
    suffers loss, ECN marking, or increased delay as a result of one
    or more network resources becoming overloaded.  For the purposes
    of ConEx, congestion is measured using the concrete signals
    provided by loss and ECN markings (delay is not considered).
    Congestion is measured as the probability of loss or the
    probability of ECN marking, usually expressed as a dimensionless
    percentage.
 Congestion-volume:  For any granularity of traffic (packet, flow,
    aggregate, link, etc.), the volume of bytes dropped or ECN-marked
    in a given period of time.  Conceptually, data volume multiplied
    by the congestion each packet of the volume experienced.  This is
    usually expressed in bytes (or kB, MB, etc.).
 Congestion policer:  A logical entity that allows a network operator
    to monitor each user's congestion-volume and enforce congestion-
    volume limits (discussed in Section 3.1).

Briscoe, et al. Informational [Page 6] RFC 6789 ConEx Concepts and Use Cases December 2012

 Rest-of-path congestion (or downstream congestion):  The congestion a
    flow of traffic is expected to experience on the remainder of its
    path.  In other words, at a measurement point in the network, the
    rest-of-path congestion is the congestion the traffic flow has yet
    to experience as it travels from that point to the receiver.
    Upstream congestion is usually expressed as a dimensionless
    percentage.
 Upstream congestion:  The accumulated congestion experienced by a
    traffic flow thus far, relative to a point along its path.  In
    other words, at a measurement point in the network, the upstream
    congestion is the accumulated 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.  This is usually
    expressed as a dimensionless percentage.
 Network operator (or provider):  Operator of a residential,
    commercial, enterprise, campus, or other network.
 User:  The contractual entity that represents an individual,
    household, business, or institution that uses the service of a
    network operator.  There is no implication that the contract has
    to be commercial; for instance, the users of a university or
    enterprise network service could be students or employees who do
    not pay for access, but may be required to comply with some form
    of contract or acceptable use policy.  There is also no
    implication that every user is an end user.  Where two networks
    form a customer-provider relationship, the term "user" applies to
    the customer network.
 [CONEX-ABS] gives further definitions for aspects of ConEx related to
 protocol mechanisms.

3. Core Use Case: Informing Traffic Management

 This section explains how ConEx could be used as the basis for
 traffic management, highlights additional benefits derived from
 having ConEx-aware nodes on the network, and compares ConEx-based
 traffic management to existing approaches.

3.1. Use Case Description

 One of the key benefits that ConEx can deliver is in helping network
 operators to improve how they manage traffic on their networks.
 Consider the common case of a commercial broadband network where a
 relatively small number of users place disproportionate demand on
 network resources, at times resulting in congestion.  The network

Briscoe, et al. Informational [Page 7] RFC 6789 ConEx Concepts and Use Cases December 2012

 operator seeks a way to manage traffic such that the traffic that
 contributes more to congestion bears more of the brunt of the
 management.
 Assuming ConEx signals are visible at the IP layer, the network
 operator can accomplish this by placing a congestion policer at an
 enforcement point within the network and configuring it with a
 traffic management policy that monitors each user's contribution to
 congestion.  As described in [CONEX-ABS] and elaborated in [CongPol],
 one way to implement a congestion policer is in a similar way to a
 bit-rate policer, except that it monitors congestion-volume (based on
 IP-layer ConEx signals) rather than bit rate.  When implemented as a
 token bucket, the tokens provide users with the right to cause bits
 of congestion-volume, rather than to send bits of data volume.  The
 fill rate represents each user's congestion-volume quota.
 The congestion policer monitors the ConEx signals of the traffic
 entering the network.  As long as the network remains uncongested and
 users stay within their quotas, no action is taken.  When the network
 becomes congested and a user exhausts his quota, some action is taken
 against the traffic that breached the quota in accordance with the
 network operator's traffic management policy.  For example, the
 traffic may be dropped, delayed, or marked with a lower QoS class.
 In this way, traffic is managed according to its contribution to
 congestion -- not some application- or flow-specific policy -- and is
 not managed at all during times of no congestion.
 As an example of how a network operator might employ a ConEx-based
 traffic management system, consider a typical DSL network
 architecture (as elaborated in [TR-059] and [TR-101]).  Traffic is
 routed from regional and global IP networks to an operator-controlled
 IP node, the Broadband Remote Access Server (BRAS).  From the BRAS,
 traffic is delivered to access nodes.  The BRAS carries enhanced
 functionality, including IP QoS and traffic management capabilities.
 By deploying a congestion policer at the BRAS location, the network
 operator can measure the congestion-volume created by users within
 the access nodes and police misbehaving users before their traffic
 affects others on the access network.  The policer would be
 provisioned with a traffic management policy, perhaps directing the
 BRAS to drop packets from users that exceed their congestion-volume
 quotas during times of congestion.  Those users' apps would be likely
 to react in the typical way to drops, backing off (assuming at least
 some use TCP), and thereby lowering the users' congestion-volumes
 back within the quota limits.  If none of a user's apps responds, the
 policer would continue to increase focused drops and effectively
 enforce its own congestion control.

Briscoe, et al. Informational [Page 8] RFC 6789 ConEx Concepts and Use Cases December 2012

3.2. Additional Benefits

 The ConEx-based approach to traffic management has a number of
 benefits in addition to efficient management of traffic.  It provides
 incentives for users to make use of "scavenger" transport protocols,
 such as the Low Extra Delay Background Transport [LEDBAT], that
 provide ways for bulk-transfer applications to rapidly yield when
 interactive applications require capacity (thereby "scavenging"
 remaining bandwidth).  With a congestion policer in place as
 described in Section 3.1, users of these protocols will be less
 likely to run afoul of the network operator's traffic management
 policy than those whose bulk-transfer applications generate the same
 volume of traffic without being sensitive to congestion.  In short,
 two users who produce similar traffic volumes over the same time
 interval may produce different congestion-volumes if one of them is
 using a scavenger transport protocol and the other is not; in that
 situation, the scavenger user's traffic is less likely to be managed
 by the network operator.
 ConEx-based traffic management also makes it possible for a user to
 control the relative performance among its own traffic flows.  If a
 user wants some flows to have more bandwidth than others, it can
 reduce the rate of some traffic so that it consumes less congestion-
 volume "budget", leaving more congestion-volume "budget" for the user
 to "spend" on making other traffic go faster.  This approach is most
 relevant if congestion is signalled by ECN, because no impairment due
 to loss is involved and delay can remain low.

3.3. Comparison with Existing Approaches

 A variety of approaches already exist for network operators to manage
 congestion, traffic, and the disproportionate usage of scarce
 capacity by a small number of users.  Common approaches can be
 categorized as rate-based, volume-based, or application-based.
 Rate-based approaches constrain the traffic rate per user or per
 network.  A user's peak and average (or "committed") rate may be
 limited.  These approaches have the potential to either over- or
 under-constrain the network, suppressing rates even when the network
 is uncongested or not suppressing them enough during heavy usage
 periods.
 Round-robin scheduling and fair queuing were developed to address
 these problems.  They equalize relative rates between active users
 (or flows) at a known bottleneck.  The bit rate allocated to any one
 user depends on the number of active users at each instant.  The
 drawback of these approaches is that they favor heavy users over
 light users over time, because they do not have any memory of usage.

Briscoe, et al. Informational [Page 9] RFC 6789 ConEx Concepts and Use Cases December 2012

 These approaches share bit rate instant by instant; however, heavy
 users are active at every instant, whereas light users only occupy
 their share of the link occasionally.
 Volume-based approaches measure the overall volume of traffic a user
 sends (and/or receives) over time.  Users may be subject to an
 absolute volume cap (for example, 10GB per month) or the "heaviest"
 users may be sanctioned in some other manner.  Many providers use
 monthly volume limits, and count volume regardless of whether the
 network is congested or not, creating the potential for over- or
 under-constraining problems, as with the original rate-based
 approaches.
 ConEx-based approaches, by comparison, only react during times of
 congestion and in proportion to each user's congestion contribution,
 making more efficient use of capacity and more proportionate
 management decisions.
 Unlike ConEx-based approaches, neither rate-based nor volume-based
 approaches provide incentives for applications to use scavenger
 transport protocols.  They may even penalize users of applications
 that employ scavenger transports for the large amount of volume they
 send, rather than rewarding them for carefully avoiding congestion
 while sending it.  While the volume-based approach described in
 "Comcast's Protocol-Agnostic Congestion Management System" [RFC6057]
 aims to overcome the over-/under-constraining problem by only
 measuring volume and triggering traffic management action during
 periods of high utilization, it still does not provide incentives to
 use scavenger transports, because congestion-causing volume cannot be
 distinguished from volume overall.  ConEx provides this ability.
 Application-based approaches use deep packet inspection or other
 techniques to determine what application a given traffic flow is
 associated with.  Network operators may then use this information to
 rate-limit or otherwise sanction certain applications, in some cases
 only during peak hours.  These approaches suffer from being at odds
 with IPsec and some application-layer encryption, and they may raise
 additional policy concerns.  In contrast, ConEx offers an
 application-agnostic metric to serve as the basis for traffic
 management decisions.
 The existing types of approaches share a further limitation that
 ConEx can help to overcome: 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

Briscoe, et al. Informational [Page 10] RFC 6789 ConEx Concepts and Use Cases December 2012

 connections is being altered or degraded based on how the network
 operator is attempting to manage congestion.  By exposing congestion
 information at the IP layer, ConEx instead provides a metric that can
 serve as an open, transparent basis for traffic management policies
 that both providers and their customers can measure and verify.  It
 can be used to reduce the performance uncertainty that some users
 currently experience, without having to sacrifice their billing
 certainty.

4. Other Use Cases

 ConEx information can be put to a number of uses other than informing
 traffic management.  These include:
 Informing inter-operator contracts:  ConEx information is made
    visible to every IP node, including border nodes between networks.
    Network operators can use ConEx combined with ECN markings to
    measure how much traffic from each network contributes to
    congestion in the other.  As such, congestion-volume could be
    included as a metric in inter-operator contracts, just as volume
    or bit rate are included today.  This would not be an initial
    deployment scenario, unless ECN became widely deployed.
 Enabling more efficient capacity provisioning:  Section 3.2 explains
    how operators can use ConEx-based traffic management to encourage
    use of scavenger transport protocols, which significantly improves
    the performance of interactive applications while still allowing
    heavy users to transfer high volumes.  Here we explain how this
    can also benefit network operators.
    Today, when loss, delay, or average utilization exceeds a certain
    threshold, some operators just buy more capacity without
    attempting to manage the traffic.  Other operators prefer to limit
    a minority of heavy users at peak times, but they still eventually
    buy more capacity when utilization rises.
    With ConEx-based traffic management, a network operator should be
    able to provision capacity more efficiently.  An operator could
    benefit from this in a variety of ways.  For example, the operator
    could add capacity as it would do without ConEx, but deliver
    better quality of service for its users.  Or, the operator could
    delay adding capacity while delivering similar quality of service
    to what it currently provides.

Briscoe, et al. Informational [Page 11] RFC 6789 ConEx Concepts and Use Cases December 2012

5. Deployment Arrangements

 ConEx is designed so that it can be incrementally deployed in the
 Internet and still be valuable for early adopters.  As long as some
 senders are ConEx-enabled, a network on the path can unilaterally use
 ConEx-aware policy devices for traffic management; no changes to
 network forwarding elements are needed, and ConEx still works if
 there are other networks on the path that are unaware of ConEx marks.
 The above two steps seem to represent a stand-off where neither step
 is useful until the other has made the first move: i) some sending
 hosts must be modified to give information to the network, and ii) a
 network must deploy policy devices to monitor this information and
 act on it.  Nonetheless, the developer of a scavenger transport
 protocol like LEDBAT does stand to benefit from deploying ConEx.  In
 this case, the developer makes the first move, expecting it will
 prompt at least some networks to move in response, using the ConEx
 information to reward users of the scavenger transport protocol.
 On the host side, we have already shown (Figure 1) how the sender
 piggy-backs ConEx signals on normal data packets to re-insert
 feedback about packet drops (and/or ECN) back into the IP layer.  In
 the case of TCP, [TCP-MOD] proposes the required sender
 modifications.  ConEx works with any TCP receiver as long as it uses
 SACK (selective acknowledgment), which most do.  There is a receiver
 optimisation [TCPM-ECN] that improves ConEx precision when using ECN,
 but ConEx can still use ECN without it.  Networks can make use of
 ConEx even if the implementations of some of the transport protocols
 on a host do not support ConEx (e.g., the implementation of DNS over
 UDP might not support ConEx, while perhaps RTP over UDP and TCP
 will).
 On the network side, the provider solely needs to place ConEx
 congestion policers at each ingress to its network in a similar
 arrangement to the edge-policed architecture of Diffserv [RFC2475].
 A sender can choose whether to send packets that support ConEx or
 packets that don't.  ConEx-enabled packets bring information to the
 policer about congestion expected on the rest of the path beyond the
 policer.  Packets that do not support ConEx bring no such
 information.  Therefore, the network will tend to conservatively
 rate-limit non-ConEx-enabled packets 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 reinforces ConEx
 deployment.

Briscoe, et al. Informational [Page 12] RFC 6789 ConEx Concepts and Use Cases December 2012

 Feasible initial deployment scenarios exist for a broadband access
 network [CONEX-DEPLOY], a mobile communications network
 [CONEX-MOBILE], and a multi-tenant data centre [CONEX-DATA].  The
 first two of these scenarios are believed to work well without ECN
 support, while the data center scenario works best with ECN (and ECN
 can be deployed unilaterally).
 The above gives only the most salient aspects of ConEx deployment.
 For further detail, [CONEX-ABS] describes the incremental deployment
 features of the ConEx protocol and the components that need to be
 deployed for ConEx to work.

6. Experimental Considerations

 ConEx is initially designed as an experimental protocol because it
 makes an ambitious change at the interoperability (IP) layer, so no
 amount of careful design can foresee all the potential feature
 interactions with other uses of IP.  This section identifies a number
 of questions that would be useful to answer through well-designed
 experiments:
 o  Are the compromises that were made in order to fit the ConEx
    encoding into IP (for example, that the initial design was solely
    for IPv6 and not for IPv4, and that the encoding has limited
    visibility when tunnelled [CONEX-DESTOPT]) the right ones?
 o  Is it possible to combine techniques for distinguishing self-
    congestion from shared congestion with ConEx-based traffic
    management such that users are not penalized for congestion that
    does not impact others on the network?  Are other techniques
    needed?
 o  In practice, how does traffic management using ConEx compare with
    traditional techniques (Section 3.3)?  Does it give the benefits
    claimed in Sections 3.1 and 3.2?
 o  Approaches are proposed for congestion policing of ConEx traffic
    alongside existing management (or lack thereof) of non-ConEx
    traffic, including UDP traffic [CONEX-ABS].  Are they strategy-
    proof against users selectively using both?  Are there better
    transition strategies?
 o  Audit devices have been designed and implemented to assure ConEx
    signal integrity [CONEX-ABS].  Do they achieve minimal false hits
    and false misses in a wide range of traffic scenarios?  Are there
    new attacks?  Are there better audit designs to defend against
    these?

Briscoe, et al. Informational [Page 13] RFC 6789 ConEx Concepts and Use Cases December 2012

 o  If ECN deployment remains patchy, are the proposed initial ConEx
    deployment scenarios (Section 5) still useful enough to kick-start
    deployment?  Is auditing effective when based on loss at a primary
    bottleneck?  Can rest-of-path congestion be approximated
    accurately enough without ECN?  Are there other useful deployment
    scenarios?
 ConEx is intended to be a generative technology that might be used
 for unexpected purposes unforeseen by the designers.  Therefore, this
 list of experimental considerations is not intended to be exhaustive.

7. Security Considerations

 This document does not specify a mechanism, it merely motivates
 congestion exposure at the IP layer.  Therefore, security
 considerations are described in the companion document that gives an
 abstract description of the ConEx protocol and the components that
 would use it [CONEX-ABS].

8. Acknowledgments

 Bob Briscoe was partly funded by Trilogy, a research project (ICT-
 216372) supported by the European Community under its Seventh
 Framework Programme.  The views expressed here are those of the
 author only.
 The authors would like to thank the many people that have commented
 on this document: Bernard Aboba, Mikael Abrahamsson, Joao Taveira
 Araujo, Marcelo Bagnulo Braun, Steve Bauer, Caitlin Bestler, Steven
 Blake, Louise Burness, Ken Carlberg, Nandita Dukkipati, Dave McDysan,
 Wes Eddy, Matthew Ford, Ingemar Johansson, Georgios Karagiannis,
 Mirja Kuehlewind, Dirk Kutscher, Zhu Lei, Kevin Mason, Matt Mathis,
 Michael Menth, Chris Morrow, Tim Shepard, Hannes Tschofenig, and
 Stuart Venters.  Please accept our apologies if your name has been
 missed off this list.

Briscoe, et al. Informational [Page 14] RFC 6789 ConEx Concepts and Use Cases December 2012

9. Contributors

 Philip Eardley and Andrea Soppera made helpful text contributions to
 this document.
 The following co-edited this document through most of its life:
    Toby Moncaster
    Computer Laboratory
    William Gates Building
    JJ Thomson Avenue
    Cambridge, CB3 0FD
    UK
    EMail: toby.moncaster@cl.cam.ac.uk
    John Leslie
    JLC.net
    10 Souhegan Street
    Milford, NH  03055
    US
    EMail: john@jlc.net

10. Informative References

 [Bauer09]       Bauer, S., Clark, D., and W. Lehr, "The Evolution of
                 Internet Congestion", 2009.
 [CONEX-ABS]     Mathis, M. and B. Briscoe, "Congestion Exposure
                 (ConEx) Concepts and Abstract Mechanism", Work
                 in Progress, October 2012.
 [CONEX-DATA]    Briscoe, B. and M. Sridharan, "Network Performance
                 Isolation in Data Centres using Congestion Exposure
                 (ConEx)", Work in Progress, July 2012.
 [CONEX-DEPLOY]  Briscoe, B., "Initial Congestion Exposure (ConEx)
                 Deployment Examples", Work in Progress, July 2012.
 [CONEX-DESTOPT] Krishnan, S., Kuehlewind, M., and C. Ucendo, "IPv6
                 Destination Option for ConEx", Work in Progress,
                 September 2012.
 [CONEX-MOBILE]  Kutscher, D., Mir, F., Winter, R., Krishnan, S.,
                 Zhang, Y., and C. Bernardos, "Mobile Communication
                 Congestion Exposure Scenario", Work in Progress,
                 July 2012.

Briscoe, et al. Informational [Page 15] RFC 6789 ConEx Concepts and Use Cases December 2012

 [CongPol]       Briscoe, B., Jacquet, A., and T. Moncaster, "Policing
                 Freedom to Use the Internet Resource Pool", ReArch
                 2008 hosted at the 2008 CoNEXT conference ,
                 December 2008.
 [LEDBAT]        Shalunov, S., Hazel, G., Iyengar, J., and M.
                 Kuehlewind, "Low Extra Delay Background Transport
                 (LEDBAT)", Work in Progress, September 2012.
 [RFC2475]       Blake, S., Black, D., Carlson, M., Davies, E., Wang,
                 Z., and W. Weiss, "An Architecture for Differentiated
                 Services", RFC 2475, December 1998.
 [RFC3168]       Ramakrishnan, K., Floyd, S., and D. Black, "The
                 Addition of Explicit Congestion Notification (ECN) to
                 IP", RFC 3168, September 2001.
 [RFC6057]       Bastian, C., Klieber, T., Livingood, J., Mills, J.,
                 and R. Woundy, "Comcast's Protocol-Agnostic
                 Congestion Management System", RFC 6057,
                 December 2010.
 [TCP-MOD]       Kuehlewind, M. and R. Scheffenegger, "TCP
                 modifications for Congestion Exposure", Work
                 in Progress, May 2012.
 [TCPM-ECN]      Kuehlewind, M. and R. Scheffenegger, "More Accurate
                 ECN Feedback in TCP", Work in Progress, July 2012.
 [TR-059]        Anschutz, T., Ed., "DSL Forum Technical Report
                 TR-059: Requirements for the Support of QoS-Enabled
                 IP Services", September 2003.
 [TR-101]        Cohen, A., Ed. and E. Schrum, Ed., "DSL Forum
                 Technical Report TR-101: Migration to Ethernet-Based
                 DSL Aggregation", April 2006.

Briscoe, et al. Informational [Page 16] RFC 6789 ConEx Concepts and Use Cases December 2012

Authors' Addresses

 Bob Briscoe (editor)
 BT
 B54/77, Adastral Park
 Martlesham Heath
 Ipswich  IP5 3RE
 UK
 Phone: +44 1473 645196
 EMail: bob.briscoe@bt.com
 URI:   http://bobbriscoe.net/
 Richard Woundy (editor)
 Comcast
 1701 John F Kennedy Boulevard
 Philadelphia, PA  19103
 US
 EMail: richard_woundy@cable.comcast.com
 URI:   http://www.comcast.com
 Alissa Cooper (editor)
 CDT
 1634 Eye St. NW, Suite 1100
 Washington, DC  20006
 US
 EMail: acooper@cdt.org

Briscoe, et al. Informational [Page 17]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6789.txt · Last modified: 2012/12/06 01:11 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki