One document matched: draft-holmer-rmcat-transport-wide-cc-extensions-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="exp" docName="draft-holmer-rmcat-transport-wide-cc-extensions-01" ipr="trust200902">
<front>
<title abbrev="trnsprt-wide-cc-exts">RTP Extensions for Transport-wide Congestion Control</title>
<author fullname="Stefan Holmer" initials="S" surname="Holmer">
<organization>Google</organization>
<address>
<postal>
<street>Kungsbron 2</street>
<city>Stockholm</city>
<region></region>
<code>11122</code>
<country>Sweden</country>
</postal>
<email>holmer@google.com</email>
</address>
</author>
<author fullname="Magnus Flodman" initials="M" surname="Flodman">
<organization>Google</organization>
<address>
<postal>
<street>Kungsbron 2</street>
<city>Stockholm</city>
<region></region>
<code>11122</code>
<country>Sweden</country>
</postal>
<email>mflodman@google.com</email>
</address>
</author>
<author fullname="Erik Sprang" initials="E" surname="Sprang">
<organization>Google</organization>
<address>
<postal>
<street>Kungsbron 2</street>
<city>Stockholm</city>
<region></region>
<code>11122</code>
<country>Sweden</country>
</postal>
<email>sprang@google.com</email>
</address>
</author>
<date day="19" month="Oct" year="2015" />
<abstract>
<t>This document proposes an RTP header extension and an RTCP message
for use in congestion control algorithms for RTP-based media flows. It
adds transport-wide packet sequence numbers and corresponding feedback
message so that congestion control can be performed on a transport level
at the send-side, while keeping the receiver dumb.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>This document proposes RTP header extension containing a transport-wide
packet sequence number and an RTCP feedback message feeding back the
arrival times and sequence numbers of the packets received on a
connection.</t>
<t>Some of the benefits that these extensions bring are:</t>
<t><list style="symbols">
<t>The congestion control algorithms are easier to maintain and
improve as there is less synchronization between sender and receiver
versions needed. It should be possible to implement
<xref target="I-D.ietf-rmcat-gcc"></xref>,
<xref target="I-D.ietf-rmcat-nada"></xref> and
<xref target="I-D.ietf-rmcat-scream-cc"></xref> with the
proposed protocol.</t>
<t>More flexibility in what algorithms are used, as long as they are
having most of their logic on the send-side. For instance different
behavior can be used depending on if the rate produced is application
limited or not.</t>
</list></t>
</section>
<section title="Transport-wide Sequence Number">
<t></t>
<section title="Semantics">
<t>This RTP header extension is added on the transport layer, and uses
the same counter for all packets which are sent over the same
connection (for instance as defined by bundle).</t>
<t>The benefit with a transport-wide sequence numbers is two-fold:</t>
<t><list style="symbols">
<t>It is a better fit for congestion control as the congestion
controller doesn't operate on media streams, but on packet flows.</t>
<t>It allows for earlier packet loss detection (and recovery) since a
loss in stream A can be detected when a packet from stream B is
received, thus we don't have to wait until the next packet of stream A
is received.</t>
</list></t>
</section>
<section title="RTP header extension format">
<t>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.</t>
<figure>
<artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xBE | 0xDE | length=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID | L=1 |transport-wide sequence number | zero padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>An RTP header extension with a 16 bits sequence number attached to
all packets sent. This sequence number is incremented by 1 for each
packet being sent over the same socket.</t>
</section>
<section title="Signaling of use of this extension">
<t>When signalled in SDP, the standard mechanism for RTP header
extensions <xref target="RFC5285"></xref> is used:</t>
<t>a=extmap:5
http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions</t>
</section>
</section>
<section title="Transport-wide RTCP Feedback Message">
<t>To allow the most freedom possible to the sender, information about
each packet delivered is needed. The simplest way of accomplishing that is
to have the receiver send back a message containing an arrival timestamp
and a packet identifier for each packet received. This way, the receiver
is dumb and simply records arrival timestamps (A) of packets. The sender
keeps a map of in-flight packets, and upon feedback arrival it looks up
the on-wire timestamp (S) of the corresponding packet. From these two
timestamps the sender can compute metrics such as:</t>
<t><list style="symbols">
<t>Inter-packet delay variation: d(i) = A(i) - S(i) - (A(i-1) - S(i-1))</t>
<t>Estimated queueing delay: q(i) = A(i) - S(i) - min{j=i-1..i-w}(A(j) - S(j))</t>
</list></t>
<t>Since the sender gets feedback about each packet sent, it will be set
to better assess the cost of sending bursts of packets compared to aiming
at sending at a constant rate decided by the receiver.</t>
<t>Two down-sides with this approach are:</t>
<t><list style="symbols">
<t>It isn't possible to differentiate between lost feedback on the
downlink and lost packets on the uplink.</t>
<t>Increased feedback rate on the reverse direction.</t>
</list></t>
<t>From a congestion control perspective, lost feedback messages are handled by
ignoring packets which would have been reported as lost or received in the lost
feedback messages. This behavior is similar to how a lost RTCP receiver report
is handled.</t>
<t>It is recommended that a feedback message is sent for every frame
received, but in cases of low uplink bandwidth it is acceptable to send
them less frequently, e.g., for instance once per RTT, to reduce the overhead.</t>
<section title="Message format">
<t>The message is an RTCP message with payload type 206. RFC 3550
<xref target="RFC3550"></xref> defines the range, RFC 4585
<xref target="RFC3550"></xref> defines the specific PT value 206 and
the FMT value 15.</t>
<figure>
<artwork><![CDATA[
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=205 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| base sequence number | packet status count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reference time | fb pkt. count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| packet chunk | packet chunk |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| packet chunk | recv delta | recv delta |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| recv delta | recv delta | zero padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list hangIndent="12" style="hanging">
<t hangText="version (V):">2 bits
This field identifies the RTP version. The current version is 2.</t>
<t hangText="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.</t>
<t hangText="feedback message type (FMT):">5 bits
This field identifies the type of the FB message. It must have the value 15.</t>
<t hangText="payload type (PT):">8 bits
This is the RTCP packet type that identifies the packet as being an RTCP FB message. The value must be RTPFB = 205.</t>
<t hangText="SSRC of packet sender:">32 bits
The synchronization source identifier for the originator of this packet.</t>
<t hangText="SSRC of media source:">32 bits
The synchronization source identifier of the media source that this piece of feedback information is related to.
TODO: This is transport wide, do we just pick any of the media source SSRCs?
</t>
<t hangText="base sequence number:">16 bits
The transport-wide sequence number of the first packet in this feedback. This number is not necessarily increased for every feedback; in the case of reordering it may be decreased.</t>
<t hangText="packet status count:">16 bits
The number of packets this feedback contains status for, starting with the packet identified by the base sequence number.</t>
<t hangText="reference time:">24 bits
Signed integer indicating an absolute reference time in some (unknown) time base chosen by the sender of the feedback packets. The value is to be interpreted in multiples of 64ms. The first recv delta in this packet is relative to the reference time. The reference time makes it possible to calculate the delta between feedbacks even if some feedback packets are lost, since it always uses the same time base.</t>
<t hangText="feedback packet count:">8 bits
A counter incremented by one for each feedback packet sent. Used to detect feedback packet losses.</t>
<t hangText="packet chunk:">16 bits
A list of packet status chunks. These indicate the status of a number of packets starting with the one identified by base sequence number. See below for details.</t>
<t hangText="recv delta:">8 bits
For each "packet received" status, in the packet status chunks, a receive delta block will follow. See details below.</t>
</list></t>
<section title="Packet Status Symbols">
<t>The status of a packet is described using a 2-bit symbol:</t>
<t><list>
<t>00 Packet not received</t>
<t>01 Packet received, small delta</t>
<t>10 Packet received, large or negative delta</t>
<t>11 [Reserved]</t>
</list></t>
<t>Packets with status "Packet not received" should not necessarily be interpreted as lost. They might just not have arrived yet.</t>
<t>For each packet received with a delta, to the previous received packet, within +/-8191.75ms, a receive delta block is appended to the feedback message.</t>
<t>Note: In the case the base sequence number is decreased, creating a window overlapping the previous feedback messages, the status for any packets previously reported as received must be marked as "Packet not received" and thus no delta included for that symbol.</t>
</section>
<section title="Packet Status Chunks">
<t>Packet status is described in chunks, similar to a Loss RLE Report Block.
The are two different kinds of chunks:</t>
<t><list style="symbols">
<t>Run length chunk</t>
<t>Status vector chunk</t>
</list></t>
<t>All chunk types are 16 bits in length. The first bit of the chunk identifies whether it is an RLE chunk or a vector chunk.</t>
</section>
<section title="Run Length Chunk">
<t>A run length chunk starts with 0 bit, followed by a packet status symbol and
the run length of that symbol.</t>
<figure>
<artwork><![CDATA[
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| S | Run Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list hangIndent="12" style="hanging">
<t hangText="chunk type (T):">1 bit
A zero identifies this as a run length chunk.</t>
<t hangText="packet status symbol (S):">2 bits
The symbol repeated in this run. See above.</t>
<t hangText="run length (L):">13 bits
An unsigned integer denoting the run length.</t>
</list></t>
<figure>
<preamble>Example 1:</preamble>
<artwork><![CDATA[
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0 0|0 0 0 0 0 1 1 0 1 1 1 0 1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>This is a run of the "packet not received" status of length 221.</t>
<figure>
<preamble>Example 2:</preamble>
<artwork><![CDATA[
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|1 1|0 0 0 0 0 0 0 0 1 1 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>This is a run of the "packet received, w/o recv delta" status of length 24.</t>
</section>
<section title="Status Vector Chunk">
<t>A status vector chunk starts with a 1 bit to identify it as a vector chunk, followed by a symbol size bit and then 7 or 14 symbols, depending on the size bit.</t>
<figure>
<artwork><![CDATA[
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|S| symbol list |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list hangIndent="12" style="hanging">
<t hangText="chunk type (T):">1 bit
A one identifies this as a status vector chunk.</t>
<t hangText="symbol size (S):">1 bit
A zero means this vector contains only "packet received" (0) and
"packet not received" (1) symbols. This means we can compress each
symbol to just one bit, 14 in total.
A one means this vector contains the normal 2-bit symbols, 7 in total.</t>
<t hangText="symbol list:">14 bits
A list of packet status symbols, 7 or 14 in total.</t>
</list></t>
<figure>
<preamble>Example 1:</preamble>
<artwork><![CDATA[
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0 1 1 1 1 1 0 0 0 1 1 1 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>This chunk contains, in order:</t>
<t><list>
<t>1x "packet not received"</t>
<t>5x "packet received"</t>
<t>3x "packet not received"</t>
<t>3x "packet received"</t>
<t>2x "packet not received"</t>
</list></t>
<figure>
<preamble>Example 2:</preamble>
<artwork><![CDATA[
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|1|0 0 1 1 0 1 0 1 0 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>This chunk contains, in order:</t>
<t><list>
<t>1x "packet not received"</t>
<t>1x "packet received, w/o timestamp"</t>
<t>3x "packet received"</t>
<t>2x "packet not received"</t>
</list></t>
</section>
<section title="Receive Delta">
<t>Deltas are represented as multiples of 250us:</t>
<t><list style="symbols">
<t>If the "Packet received, small delta" symbol has been appended to the
status list, an 8-bit unsigned receive delta will be appended to recv
delta list, representing a delta in the range [0, 63.75] ms.</t>
<t>If the "Packet received, large or negative delta" symbol has been
appended to the status list, a 16-bit signed receive delta will be
appended to recv delta list, representing a delta in the range
[-8192.0, 8191.75] ms.</t>
<t>If the delta exceeds even the larger limits, a new feedback message must
be used, where the 24-bit base receive delta can cover very large gaps.</t>
</list></t>
<t>Note that the first receive delta is relative to the reference time indicated by the base receive delta.</t>
<t>TODO: Add examples.</t>
<t>The smaller receive delta upper bound of 63.75 ms means that this is only viable at about 1000/25.5 ~= 16 packets per second and above. With a packet size of 1200 bytes/packet that amounts to a bitrate of about 150 kbit/s.</t>
<t>The 0.25 ms resolution means that up to 4000 packets per second can be represented. With a 1200 bytes/packet payload, that amounts to 38.4 Mbit/s payload bandwidth.</t>
</section>
</section>
</section>
<section title="Overhead discussion">
<t>TODO: Examples of overhead in various scenarios.</t>
</section>
<section title="IANA considerations">
<t>Upon publication of this document as an RFC (if it is decided to
publish it), IANA is requested to register the string "goog-remb" in its
registry of "rtcp-fb" values in the SDP attribute registry group.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>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.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t></t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3550"?>
<?rfc include="reference.RFC.5285"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-rmcat-gcc"?>
<?rfc include="reference.I-D.ietf-rmcat-nada"?>
<?rfc include="reference.I-D.ietf-rmcat-scream-cc"?>
</references>
<section title="Change log">
<t></t>
<section title="First version">
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 15:00:41 |