idnits 2.17.1 draft-carlberg-avt-rtcp-xr-ecn-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 35 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 125: '...bits in this field MUST be set to zero...' RFC 2119 keyword, line 126: '... and MUST be ignored by the re...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC 4585' on line 83 looks like a reference -- Missing reference section? 'RFC3611' on line 183 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Piers O'Hanlon 3 INTERNET DRAFT UCL 4 June 29, 2009 Ken Carlberg 5 G11 7 RTCP Extended Report for ECN Marked Packets 8 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (c) 2009 IETF Trust and the persons identified as the document 33 authors. All rights reserved. 35 This document is subject to BCP 78 and the IETF Trust's Legal Provisions 36 Relating to IETF Documents in effect on the date of publication of this 37 document (http://trustee.ietf.org/license-info). Please review these 38 documents carefully, as they describe your rights and restrictions with 39 respect to this document. 41 Abstract 43 This document describes a Real-Time Control Protocol (RTCP) Extended 44 Report (XR) containing information derived from the reception of 45 Explicit Congestion Notification (ECN) marked packets. This document is 46 symbiotic with the approach described in [rtp-ecn], which presents one 47 approach in establishing end-to-end ECN support for real-time sessions. 49 1 Introduction 51 Explicit Congestion Notification (ECN) is a dual-layer means of 52 conveying the presence of congestion on an end-to-end manner without 53 dropping packets. The network layer indicates in hop-by-hop IP packets 54 whether or not endpoints support ECN. If yes, then if congestion exists 55 along the downstream path, the IP packet is marked to indicate the 56 congested condition to the endpoint. At the upper layer has the dual 57 responsibility of initially negotiating support for ECN as well as 58 conveying the congested condition to the source endpoint. 60 The initial realization of ECN was described in [rfc2481], and later 61 obsoleted by [rfc3168]. In both cases, TCP was used as the upper layer 62 transport protocol used to negotiate support for ECN during the 63 establishment of an end-to-end connection and convey through the use of 64 TCP acks the presence of congestion along the downstream path. The 65 architecture presented [rfc3168] also opened the design to allow 66 other upper layer protocols to be substitued for TCP. 68 1.1. Applicability 70 This metric is believed to be applicable to all RTP applications 71 which utilise ECN for congetsion control or other purposes. Additionally 72 it may be utilised by monitoring systems. 74 2. Design Approach 76 Protocols such as SCTP and DCCP are natural candidates for support of 77 ECN due to the stateful behavior. However, UDP is stateless and not a 78 viable candidate for accomplishing the state negotiation outlined in 79 [rfc3168]. To compensate for this stateless feature, [rtp-ecn] proposes 80 utilizing this RTCP XR extension to provide for an RTP minimal 81 congestion control functionality. By employing Extended RTP Profile for 82 Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) 83 [RFC 4585], it is possible to provide suitable timely feedback at the 84 level necessary for base-line congestion control mechanisms. This newly 85 proposed XR follows the guidelines defined in [rfc3550] and [rfc3611]. 87 3 RTCP Block Extended Report: ECN 89 This block type permits detailed reporting upon the ECN marking of 90 individual packets. As detailed above the ECN marking may be employed 91 in a variety of ways. The information may also be utilised by 92 monitoring systems. 94 This reporting format utilises an approach closely aligned that in 95 the Section 4.1 [rfc3611] Loss RLE report Block. The main difference 96 with the ECN report block is that it reports both bits of the ECN field. 98 The reason for this is so that the ECN statistics may be complete, by 99 conveying all three codepoints; Congestion Experienced (CE), ECN-Capable 100 Transport (ECT), and Not-ECT. 102 The ECN Report Block has the following format: 104 0 1 2 3 105 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 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 | BT=TBD | rsvd. | T | block length | 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 | SSRC of source | 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | begin_seq | end_seq | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | chunk 1 | chunk 2 | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 : ... : 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | chunk n-1 | chunk n | 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 block type (BT): 8 bits 121 A Loss RLE Report Block is identified by the constant TBD. 123 rsvd.: 4 bits 124 This field is reserved for future definition. In the absence 125 of such definition, the bits in this field MUST be set to zero 126 and MUST be ignored by the receiver. 128 thinning (T): 4 bits 129 The amount of thinning performed on the sequence number space. 130 Only those packets with sequence numbers 0 mod 2^T are reported 131 on by this block. A value of 0 indicates that there is no 132 thinning, and all packets are reported on. The maximum 133 thinning is one packet in every 32,768 (amounting to two 134 packets within each 16-bit sequence space). 136 block length: 16 bits 137 The length of this report block, including the header, in 32- 138 bit words minus one. 140 SSRC of source: 32 bits 141 The SSRC of the RTP data packet source being reported upon by 142 this report block. 144 begin_seq: 16 bits 145 The first sequence number that this block reports on. 147 end_seq: 16 bits 148 The last sequence number that this block reports on plus one. 150 chunk i: 16 bits 151 There are three chunk types: run length, bit vector, and 152 terminating null, defined in [RFC3611] (Section 4). If the 153 chunk is all zeroes, then it is a terminating null chunk. 154 Otherwise, the left most bit of the chunk determines its type: 155 0 for run length and 1 for bit vector. 157 4. SDP Attribute 159 The use of SDP to signal XR blocks is specified in [RFC3611], which 160 provides for ease of extension. This section defines such an extension 161 to provide for signalling of the ECN report block. 163 An additional value, "ecn-rle", is defined for the existing "xr-format" 164 parameter in RTCP XR attribute. 166 rtcp-xr-attrib = "a=" "rtcp-xr" ":" [xr-format *(SP xr-format)] CRLF 168 (as defined in RFC3611) 170 xr-format = xr-format / ecn-rle 172 ecn-rle = "ecn-rle" ["=" max-size] 174 5. IANA Considerations 176 This document creates a new block type within the IANA "RTCP XR Block 177 Type Registry" called the ECN Metrics Block, and a new parameter xr-ecn 178 within the "RTCP XR SDP Parameters Registry". 180 6. Security Considerations 182 The proposed RTCP XR report block introduces no new security 183 considerations beyond those described in [RFC3611]. This block may 184 provide per-packet statistics of downstream flows to the upstream 185 source node. 187 7. References 189 7.1. Normative References 191 [rfc2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement 192 Levels", BCP 14, RFC 2119, IETF, March 1997. 194 [rfc3550] Schulzrinne, S., et al, "RTP: A Transport Protocol for Real-Time 195 Applications", RFC 3550, IETF, July 2003 197 [rfc3611] Friedman, T., et al, "RTP Control Protocol Extended Reports 198 (RTCP XR)", RFC 3611, IETF, November 2003 200 [rfc4585] Ott, J., et al, "Extended RTP Profile for Real-time Transport 201 Control Protocol (RTCP) -Based Feedback (RTP/AVPF)", RFC 4585, 202 IETF, July 2006 204 7.2 Informative References 206 [rtp-ecn] Carlberg, K., P. O'Hanlon, "Explicit Notification Extension (ECN) 207 Extension for RTP", Internet Draft, Work in Progress, Jun 2009 209 [rfc2481] Ramakrishnan, S., S. Floyd, "A Proposal to Add Explicit Congestion 210 Notification (ECN) to IP", RFC2481, IETF, January 1999 212 [rfc3168] Ramakrishnan, S., et al, "The Addition of Explicit Congestion 213 Notification (ECN) to IP", RFC3168, IETF, September 2001 215 Author's Addresses 217 Piers O'Hanlon 218 University College London 219 Gower Street 220 London, UK 221 EMail: p.ohanlon@cs.ucl.ac.uk 223 Ken Carlberg 224 G11 225 1601 Clarendon Blvd 226 Arlington, VA, USA 227 email: carlberg@g11.org.uk