Internet Engineering Task Force                       Ken Carlberg
INTERNET DRAFT                                        G11
July 13, 2009                                         Piers, O'Hanlon
                                                      UCL




     Explicit Notification Extension (ECN) Support for RTP Sessions
                  <draft-carlberg-avt-rtp-ecn-02.txt>



Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering Task
   Force (IETF), its areas, and its working groups.  Note that other groups
   may also distribute working documents as Internet-Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of publication of this
   document (http://trustee.ietf.org/license-info).  Please review these
   documents carefully, as they describe your rights and restrictions with
   respect to this document.

Abstract

   This document describes a design to support Explicit Congestion
   Notification (ECN) for the RTP layer.  The design defines a means of
   end-to-end negotiated support of ECN using the Session Description
   Protocol (SDP) and a new RTCP Extended Report.




Carlberg, O'Hanlon      Expires January 13, 2009                [Page 1]

Internet Draft           ECN Extension for RTP             July 13, 2009


  Introduction

   This document describes a design to support Explicit Congestion
   Notification (ECN) for the RTP layer.  The design defines a means of
   end-to-end negotiated support of ECN using the Session Description
   Protocol (SDP) and a new RTCP Extended Report defined in [rtcp-ecn].

   Explicit Congestion Notification (ECN) is a dual-layer means of
   conveying the presence of congestion on an end-to-end manner without
   dropping packets.  The network layer indicates in hop-by-hop IP packets
   whether or not endpoints support ECN.  If ECN is supported, then when
   congestion exists along the downstream path, the IP packet is marked to
   indicate the congested condition to the endpoint.  The upper layer has
   the dual responsibility of initially negotiating support for ECN on an
   end-to-end basis as well as conveying any congested condition to the
   source endpoint.

   The initial realization of ECN was described in [rfc2481], and later
   obsoleted by [rfc3168].  In both cases, TCP was used as the upper layer
   transport protocol used to negotiate support for ECN during the
   establishment of an end-to-end connection and convey through the use of
   TCP acks the presence of congestion along the downstream path. The
   architecture presented [rfc3168] also opened the design to allow
   other upper layer protocols to be substitued for TCP.

.  Design

   A primary objective is to quickly convey, on an end-to-end basis, the
   presence of congestion along the downstream path of realtime traffic.
   In today's Internet, the overwhelming majority of realtime traffic uses
   UDP as an underlying transport protocol.  However, given that UDP is a
   stateless transport protocol, this document presents a solution
   involving SDP and RTCP packet headers; whose endpoints retain a
   measure of state per underlying UDP/IP flows.

   The advantage of accomplishing this at the RTP layer is that the
   signaling (both initial discovery and in-session) can be accomplished
   independent of the application.  Hence, a common API can be made
   available for any realtime application instead of duplicating the
   signaling process on a per-application basis.

2.1 Two Layer Design

   Unlike TCP sessions that operates exclusively over unicast IP flows,
   RTP/UDP sessions can operate over unicast or multicast IP flows.  This
   expansion in the types of underlying flows places constraints and
   conditions on how ECN is initially signaled by the respective
   endpoint(s).



Carlberg, O'Hanlon      Expires January 13, 2009                [Page 2]

Internet Draft           ECN Extension for RTP             July 13, 2009


2.1.1  Unicast Sessions

   The proposed effort in this document follows the design principles of
   [rfc3168], which separates the support of ECN into two layers.  One is
   the lower layer hop-by-hop state conveyed in the header of an IP packet.
   The second is the upper layer end-to-end signaling exchange conveying
   the initial support of ECN as well as its subsequent presence within a
   session.  Specifically, our proposed support for ECN is defined in SDP
   as a new attribute, while the presence of congestion within a session is
   conveyed in a new RTCP Extended report.

   An initial Offer/Answer exchange of SDP packets at the start of a
   session determines the extent by which ECN is supported by two or more
   RTP peers.  The absence of an ECN attribute in SDP by either peer
   cancels any support of RTP based ECN.

   In the case of bi-directional unicast flows, we add the ECN Extended
   report to the next upstream RTCP packet, as defined in [rtcp-ecn].  If
   this is the first time the downstream packet receives CE bit in the IP
   packet for the specific session, then we ignore the current RTCP
   transmit timer and send an RTCP packet + ECN Extended report
   immediately.  The use of immediate RTCP responses could be signalled by
   using the mechanisms in [rfc4585].

   Subsequent CE marked downstream IP packets use a timer value half that
   configured for the session.  We do this to convey information to the
   upstream source quickly, but not to drastically increase the chances of
   causing upstream congestion with excess overhead.  When the downstream
   host stops receiving CE bit set packets within the past RTCP transmit
   period, then the transmission timer is set to its normal periodic time.

2.1.2 Multicast Sessions

   This topic is outside the scope of this document.  Subsequent work on
   this topic may be presented in a future companion document.


. SDP Signaling

   In compliance with [rfc4566], we specify a new attribute, used for SDP,
   that contains two parameters.

   a               = <attribute>: <direction>
   <attribute>     = "rtp-ecn"
   <direction>     = "sendonly" / "sendrecv"

   The "rtp-ecn" value identifies the attribute as pertaining to ECN
   negotiated support for RTP layer sessions.  The values attributed to the



Carlberg, O'Hanlon      Expires January 13, 2009                [Page 3]

Internet Draft           ECN Extension for RTP             July 13, 2009


   <direction> token indicate the measure of support by each endpoint for
   ECN markings in IP packets.

   The "sendonly" conveys the state where only the sender is capable of
   setting and reading ECN bits in an IP packet.  In the context of an
   Offer/Answer exchange, "sendonly" is the default value set of the
   Offerer, since its has no pre-existing knowledge about the Answerer's
   capability.

   The "sendrecv" conveys the state where both the receiver is capable of
   setting and reading ECN bits in an IP packet.  In the context of an
   Offer/Answer exchange, "sendrecv" indicates that both the Offerer and
   Answerer can set and read ECN bits in an IP packet.  The ommision of the
   "rtp-ecn" attribute by the receiver indicates its lack of support for
   ECN.  Note that the lack of a an "rtp-ecn" entry by the Offerer means
   that the Answerer shall not insert an "rtp-ecn" attribute.


. IANA Considerations

   This document defines a new session attribute "rtp-ecn".


. Security Considerations

   The proposed session attribute "rtp-ecn" introduces no new security
   considerations beyond those described in [RFC4566].


. References

6.1. Normative References

   [rtcp-ecn] O'Hanlon, P., K. Carlberg, "RTCP Extended Report for ECN Marked
              Packets", Internet Draft, Work in Progress, Jun 2009.

   [rfc2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement
             Levels", BCP 14, RFC 2119, IETF, March 1997.

   [rfc2481] Ramakrishnan, K., S. Floyd, A Proposal to Add Explicit Congestion
             Notification (ECN) to IP", RFC 2481, IETF, January 1999.

   [rfc3668] Ramakrishnan, K., et al, "The Addition of Explicit Congestion
             Notification (ECN) to IP", RFC 3168, IETF, September 2001.

   [rfc4566] Handley, M., et al, "SDP: Session Description Protocol", RFC 4566,
             IETF July 2006.




Carlberg, O'Hanlon      Expires January 13, 2009                [Page 4]

Internet Draft           ECN Extension for RTP             July 13, 2009


   [rfc4585] Ott, J., et al., "Extended RTP Profile for real-Time Transport
             Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
             IETF, July 2006.

6.2 Informative References

   [rfc2481] Ramakrishnan, S., S. Floyd, "A Proposal to Add Explicit Congestion
             Notification (ECN) to IP", RFC2481, IETF, January 1999.

   [rfc3168] Ramakrishnan, S., et al, "The Addition of Explicit Congestion
             Notification (ECN) to IP", RFC3168, IETF, September 2001.

Author's Addresses

   Ken Carlberg
   G11
   1601 Clarendon Blvd
   Arlington, VA, USA
   carlberg@g11.org.uk

   Piers O'Hanlon
   University College London
   Gower Street
   London, UK
   p.ohanlon@cs.ucl.ac.uk


























Carlberg, O'Hanlon      Expires January 13, 2009                [Page 5]