Internet DRAFT - draft-carlberg-avt-rtp-ecn
draft-carlberg-avt-rtp-ecn
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
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 = <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.
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]
