idnits 2.17.1 draft-alvestrand-rmcat-remb-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 17, 2012) is 4483 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '2' on line 129 -- Looks like a reference, but probably isn't: '3' on line 153 == Outdated reference: A later version (-03) exists of draft-alvestrand-rtcweb-congestion-01 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Alvestrand, Ed. 3 Internet-Draft Google 4 Intended status: Experimental January 17, 2012 5 Expires: July 20, 2012 7 RTCP message for Receiver Estimated Maximum Bitrate 8 draft-alvestrand-rmcat-remb-00 10 Abstract 12 This document proposes an RTCP message for use in experimentally- 13 deployed congestion control algorithms for RTP-based media flows. 15 Requirements Language 17 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 18 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 19 document are to be interpreted as described in RFC 2119 [RFC2119]. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 20, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Receiver Estimated Max Bitrate (REMB) . . . . . . . . . . . . . 3 57 2.1. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.2. Message format . . . . . . . . . . . . . . . . . . . . . . 3 59 2.3. Signaling of use of this extension . . . . . . . . . . . . 5 60 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 62 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 65 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 66 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . . 7 67 A.1. From appendix of -congestion-01 to -00 . . . . . . . . . . 7 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 This document proposes an RTCP feedback message signalling the 73 estimated total available bandwidth for a session. 75 If this function is available, it is possible to implement the 76 algorithm in [I-D.alvestrand-rtcweb-congestion], or other algorithms 77 with the same kind of feedback messaging need, in a fashion that 78 covers multiple RTP streams at once. 80 2. Receiver Estimated Max Bitrate (REMB) 82 2.1. Semantics 84 This feedback message is used to notify a sender of multiple media 85 streams over the same RTP session of the total estimated available 86 bit rate on the path to the receiving side of this RTP session. 88 Within the common packet header for feedback messages (as defined in 89 section 6.1 of [RFC4585]), the "SSRC of packet sender" field 90 indicates the source of the notification. The "SSRC of media source" 91 is not used and SHALL be set to 0. This usage of the value zero is 92 also done 94 The reception of a REMB message by a media sender conforming to this 95 specification SHALL result in the total bit rate sent on the RTP 96 session this message applies to being equal to or lower than the bit 97 rate in this message. The new bit rate constraint should be applied 98 as fast as reasonable. The sender is free to apply additional 99 bandwidth restrictions based on its own restrictions and estimates. 101 2.2. Message format 103 This document describes a message using the application specific 104 payload type. This is suitable for experimentation; upon 105 standardization, a specific type can be assigned for the purpose. 107 The message is an RTCP message with payload type 206. RFC 3550 108 [RFC3550] defines the range, RFC 4585 defines the specific PT value 109 206 and the FMT value 15. 111 0 1 2 3 112 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 113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 |V=2|P| FMT=15 | PT=206 | length | 115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 116 | SSRC of packet sender | 117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 118 | SSRC of media source | 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | Unique identifier 'R' 'E' 'M' 'B' | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | Num SSRC | BR Exp | BR Mantissa | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | SSRC feedback | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | ... | 128 The fields V, P, SSRC, and length are defined in the RTP 129 specification [2], the respective meaning being summarized below: 131 version (V): (2 bits): This field identifies the RTP version. The 132 current version is 2. 134 padding (P) (1 bit): If set, the padding bit indicates that the 135 packet contains additional padding octets at the end that 136 are not part of the control information but are included 137 in the length field. Always 0. 139 Feedback message type (FMT) (5 bits): This field identifies the type 140 of the FB message and is interpreted relative to the type 141 (transport layer, payload- specific, or application layer 142 feedback). Always 15, application layer feedback 143 message. RFC 4585 section 6.4. 145 Payload type (PT) (8 bits): This is the RTCP packet type that 146 identifies the packet as being an RTCP FB message. 147 Always PSFB (206), Payload-specific FB message. RFC 4585 148 section 6.4. 150 Length (16 bits): The length of this packet in 32-bit words minus 151 one, including the header and any padding. This is in 152 line with the definition of the length field used in RTCP 153 sender and receiver reports [3]. RFC 4585 section 6.4. 155 SSRC of packet sender (32 bits): The synchronization source 156 identifier for the originator of this packet. RFC 4585 157 section 6.4. 159 SSRC of media source (32 bits): Always 0; this is the same 160 convention as in [RFC5104] section 4.2.2.2 (TMMBN). 162 Unique identifier (32 bits): Always 'R' 'E' 'M' 'B' (4 ASCII 163 characters). 165 Num SSRC (8 bits): Number of SSRCs in this message. 167 BR Exp (6 bits): The exponential scaling of the mantissa for the 168 maximum total media bit rate value, ignoring all packet 169 overhead. The value is an unsigned integer [0..63], as 170 in RFC 5104 section 4.2.2.1. 172 BR Mantissa (18 bits): The mantissa of the maximum total media bit 173 rate (ignoring all packet overhead) that the sender of 174 the REMB estimates. The BR is the estimate of the 175 traveled path for the SSRCs reported in this message. 176 The value is an unsigned integer in number of bits per 177 second. 179 SSRC feedback (32 bits) Consists of one or more SSRC entries which 180 this feedback message applies to. 182 2.3. Signaling of use of this extension 184 Either end of an RTP session can send this message. There is no 185 signalling to indicate that the message can be understood. 187 OPEN ISSUE: Do we need signalling, and if so, how should it be done? 189 It does not seem harmful to send it when recipient does not 190 understand it, but negotiating it may give better behaviour when it 191 is not available (by falling back to per-RTP-session TMMBR messages). 193 3. IANA Considerations 195 This document requests no action of IANA. 197 This section can be removed upon publication as an RFC. 199 4. Security Considerations 201 If the RTCP packet is not protected, it is possible to inject fake 202 RTCP packets that can increase or decrease bandwidth. This is not 203 different from security considerations for any other RTCP message. 205 5. Acknowledgements 207 This proposal has emerged from discussions between, among others, 208 Justin Uberti, Magnus Flodman, Patrik Westin, Stefan Holmer and 209 Henrik Lundin. 211 6. References 213 6.1. Normative References 215 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 216 Requirement Levels", BCP 14, RFC 2119, March 1997. 218 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 219 Jacobson, "RTP: A Transport Protocol for Real-Time 220 Applications", STD 64, RFC 3550, July 2003. 222 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 223 "Extended RTP Profile for Real-time Transport Control 224 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 225 July 2006. 227 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 228 "Codec Control Messages in the RTP Audio-Visual Profile 229 with Feedback (AVPF)", RFC 5104, February 2008. 231 6.2. Informative References 233 [I-D.alvestrand-rtcweb-congestion] 234 Lundin, H., Holmer, S., and H. Alvestrand, "A Google 235 Congestion Control Algorithm for Real-Time Communication 236 on the World Wide Web", 237 draft-alvestrand-rtcweb-congestion-01 (work in progress), 238 October 2011. 240 [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in 241 RTP Streams", RFC 5450, March 2009. 243 Appendix A. Change log 245 A.1. From appendix of -congestion-01 to -00 247 The timestamp option was removed. Discussion concluded that the RFC 248 5450 [RFC5450] "transmission time offset" header likely gives 249 accurate enough send-time information for our purposes. 251 Author's Address 253 Harald Alvestrand (editor) 254 Google 255 Kungsbron 2 256 Stockholm, 11122 257 Sweden 259 Email: harald@alvestrand.no