RTP Multiple Stream Sessions and Simulcast
draft-westerlund-avtcore-multistream-and-simulcast-00

Congestion Exposure (ConEx) Working                            M. Mathis
Group                                                        Google, Inc
Internet-Draft                                                B. Briscoe
Intended status: Informational                                        BT
Expires: September 14, 2014                              March 13, 2014

      Congestion Exposure (ConEx) Concepts and Abstract Mechanism
                  draft-ietf-conex-abstract-mech-11

Abstract

  This document describes an abstract mechanism by which senders inform
  the network about the congestion encountered by packets earlier in
  the same flow.  Today, network elements at any layer may signal
  congestion to the receiver by dropping packets or by ECN markings,
  and the receiver passes this information back to the sender in
  transport-layer feedback.  The mechanism described here enables the
  sender to also relay this congestion information back into the
  network in-band at the IP layer, such that the total amount of
  congestion from all elements on the path is revealed to all IP
  elements along the path, where it could, for example, be used to
  provide input to traffic management.  This mechanism is called
  congestion exposure or ConEx.  The companion document "ConEx Concepts
  and Use Cases" provides the entry-point to the set of ConEx
  documentation.

Status of This Memo

  This Internet-Draft is submitted in full conformance with the
  provisions of BCP 78 and BCP 79.

  Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF).  Note that other groups may also distribute
  working documents as Internet-Drafts.  The list of current Internet-
  Drafts is at http://datatracker.ietf.org/drafts/current/.

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time.  It is inappropriate to use Internet-Drafts as reference
  material or to cite them other than as "work in progress."

  This Internet-Draft will expire on September 14, 2014.

Copyright Notice

  Copyright (c) 2014 IETF Trust and the persons identified as the
  document authors.  All rights reserved.

Mathis & Briscoe      Expires September 14, 2014              [Page 1]
Internet-Draft    ConEx Concepts and Abstract Mechanism      March 2014

  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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
  2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
    2.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
  3.  Requirements for the ConEx Abstract Mechanism  . . . . . . . .  7
    3.1.  Requirements for ConEx Signals . . . . . . . . . . . . . .  7
    3.2.  Requirements for the Audit Function  . . . . . . . . . . .  8
    3.3.  Requirements for non-abstract ConEx specifications . . . .  9
  4.  Encoding Congestion Exposure . . . . . . . . . . . . . . . . . 10
    4.1.  Naive Encoding . . . . . . . . . . . . . . . . . . . . . . 11
    4.2.  Null Encoding  . . . . . . . . . . . . . . . . . . . . . . 11
    4.3.  ECN Based Encoding . . . . . . . . . . . . . . . . . . . . 12
    4.4.  Independent Bits . . . . . . . . . . . . . . . . . . . . . 12
    4.5.  Codepoint Encoding . . . . . . . . . . . . . . . . . . . . 13
    4.6.  Units Implied by an Encoding . . . . . . . . . . . . . . . 14
  5.  Congestion Exposure Components . . . . . . . . . . . . . . . . 15
    5.1.  Network Devices (Not modified) . . . . . . . . . . . . . . 15
    5.2.  Modified Senders . . . . . . . . . . . . . . . . . . . . . 15
    5.3.  Receivers (Optionally Modified)  . . . . . . . . . . . . . 15
    5.4.  Policy Devices . . . . . . . . . . . . . . . . . . . . . . 16
      5.4.1.  Congestion Monitoring Devices  . . . . . . . . . . . . 16
      5.4.2.  Rest-of-Path Congestion Monitoring . . . . . . . . . . 16
      5.4.3.  Congestion Policers  . . . . . . . . . . . . . . . . . 17
    5.5.  Audit  . . . . . . . . . . . . . . . . . . . . . . . . . . 18
  6.  Support for Incremental Deployment . . . . . . . . . . . . . . 21
  7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 23
  8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 24
  9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
  10. Comments Solicited . . . . . . . . . . . . . . . . . . . . . . 25
  11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
    11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
    11.2. Informative References . . . . . . . . . . . . . . . . . . 25

Mathis & Briscoe      Expires September 14, 2014              [Page 2]
Internet-Draft    ConEx Concepts and Abstract Mechanism      March 2014

1.  Introduction

  This document describes an abstract mechanism by which, to a first
  approximation, senders inform the network about the congestion
  encountered by packets earlier in the same flow.  It is not a
  complete protocol specification, because it is known that designing
  an encoding (e.g. packet formats, codepoint allocations, etc) is
  likely to entail compromises that preclude some uses of the protocol.
  The goal of this document is to provide a framework for developing
  and testing algorithms to evaluate the benefits of the ConEx protocol
  and to evaluate the consequences of the compromises in various
  different encoding designs.

  A companion document [RFC6789] provides the entry point to the set of
  ConEx documentation.  It outlines concepts that are pre-requisites to
  understanding why ConEx is useful, and it outlines various ways that
  ConEx might be used.

2.  Overview

  As typical end-to-end transport protocols continually seek out more
  network capacity, network elements signal whenever congestion
  results, and the transports are responsible for controlling this
  network congestion [RFC5681].  The more a transport tries to use
  capacity that others want to use, the more congestion signals will be
  attributable to that transport.  Likewise, the more transport
  sessions sustained by a user and the longer the user sustains them,
  the more congestion signals will be attributable to that user.  The
  goal of ConEx is to ensure that the resulting congestion signals are
  sufficiently visible and robust, because they are an ideal metric for
  networks to use as the basis of traffic management or other related
  functions.

  Networks indicate congestion by three possible signals: packet loss,
  ECN marking or queueing delay.  ECN marking and some packet loss may
  be the outcome of Active Queue Management (AQM), which the network
  uses to warn senders to reduce their rates.  Packet loss is also the
  natural consequence of complete exhaustion of a buffer or other
  network resource.  Some experimental transport protocols and TCP
  variants infer impending congestion from increasing queuing delay.
  However, delay is too amorphous to use as a congestion metric.  In
  this and other ConEx documents, the term 'congestion signals' is
  generally used solely for ECN markings and packet losses, because
  they are unambiguous signals of congestion.

  In both cases the congestion signals follow the route indicated in
  Figure 1.  A congested network device sends a signal in the data
  stream on the forward path to the transport receiver, the receiver

Mathis & Briscoe      Expires September 14, 2014              [Page 3]
Internet-Draft    ConEx Concepts and Abstract Mechanism      March 2014

  passes it back to the sender through transport level feedback, and
  the sender makes some congestion control adjustment.

  This document extends the capabilities of the Internet protocol suite
  with the addition of a new Congestion Exposure signal.  To a first
  approximation this signal, also shown in Figure 1, relays the
  congestion information from the transport sender back through the
  internetwork layer where it is visible to any interested internetwork
  layer devices along the forward path.  This document frames the
  engineering problem of designing the ConEx signal.  The requirements
  are described in Section 3 and some example encoding are presented in
  Section 4.  Section 5 describes all of the protocol components.

  This new signal is expressly designed to support a variety of new
  policy mechanisms that might be used to instrument, monitor or manage
  traffic.  The policy devices are not shown in Figure 1 but might be
  placed anywhere along the forward data path (see Section 5.4).

  ,---------.                                              ,---------.
  |Transport|                                              |Transport|
  | Sender  |  .                                          |Receiver |
  |        |  /|___________________________________________|        |
  |    ,-