Internet Engineering Task Force Ken Carlberg INTERNET DRAFT G11 July 13, 2009 Piers, O'Hanlon UCL Explicit Notification Extension (ECN) Support for RTP Sessions 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 1 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. 2. 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. 3. SDP Signaling In compliance with [rfc4566], we specify a new attribute, used for SDP, that contains two parameters. a = : = "rtp-ecn" = "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 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. 4. IANA Considerations This document defines a new session attribute "rtp-ecn". 5. Security Considerations The proposed session attribute "rtp-ecn" introduces no new security considerations beyond those described in [RFC4566]. 6. 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]