RMCAT WG I. Johansson
Internet-Draft Z. Sarker
Intended status: Informational Ericsson AB
Expires: December 28, 2014 June 26, 2014
Self-Clocked Rate Adaptation for Multimedia
draft-johansson-rmcat-scream-cc-02
Abstract
This memo describes a rate adaptation framework for conversational
video services. The solution conforms to the packet conservation
principle and uses a hybrid loss and delay based congestion control
algorithm. The framework is evaluated over both simulated bottleneck
scenarios as well as in a LTE (Long Term Evolution) system simulator
and is shown to achieve both low latency and high video throughput in
these scenarios.
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 December 28, 2014.
Copyright Notice
Copyright (c) 2014 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
include Simplified BSD License text as described in Section 4.e of
Johansson & Sarker Expires December 28, 2014 [Page 1]
Internet-Draft SCReAM June 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Wireless (LTE) access properties . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. The adaptation framework . . . . . . . . . . . . . . . . . . 3
3.1. Congestion control . . . . . . . . . . . . . . . . . . . 7
3.2. Transmission scheduling . . . . . . . . . . . . . . . . . 8
3.3. Media rate control . . . . . . . . . . . . . . . . . . . 8
4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Change history . . . . . . . . . . . . . . . . . . . . . . . 9
10. Algorithm details . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Sender side functions . . . . . . . . . . . . . . . . . 10
10.1.1. RTP packet queue handling (a.k.a Sender queue) . . . 10
10.1.2. Transmission scheduler . . . . . . . . . . . . . . . 11
10.1.3. Reception of RTCP feedback in sender . . . . . . . . 13
10.1.4. Congestion window adjustment . . . . . . . . . . . . 15
10.1.5. Video encoder . . . . . . . . . . . . . . . . . . . 16
10.1.6. Video encoder rate adaptation . . . . . . . . . . . 17
10.2. Receiver side functions . . . . . . . . . . . . . . . . 19
10.2.1. Reception of RTP packet . . . . . . . . . . . . . . 19
11. Simulations . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. DL . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.1.1. RTT 40ms 3km/h . . . . . . . . . . . . . . . . . . . 21
11.1.2. RTT 40ms 30km/h . . . . . . . . . . . . . . . . . . 22
11.2. UL . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.2.1. RTT 40ms 3km/h . . . . . . . . . . . . . . . . . . . 23
11.2.2. RTT 40ms 30km/h . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction
Rate adaptation is considered as an important part of a interactive
realtime communication as the transmission channel bandwidth may vary
over period of time. Wireless access such as LTE (Long Term
Evolution), which is an integral part of the current Internet,
increases the importance of rate adaptation as the channel bandwidth
of a default LTE bearer [QoS-3GPP] can change considerably in a very
Johansson & Sarker Expires December 28, 2014 [Page 2]
Internet-Draft SCReAM June 2014
short time frame. Thus a rate adaptation solution for interactive
realtime media, such as WebRTC, in LTE must be both quick and also
able to operate over a large span in available channel bandwidth.
This memo describes a solution that borrows the self-clocking
principle of TCP and combines it with a new delay based rate
adaptation algorithm, LEDBAT [RFC6817]. Because neither TCP nor
LEDBAT was designed for interactive realtime media, a few extra
features are needed to make the concept work well with in this
context. This memo describes these extra features.
1.1. Wireless (LTE) access properties
[I-D.draft-sarker-rmcat-cellular-eval-test-cases] introduces the
complications that can be observed in wireless environments.
Wireless access such as LTE can typically not guarantee a given
bandwidth, this holds for true especially for default bearers. The
network throughput may vary considerably for instance in cases where
the wireless terminal is moving around.
Unlike wireline bottlenecks with large statistical multiplexing it is
not possible to try to maintain a given bitrate when congestion is
detected with the hope that other flows will yield, this because
there are generally few other flows competing for the same
bottleneck. Each user gets its own variable throughput bottleneck,
where the throughput depends on factors like channel quality, load
and historical throughput. The bottom line is thus, if the
throughput drops, the sender has no other option than to reduce the
bitrate. In addition, the grace time, i.e. allowed reaction time
from the time that the congestion is detected until a reaction in
terms of a rate reduction is effected, is generally very short, in
the order of one RTT (Round Trip Time).
2. Terminology
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 RFC2119 [RFC2119]
3. The adaptation framework
The adaptation framework has similarities to concepts like TFWC
[TFWC]. One important property is self-clocking and compliance to
the packet conservation principle. The packet conservation principle
is described as an important key-factor behind the protection of
networks from congestion [FACK].
The packet conservation principle is realized by including a vector
of the sequence numbers of received packets in the feedback from the
Johansson & Sarker Expires December 28, 2014 [Page 3]
Internet-Draft SCReAM June 2014
receiver back to the sender, the sender keeps a list of transmitted
packets and their respective sizes. This information is then used to
determine how many bytes can be transmitted. A congestion window
puts an upper limit on how many bytes can be in flight, i.e.
transmitted but not yet acknowledged. The congestion window is
determined in a way similar to LEDBAT. This ensures that the e2e
latency is kept low. The basic functionality is quite simple, there
are however a few steps to take to make the concept work with
conversational media. These will be briefly described in sections
Section 3.1 to Section 3.3.
The feedback is over RTCP [RFC3550] and is based on [RFC4585]. It is
implemented as a transport layer feedback message, see proposed
example in Figure 1. The feedback control information part (FCI)
consists of the following elements.
o Timestamp: A timestamp value indicating when the last packet was
received which makes it possible to compute the one way (extra)
delay (OWD).
o The ACK list (Highest received sequence number + ACK vector):
Makes it possible to detect lost packets and determine the number
of bytes in flight.
o ECN (Explicit Congestion Notification) echo: Makes it possible to
indicate if packets are ECN-CE (ECN Congestion Experienced)
marked. The use for the 8 ECN echo bits is T.B.D.
o Source quench bit (Q): Makes it possible to request the sender to
reduce its congestion window. This is useful if WebRTC media is
received from many hosts and it becomes necessary to balance the
bitrates between the streams. The exact behavior and use for the
source quench bit is T.B.D.
Johansson & Sarker Expires December 28, 2014 [Page 4]
Internet-Draft SCReAM June 2014
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 | PT | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp (32bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Highest recv. seq. nr. (16b) | ECN echo |Q|R|R|R|R|R|R|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ACK vector (32b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Transport layer feedback message
To make the feedback as frequent as possible, the feedback packets
are transmitted as reduced size RTCP according to [RFC5506].
The timestamp clock time base is typically set to the same time base
as the media source in question but as the protocol described here is
not dependent on the media it can be set to a fixed value defined in
this specification. The ACK vector is here a bit vector that
indicates the reception of the last 1+32 = 33 RTP packets. The ACK
vector may also be RLE coded.
Section 10 describes the main algorithm details and how the feedback
is used.
Johansson & Sarker Expires December 28, 2014 [Page 5]
Internet-Draft SCReAM June 2014
---------------------------- -----------------------------
| Video encoder | | Video encoder |
---------------------------- -----------------------------
^ | ^ ^ | ^
(1)| (2)| (3)| (1)| (2)| (3)|
| RTP | | RTP |
| V | | V |
| ------------- | | ------------- |
----------- | |-- ----------- | |--
| Rate | (4) | Queue | | Rate | (4) | Queue |
| control |<----| | | control |<----| |
| | |RTP packets| | | |RTP packets|
----------- | | ----------- | |
------------- -------------
| |
--------------- --------------
(5)| |(5)
RTP RTP
| |
v v
-------------- ----------------
| Network | (8) | Transmission |
| congestion |<-------->| scheduler |
| control | | |
-------------- ----------------
^ |
| (7) |(6)
---------RTCP---------- RTP
| |
| v
-------------
| UDP |
| socket |
-------------
Figure 2: Rate adaptation framework
Johansson & Sarker Expires December 28, 2014 [Page 6]
Internet-Draft SCReAM June 2014
Figure 2 shows the functional overview of the adaptation framework.
Each media type or source implements rate control and a queue, where
encoded media frames are temporarily stored for transmission, the
figure shows the details for one two video sources. Video frames are
encoded and forwarded to the queue (2). The media rate adaptation
adapts to the age of the oldest RTP frame in the queue and controls
the video bitrate (1). It is also possible to make the video encoder
skip frames and thus temporarily reduce the frame rate if the queue
age exceeds a given threshold (3). The RTP packets are picked from
each queue based on some defined priority order or simply in a round
robin fashion (5). A transmission scheduler takes care of the
transmission of RTP packets, to be written to the UDP socket (6). In
the general case all media must go through the packet scheduler and
is allowed to be transmitted if the number of bytes in flight is less
than the congestion window. However audio frames can be allowed to
be transmitted as audio is typically low bitrate and thus contributes
little to congestion, this is however something that is left as an
implementation choice. RTCP packets are received (7) and the
information about bytes in flight and congestion window is exchanged
between the network congestion control and the transmission scheduler
(8).
The rate adaptation solution constitutes three parts; congestion
control, transmission scheduling and media rate adaptation.
3.1. Congestion control
The congestion control sets an upper limit on how much data can be in
the network (bytes in flight); this limit is called CWND (congestion
window) and is used in the transmission scheduling.
A congestion control method, similar to LEDBAT, measures the OWD (one
way delay). The congestion window is allowed to increase if the OWD
is below a predefined target, otherwise the congestion window
decreases. The delay target is typically set to 50-100ms. This
ensures that the OWD is kept low on the average. The reaction to
loss events is similar to that of loss based TCP, i.e. an instant
reduction of CWND.
LEDBAT is designed with file transfers as main use case which means
that the algorithm must be modified somewhat to work with rate-
limited sources such as video. The modifications are:
o Congestion window validation techniques. These are similar in
action as the method described in [I-D.ietf-tcpm-newcwv].
o Fast start for bitrate increase. It makes the video bitrate ramp-
up within 3 to 5 seconds. The behavior is similar to TCP
Johansson & Sarker Expires December 28, 2014 [Page 7]
Internet-Draft SCReAM June 2014
slowstart. The fast start is exited when the OWD exceeds a given
threshold.
o Adaptive delay target. This helps the congestion control to
compete with FTP traffic to some degree.
3.2. Transmission scheduling
Transmission scheduling limits the output of data, given by the
relation between the number of bytes in flight and the congestion
window similar to TCP. Packet pacing is used to mitigate issues with
coalescing that may cause increased jitter in the media traffic.
3.3. Media rate control
The media rate control serves to adjust the media bitrate to ramp up
quickly enough to get a fair share of the system resources when link
throughput increases.
The reaction to reduced throughput must be prompt in order to avoid
getting too much data queued up in the sender frame queues. The
queuing delay is determined and the media bitrate is decreased if it
exceeds a threshold.
In cases where the sender frame queues increase rapidly such as the
case of a RAT (Radio Access Type) handover it may be necessary to
implement additional actions, such as discarding of encoded video
frames or frame skipping in order to ensure that the sender frame
queues are drained quickly. Frame skipping means that the frame rate
is temporarily reduced. Discarding of old video frames is a more
efficient way to reduce latency than frame skipping but it comes with
a requirement to repair codec state.
4. Conclusion
This memo describes a congestion control framework for RMCAT that it
is particularly good at handling the quickly changing condition in
wireless network such as LTE. The solution conforms to the packet
conservation principle and leverages on novel congestion control
algorithms and recent TCP research, together with media bitrate
determined by sender queuing delay and given delay thresholds. The
solution has shown potential to meet the goals of high link
utilization and prompt reaction to congestion. The solution is
realized with a new RFC4585 transport layer feedback message.
Johansson & Sarker Expires December 28, 2014 [Page 8]
Internet-Draft SCReAM June 2014
5. Open issues
A list of open issues.
o Describe how the RTCP feedback described in this memo is handled
by mixers in various scenarios
o Describe how clock drift compensation is done
o RTCP AVPF mode. Determine if AVPF immediate mode is to prefer,
see discussion in Section 11
o Determine use of Q bit
o Determine format and use of ECN echo field
o The example code in Section 10 assumes a video source where the
sizes of the video frames are scaled according to a scale-factor
to produce the desired bitrate. This may not be implementable in
a real-life encoder, hence the code in said section is tightly
connected to mentioned synthetic video source model.
6. Acknowledgements
We would like to thank the following persons for their comments,
questions and support during the work that led to this memo: Markus
Andersson, Bo Burman, Tomas Frankkila, Laurits Hamm, Hans Hannu,
Nikolas Hermanns, Stefan Haekansson, Erlendur Karlsson, Mats
Nordberg, Jonathan Samuelsson, Rickard Sjoeberg, Magnus Westerlund.
7. IANA Considerations
A new RFC4585 transport layer feedback message needs to be
standardized.
8. Security Considerations
The feedback can be vulnerable to attacks similar to those that can
affect TCP. It is therefore recommended that the RTCP feedback is at
least integrity protected.
9. Change history
A list of changes:
o -01 to -02 : Updated GCC simulation results
o -00 to -01 : Fixed a few bugs in example code
Johansson & Sarker Expires December 28, 2014 [Page 9]
Internet-Draft SCReAM June 2014
10. Algorithm details
This section describes the algorithm in a Java syntax. The code is
not complete however and wont compile, for instance Java class
constructors are omitted for brevity. Algorithm details that are
missing are:
o Fast start
o Congestion Window Validation
o Adjustment to competing flows
o Discard old video frames in sender queue
10.1. Sender side functions
10.1.1. RTP packet queue handling (a.k.a Sender queue)
The RTP packets produced by the video encoder are inserted in a FIFO
queue. The FIFO order may be overridden for instance if
retransmission of RTP packets is needed, in which case the RTP packet
to be retransmitted is put first in queue.
Johansson & Sarker Expires December 28, 2014 [Page 10]
Internet-Draft SCReAM June 2014
/*
* RtpPacket contains the RTP packet
* Details are omitted
*/
class RtpPacket {
};
/*
* The SenderQItem is a container for SSRC, timestamp when
* item is added to the queue and the RTP packet itself
*/
class SenderQItem {
int SSRC;
int TS;
RtpPacket rtpPacket;
};
/*
* The list implements functions like
* add(..) : add a SenderQItem
* get() : get the oldest Item
* remove() : remove the oldest item
* age() : get the queuing delay of the oldest packet
*/
ArrayList<SenderQItem> senderQ = new list ArrayList<SenderQItem>;
/*
* Add an RTP packet to the sender queue
*/
function addRtpPacket(int SSRC, RtpPacket rtpPacket) {
senderQ.add(new SenderQItem(SSRC,now,rtpPacket));
}
10.1.2. Transmission scheduler
The RTP packet transmission procedure is executed every tp interval
where tp is computed according to the equation further down.
/*
* The TransmitItem is a container for SSRC, timestamp when
* item is transmitted to the queue and the RTP packet itself
*/
class TransmitItem {
int SSRC;
int TS_Tx;
int SN;
int size;
Johansson & Sarker Expires December 28, 2014 [Page 11]
Internet-Draft SCReAM June 2014
};
/*
* The list implements functions like
* add(..) : add a SenderQItem
* get() : get the oldest Item
* remove() : remove the oldest item
* age() : get the queuing delay of the oldest packet
* find(..) : find and return the item that matches....
*/
ArrayList<TransmitItem> transmitted = new ArrayList<TransmitItem>;
/*
* Constants
*/
int MSS_INIT = 1200;
/*
* Global variables
*/
int bytesInFlight = 0;
double tp = 0.001;
int mss = MSS_INIT;
int cwndMin = 2*mss;
/*
* Function that is called every tp interval
*/
function tryTransmit() {
RtpPacket rtpPacket = senderQ.get();
if (bytesInFlight+rtpPacket.size < cwnd && rtpPacket != null) {
/*
* OK to transmit
* Transmit next RTP packet in the sender queue and remove
* the RTP packet from the sender queue
*/
sendRtp(rtpPacket);
senderQ.remove();
/*
* Add info about transmitted RTP packet to transmitted list
* The RTP packet itself may be stored too to support
* retransmission
*/
transmitted.add(
new TransmitItem(rtpPacket.SSRC,now,rtpPacket.SN,
rtpPacket.size));
Johansson & Sarker Expires December 28, 2014 [Page 12]
Internet-Draft SCReAM June 2014
/*
* update bytesInFlight
*/
bytesInFlight += rtpPacket.size;
/*
* compute tp, we assume a min bw of 50kbps and a min tp of 1ms
* for stable operation
* this function implements the packet pacing
*/
bw = cwnd*8/rtt;
tp = max(0.001,max(rtpPacket.size*8/max(50000,bw)));
/*
* Update MSS and cwndMin
*/
mss = max(mss,rtpPacket.size);
cwndMin = 2*mss;
} else {
/*
* Not OK to transmit
*/
tp = 0.001;
}
}
10.1.3. Reception of RTCP feedback in sender
From the RTCP feedback, the following information is used to adjust
the number of bytesInFlight and to update the bytesNewlyAcked, the
ackVector is also used to determine loss events. Furthermore TX_Rx
is used to determine owd.
/*
* RtcpPacket contains the feedback RTCP packet
* Details are omitted
*/
class RtcpPacket {
};
/*
* Global variables
*/
double lastLossEvent = -1;
boolean lossEvent = false;
int bytesNewlyAcked = 0;
double owd = 0.0;
Johansson & Sarker Expires December 28, 2014 [Page 13]
Internet-Draft SCReAM June 2014
function rtcpFeedbackReceived(RtcpPacket rtcp) {
item = transmitted.find(rtcp.SSRC, rtcp.SN)
/*
* Update OWD according to RFC6817
* based on item.TS_Tx and rtcp.TS_Rx
*/
updatedOwd(); // Function not specified in this memo
/*
* Update the number of bytesInFlight and bytesNewlyAcked
* Remove items with sequence number lower than or equal to
* rtcp.SN.
* Sequence number wrap around is not considered in this code
*/
for (TransmitItem item : transmitted) {
if (item.SSRC == rtcp.SSRC && item.SN <= rtcp.SN) {
bytesInFlight -= item.size;
bytesNewlyAcked += item.size;
/*
* Remove item from transmitted list
*/
transmitted.remove(item);
}
}
/*
* Determine if a loss event has occurred
*/
if (now - lastLostEvent > rtt) {
/*
* A loss event is determined by a hole in the sequence
* number space in the ACK vector, a guard time of the
* last ACKed RTP SN is used to avoid false loss event
* detection in the presence of packet reordering in the
* network.
*/
/*
* Function loss event not specified in this memo
*/
lossEvent = isLossEvent(rtcp.SN, rtcp.ackVector);
if (lossEvent)
lastLostEvent = now;
}
/*
* Update the congestion window
*/
updateCwnd();
Johansson & Sarker Expires December 28, 2014 [Page 14]
Internet-Draft SCReAM June 2014
}
10.1.4. Congestion window adjustment
The congestion window is adjusted for every received RTCP feedback.
/*
* Constants
*/
double cwndHeadroomMin = 1.0;
double cwndHeadroomMax = 2.0;
double gainUp = 1.0;
double gainDown = 1.0;
double beta = 0.8;
double OWD_TARGET = 0.08;
/*
* Global variables
*/
double owdTarget = OWD_TARGET;
double lastOwd = 0.0;
function updateCwnd() {
/*
* offTarget is a normalized deviation from the owdTarget
*/
offTarget = (owdTarget-owd)/owdTarget;
/*
* cwndHeadRoom gives indicates how much lower bytesInFlight
* can be compared to cwnd to allow a cwnd increase
*/
cwndHeadroom = cwndHeadroomMin+
max(0.0,offTarget)*(cwndHeadroomMax-cwndHeadroomMin);
if (lossEvent) {
/*
* loss event detected, decrease congestion window
*/
cwnd = max(cwndMin, beta*cwnd);
lossEvent = false;
}
if (offTarget > 0) {
/*
* owd is lower that owdTarget,
* possible to increase cwnd
*/
Johansson & Sarker Expires December 28, 2014 [Page 15]
Internet-Draft SCReAM June 2014
if bytesInFlight*cwndHeadroom > cwnd {
/*
* Pipe is sufficiently filled with data,
* increase cwnd
*/
cwnd += gainUp * offTarget *
bytesNewlyAcked * mss / cwnd;
}
} else {
if (owd-lastOwd >= 0.0) {
/*
* Decrease cwnd quickly if owd is constant high or
* increasing
*/
rttFactor = Math.min(2.0,Math.max(0.1, getRtt())/0.1);
cwnd += gainDown * rttFactor * max(-3.0,offTarget) *
bytesNewlyAcked * mss / cwnd;
} else {
/*
* Decrease cwnd slowly if owd is declining
*/
cwnd += gainDown * max(-3.0,offTarget) *
bytesNewlyAcked * mss / cwnd;
}
}
cwnd = max(cwndMin,cwnd);
lastOwd = owd;
bytesNewlyAcked = 0;
}
10.1.5. Video encoder
NOT_SPECIFIED means that the values need to be specifed based on
video codec properties.
Johansson & Sarker Expires December 28, 2014 [Page 16]
Internet-Draft SCReAM June 2014
/*
* Constants
*/
double scaleFactorMin = NOT_SPECIFIED_1;
double scaleFactorMax = NOT_SPECIFIED_2;
double framePeriod = NOT_SPECIFIED_3;
/*
* Global varaibles
*/
boolean skipFrame = false;
double scaleFactor = scaleFactorMin;
/*
* Function called for every grabbed video frame
*/
function encodeVideoFrame() {
if (!skipFrame) {
/*
* Details of encode function call depends on
* video encoder properties
*/
rtpPacket = encode(..., scaleFactor);
addRtpPacket(SSRC,rtpPacket);
}
adjustVideoBitrate();
}
10.1.6. Video encoder rate adaptation
The video encoder rate is adjusted every RTT. The bitrate is
controlled by a scale factor that is bounded by [minScaleFactor
maxScaleFactor]. A history of the age of the oldest RTP packet in
the sender queue over the 5 latest RTTs is maintained (ageHist).
/*
* Constants
*/
int ageHistSizeMax = 5;
/*
* Global variables
*/
double lastTimeAdjustVideoBitrate = 0.0;
ArrayList<double> ageHist = new ArrayList<double>;
/*
* Function called every videoframe interval
Johansson & Sarker Expires December 28, 2014 [Page 17]
Internet-Draft SCReAM June 2014
*/
function adjustVideoBitrate() {
if (senderQ.age > skipFrameTh)
skipFrame = true;
else
skipFrame = false;
if (now-lastTimeAdjustVideoBitrate < framePeriod)
return;
ageHist.add(senderQ.age());
if (ageHist.size >= ageHistSizeMax) {
age = ageHist.average(); // Compute average
owdFraction = owd/owdTarget;
if (age > framePeriod/2) {
/*
* Decrease the scale factor proportional to the age
*/
scaleFactor = max(scaleFactorMin, scaleFactor*(1.0-age));
} else {
/*
* Increase the scale factor
*/
/*
* Put an upper limit on how fast the scalefactor can
* increase
*/
scaleLimit = max(scaleFactor, scaleFactorMax*0.1)*0.2;
/*
* Increment is slowed down
* if owd shows a tendency to increase
*/
rampUpSlowDown = min(5.0, max(rampUpSlowDown*0.9,
1.0+5.0*max(0.0,owdFraction-0.2)));
increment =
min(framePeriod*maxScaleFactor/
(rampUpTime*rampUpSlowDown), scaleLimit);
scaleFactor = min(maxScaleFactor, scaleFactor+increment);
}
/*
* Remove oldest element in age history
*/
ageHist.remove();
}
}
Johansson & Sarker Expires December 28, 2014 [Page 18]
Internet-Draft SCReAM June 2014
10.2. Receiver side functions
10.2.1. Reception of RTP packet
An RTCP packet is created and scheduled for transmission. If an RTCP
packet is already present and waiting for transmission, the new RTCP
packet will replace the older RTCP feedback packet.
/*
* Global variables
*/
RtcpPacket rtcpFeedbackPacket = null;
ArrayList<integer> rtpSn = new ArrayList<integer>;
/*
* New RTP packet received
*/
function rtpReceived(rtp) {
rtpSn.add(rtp.SN);
/*
* A new RTCP feedback is prepared for transmission,
* due to RTCP bandwidth and timing rules it may happen that
* an RTCP feedback has not been transmitted when a new
* feedback packet is generated. To make feedback as timely
* as possible, older unsent feedback packets should be replaced
* by new feedback packets.
*/
rtcpFeedbackPacket = RtcpFeedbackPacket(SSRC,now,rtp.SN,rtpSn)
/*
* Decode RTP packet and render media
*/
}
11. Simulations
A state of the art dynamic LTE simulation with settings according to
Table 1 , derived from
[I-D.draft-sarker-rmcat-cellular-eval-test-cases] was used to assess
the performance of the algorithm. The simulator models the whole
protocol chain including handover, radio propagation etc.
Johansson & Sarker Expires December 28, 2014 [Page 19]
Internet-Draft SCReAM June 2014
LTE simulation configuration
+-------------+-----------------------------------------------------+
| Cellular | 21 cells (7 sites); 3GPP case 1 settings |
| layout | |
| System | 10MHz bandwidth, 2GHz carrier frequency, eNB |
| setup | transmission power 40W, MIMO transmission mode |
| Channel | Typical Urban |
| Propagation | Okumura-Hata model |
| model | |
| Scheduler | DL scheduler: Proportional fair. UL scheduler: |
| | Proportional fair |
| User | Poisson arrival based user arrival |
| generation | |
| Mobility | UE moves straight in a randomly selected direction, |
| | at a speed 3km/h or 30km/h, ideal handover model |
| | (no user plane interruption, no handover signaling) |
| Traffic | Video: Rate adaptive video, codec : H.264, bitrate |
| scenario | 150-1500kbps. RTCP BW: 75kbps. Audio: Frame size |
| | 20ms, bitrate 20kbps, frame skip feature enabled. |
| | FTP: 500kB objects corresponding to an average of |
| | 4Mbps load per cell for the DL test case and 2Mbps |
| | load per cell for the UL test case. |
+-------------+-----------------------------------------------------+
Table 1
The self-clocked algorithm is compared against the Google congestion
control algorithm [I-D.alvestrand-rmcat-congestion]. The load level
i.e. the intensity of new video users and the FTP load is:
o DL simulations: Video users: 2 to 16 users/cell, FTP load: 4Mbps
o UL simulations: Video users: 1 to 10 users/cell, FTP load: 2Mbps
The latency is expressed as "packet 98%ile, user 95%ile delay",
meaning that the "98%ile delay" is determined for all users, i.e 98%
of the video frames or IP packets have a delay less than the "packet
98%ile delay" value. Based on this the "user 95%ile delay" is
determined, meaning that 95% of the users have a "packet 98%ile
delay" less than said "user 95%ile value", this is a relatively
strict metric but it gives a fairly good idea of how stable the video
(and audio playback) is.
The users/cell indications and the associated performance metrics
should not be treated as exact values as there is a lot of
dependencies in propagation models, antenna configurations, scheduler
implementations, other cross traffic involved. Therefore the tables
Johansson & Sarker Expires December 28, 2014 [Page 20]
Internet-Draft SCReAM June 2014
should be read as a comparison between congestion control algorithms
at the same given network conditions. Only the results with AQM
enabled are shown in the tables below.
In general the results indicate that SCReAM is more stable in terms
of latency and packet loss than GCC. Furthermore, SCReAM achieves
good throughput at low load levels in both uplink and downlink.
SCReAM implements the frame skipping mechansism in these simulations,
which means that the frame rate is reduced if the queuing delay in
the sender queue exceeds 100ms. The 30km/h test cases are more
challenging as the channel conditions vary more quickly, also in this
case SCReAM performs better than GCC. The performance can be further
improved if frames in the sender queue are discarded if they are too
old to be rendered in a meaningful way in the receiver.
The SCReAM simulations was done in AVPF regular mode with an RTCP
feedback overhead of ~12kbps (including IP and UDP). The effect of
the AVPF regular mode is however that the RTCP feedback is not
transmitted for each received IP packet but rather for each video
frame and this can potentially cause a less stable self-clocking.
AVPF immediate mode should be tried out to see if it gives an
improvement.
11.1. DL
11.1.1. RTT 40ms 3km/h
GCC
+---------------------------+------+-----+-----+------+------+------+
| Users/cell | 2 | 4 | 6 | 8 | 12 | 16 |
+---------------------------+------+-----+-----+------+------+------+
| Video tail latency [ms] | 121 | 381 | 879 | 1026 | 1078 | 1182 |
| IP packet tail latency | 129 | 418 | 882 | 1027 | 1083 | 1228 |
| [ms] | | | | | | |
| Average PLR [%] | 0.0 | 0.1 | 0.5 | 2.0 | 6.4 | 15.5 |
| Average bitrate [kbps] | 1153 | 857 | 605 | 462 | 306 | 210 |
+---------------------------+------+-----+-----+------+------+------+
Table 2
Johansson & Sarker Expires December 28, 2014 [Page 21]
Internet-Draft SCReAM June 2014
SCReAM
+-----------------------------+------+-----+-----+-----+-----+-----+
| Users/cell | 2 | 4 | 6 | 8 | 12 | 16 |
+-----------------------------+------+-----+-----+-----+-----+-----+
| Video tail latency [ms] | 126 | 192 | 192 | 258 | 412 | 559 |
| IP packet tail latency [ms] | 92 | 126 | 139 | 171 | 233 | 293 |
| Average PLR [%] | 0.0 | 0.0 | 0.0 | 0.1 | 0.2 | 0.8 |
| Average bitrate [kbps] | 1202 | 812 | 575 | 461 | 328 | 232 |
+-----------------------------+------+-----+-----+-----+-----+-----+
Table 3
11.1.2. RTT 40ms 30km/h
GCC
+---------------------------+-----+-----+------+------+------+------+
| Users/cell | 2 | 4 | 6 | 8 | 12 | 16 |
+---------------------------+-----+-----+------+------+------+------+
| Video tail latency [ms] | 524 | 905 | 1108 | 1373 | 2273 | 2099 |
| IP packet tail latency | 528 | 902 | 1094 | 1400 | 2299 | 2177 |
| [ms] | | | | | | |
| Average PLR [%] | 0.1 | 0.5 | 1.8 | 4.3 | 15.8 | 34.6 |
| Average bitrate [kbps] | 941 | 523 | 309 | 217 | 108 | 67 |
+---------------------------+-----+-----+------+------+------+------+
Table 4
SCReAM
+-----------------------------+-----+-----+-----+-----+-----+------+
| Users/cell | 2 | 4 | 6 | 8 | 12 | 16 |
+-----------------------------+-----+-----+-----+-----+-----+------+
| Video tail latency [ms] | 229 | 263 | 350 | 414 | 748 | 1470 |
| IP packet tail latency [ms] | 134 | 164 | 197 | 224 | 438 | 920 |
| Average PLR [%] | 0.0 | 0.1 | 0.1 | 0.2 | 1.4 | 7.4 |
| Average bitrate [kbps] | 878 | 512 | 351 | 277 | 184 | 131 |
+-----------------------------+-----+-----+-----+-----+-----+------+
Table 5
11.2. UL
Johansson & Sarker Expires December 28, 2014 [Page 22]
Internet-Draft SCReAM June 2014
11.2.1. RTT 40ms 3km/h
GCC
+----------------------------+------+------+------+-----+-----+-----+
| Users/cell | 1 | 2 | 3 | 5 | 8 | 10 |
+----------------------------+------+------+------+-----+-----+-----+
| Video tail latency [ms] | 135 | 123 | 390 | 477 | 926 | 984 |
| IP packet tail latency | 147 | 129 | 352 | 473 | 929 | 982 |
| [ms] | | | | | | |
| Average PLR [%] | 0.0 | 0.1 | 0.3 | 0.2 | 1.4 | 1.8 |
| Average bitrate [kbps] | 1219 | 1153 | 1012 | 819 | 463 | 418 |
+----------------------------+------+------+------+-----+-----+-----+
Table 6
SCReAM
+-----------------------------+------+------+-----+-----+-----+-----+
| Users/cell | 1 | 2 | 3 | 5 | 8 | 10 |
+-----------------------------+------+------+-----+-----+-----+-----+
| Video tail latency [ms] | 111 | 124 | 174 | 182 | 209 | 268 |
| IP packet tail latency [ms] | 95 | 101 | 118 | 128 | 154 | 170 |
| Average PLR [%] | 0.0 | 0.0 | 0.1 | 0.4 | 0.1 | 0.1 |
| Average bitrate [kbps] | 1286 | 1123 | 856 | 663 | 451 | 362 |
+-----------------------------+------+------+-----+-----+-----+-----+
Table 7
11.2.2. RTT 40ms 30km/h
GCC
+----------------------------+------+-----+-----+-----+------+------+
| Users/cell | 1 | 2 | 3 | 5 | 8 | 10 |
+----------------------------+------+-----+-----+-----+------+------+
| Video tail latency [ms] | 434 | 733 | 913 | 996 | 1047 | 1066 |
| IP packet tail latency | 523 | 757 | 902 | 987 | 1046 | 1062 |
| [ms] | | | | | | |
| Average PLR [%] | 0.3 | 0.5 | 0.9 | 0.9 | 2.3 | 2.7 |
| Average bitrate [kbps] | 1154 | 939 | 753 | 546 | 288 | 241 |
+----------------------------+------+-----+-----+-----+------+------+
Table 8
Johansson & Sarker Expires December 28, 2014 [Page 23]
Internet-Draft SCReAM June 2014
SCReAM
+-----------------------------+-----+-----+-----+-----+-----+-----+
| Users/cell | 1 | 2 | 3 | 5 | 8 | 10 |
+-----------------------------+-----+-----+-----+-----+-----+-----+
| Video tail latency [ms] | 144 | 174 | 232 | 263 | 276 | 357 |
| IP packet tail latency [ms] | 109 | 113 | 134 | 141 | 167 | 215 |
| Average PLR [%] | 0.0 | 0.0 | 0.1 | 0.1 | 0.1 | 0.3 |
| Average bitrate [kbps] | 848 | 698 | 572 | 456 | 302 | 240 |
+-----------------------------+-----+-----+-----+-----+-----+-----+
Table 9
12. References
12.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.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, April 2009.
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
"Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
December 2012.
12.2. Informative References
[FACK] "Forward Acknowledgement: Refining TCP Congestion
Control", 2006.
[I-D.alvestrand-rmcat-congestion]
Holmer, S., Cicco, L., Mascolo, S., and H. Alvestrand, "A
Google Congestion Control Algorithm for Real-Time
Communication", draft-alvestrand-rmcat-congestion-02 (work
in progress), February 2014.
Johansson & Sarker Expires December 28, 2014 [Page 24]
Internet-Draft SCReAM June 2014
[I-D.draft-sarker-rmcat-cellular-eval-test-cases]
Sarker, Z., "Evaluation Test Cases for Interactive Real-
Time Media over Cellular Networks",
<http://www.ietf.org/id/
draft-sarker-rmcat-cellular-eval-test-cases-00.txt>.
[I-D.ietf-tcpm-newcwv]
Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating
TCP to support Rate-Limited Traffic", draft-ietf-tcpm-
newcwv-06 (work in progress), March 2014.
[QoS-3GPP]
TS 23.203, 3GPP., "Policy and charging control
architecture", June 2011, <http://www.3gpp.org/ftp/specs/
archive/23_series/23.203/23203-990.zip>.
[TFWC] University College London, "Fairer TCP-Friendly Congestion
Control Protocol for Multimedia Streaming", December 2007,
<http://www-dept.cs.ucl.ac.uk/staff/M.Handley/papers/
tfwc-conext.pdf>.
Authors' Addresses
Ingemar Johansson
Ericsson AB
Laboratoriegraend 11
Luleae 977 53
Sweden
Phone: +46 730783289
Email: ingemar.s.johansson@ericsson.com
Zaheduzzaman Sarker
Ericsson AB
Laboratoriegraend 11
Luleae 977 53
Sweden
Phone: +46 761153743
Email: zaheduzzaman.sarker@ericsson.com
Johansson & Sarker Expires December 28, 2014 [Page 25]