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