RTCP message for Receiver Estimated Maximum Bitrate
draft-alvestrand-rmcat-remb-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Author | Harald T. Alvestrand | ||
| Last updated | 2012-01-17 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-alvestrand-rmcat-remb-00
Network Working Group H. Alvestrand, Ed.
Internet-Draft Google
Intended status: Experimental January 17, 2012
Expires: July 20, 2012
RTCP message for Receiver Estimated Maximum Bitrate
draft-alvestrand-rmcat-remb-00
Abstract
This document proposes an RTCP message for use in experimentally-
deployed congestion control algorithms for RTP-based media flows.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on July 20, 2012.
Copyright Notice
Copyright (c) 2012 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Alvestrand Expires July 20, 2012 [Page 1]
Internet-Draft REMB January 2012
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Receiver Estimated Max Bitrate (REMB) . . . . . . . . . . . . . 3
2.1. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Message format . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Signaling of use of this extension . . . . . . . . . . . . 5
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . . 6
Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . . 7
A.1. From appendix of -congestion-01 to -00 . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Alvestrand Expires July 20, 2012 [Page 2]
Internet-Draft REMB January 2012
1. Introduction
This document proposes an RTCP feedback message signalling the
estimated total available bandwidth for a session.
If this function is available, it is possible to implement the
algorithm in [I-D.alvestrand-rtcweb-congestion], or other algorithms
with the same kind of feedback messaging need, in a fashion that
covers multiple RTP streams at once.
2. Receiver Estimated Max Bitrate (REMB)
2.1. Semantics
This feedback message is used to notify a sender of multiple media
streams over the same RTP session of the total estimated available
bit rate on the path to the receiving side of this RTP session.
Within the common packet header for feedback messages (as defined in
section 6.1 of [RFC4585]), the "SSRC of packet sender" field
indicates the source of the notification. The "SSRC of media source"
is not used and SHALL be set to 0. This usage of the value zero is
also done
The reception of a REMB message by a media sender conforming to this
specification SHALL result in the total bit rate sent on the RTP
session this message applies to being equal to or lower than the bit
rate in this message. The new bit rate constraint should be applied
as fast as reasonable. The sender is free to apply additional
bandwidth restrictions based on its own restrictions and estimates.
2.2. Message format
This document describes a message using the application specific
payload type. This is suitable for experimentation; upon
standardization, a specific type can be assigned for the purpose.
The message is an RTCP message with payload type 206. RFC 3550
[RFC3550] defines the range, RFC 4585 defines the specific PT value
206 and the FMT value 15.
Alvestrand Expires July 20, 2012 [Page 3]
Internet-Draft REMB January 2012
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT=15 | PT=206 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unique identifier 'R' 'E' 'M' 'B' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num SSRC | BR Exp | BR Mantissa |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC feedback |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
The fields V, P, SSRC, and length are defined in the RTP
specification [2], the respective meaning being summarized below:
version (V): (2 bits): This field identifies the RTP version. The
current version is 2.
padding (P) (1 bit): If set, the padding bit indicates that the
packet contains additional padding octets at the end that
are not part of the control information but are included
in the length field. Always 0.
Feedback message type (FMT) (5 bits): This field identifies the type
of the FB message and is interpreted relative to the type
(transport layer, payload- specific, or application layer
feedback). Always 15, application layer feedback
message. RFC 4585 section 6.4.
Payload type (PT) (8 bits): This is the RTCP packet type that
identifies the packet as being an RTCP FB message.
Always PSFB (206), Payload-specific FB message. RFC 4585
section 6.4.
Length (16 bits): The length of this packet in 32-bit words minus
one, including the header and any padding. This is in
line with the definition of the length field used in RTCP
sender and receiver reports [3]. RFC 4585 section 6.4.
Alvestrand Expires July 20, 2012 [Page 4]
Internet-Draft REMB January 2012
SSRC of packet sender (32 bits): The synchronization source
identifier for the originator of this packet. RFC 4585
section 6.4.
SSRC of media source (32 bits): Always 0; this is the same
convention as in [RFC5104] section 4.2.2.2 (TMMBN).
Unique identifier (32 bits): Always 'R' 'E' 'M' 'B' (4 ASCII
characters).
Num SSRC (8 bits): Number of SSRCs in this message.
BR Exp (6 bits): The exponential scaling of the mantissa for the
maximum total media bit rate value, ignoring all packet
overhead. The value is an unsigned integer [0..63], as
in RFC 5104 section 4.2.2.1.
BR Mantissa (18 bits): The mantissa of the maximum total media bit
rate (ignoring all packet overhead) that the sender of
the REMB estimates. The BR is the estimate of the
traveled path for the SSRCs reported in this message.
The value is an unsigned integer in number of bits per
second.
SSRC feedback (32 bits) Consists of one or more SSRC entries which
this feedback message applies to.
2.3. Signaling of use of this extension
Either end of an RTP session can send this message. There is no
signalling to indicate that the message can be understood.
OPEN ISSUE: Do we need signalling, and if so, how should it be done?
It does not seem harmful to send it when recipient does not
understand it, but negotiating it may give better behaviour when it
is not available (by falling back to per-RTP-session TMMBR messages).
3. IANA Considerations
This document requests no action of IANA.
This section can be removed upon publication as an RFC.
Alvestrand Expires July 20, 2012 [Page 5]
Internet-Draft REMB January 2012
4. Security Considerations
If the RTCP packet is not protected, it is possible to inject fake
RTCP packets that can increase or decrease bandwidth. This is not
different from security considerations for any other RTCP message.
5. Acknowledgements
This proposal has emerged from discussions between, among others,
Justin Uberti, Magnus Flodman, Patrik Westin, Stefan Holmer and
Henrik Lundin.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, February 2008.
6.2. Informative References
[I-D.alvestrand-rtcweb-congestion]
Lundin, H., Holmer, S., and H. Alvestrand, "A Google
Congestion Control Algorithm for Real-Time Communication
on the World Wide Web",
draft-alvestrand-rtcweb-congestion-01 (work in progress),
October 2011.
[RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in
RTP Streams", RFC 5450, March 2009.
Alvestrand Expires July 20, 2012 [Page 6]
Internet-Draft REMB January 2012
Appendix A. Change log
A.1. From appendix of -congestion-01 to -00
The timestamp option was removed. Discussion concluded that the RFC
5450 [RFC5450] "transmission time offset" header likely gives
accurate enough send-time information for our purposes.
Author's Address
Harald Alvestrand (editor)
Google
Kungsbron 2
Stockholm, 11122
Sweden
Email: harald@alvestrand.no
Alvestrand Expires July 20, 2012 [Page 7]