idnits 2.17.1 draft-alvestrand-rmcat-remb-03.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 (October 21, 2013) is 3840 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '2' on line 135 -- Looks like a reference, but probably isn't: '3' on line 159 ** Obsolete normative reference: RFC 5285 (Obsoleted by RFC 8285) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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 October 21, 2013 5 Expires: April 24, 2014 7 RTCP message for Receiver Estimated Maximum Bitrate 8 draft-alvestrand-rmcat-remb-03 10 Abstract 12 This document proposes an RTCP message for use in experimentally- 13 deployed congestion control algorithms for RTP-based media flows. 15 It also describes an absolute-value timestamp option for use in 16 bandwidth estimatoin. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 24, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Receiver Estimated Max Bitrate (REMB) . . . . . . . . . . . . . 3 60 2.1. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.2. Message format . . . . . . . . . . . . . . . . . . . . . . 3 62 2.3. Signaling of use of this extension . . . . . . . . . . . . 5 63 3. Absolute Send Time . . . . . . . . . . . . . . . . . . . . . . 5 64 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 6 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 70 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . . 7 71 A.1. From appendix of -congestion-01 to -00 . . . . . . . . . . 7 72 A.2. From -00 to -02 . . . . . . . . . . . . . . . . . . . . . . 7 73 A.3. From -02 to -03 . . . . . . . . . . . . . . . . . . . . . . 8 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 This document proposes an RTCP feedback message signalling the 79 estimated total available bandwidth for a session. 81 If this function is available, it is possible to implement the 82 algorithm in [I-D.alvestrand-rtcweb-congestion], or other algorithms 83 with the same kind of feedback messaging need, in a fashion that 84 covers multiple RTP streams at once. 86 2. Receiver Estimated Max Bitrate (REMB) 88 2.1. Semantics 90 This feedback message is used to notify a sender of multiple media 91 streams over the same RTP session of the total estimated available 92 bit rate on the path to the receiving side of this RTP session. 94 Within the common packet header for feedback messages (as defined in 95 section 6.1 of [RFC4585]), the "SSRC of packet sender" field 96 indicates the source of the notification. The "SSRC of media source" 97 is not used and SHALL be set to 0. This usage of the value zero is 98 also done in other RFCs. 100 The reception of a REMB message by a media sender conforming to this 101 specification SHALL result in the total bit rate sent on the RTP 102 session this message applies to being equal to or lower than the bit 103 rate in this message. The new bit rate constraint should be applied 104 as fast as reasonable. The sender is free to apply additional 105 bandwidth restrictions based on its own restrictions and estimates. 107 2.2. Message format 109 This document describes a message using the application specific 110 payload type. This is suitable for experimentation; upon 111 standardization, a specific type can be assigned for the purpose. 113 The message is an RTCP message with payload type 206. RFC 3550 114 [RFC3550] defines the range, RFC 4585 defines the specific PT value 115 206 and the FMT value 15. 117 0 1 2 3 118 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 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 |V=2|P| FMT=15 | PT=206 | length | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | SSRC of packet sender | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | SSRC of media source | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Unique identifier 'R' 'E' 'M' 'B' | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 | Num SSRC | BR Exp | BR Mantissa | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | SSRC feedback | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | ... | 134 The fields V, P, SSRC, and length are defined in the RTP 135 specification [2], the respective meaning being summarized below: 137 version (V): (2 bits): This field identifies the RTP version. The 138 current version is 2. 140 padding (P) (1 bit): If set, the padding bit indicates that the 141 packet contains additional padding octets at the end that 142 are not part of the control information but are included 143 in the length field. Always 0. 145 Feedback message type (FMT) (5 bits): This field identifies the type 146 of the FB message and is interpreted relative to the type 147 (transport layer, payload- specific, or application layer 148 feedback). Always 15, application layer feedback 149 message. RFC 4585 section 6.4. 151 Payload type (PT) (8 bits): This is the RTCP packet type that 152 identifies the packet as being an RTCP FB message. 153 Always PSFB (206), Payload-specific FB message. RFC 4585 154 section 6.4. 156 Length (16 bits): The length of this packet in 32-bit words minus 157 one, including the header and any padding. This is in 158 line with the definition of the length field used in RTCP 159 sender and receiver reports [3]. RFC 4585 section 6.4. 161 SSRC of packet sender (32 bits): The synchronization source 162 identifier for the originator of this packet. RFC 4585 163 section 6.4. 165 SSRC of media source (32 bits): Always 0; this is the same 166 convention as in [RFC5104] section 4.2.2.2 (TMMBN). 168 Unique identifier (32 bits): Always 'R' 'E' 'M' 'B' (4 ASCII 169 characters). 171 Num SSRC (8 bits): Number of SSRCs in this message. 173 BR Exp (6 bits): The exponential scaling of the mantissa for the 174 maximum total media bit rate value, ignoring all packet 175 overhead. The value is an unsigned integer [0..63], as 176 in RFC 5104 section 4.2.2.1. 178 BR Mantissa (18 bits): The mantissa of the maximum total media bit 179 rate (ignoring all packet overhead) that the sender of 180 the REMB estimates. The BR is the estimate of the 181 traveled path for the SSRCs reported in this message. 182 The value is an unsigned integer in number of bits per 183 second. 185 SSRC feedback (32 bits) Consists of one or more SSRC entries which 186 this feedback message applies to. 188 2.3. Signaling of use of this extension 190 We negotiate use of the message in SDP using a header extension 191 according to RFC 4585 section 4.2, with the value "goog-remb": 193 a=rtcp-fb: goog-remb 195 3. Absolute Send Time 197 Google has found that there are issues with relative send time offset 198 when packets are relayed at nodes that are not the source of the RTP 199 clock; it is hard to generate accurate offsets when you have to 200 regenerate the base clock from the incoming packets before you can 201 figure out what time to match; also, using signals from multiple 202 flows becomes impossible unless the timestamps come from a common 203 clock. 205 The Absolute Send Time extension is used to stamp RTP packets with a 206 timestamp showing the departure time from the system that put this 207 packet on the wire (or as close to this as we can manage). 209 o Name: "Absolute Sender Time" ; "RTP Header Extension for Absolute 210 Sender Time". 212 o Formal name: 213 "http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time". 215 o Wire format: 1-byte extension, 3 bytes of data. total 4 bytes 216 extra per packet (plus shared 4 bytes for all extensions present: 217 2 byte magic word 0xBEDE, 2 byte # of extensions). 219 o Encoding: Timestamp is in seconds, 24 bit 6.18 fixed point, 220 yielding 64s wraparound and 3.8us resolution (one increment for 221 each 477 bytes going out on a 1Gbps interface). 223 o Relation to NTP timestamps: abs_send_time_24 = (ntp_timestamp_64 224 >> 14) & 0x00ffffff ; NTP timestamp is the number of seconds since 225 the epoch, in 32.32 bit fixed point format. 227 o Notes: Packets are time stamped when going out, preferably close 228 to metal. Intermediate RTP relays (RTP entities possibly altering 229 the relative timing of packets in the stream) should remove the 230 extension or overwrite its value with its own timestamp. 232 When signalled in SDP, the standard mechanism for RTCP extensions 233 [RFC5285] is used: 235 a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time 237 4. IANA considerations 239 Upon publication of this document as an RFC (if it is decided to 240 publish it), IANA is requested to register the string "goog-remb" in 241 its registry of "rtcp-fb" values in the SDP attribute registry group. 243 5. Security Considerations 245 If the RTCP packet is not protected, it is possible to inject fake 246 RTCP packets that can increase or decrease bandwidth. This is not 247 different from security considerations for any other RTCP message. 249 6. Acknowledgements 251 This proposal has emerged from discussions between, among others, 252 Justin Uberti, Magnus Flodman, Patrik Westin, Stefan Holmer and 253 Henrik Lundin. 255 7. References 257 7.1. Normative References 259 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 260 Requirement Levels", BCP 14, RFC 2119, March 1997. 262 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 263 Jacobson, "RTP: A Transport Protocol for Real-Time 264 Applications", STD 64, RFC 3550, July 2003. 266 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 267 "Extended RTP Profile for Real-time Transport Control 268 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 269 July 2006. 271 [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, 272 "Codec Control Messages in the RTP Audio-Visual Profile 273 with Feedback (AVPF)", RFC 5104, February 2008. 275 [RFC5285] Singer, D. and H. Desineni, "A General Mechanism for RTP 276 Header Extensions", RFC 5285, July 2008. 278 7.2. Informative References 280 [I-D.alvestrand-rtcweb-congestion] 281 Holmer, S. and H. Alvestrand, "A Google Congestion Control 282 Algorithm for Real-Time Communication on the World Wide 283 Web", draft-alvestrand-rtcweb-congestion-03 (work in 284 progress), October 2012. 286 [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in 287 RTP Streams", RFC 5450, March 2009. 289 Appendix A. Change log 291 A.1. From appendix of -congestion-01 to -00 293 The timestamp option was removed. Discussion concluded that the RFC 294 5450 [RFC5450] "transmission time offset" header likely gives 295 accurate enough send-time information for our purposes. 297 A.2. From -00 to -02 299 No changes. These are "keepalive" publications. 301 A.3. From -02 to -03 303 Added information on the absolute-timestamp extension and on SDP 304 negotiation of REMB. 306 Author's Address 308 Harald Alvestrand (editor) 309 Google 310 Kungsbron 2 311 Stockholm, 11122 312 Sweden 314 Email: harald@alvestrand.no