Internet DRAFT - draft-carlberg-avt-rtcp-xr-ecn
draft-carlberg-avt-rtcp-xr-ecn
Internet Engineering Task Force Piers O'Hanlon
INTERNET DRAFT UCL
June 29, 2009 Ken Carlberg
G11
RTCP Extended Report for ECN Marked Packets
<draft-carlberg-avt-rtcp-xr-ecn-01.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 Real-Time Control Protocol (RTCP) Extended
Report (XR) containing information derived from the reception of
Explicit Congestion Notification (ECN) marked packets. This document is
symbiotic with the approach described in [rtp-ecn], which presents one
approach in establishing end-to-end ECN support for real-time sessions.
O'Hanlon, Carlberg Expires December 29, 2009 [Page 1]
Internet Draft ECN Extension Report June 29, 2009
1 Introduction
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 yes, then if congestion exists
along the downstream path, the IP packet is marked to indicate the
congested condition to the endpoint. At the upper layer has the dual
responsibility of initially negotiating support for ECN as well as
conveying the 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.
1.1. Applicability
This metric is believed to be applicable to all RTP applications
which utilise ECN for congetsion control or other purposes. Additionally
it may be utilised by monitoring systems.
2. Design Approach
Protocols such as SCTP and DCCP are natural candidates for support of
ECN due to the stateful behavior. However, UDP is stateless and not a
viable candidate for accomplishing the state negotiation outlined in
[rfc3168]. To compensate for this stateless feature, [rtp-ecn] proposes
utilizing this RTCP XR extension to provide for an RTP minimal
congestion control functionality. By employing Extended RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)
[RFC 4585], it is possible to provide suitable timely feedback at the
level necessary for base-line congestion control mechanisms. This newly
proposed XR follows the guidelines defined in [rfc3550] and [rfc3611].
3 RTCP Block Extended Report: ECN
This block type permits detailed reporting upon the ECN marking of
individual packets. As detailed above the ECN marking may be employed
in a variety of ways. The information may also be utilised by
monitoring systems.
This reporting format utilises an approach closely aligned that in
the Section 4.1 [rfc3611] Loss RLE report Block. The main difference
with the ECN report block is that it reports both bits of the ECN field.
O'Hanlon, Carlberg Expires December 29, 2009 [Page 2]
Internet Draft ECN Extension Report June 29, 2009
The reason for this is so that the ECN statistics may be complete, by
conveying all three codepoints; Congestion Experienced (CE), ECN-Capable
Transport (ECT), and Not-ECT.
The ECN Report Block has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=TBD | rsvd. | T | block length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| begin_seq | end_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk 1 | chunk 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
block type (BT): 8 bits
A Loss RLE Report Block is identified by the constant TBD.
rsvd.: 4 bits
This field is reserved for future definition. In the absence
of such definition, the bits in this field MUST be set to zero
and MUST be ignored by the receiver.
thinning (T): 4 bits
The amount of thinning performed on the sequence number space.
Only those packets with sequence numbers 0 mod 2^T are reported
on by this block. A value of 0 indicates that there is no
thinning, and all packets are reported on. The maximum
thinning is one packet in every 32,768 (amounting to two
packets within each 16-bit sequence space).
block length: 16 bits
The length of this report block, including the header, in 32-
bit words minus one.
SSRC of source: 32 bits
The SSRC of the RTP data packet source being reported upon by
this report block.
begin_seq: 16 bits
The first sequence number that this block reports on.
O'Hanlon, Carlberg Expires December 29, 2009 [Page 3]
Internet Draft ECN Extension Report June 29, 2009
end_seq: 16 bits
The last sequence number that this block reports on plus one.
chunk i: 16 bits
There are three chunk types: run length, bit vector, and
terminating null, defined in [RFC3611] (Section 4). If the
chunk is all zeroes, then it is a terminating null chunk.
Otherwise, the left most bit of the chunk determines its type:
0 for run length and 1 for bit vector.
4. SDP Attribute
The use of SDP to signal XR blocks is specified in [RFC3611], which
provides for ease of extension. This section defines such an extension
to provide for signalling of the ECN report block.
An additional value, "ecn-rle", is defined for the existing "xr-format"
parameter in RTCP XR attribute.
rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF
(as defined in RFC3611)
xr-format = xr-format / ecn-rle
ecn-rle = "ecn-rle" ["=" max-size]
5. IANA Considerations
This document creates a new block type within the IANA "RTCP XR Block
Type Registry" called the ECN Metrics Block, and a new parameter xr-ecn
within the "RTCP XR SDP Parameters Registry".
6. Security Considerations
The proposed RTCP XR report block introduces no new security
considerations beyond those described in [RFC3611]. This block may
provide per-packet statistics of downstream flows to the upstream
source node.
7. References
7.1. Normative References
[rfc2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, IETF, March 1997.
[rfc3550] Schulzrinne, S., et al, "RTP: A Transport Protocol for Real-Time
O'Hanlon, Carlberg Expires December 29, 2009 [Page 4]
Internet Draft ECN Extension Report June 29, 2009
Applications", RFC 3550, IETF, July 2003
[rfc3611] Friedman, T., et al, "RTP Control Protocol Extended Reports
(RTCP XR)", RFC 3611, IETF, November 2003
[rfc4585] Ott, J., et al, "Extended RTP Profile for Real-time Transport
Control Protocol (RTCP) -Based Feedback (RTP/AVPF)", RFC 4585,
IETF, July 2006
7.2 Informative References
[rtp-ecn] Carlberg, K., P. O'Hanlon, "Explicit Notification Extension (ECN)
Extension for RTP", Internet Draft, Work in Progress, Jun 2009
[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
Piers O'Hanlon
University College London
Gower Street
London, UK
EMail: p.ohanlon@cs.ucl.ac.uk
Ken Carlberg
G11
1601 Clarendon Blvd
Arlington, VA, USA
email: carlberg@g11.org.uk
O'Hanlon, Carlberg Expires December 29, 2009 [Page 5]
