idnits 2.17.1 draft-johansson-rmcat-scream-cc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (June 18, 2014) is 3599 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-alvestrand-rmcat-congestion-02 == Outdated reference: A later version (-02) exists of draft-sarker-rmcat-cellular-eval-test-cases-00 == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-newcwv-06 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RMCAT WG I. Johansson 3 Internet-Draft Z. Sarker 4 Intended status: Informational Ericsson AB 5 Expires: December 20, 2014 June 18, 2014 7 Self-Clocked Rate Adaptation for Multimedia 8 draft-johansson-rmcat-scream-cc-01 10 Abstract 12 This memo describes a rate adaptation framework for conversational 13 video services. The solution conforms to the packet conservation 14 principle and uses a hybrid loss and delay based congestion control 15 algorithm. The framework is evaluated over both simulated bottleneck 16 scenarios as well as in a LTE (Long Term Evolution) system simulator 17 and is shown to achieve both low latency and high video throughput in 18 these scenarios. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 20, 2014. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Wireless (LTE) access properties . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. The adaptation framework . . . . . . . . . . . . . . . . . . 3 58 3.1. Congestion control . . . . . . . . . . . . . . . . . . . 7 59 3.2. Transmission scheduling . . . . . . . . . . . . . . . . . 8 60 3.3. Media rate control . . . . . . . . . . . . . . . . . . . 8 61 4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 5. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 9. Change history . . . . . . . . . . . . . . . . . . . . . . . 9 67 10. Algorithm details . . . . . . . . . . . . . . . . . . . . . . 10 68 10.1. Sender side functions . . . . . . . . . . . . . . . . . 10 69 10.1.1. RTP packet queue handling (a.k.a Sender queue) . . . 10 70 10.1.2. Transmission scheduler . . . . . . . . . . . . . . . 11 71 10.1.3. Reception of RTCP feedback in sender . . . . . . . . 13 72 10.1.4. Congestion window adjustment . . . . . . . . . . . . 15 73 10.1.5. Video encoder . . . . . . . . . . . . . . . . . . . 16 74 10.1.6. Video encoder rate adaptation . . . . . . . . . . . 17 75 10.2. Receiver side functions . . . . . . . . . . . . . . . . 19 76 10.2.1. Reception of RTP packet . . . . . . . . . . . . . . 19 77 11. Simulations . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 11.1. DL . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 79 11.1.1. RTT 40ms 3km/h . . . . . . . . . . . . . . . . . . . 21 80 11.1.2. RTT 40ms 30km/h . . . . . . . . . . . . . . . . . . 22 81 11.2. UL . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 82 11.2.1. RTT 40ms 3km/h . . . . . . . . . . . . . . . . . . . 23 83 11.2.2. RTT 40ms 30km/h . . . . . . . . . . . . . . . . . . 23 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 85 12.1. Normative References . . . . . . . . . . . . . . . . . . 24 86 12.2. Informative References . . . . . . . . . . . . . . . . . 24 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 89 1. Introduction 91 Rate adaptation is considered as an important part of a interactive 92 realtime communication as the transmission channel bandwidth may vary 93 over period of time. Wireless access such as LTE (Long Term 94 Evolution), which is an integral part of the current Internet, 95 increases the importance of rate adaptation as the channel bandwidth 96 of a default LTE bearer [QoS-3GPP] can change considerably in a very 97 short time frame. Thus a rate adaptation solution for interactive 98 realtime media, such as WebRTC, in LTE must be both quick and also 99 able to operate over a large span in available channel bandwidth. 100 This memo describes a solution that borrows the self-clocking 101 principle of TCP and combines it with a new delay based rate 102 adaptation algorithm, LEDBAT [RFC6817]. Because neither TCP nor 103 LEDBAT was designed for interactive realtime media, a few extra 104 features are needed to make the concept work well with in this 105 context. This memo describes these extra features. 107 1.1. Wireless (LTE) access properties 109 [I-D.draft-sarker-rmcat-cellular-eval-test-cases] introduces the 110 complications that can be observed in wireless environments. 111 Wireless access such as LTE can typically not guarantee a given 112 bandwidth, this holds for true especially for default bearers. The 113 network throughput may vary considerably for instance in cases where 114 the wireless terminal is moving around. 116 Unlike wireline bottlenecks with large statistical multiplexing it is 117 not possible to try to maintain a given bitrate when congestion is 118 detected with the hope that other flows will yield, this because 119 there are generally few other flows competing for the same 120 bottleneck. Each user gets its own variable throughput bottleneck, 121 where the throughput depends on factors like channel quality, load 122 and historical throughput. The bottom line is thus, if the 123 throughput drops, the sender has no other option than to reduce the 124 bitrate. In addition, the grace time, i.e. allowed reaction time 125 from the time that the congestion is detected until a reaction in 126 terms of a rate reduction is effected, is generally very short, in 127 the order of one RTT (Round Trip Time). 129 2. Terminology 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC2119 [RFC2119] 135 3. The adaptation framework 137 The adaptation framework has similarities to concepts like TFWC 138 [TFWC]. One important property is self-clocking and compliance to 139 the packet conservation principle. The packet conservation principle 140 is described as an important key-factor behind the protection of 141 networks from congestion [FACK]. 143 The packet conservation principle is realized by including a vector 144 of the sequence numbers of received packets in the feedback from the 145 receiver back to the sender, the sender keeps a list of transmitted 146 packets and their respective sizes. This information is then used to 147 determine how many bytes can be transmitted. A congestion window 148 puts an upper limit on how many bytes can be in flight, i.e. 149 transmitted but not yet acknowledged. The congestion window is 150 determined in a way similar to LEDBAT. This ensures that the e2e 151 latency is kept low. The basic functionality is quite simple, there 152 are however a few steps to take to make the concept work with 153 conversational media. These will be briefly described in sections 154 Section 3.1 to Section 3.3. 156 The feedback is over RTCP [RFC3550] and is based on [RFC4585]. It is 157 implemented as a transport layer feedback message, see proposed 158 example in Figure 1. The feedback control information part (FCI) 159 consists of the following elements. 161 o Timestamp: A timestamp value indicating when the last packet was 162 received which makes it possible to compute the one way (extra) 163 delay (OWD). 165 o The ACK list (Highest received sequence number + ACK vector): 166 Makes it possible to detect lost packets and determine the number 167 of bytes in flight. 169 o ECN (Explicit Congestion Notification) echo: Makes it possible to 170 indicate if packets are ECN-CE (ECN Congestion Experienced) 171 marked. The use for the 8 ECN echo bits is T.B.D. 173 o Source quench bit (Q): Makes it possible to request the sender to 174 reduce its congestion window. This is useful if WebRTC media is 175 received from many hosts and it becomes necessary to balance the 176 bitrates between the streams. The exact behavior and use for the 177 source quench bit is T.B.D. 179 0 1 2 3 180 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 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 |V=2|P| FMT | PT | length | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | SSRC of packet sender | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | SSRC of media source | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Timestamp (32bits) | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Highest recv. seq. nr. (16b) | ECN echo |Q|R|R|R|R|R|R|R| 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | ACK vector (32b) | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 Figure 1: Transport layer feedback message 197 To make the feedback as frequent as possible, the feedback packets 198 are transmitted as reduced size RTCP according to [RFC5506]. 200 The timestamp clock time base is typically set to the same time base 201 as the media source in question but as the protocol described here is 202 not dependent on the media it can be set to a fixed value defined in 203 this specification. The ACK vector is here a bit vector that 204 indicates the reception of the last 1+32 = 33 RTP packets. The ACK 205 vector may also be RLE coded. 207 Section 10 describes the main algorithm details and how the feedback 208 is used. 210 ---------------------------- ----------------------------- 211 | Video encoder | | Video encoder | 212 ---------------------------- ----------------------------- 213 ^ | ^ ^ | ^ 214 (1)| (2)| (3)| (1)| (2)| (3)| 215 | RTP | | RTP | 216 | V | | V | 217 | ------------- | | ------------- | 218 ----------- | |-- ----------- | |-- 219 | Rate | (4) | Queue | | Rate | (4) | Queue | 220 | control |<----| | | control |<----| | 221 | | |RTP packets| | | |RTP packets| 222 ----------- | | ----------- | | 223 ------------- ------------- 224 | | 225 --------------- -------------- 226 (5)| |(5) 227 RTP RTP 228 | | 229 v v 230 -------------- ---------------- 231 | Network | (8) | Transmission | 232 | congestion |<-------->| scheduler | 233 | control | | | 234 -------------- ---------------- 235 ^ | 236 | (7) |(6) 237 ---------RTCP---------- RTP 238 | | 239 | v 240 ------------- 241 | UDP | 242 | socket | 243 ------------- 245 Figure 2: Rate adaptation framework 247 Figure 2 shows the functional overview of the adaptation framework. 248 Each media type or source implements rate control and a queue, where 249 encoded media frames are temporarily stored for transmission, the 250 figure shows the details for one two video sources. Video frames are 251 encoded and forwarded to the queue (2). The media rate adaptation 252 adapts to the age of the oldest RTP frame in the queue and controls 253 the video bitrate (1). It is also possible to make the video encoder 254 skip frames and thus temporarily reduce the frame rate if the queue 255 age exceeds a given threshold (3). The RTP packets are picked from 256 each queue based on some defined priority order or simply in a round 257 robin fashion (5). A transmission scheduler takes care of the 258 transmission of RTP packets, to be written to the UDP socket (6). In 259 the general case all media must go through the packet scheduler and 260 is allowed to be transmitted if the number of bytes in flight is less 261 than the congestion window. However audio frames can be allowed to 262 be transmitted as audio is typically low bitrate and thus contributes 263 little to congestion, this is however something that is left as an 264 implementation choice. RTCP packets are received (7) and the 265 information about bytes in flight and congestion window is exchanged 266 between the network congestion control and the transmission scheduler 267 (8). 269 The rate adaptation solution constitutes three parts; congestion 270 control, transmission scheduling and media rate adaptation. 272 3.1. Congestion control 274 The congestion control sets an upper limit on how much data can be in 275 the network (bytes in flight); this limit is called CWND (congestion 276 window) and is used in the transmission scheduling. 278 A congestion control method, similar to LEDBAT, measures the OWD (one 279 way delay). The congestion window is allowed to increase if the OWD 280 is below a predefined target, otherwise the congestion window 281 decreases. The delay target is typically set to 50-100ms. This 282 ensures that the OWD is kept low on the average. The reaction to 283 loss events is similar to that of loss based TCP, i.e. an instant 284 reduction of CWND. 286 LEDBAT is designed with file transfers as main use case which means 287 that the algorithm must be modified somewhat to work with rate- 288 limited sources such as video. The modifications are: 290 o Congestion window validation techniques. These are similar in 291 action as the method described in [I-D.ietf-tcpm-newcwv]. 293 o Fast start for bitrate increase. It makes the video bitrate ramp- 294 up within 3 to 5 seconds. The behavior is similar to TCP 295 slowstart. The fast start is exited when the OWD exceeds a given 296 threshold. 298 o Adaptive delay target. This helps the congestion control to 299 compete with FTP traffic to some degree. 301 3.2. Transmission scheduling 303 Transmission scheduling limits the output of data, given by the 304 relation between the number of bytes in flight and the congestion 305 window similar to TCP. Packet pacing is used to mitigate issues with 306 coalescing that may cause increased jitter in the media traffic. 308 3.3. Media rate control 310 The media rate control serves to adjust the media bitrate to ramp up 311 quickly enough to get a fair share of the system resources when link 312 throughput increases. 314 The reaction to reduced throughput must be prompt in order to avoid 315 getting too much data queued up in the sender frame queues. The 316 queuing delay is determined and the media bitrate is decreased if it 317 exceeds a threshold. 319 In cases where the sender frame queues increase rapidly such as the 320 case of a RAT (Radio Access Type) handover it may be necessary to 321 implement additional actions, such as discarding of encoded video 322 frames or frame skipping in order to ensure that the sender frame 323 queues are drained quickly. Frame skipping means that the frame rate 324 is temporarily reduced. Discarding of old video frames is a more 325 efficient way to reduce latency than frame skipping but it comes with 326 a requirement to repair codec state. 328 4. Conclusion 330 This memo describes a congestion control framework for RMCAT that it 331 is particularly good at handling the quickly changing condition in 332 wireless network such as LTE. The solution conforms to the packet 333 conservation principle and leverages on novel congestion control 334 algorithms and recent TCP research, together with media bitrate 335 determined by sender queuing delay and given delay thresholds. The 336 solution has shown potential to meet the goals of high link 337 utilization and prompt reaction to congestion. The solution is 338 realized with a new RFC4585 transport layer feedback message. 340 5. Open issues 342 A list of open issues. 344 o Describe how the RTCP feedback described in this memo is handled 345 by mixers in various scenarios 347 o Describe how clock drift compensation is done 349 o RTCP AVPF mode. Determine if AVPF immediate mode is to prefer, 350 see discussion in Section 11 352 o Determine use of Q bit 354 o Determine format and use of ECN echo field 356 o The example code in Section 10 assumes a video source where the 357 sizes of the video frames are scaled according to a scale-factor 358 to produce the desired bitrate. This may not be implementable in 359 a real-life encoder, hence the code in said section is tightly 360 connected to mentioned synthetic video source model. 362 6. Acknowledgements 364 We would like to thank the following persons for their comments, 365 questions and support during the work that led to this memo: Markus 366 Andersson, Bo Burman, Tomas Frankkila, Laurits Hamm, Hans Hannu, 367 Nikolas Hermanns, Stefan Haekansson, Erlendur Karlsson, Mats 368 Nordberg, Jonathan Samuelsson, Rickard Sjoeberg, Magnus Westerlund. 370 7. IANA Considerations 372 A new RFC4585 transport layer feedback message needs to be 373 standardized. 375 8. Security Considerations 377 The feedback can be vulnerable to attacks similar to those that can 378 affect TCP. It is therefore recommended that the RTCP feedback is at 379 least integrity protected. 381 9. Change history 383 A list of changes: 385 o -00 to -01 : Fixed a few bugs in example code 387 10. Algorithm details 389 This section describes the algorithm in a Java syntax. The code is 390 not complete however and wont compile, for instance Java class 391 constructors are omitted for brevity. Algorithm details that are 392 missing are: 394 o Fast start 396 o Congestion Window Validation 398 o Adjustment to competing flows 400 o Discard old video frames in sender queue 402 10.1. Sender side functions 404 10.1.1. RTP packet queue handling (a.k.a Sender queue) 406 The RTP packets produced by the video encoder are inserted in a FIFO 407 queue. The FIFO order may be overridden for instance if 408 retransmission of RTP packets is needed, in which case the RTP packet 409 to be retransmitted is put first in queue. 411 /* 412 * RtpPacket contains the RTP packet 413 * Details are omitted 414 */ 415 class RtpPacket { 417 }; 419 /* 420 * The SenderQItem is a container for SSRC, timestamp when 421 * item is added to the queue and the RTP packet itself 422 */ 423 class SenderQItem { 424 int SSRC; 425 int TS; 426 RtpPacket rtpPacket; 427 }; 429 /* 430 * The list implements functions like 431 * add(..) : add a SenderQItem 432 * get() : get the oldest Item 433 * remove() : remove the oldest item 434 * age() : get the queuing delay of the oldest packet 435 */ 436 ArrayList senderQ = new list ArrayList; 438 /* 439 * Add an RTP packet to the sender queue 440 */ 441 function addRtpPacket(int SSRC, RtpPacket rtpPacket) { 442 senderQ.add(new SenderQItem(SSRC,now,rtpPacket)); 443 } 445 10.1.2. Transmission scheduler 447 The RTP packet transmission procedure is executed every tp interval 448 where tp is computed according to the equation further down. 450 /* 451 * The TransmitItem is a container for SSRC, timestamp when 452 * item is transmitted to the queue and the RTP packet itself 453 */ 454 class TransmitItem { 455 int SSRC; 456 int TS_Tx; 457 int SN; 458 int size; 460 }; 462 /* 463 * The list implements functions like 464 * add(..) : add a SenderQItem 465 * get() : get the oldest Item 466 * remove() : remove the oldest item 467 * age() : get the queuing delay of the oldest packet 468 * find(..) : find and return the item that matches.... 469 */ 470 ArrayList transmitted = new ArrayList; 472 /* 473 * Constants 474 */ 475 int MSS_INIT = 1200; 477 /* 478 * Global variables 479 */ 480 int bytesInFlight = 0; 481 double tp = 0.001; 482 int mss = MSS_INIT; 483 int cwndMin = 2*mss; 485 /* 486 * Function that is called every tp interval 487 */ 488 function tryTransmit() { 489 RtpPacket rtpPacket = senderQ.get(); 490 if (bytesInFlight+rtpPacket.size < cwnd && rtpPacket != null) { 491 /* 492 * OK to transmit 493 * Transmit next RTP packet in the sender queue and remove 494 * the RTP packet from the sender queue 495 */ 496 sendRtp(rtpPacket); 497 senderQ.remove(); 499 /* 500 * Add info about transmitted RTP packet to transmitted list 501 * The RTP packet itself may be stored too to support 502 * retransmission 503 */ 504 transmitted.add( 505 new TransmitItem(rtpPacket.SSRC,now,rtpPacket.SN, 506 rtpPacket.size)); 508 /* 509 * update bytesInFlight 510 */ 511 bytesInFlight += rtpPacket.size; 513 /* 514 * compute tp, we assume a min bw of 50kbps and a min tp of 1ms 515 * for stable operation 516 * this function implements the packet pacing 517 */ 518 bw = cwnd*8/rtt; 519 tp = max(0.001,max(rtpPacket.size*8/max(50000,bw))); 521 /* 522 * Update MSS and cwndMin 523 */ 524 mss = max(mss,rtpPacket.size); 525 cwndMin = 2*mss; 526 } else { 527 /* 528 * Not OK to transmit 529 */ 530 tp = 0.001; 531 } 532 } 534 10.1.3. Reception of RTCP feedback in sender 536 From the RTCP feedback, the following information is used to adjust 537 the number of bytesInFlight and to update the bytesNewlyAcked, the 538 ackVector is also used to determine loss events. Furthermore TX_Rx 539 is used to determine owd. 541 /* 542 * RtcpPacket contains the feedback RTCP packet 543 * Details are omitted 544 */ 545 class RtcpPacket { 547 }; 549 /* 550 * Global variables 551 */ 552 double lastLossEvent = -1; 553 boolean lossEvent = false; 554 int bytesNewlyAcked = 0; 555 double owd = 0.0; 556 function rtcpFeedbackReceived(RtcpPacket rtcp) { 557 item = transmitted.find(rtcp.SSRC, rtcp.SN) 558 /* 559 * Update OWD according to RFC6817 560 * based on item.TS_Tx and rtcp.TS_Rx 561 */ 562 updatedOwd(); // Function not specified in this memo 564 /* 565 * Update the number of bytesInFlight and bytesNewlyAcked 566 * Remove items with sequence number lower than or equal to 567 * rtcp.SN. 568 * Sequence number wrap around is not considered in this code 569 */ 570 for (TransmitItem item : transmitted) { 571 if (item.SSRC == rtcp.SSRC && item.SN <= rtcp.SN) { 572 bytesInFlight -= item.size; 573 bytesNewlyAcked += item.size; 574 /* 575 * Remove item from transmitted list 576 */ 577 transmitted.remove(item); 578 } 579 } 580 /* 581 * Determine if a loss event has occurred 582 */ 583 if (now - lastLostEvent > rtt) { 584 /* 585 * A loss event is determined by a hole in the sequence 586 * number space in the ACK vector, a guard time of the 587 * last ACKed RTP SN is used to avoid false loss event 588 * detection in the presence of packet reordering in the 589 * network. 590 */ 591 /* 592 * Function loss event not specified in this memo 593 */ 594 lossEvent = isLossEvent(rtcp.SN, rtcp.ackVector); 596 if (lossEvent) 597 lastLostEvent = now; 598 } 600 /* 601 * Update the congestion window 602 */ 603 updateCwnd(); 605 } 607 10.1.4. Congestion window adjustment 609 The congestion window is adjusted for every received RTCP feedback. 611 /* 612 * Constants 613 */ 614 double cwndHeadroomMin = 1.0; 615 double cwndHeadroomMax = 2.0; 616 double gainUp = 1.0; 617 double gainDown = 1.0; 618 double beta = 0.8; 619 double OWD_TARGET = 0.08; 621 /* 622 * Global variables 623 */ 624 double owdTarget = OWD_TARGET; 625 double lastOwd = 0.0; 627 function updateCwnd() { 628 /* 629 * offTarget is a normalized deviation from the owdTarget 630 */ 631 offTarget = (owdTarget-owd)/owdTarget; 633 /* 634 * cwndHeadRoom gives indicates how much lower bytesInFlight 635 * can be compared to cwnd to allow a cwnd increase 636 */ 637 cwndHeadroom = cwndHeadroomMin+ 638 max(0.0,offTarget)*(cwndHeadroomMax-cwndHeadroomMin); 640 if (lossEvent) { 641 /* 642 * loss event detected, decrease congestion window 643 */ 644 cwnd = max(cwndMin, beta*cwnd); 645 lossEvent = false; 646 } 648 if (offTarget > 0) { 649 /* 650 * owd is lower that owdTarget, 651 * possible to increase cwnd 652 */ 653 if bytesInFlight*cwndHeadroom > cwnd { 654 /* 655 * Pipe is sufficiently filled with data, 656 * increase cwnd 657 */ 658 cwnd += gainUp * offTarget * 659 bytesNewlyAcked * mss / cwnd; 660 } 661 } else { 662 if (owd-lastOwd >= 0.0) { 663 /* 664 * Decrease cwnd quickly if owd is constant high or 665 * increasing 666 */ 667 rttFactor = Math.min(2.0,Math.max(0.1, getRtt())/0.1); 668 cwnd += gainDown * rttFactor * max(-3.0,offTarget) * 669 bytesNewlyAcked * mss / cwnd; 670 } else { 671 /* 672 * Decrease cwnd slowly if owd is declining 673 */ 674 cwnd += gainDown * max(-3.0,offTarget) * 675 bytesNewlyAcked * mss / cwnd; 676 } 677 } 678 cwnd = max(cwndMin,cwnd); 679 lastOwd = owd; 680 bytesNewlyAcked = 0; 681 } 683 10.1.5. Video encoder 685 NOT_SPECIFIED means that the values need to be specifed based on 686 video codec properties. 688 /* 689 * Constants 690 */ 691 double scaleFactorMin = NOT_SPECIFIED_1; 692 double scaleFactorMax = NOT_SPECIFIED_2; 693 double framePeriod = NOT_SPECIFIED_3; 695 /* 696 * Global varaibles 697 */ 698 boolean skipFrame = false; 699 double scaleFactor = scaleFactorMin; 701 /* 702 * Function called for every grabbed video frame 703 */ 704 function encodeVideoFrame() { 705 if (!skipFrame) { 706 /* 707 * Details of encode function call depends on 708 * video encoder properties 709 */ 710 rtpPacket = encode(..., scaleFactor); 711 addRtpPacket(SSRC,rtpPacket); 712 } 713 adjustVideoBitrate(); 714 } 716 10.1.6. Video encoder rate adaptation 718 The video encoder rate is adjusted every RTT. The bitrate is 719 controlled by a scale factor that is bounded by [minScaleFactor 720 maxScaleFactor]. A history of the age of the oldest RTP packet in 721 the sender queue over the 5 latest RTTs is maintained (ageHist). 723 /* 724 * Constants 725 */ 726 int ageHistSizeMax = 5; 728 /* 729 * Global variables 730 */ 731 double lastTimeAdjustVideoBitrate = 0.0; 732 ArrayList ageHist = new ArrayList; 734 /* 735 * Function called every videoframe interval 736 */ 737 function adjustVideoBitrate() { 738 if (senderQ.age > skipFrameTh) 739 skipFrame = true; 740 else 741 skipFrame = false; 742 if (now-lastTimeAdjustVideoBitrate < framePeriod) 743 return; 744 ageHist.add(senderQ.age()); 745 if (ageHist.size >= ageHistSizeMax) { 746 age = ageHist.average(); // Compute average 747 owdFraction = owd/owdTarget; 748 if (age > framePeriod/2) { 749 /* 750 * Decrease the scale factor proportional to the age 751 */ 752 scaleFactor = max(scaleFactorMin, scaleFactor*(1.0-age)); 753 } else { 754 /* 755 * Increase the scale factor 756 */ 757 /* 758 * Put an upper limit on how fast the scalefactor can 759 * increase 760 */ 761 scaleLimit = max(scaleFactor, scaleFactorMax*0.1)*0.2; 762 /* 763 * Increment is slowed down 764 * if owd shows a tendency to increase 765 */ 766 rampUpSlowDown = min(5.0, max(rampUpSlowDown*0.9, 767 1.0+5.0*max(0.0,owdFraction-0.2))); 769 increment = 770 min(framePeriod*maxScaleFactor/ 771 (rampUpTime*rampUpSlowDown), scaleLimit); 772 scaleFactor = min(maxScaleFactor, scaleFactor+increment); 773 } 775 /* 776 * Remove oldest element in age history 777 */ 778 ageHist.remove(); 779 } 780 } 782 10.2. Receiver side functions 784 10.2.1. Reception of RTP packet 786 An RTCP packet is created and scheduled for transmission. If an RTCP 787 packet is already present and waiting for transmission, the new RTCP 788 packet will replace the older RTCP feedback packet. 790 /* 791 * Global variables 792 */ 793 RtcpPacket rtcpFeedbackPacket = null; 794 ArrayList rtpSn = new ArrayList; 796 /* 797 * New RTP packet received 798 */ 799 function rtpReceived(rtp) { 800 rtpSn.add(rtp.SN); 802 /* 803 * A new RTCP feedback is prepared for transmission, 804 * due to RTCP bandwidth and timing rules it may happen that 805 * an RTCP feedback has not been transmitted when a new 806 * feedback packet is generated. To make feedback as timely 807 * as possible, older unsent feedback packets should be replaced 808 * by new feedback packets. 809 */ 810 rtcpFeedbackPacket = RtcpFeedbackPacket(SSRC,now,rtp.SN,rtpSn) 812 /* 813 * Decode RTP packet and render media 814 */ 815 } 817 11. Simulations 819 A state of the art dynamic LTE simulation with settings according to 820 Table 1 , derived from 821 [I-D.draft-sarker-rmcat-cellular-eval-test-cases] was used to assess 822 the performance of the algorithm. The simulator models the whole 823 protocol chain including handover, radio propagation etc. 825 LTE simulation configuration 827 +-------------+-----------------------------------------------------+ 828 | Cellular | 21 cells (7 sites); 3GPP case 1 settings | 829 | layout | | 830 | System | 10MHz bandwidth, 2GHz carrier frequency, eNB | 831 | setup | transmission power 40W, MIMO transmission mode | 832 | Channel | Typical Urban | 833 | Propagation | Okumura-Hata model | 834 | model | | 835 | Scheduler | DL scheduler: Proportional fair. UL scheduler: | 836 | | Proportional fair | 837 | User | Poisson arrival based user arrival | 838 | generation | | 839 | Mobility | UE moves straight in a randomly selected direction, | 840 | | at a speed 3km/h or 30km/h, ideal handover model | 841 | | (no user plane interruption, no handover signaling) | 842 | Traffic | Video: Rate adaptive video, codec : H.264, bitrate | 843 | scenario | 150-1500kbps. RTCP BW: 75kbps. Audio: Frame size | 844 | | 20ms, bitrate 20kbps, frame skip feature enabled. | 845 | | FTP: 500kB objects corresponding to an average of | 846 | | 4Mbps load per cell for the DL test case and 2Mbps | 847 | | load per cell for the UL test case. | 848 +-------------+-----------------------------------------------------+ 850 Table 1 852 The self-clocked algorithm is compared against the Google congestion 853 control algorithm [I-D.alvestrand-rmcat-congestion]. The load level 854 i.e. the intensity of new video users and the FTP load is: 856 o DL simulations: Video users: 2 to 16 users/cell, FTP load: 4Mbps 858 o UL simulations: Video users: 1 to 10 users/cell, FTP load: 2Mbps 860 The latency is expressed as "packet 98%ile, user 95%ile delay", 861 meaning that the "98%ile delay" is determined for all users, i.e 98% 862 of the video frames or IP packets have a delay less than the "packet 863 98%ile delay" value. Based on this the "user 95%ile delay" is 864 determined, meaning that 95% of the users have a "packet 98%ile 865 delay" less than said "user 95%ile value", this is a relatively 866 strict metric but it gives a fairly good idea of how stable the video 867 (and audio playback) is. 869 The users/cell indications and the associated performance metrics 870 should not be treated as exact values as there is a lot of 871 dependencies in propagation models, antenna configurations, scheduler 872 implementations, other cross traffic involved. Therefore the tables 873 should be read as a comparison between congestion control algorithms 874 at the same given network conditions. Only the results with AQM 875 enabled are shown in the tables below. 877 In general the results indicate that SCReAM is more stable in terms 878 of latency and packet loss than GCC. Furthermore, SCReAM achieves 879 good throughput at low load levels in both uplink and downlink. 880 SCReAM implements the frame skipping mechansism in these simulations, 881 which means that the frame rate is reduced if the queuing delay in 882 the sender queue exceeds 100ms. The 30km/h test cases are more 883 challenging as the channel conditions vary more quickly, also in this 884 case SCReAM performs better than GCC. The performance can be further 885 improved if frames in the sender queue are discarded if they are too 886 old to be rendered in a meaningful way in the receiver. 888 The SCReAM simulations was done in AVPF early mode with an RTCP 889 feedback overhead of ~12kbps (including IP and UDP). The effect of 890 the AVPF early mode is however that the RTCP feedpack is not 891 transmitted for each received IP packet but rather for each video 892 frame and this can potentially cause a less stable self-clocking. 893 AVPF immediate mode should be tried out to see if it gives an 894 improvement. 896 11.1. DL 898 11.1.1. RTT 40ms 3km/h 900 GCC 902 +-----------------------------+-----+-----+-----+-----+------+------+ 903 | Users/cell | 2 | 4 | 6 | 8 | 12 | 16 | 904 +-----------------------------+-----+-----+-----+-----+------+------+ 905 | Video tail latency [ms] | 35 | 65 | 168 | 828 | 1028 | 1071 | 906 | IP packet tail latency [ms] | 35 | 65 | 168 | 826 | 1028 | 1073 | 907 | Average PLR [%] | 0.0 | 0.0 | 0.0 | 0.5 | 3.8 | 9.4 | 908 | Average bitrate [kbps] | 423 | 371 | 358 | 332 | 247 | 177 | 909 +-----------------------------+-----+-----+-----+-----+------+------+ 911 Table 2 912 SCReAM 914 +-----------------------------+------+-----+-----+-----+-----+-----+ 915 | Users/cell | 2 | 4 | 6 | 8 | 12 | 16 | 916 +-----------------------------+------+-----+-----+-----+-----+-----+ 917 | Video tail latency [ms] | 126 | 192 | 192 | 258 | 412 | 559 | 918 | IP packet tail latency [ms] | 92 | 126 | 139 | 171 | 233 | 293 | 919 | Average PLR [%] | 0.0 | 0.0 | 0.0 | 0.1 | 0.2 | 0.9 | 920 | Average bitrate [kbps] | 1202 | 812 | 575 | 461 | 328 | 232 | 921 +-----------------------------+------+-----+-----+-----+-----+-----+ 923 Table 3 925 11.1.2. RTT 40ms 30km/h 927 GCC 929 +----------------------------+-----+-----+-----+------+------+------+ 930 | Users/cell | 2 | 4 | 6 | 8 | 12 | 16 | 931 +----------------------------+-----+-----+-----+------+------+------+ 932 | Video tail latency [ms] | 64 | 237 | 847 | 1304 | 2023 | 2195 | 933 | IP packet tail latency | 63 | 237 | 823 | 1281 | 2023 | 2192 | 934 | [ms] | | | | | | | 935 | Average PLR [%] | 0.0 | 0.0 | 0.6 | 2.1 | 15.2 | 50.5 | 936 | Average bitrate [kbps] | 342 | 332 | 261 | 201 | 105 | 61 | 937 +----------------------------+-----+-----+-----+------+------+------+ 939 Table 4 941 SCReAM 943 +-----------------------------+-----+-----+-----+-----+-----+------+ 944 | Users/cell | 2 | 4 | 6 | 8 | 12 | 16 | 945 +-----------------------------+-----+-----+-----+-----+-----+------+ 946 | Video tail latency [ms] | 229 | 263 | 350 | 414 | 748 | 1470 | 947 | IP packet tail latency [ms] | 134 | 164 | 197 | 224 | 438 | 920 | 948 | Average PLR [%] | 0.0 | 0.1 | 0.1 | 0.2 | 1.6 | 11.3 | 949 | Average bitrate [kbps] | 878 | 512 | 351 | 277 | 184 | 131 | 950 +-----------------------------+-----+-----+-----+-----+-----+------+ 952 Table 5 954 11.2. UL 955 11.2.1. RTT 40ms 3km/h 957 GCC 959 +-----------------------------+-----+-----+-----+-----+------+------+ 960 | Users/cell | 1 | 2 | 3 | 5 | 8 | 10 | 961 +-----------------------------+-----+-----+-----+-----+------+------+ 962 | Video tail latency [ms] | 93 | 103 | 183 | 261 | 607 | 494 | 963 | IP packet tail latency [ms] | 94 | 106 | 195 | 237 | 608 | 497 | 964 | Average PLR [%] | 0.4 | 0.3 | 2.0 | 1.9 | 19.2 | 27.2 | 965 | Average bitrate [kbps] | 770 | 757 | 655 | 612 | 381 | 361 | 966 +-----------------------------+-----+-----+-----+-----+------+------+ 968 Table 6 970 SCReAM 972 +-----------------------------+------+------+-----+-----+-----+-----+ 973 | Users/cell | 1 | 2 | 3 | 5 | 8 | 10 | 974 +-----------------------------+------+------+-----+-----+-----+-----+ 975 | Video tail latency [ms] | 111 | 124 | 174 | 182 | 209 | 268 | 976 | IP packet tail latency [ms] | 95 | 101 | 118 | 128 | 154 | 170 | 977 | Average PLR [%] | 0.0 | 0.0 | 0.4 | 0.4 | 1.2 | 2.6 | 978 | Average bitrate [kbps] | 1286 | 1123 | 856 | 663 | 451 | 362 | 979 +-----------------------------+------+------+-----+-----+-----+-----+ 981 Table 7 983 11.2.2. RTT 40ms 30km/h 985 GCC 987 +---------------------------+-----+-----+------+------+------+------+ 988 | Users/cell | 1 | 2 | 3 | 5 | 8 | 10 | 989 +---------------------------+-----+-----+------+------+------+------+ 990 | Video tail latency [ms] | 200 | 340 | 757 | 845 | 1020 | 1017 | 991 | IP packet tail latency | 225 | 374 | 747 | 829 | 1020 | 1017 | 992 | [ms] | | | | | | | 993 | Average PLR [%] | 4.8 | 4.0 | 21.7 | 14.7 | 80.0 | 91.1 | 994 | Average bitrate [kbps] | 718 | 681 | 557 | 456 | 266 | 230 | 995 +---------------------------+-----+-----+------+------+------+------+ 997 Table 8 998 SCReAM 1000 +-----------------------------+-----+-----+-----+-----+-----+------+ 1001 | Users/cell | 1 | 2 | 3 | 5 | 8 | 10 | 1002 +-----------------------------+-----+-----+-----+-----+-----+------+ 1003 | Video tail latency [ms] | 144 | 174 | 232 | 263 | 276 | 357 | 1004 | IP packet tail latency [ms] | 109 | 113 | 134 | 141 | 167 | 215 | 1005 | Average PLR [%] | 1.1 | 0.9 | 2.4 | 2.2 | 3.5 | 11.2 | 1006 | Average bitrate [kbps] | 848 | 698 | 572 | 456 | 302 | 240 | 1007 +-----------------------------+-----+-----+-----+-----+-----+------+ 1009 Table 9 1011 12. References 1013 12.1. Normative References 1015 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1016 Requirement Levels", BCP 14, RFC 2119, March 1997. 1018 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1019 Jacobson, "RTP: A Transport Protocol for Real-Time 1020 Applications", STD 64, RFC 3550, July 2003. 1022 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 1023 "Extended RTP Profile for Real-time Transport Control 1024 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 1025 2006. 1027 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 1028 Real-Time Transport Control Protocol (RTCP): Opportunities 1029 and Consequences", RFC 5506, April 2009. 1031 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 1032 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 1033 December 2012. 1035 12.2. Informative References 1037 [FACK] "Forward Acknowledgement: Refining TCP Congestion 1038 Control", 2006. 1040 [I-D.alvestrand-rmcat-congestion] 1041 Holmer, S., Cicco, L., Mascolo, S., and H. Alvestrand, "A 1042 Google Congestion Control Algorithm for Real-Time 1043 Communication", draft-alvestrand-rmcat-congestion-02 (work 1044 in progress), February 2014. 1046 [I-D.draft-sarker-rmcat-cellular-eval-test-cases] 1047 Sarker, Z., "Evaluation Test Cases for Interactive Real- 1048 Time Media over Cellular Networks", 1049 . 1052 [I-D.ietf-tcpm-newcwv] 1053 Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating 1054 TCP to support Rate-Limited Traffic", draft-ietf-tcpm- 1055 newcwv-06 (work in progress), March 2014. 1057 [QoS-3GPP] 1058 TS 23.203, 3GPP., "Policy and charging control 1059 architecture", June 2011, . 1062 [TFWC] University College London, "Fairer TCP-Friendly Congestion 1063 Control Protocol for Multimedia Streaming", December 2007, 1064 . 1067 Authors' Addresses 1069 Ingemar Johansson 1070 Ericsson AB 1071 Laboratoriegraend 11 1072 Luleae 977 53 1073 Sweden 1075 Phone: +46 730783289 1076 Email: ingemar.s.johansson@ericsson.com 1078 Zaheduzzaman Sarker 1079 Ericsson AB 1080 Laboratoriegraend 11 1081 Luleae 977 53 1082 Sweden 1084 Phone: +46 761153743 1085 Email: zaheduzzaman.sarker@ericsson.com