RMCAT WG I. Johansson Internet-Draft Z. Sarker Intended status: Informational Ericsson AB Expires: December 19, 2014 June 17, 2014 Self-Clocked Rate Adaptation for Multimedia draft-johansson-rmcat-scream-cc-00 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 19, 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 19, 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. Algorithm details . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Sender side functions . . . . . . . . . . . . . . . . . . 10 9.1.1. RTP packet queue handling (a.k.a Sender queue) . . . 10 9.1.2. Transmission scheduler . . . . . . . . . . . . . . . 11 9.1.3. Reception of RTCP feedback in sender . . . . . . . . 13 9.1.4. Congestion window adjustment . . . . . . . . . . . . 15 9.1.5. Video encoder . . . . . . . . . . . . . . . . . . . . 16 9.1.6. Video encoder rate adaptation . . . . . . . . . . . . 17 9.2. Receiver side functions . . . . . . . . . . . . . . . . . 19 9.2.1. Reception of RTP packet . . . . . . . . . . . . . . . 19 10. Simulations . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. DL . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.1.1. RTT 40ms 3km/h . . . . . . . . . . . . . . . . . . . 21 10.1.2. RTT 40ms 30km/h . . . . . . . . . . . . . . . . . . 22 10.2. UL . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.2.1. RTT 40ms 3km/h . . . . . . . . . . . . . . . . . . . 23 10.2.2. RTT 40ms 30km/h . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 11.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 short time frame. Thus a rate adaptation solution for interactive Johansson & Sarker Expires December 19, 2014 [Page 2] Internet-Draft SCReAM June 2014 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 receiver back to the sender, the sender keeps a list of transmitted Johansson & Sarker Expires December 19, 2014 [Page 3] Internet-Draft SCReAM June 2014 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 19, 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 9 describes the main algorithm details and how the feedback is used. Johansson & Sarker Expires December 19, 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 19, 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 19, 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 19, 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 10 o Determine use of Q bit o Determine format and use of ECN echo field o The example code in Section 9 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. 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: Johansson & Sarker Expires December 19, 2014 [Page 9] Internet-Draft SCReAM June 2014 o Fast start o Congestion Window Validation o Adjustment to competing flows o Discard old video frames in sender queue 9.1. Sender side functions 9.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 19, 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 senderQ = new list ArrayList; /* * Add an RTP packet to the sender queue */ function addRtpPacket(int SSRC, RtpPacket rtpPacket) { senderQ.add(new SenderQItem(SSRC,now,rtpPacket)); } 9.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 19, 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 transmitted = new ArrayList; /* * 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 */ senderQ.remove(); sendRtp(rtpPacket); // Is it necessary to rewrite the RTP timestamp? /* * 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 19, 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; } } 9.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 19, 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.SSRC) { 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 19, 2014 [Page 14] Internet-Draft SCReAM June 2014 } 9.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 19, 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(3*mtuMax,cwnd); lastOwd = owd; } 9.1.5. Video encoder NOT_SPECIFIED means that the values need to be specifed based on video codec properties. Johansson & Sarker Expires December 19, 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(); } 9.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 ageHist = new ArrayList; /* * Function called every videoframe interval Johansson & Sarker Expires December 19, 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 19, 2014 [Page 18] Internet-Draft SCReAM June 2014 9.2. Receiver side functions 9.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 rtpSn = new ArrayList; /* * 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 */ } 10. 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 19, 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 19, 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 early mode with an RTCP feedback overhead of ~12kbps (including IP and UDP). The effect of the AVPF early mode is however that the RTCP feedpack 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. 10.1. DL 10.1.1. RTT 40ms 3km/h GCC +-----------------------------+-----+-----+-----+-----+------+------+ | Users/cell | 2 | 4 | 6 | 8 | 12 | 16 | +-----------------------------+-----+-----+-----+-----+------+------+ | Video tail latency [ms] | 35 | 65 | 168 | 828 | 1028 | 1071 | | IP packet tail latency [ms] | 35 | 65 | 168 | 826 | 1028 | 1073 | | Average PLR [%] | 0.0 | 0.0 | 0.0 | 0.5 | 3.8 | 9.4 | | Average bitrate [kbps] | 423 | 371 | 358 | 332 | 247 | 177 | +-----------------------------+-----+-----+-----+-----+------+------+ Table 2 Johansson & Sarker Expires December 19, 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.9 | | Average bitrate [kbps] | 1202 | 812 | 575 | 461 | 328 | 232 | +-----------------------------+------+-----+-----+-----+-----+-----+ Table 3 10.1.2. RTT 40ms 30km/h GCC +----------------------------+-----+-----+-----+------+------+------+ | Users/cell | 2 | 4 | 6 | 8 | 12 | 16 | +----------------------------+-----+-----+-----+------+------+------+ | Video tail latency [ms] | 64 | 237 | 847 | 1304 | 2023 | 2195 | | IP packet tail latency | 63 | 237 | 823 | 1281 | 2023 | 2192 | | [ms] | | | | | | | | Average PLR [%] | 0.0 | 0.0 | 0.6 | 2.1 | 15.2 | 50.5 | | Average bitrate [kbps] | 342 | 332 | 261 | 201 | 105 | 61 | +----------------------------+-----+-----+-----+------+------+------+ 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.6 | 11.3 | | Average bitrate [kbps] | 878 | 512 | 351 | 277 | 184 | 131 | +-----------------------------+-----+-----+-----+-----+-----+------+ Table 5 10.2. UL Johansson & Sarker Expires December 19, 2014 [Page 22] Internet-Draft SCReAM June 2014 10.2.1. RTT 40ms 3km/h GCC +-----------------------------+-----+-----+-----+-----+------+------+ | Users/cell | 1 | 2 | 3 | 5 | 8 | 10 | +-----------------------------+-----+-----+-----+-----+------+------+ | Video tail latency [ms] | 93 | 103 | 183 | 261 | 607 | 494 | | IP packet tail latency [ms] | 94 | 106 | 195 | 237 | 608 | 497 | | Average PLR [%] | 0.4 | 0.3 | 2.0 | 1.9 | 19.2 | 27.2 | | Average bitrate [kbps] | 770 | 757 | 655 | 612 | 381 | 361 | +-----------------------------+-----+-----+-----+-----+------+------+ 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.4 | 0.4 | 1.2 | 2.6 | | Average bitrate [kbps] | 1286 | 1123 | 856 | 663 | 451 | 362 | +-----------------------------+------+------+-----+-----+-----+-----+ Table 7 10.2.2. RTT 40ms 30km/h GCC +---------------------------+-----+-----+------+------+------+------+ | Users/cell | 1 | 2 | 3 | 5 | 8 | 10 | +---------------------------+-----+-----+------+------+------+------+ | Video tail latency [ms] | 200 | 340 | 757 | 845 | 1020 | 1017 | | IP packet tail latency | 225 | 374 | 747 | 829 | 1020 | 1017 | | [ms] | | | | | | | | Average PLR [%] | 4.8 | 4.0 | 21.7 | 14.7 | 80.0 | 91.1 | | Average bitrate [kbps] | 718 | 681 | 557 | 456 | 266 | 230 | +---------------------------+-----+-----+------+------+------+------+ Table 8 Johansson & Sarker Expires December 19, 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 [%] | 1.1 | 0.9 | 2.4 | 2.2 | 3.5 | 11.2 | | Average bitrate [kbps] | 848 | 698 | 572 | 456 | 302 | 240 | +-----------------------------+-----+-----+-----+-----+-----+------+ Table 9 11. References 11.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. 11.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 19, 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", . [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, . [TFWC] University College London, "Fairer TCP-Friendly Congestion Control Protocol for Multimedia Streaming", December 2007, . 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 19, 2014 [Page 25]