Internet Engineering Task Force Ken Carlberg INTERNET DRAFT G11 December 18, 2008 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) 2008 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. 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 June 18, 2009 [Page 1] Internet Draft ECN Extension for RTP December 18, 2008 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 June 18, 2009 [Page 2] Internet Draft ECN Extension for RTP December 18, 2008 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 TBD. Note to reader: because of the potential complexity of the subject, we may want to write a new draft just on the subject of mulicast sessions and ECN. 3. SDP Signaling In compliance with [rfc4566], we specify a new attribute, used for SDP, that contains two parameters. The first parameter contains one of two values that convey the type of data stream (unicast or multicast). The second parameter direction that is known to support ECN at the endpoint. a = : = "rtp-ecn" = "sendonly" / "sendrcv" Carlberg, O'Hanlon Expires June 18, 2009 [Page 3] Internet Draft ECN Extension for RTP December 18, 2008 The "rtp-ecn" value identifies the attribute as pertaining to ECN support for RTP layer sessions. The values attributed to the 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 "sendrcv" 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, "sendrcv" 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. 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, December 2008. [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 June 18, 2009 [Page 4] Internet Draft ECN Extension for RTP December 18, 2008 [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 123a Versailles Circle Baltimore, MD, 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 June 18, 2009 [Page 5] Internet Draft ECN Extension for RTP December 18, 2008 Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Carlberg, O'Hanlon Expires June 18, 2009 [Page 6]