One document matched: draft-holmer-rmcat-transport-wide-cc-extensions-00.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-00" 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="9" month="March" 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.alvestrand-rmcat-congestion"></xref>,
<xref target="I-D.zhu-rmcat-nada"></xref> and
<xref target="I-D.johansson-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></t>
<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:3
http://www.webrtc.org/experiments/rtp-hdrext/transport-sequence-number</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>Link propagation time delta: 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>Lost feedback messages shouldn't be a big problem as we could simply
ignore losses which coincide with lost feedback messages from a congestion
control perspective.</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.</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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| fb seq num |r| base sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| base receive time | sequence number ack vector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| recv delta | recv delta | recv delta |...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| recovery base sequence number | recovery vector |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list hangIndent="12" style="hanging">
<t hangText="fb sequence number:">Incremented by one for each feedback message sent. This can be used to figure out if feedback messages have been lost, so that the sender can avoid interpreting lost feedback messages on the downlink as lost media packets on the uplink.</t>
<t hangText="r:">Set if the recovery base sequence number and recovery vector are included.</t>
<t hangText="base transport sequence number:">The lowest received (not recovered) sequence number of this feedback message.</t>
<t hangText="base receive time:">Receive time of the base packet in multiples of 0.1 milliseconds, able to represent up to (2^16 - 1) * 0.1 = 6553.5 milliseconds. This allows probing of up to 96 Mbps with 1200 bytes packets.</t>
<t hangText="sequence number ack vector:">A bit vector where a 1 at position i represents that base sequence number + i + 1 has been received, and that a recv delta will be included in the feedback message. Recovered packets are not acked here, but will instead be acked using the recovery base sequence number and the recovery vector.</t>
<t hangText="recv delta:">A signed receive delta in multiples of 0.1 milliseconds relative to the base receive time, able to represent up to (2^9 - 1) * 0.1 = +/-51.1 milliseconds between packets. A feedback message contains the same number of recv deltas as there are 1s in the sequence number ack vector.</t>
<t hangText="recovery base sequence number:">The lowest recovered sequence number of this feedback message. It is optional and can be omitted if no sequence numbers were recovered. If it is included the r bit of the second byte should be set.</t>
<t hangText="recovery vector:">A bit vector where a 1 at position i represents that sequence number recovery base + i + 1 has been recovered and therefore the sender can stop sending it.</t>
</list></t>
<t>The length of a feedback message can be derived by counting the number of acked packets and acked feedback packets. Therefore several feedback messages can be stacked to ack more than 17 packets with a single RTCP.</t>
</section>
</section>
<section title="Overhead discussion">
<t>The overhead of this scheme will be higher than what the overhead is
for a regular audio/video call over RTP. To get an understanding of this
overhead, let's consider the following example:</t>
<t>A 2 Mbps, 30 fps, (208 pps) video is sent in one direction and audio
only is sent in the other direction. Average packet size of the video
stream is 1200 bytes. A feedback message is sent over RTCP sent for every
frame received.</t>
<t>The average feedback delay will be ~16.7 ms, compared to having logic
at the receiver and immediately sending an RTCP when an event is
detected.</t>
<t>The average protocol overhead is:</t>
<t><list style="symbols">
<t>30 packets per second and (5*4 + 3*4) * 30 * 8 = 7680 bits per
second.</t>
<t>Transport-wide sequence number overhead: 4 * 8 * 208 = 6656 bps.</t>
</list></t>
<t>For extremely asymmetric connections the feedback frequency could be
reduced.</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.alvestrand-rmcat-congestion"?>
<?rfc include="reference.I-D.zhu-rmcat-nada"?>
<?rfc include="reference.I-D.johansson-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 04:01:28 |