datatracker.ietf.org
Sign In
Version 4.45, 2013-05-14
Report a bug

Reactions to Signaling from ECN Support for RTP/RTCP
draft-carlberg-tsvwg-ecn-reactions-04

Active Internet-Draft (None)
Document Stream: No stream defined
Last updated: 2013-03-08
Intended RFC status: (None)
Other versions: plain text, pdf, html

Document shepherd:(None)
Shepherd writeup

IESG State: I-D Exists
Responsible AD: (None)
Send notices to: No addresses provided

TSVWG                                           K. Carlberg
Internet-Draft                                  G11
Intended Status: Informational                  P. O'Hanlon
Expires: August 25, 2013                        UCL
                                                Feb 25, 2013

          Reactions to Signaling from ECN Support for RTP/RTCP
              <draft-carlberg-tsvwg-ecn-reactions-04.txt>

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 August 25, 2013.

Copyright Notice

   Copyright (c) 2013 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.

Abstract

   This document presents an examination of various responses to Congestion
   Experience (CE) notifications by real time applications that have
   negotiated end-to-end support of Explicit Congestion Notification (ECN).
   This document is a follow-on effort of [rfc6679], which specifies the
   signaling used to provide ECN support for RTP/RTCP flows.

Carlberg & O'Hanlon                Expires August 25, 2013      [Page 1]

Internet Drafts       Reactions to ECN for RTP/RTCP         Feb 25, 2013

1. Introduction

   This document presents an examination of various responses to Congestion
   Experience (CE) notifications by real time applications that have
   negotiated end-to-end support of Explicit Congestion Notification (ECN).
   [rfc6679] defines the signaling for support of ECN by RTP based sessions
   and also covers the case where a et of nodes do not respond to CE
   notifications.  A more detailed discussion about how back-off algorithms
   can be achieved, as well as other potential reactions, is viewed as out
   of scope of that document and may be addressed by a companion document.

1.1 Background

   ECN is a mechanism used to explicitly signal the presence of congestion
   without relying on packet loss.  It was initially designed using a dual
   layer signaling model; negotiation and feedback at the transport layer,
   and downstream notification of congestion at the network layer.  For IP,
   a new two bit field was used to both indicate the successful negotiated
   support for ECN signaling, as well as indicate the presence of
   congestion via the CE flag.  In the case of TCP [rfc3168], a new TCP
   header flag was defined that provides upstream end-to-end indication of
   congestion occurring somewhere along the downstream path.

   There should be no difference in congestion response if ECN-CE marks or
   packet drops are detected.  However it is noted that there MAY be other
   reactions to ECN-CE specified in the future.  Such an alternative
   reaction MUST be specified and considered to be safe for deployment
   under any restrictions specified.  We specify such an alternative in
   this document.

   With respect to ECN for TCP, [rfc3168] specifies an indication of
   congestion, but it does so once per Round Trip Time (RTT). [rfc6679] is
   an effort that proposes a finer grained notification reflecting a more
   accurate indication of the number of ECN marked packets received within
   one RTT. It should be noted that there is also other on going work to
   provide more accurate ECN feedback information for TCP
   [draft-tcpm-accecn-reqs].

1.2  Terminology and Abbreviations

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [RFC2119].

2. Issues