idnits 2.17.1 draft-gwock-rmcat-ccfs-02.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 seems to have RFC 2119 boilerplate text. -- The document date (August 29, 2019) is 1701 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 122, but not defined == Unused Reference: 'RFC6817' is defined on line 882, but no explicit reference was found in the text == Unused Reference: 'KEYWORDS' is defined on line 887, but no explicit reference was found in the text == Unused Reference: 'RFC1776' is defined on line 892, but no explicit reference was found in the text == Unused Reference: 'TRUTHS' is defined on line 896, but no explicit reference was found in the text == Unused Reference: 'RFC4566' is defined on line 906, but no explicit reference was found in the text == Unused Reference: 'RFC5513' is defined on line 910, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dt-rmcat-feedback-message' is defined on line 914, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dt-rmcat-adaptive-fec' is defined on line 919, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-09) exists of draft-ietf-avtcore-cc-feedback-message-02 Summary: 0 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RMCAT WG J. Gwock 3 Internet-Draft S. Lee 4 Intended Status: Experimental Line Plus 5 Expires: February 28, 2020 August 29, 2019 7 Congestion Control based on Forward path Status 8 draft-gwock-rmcat-ccfs-02 10 Abstract 12 This document describes CCFS(Congestion Control based on Forward path 13 Status), a rate adaptation scheme for interactive real-time media 14 applications, such as video conferencing. CCFS classifies the forward 15 paths's status as throttled, competing, probing and default which is 16 managed based on estimated parameters - bottleneck bandwidth, queue 17 delay and loss ratio. Considering only forward path status minimizes 18 influence of backward path's network events such as congestion. It is 19 also free from compatibility issues because it defines generalized 20 feedback message. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Copyright and License Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4 Detailed Description of CCFS . . . . . . . . . . . . . . . . . . 5 64 4.1 CCFS Negotiation . . . . . . . . . . . . . . . . . . . . . . 5 65 4.2 Rxer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.2.1 Feedback message format . . . . . . . . . . . . . . . . 6 67 4.2.2 CCFS feedback message size . . . . . . . . . . . . . . . 11 68 4.2.3 Handle CCFS control messages . . . . . . . . . . . . . . 11 69 4.3 Txer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 4.3.1 Constants . . . . . . . . . . . . . . . . . . . . . . . 12 71 4.3.2 Monitoring time on txer . . . . . . . . . . . . . . . . 13 72 4.3.3 Forward path bandwidth estimation . . . . . . . . . . . 14 73 4.3.4 Queue delay estimation and find increase pattern . . . . 15 74 4.3.5 Handle by status . . . . . . . . . . . . . . . . . . . . 16 75 4.3.5.1 Control event . . . . . . . . . . . . . . . . . . . 17 76 4.3.5.2 Handle control event by status . . . . . . . . . . . 18 77 4.4 CCFS Control messages . . . . . . . . . . . . . . . . . . . 21 78 4.4.1 Update preferred feedback interval . . . . . . . . . . . 21 79 4.4.2 Update preferred monitoring time . . . . . . . . . . . . 22 80 5 Implement . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 81 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 22 82 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 22 83 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 84 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 22 85 8.2 Informative References . . . . . . . . . . . . . . . . . . . 23 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 88 1 Introduction 90 Interactive real-time multi-media applications have a requirement 91 that controls their transmitting rate to adapt to bandwidth changes 92 and maintains low queuing delay over the network [RFC2914]. To solve 93 this challenge, many metrics such as RTT, packet loss and ECN are 94 used to reason the current network condition. 96 These real-time communication applications can have two streaming 97 paths - forward path to send media and backward path to receive 98 media. Moreover, each path is independent in most of the cases. For 99 example, if congestion occurs in the backward path, their is no need 100 to lower the transmitting rate on the forward path. However, if RTT 101 is used for congestion control, careful approaching is required 102 because RTT could be affected by not only the forward path's latency 103 but the backward path's latency. Although it is used to control the 104 transmitting rate, a metric or behavior such as RTT could be affected 105 by backward path's status and lead to a wrong decision. 107 CCFS uses metrics reflecting only the forward path's characteristic 108 in its algorithm to remove the influence of backward path's 109 conditions. 111 CCFS is a sender-based method to be free from compatibility issues. 112 That is, coexistence of multiple CCFS sender versions are available 113 because of algorithm variations or any other issues. To achieve this, 114 passive behavior of CCFS receiver and generalized feedback mechanisms 115 are defined in this memo. 117 2 Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 3 Overview 125 There are two modules to carry out a CCFS - Txer and Rxer. Txer is an 126 abbreviation for transmitter of CCFS and rxer means a receiver of 127 CCFS. Txer has a main active role to control the transmitting bitrate 128 by examining CCFS feedback messages from an associated rxer. Rxer 129 operates passively except when sending periodic CCFS feedback 130 messages. Txer and rxer manage multiple RTP streams if they are able 131 to share network paths. For example, multiple RTP streams using same 132 4 tuple - source ip, source port, destination ip and destination port 133 - would be associated with one txer and rxer. 135 To start CCFS, Txer and rxer must complete CCFS negotiation. 136 Negotiation should be accomplished on an external channel before 137 associating RTP session is established. 139 Rxer sends a periodic CCFS feedback message if CCFS feature is 140 negotiated. Txer estimates various metrics, mainly 3 metrics - 141 bottlenecked bandwidth, queue latency and loss ratio. Then, it makes 142 a decision on the forward path's status, which is one of throttled, 143 probing, competing and default. Txer operates target transmitting 144 rate based on the forward path's status. 146 Throttled status: detected the network queue is piling up. The 147 current transmitting rate should be lowered to empty the queue. 149 Competing status: detected cross traffics. The current 150 transmitting rate should be controlled to keep the queue latency 151 within targeting queue latency. 153 Probing status: The forward path's bottlenecked bandwidth may be 154 larger than the estimated bandwidth. The current transmitting rate 155 should be increased to probe the bottlenecked bandwidth. 157 Default status: does not belong to above 3 statuses. The current 158 transmitting rate should be controlled to keep the queue latency 159 within targeting queue latency. 161 While the probing status, the transmitting rate should be increased 162 to probe available bandwidth. However, it can lead to congestion and 163 this can harm the media quality. To minimize the side effects, 164 sending redundant packets like FEC packets is recommended[I-D.ietf- 165 dt-rmcat-adaptive-fec]. 167 4 Detailed Description of CCFS 169 4.1 CCFS Negotiation 171 CCFS must be negotiated before run. Defining the way of negotiation 172 is beyond the scope of this document. It may use SDP negotiation[RFC 173 4566] or an application defined protocol. However, parameters that 174 should be decided from negotiation are described here. 176 1. txer id (4 bytes): CCFS txer's ID should be decided. This is used 177 as SSRC in RTCP messages used by CCFS. So this value should unique 178 among transmitting RTP stream's SSRC. 180 2. rxer id (4 bytes): Also, the rxer associated with the txer must 181 have its own ID to use as SSRC in RTCP messages. 183 3. preferred feedback interval time: Rxer should know initial 184 feedback interval time. This interval may be changed by the txer in 185 the session. 187 4. preferred monitoring time: A feedback message has information of 188 received packets for this recent monitored time. 190 5. lower-layer protocol: RTP packets are sent on the UDP stack in 191 most cases. However it may be sent on other transport layers 192 dependding on the application requirement. A different congestion 193 control mechanism for different lower-layer protocol stack is 194 reasonable. To decide which congestion control mechanism should be 195 used, both rxer's transport layer and txer's transport layer is 196 needed. CCFS described in this memo supposes only UDP. However CCFS 197 txer may be modified for other transport layers. 199 4.2 Rxer 201 Rxer must know the preferred feedback interval time and its default 202 is 100 msec. This feedback interval time can be changed by RTCP 203 message sent by a txer. Rxer starts a periodic timer with that 204 interval when a session starts. When the timer fires an event rxer 205 determines whether sends a feedback or not. Rxer does not send 206 feedbacks if it has not received any packets and has not sent a 207 feedback before, even when the feedback interval time is passed. So 208 the first feedback message must include reports about one or more 209 received RTP packets. And the rxer should periodically send feedbacks 210 once it has sent the first feedbacks message. Even when there is no 211 received packets for the last feedback interval time, the rxer must 212 send a feedback because it could be an important signal. 214 One rxer is able to report multiple receiving RTP streams that seem 215 to use the same network path into one feedback message. This may make 216 a larger feedback message. If a feedback message size can be bigger 217 than MTU size, immediately rxer must sends the feedback even before 218 arriving the next feedback interval time. This feedback message's 219 monitored time value should be smaller than preferred feedback 220 interval time. Rxer must restart periodic timer without changing the 221 used interval right after sending the large feedback message. 223 4.2.1 Feedback message format 225 CCFS feedback message has a similar design goal as the [I-D.ietf-dt- 226 rmcat-feedback-message]. However, CCFS feedback message needs more 227 specific information for the CCFS algorithm. 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 |V=2|P| FMT | PT = 205 | length | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | SSRC (Rxer Id) | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | SSRC (Txer Id) | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | | 239 + CCFS Feedback Message Header + 240 | | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | | 243 + + 244 . Report-Block of 1st Media Source . 245 . . 246 . . 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 . . 249 . . 250 . . 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | | 253 + + 254 . Report-Block of Nth Media Source . 255 . . 256 . . 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 CCFS Feedback Message Format 261 The first 4 octets are the RTCP header, with PT=205 and FMT=CCFSFB, 262 and next 4 octets are the SSRC of the packet sender. CCFS replaces 263 SSRC with rxer id which should be obtained from the prior 264 negotiation. 266 Section 6.1 of [RFC4585] requires the RTCP header to be followed by 267 the SSRC of the media source being reported upon. Txer id is located 268 here instead of a specific RTP SSRC. And SSRC of the media source to 269 be reported is located within its Report-Block. 271 And next 8 octets are a CCFS Feedback Message Header that is 272 formatted as below: 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Report Time | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Feedback Sequence | Monitored Time | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 CCFS Feedback Message Header 284 Report Time(4 octets) : The time instant when this feedback message 285 is generated. The value of the report time is derived from the same 286 wall clock used to generate the NTP timestamp field in RTCP Sender 287 Report (SR) packets. It is formatted as the middle 32 bits of an NTP 288 format timestamp, as described in Section 4 of [RFC3550]. If the rxer 289 does not use NTP, it can be replaced with other measures such as 290 system up time, but the corresponding txer should be informed. 292 Feedback Sequence(2 octets) : Feedback message's own sequence number. 293 Txer finds out the feedback message was lost or not by watching this 294 feedback sequence's increasement. If a feedback message was lost, 295 Txer must ignore the period that is monitored by the lost feedback 296 message. Also Txer can figure out the forward path's packet loss 297 event if the reported packet sequence number is not continued even 298 though the feedback sequence is increase by one. 300 Monitored time(2 octets) : Actually observed millisecond duration to 301 generate a feedback message. Normally this is the time by txer 302 preferred and equal or bigger than the current feedback interval 303 time. However if the building feedback information causes bigger 304 message size than MTU size, rxer must immediately send the feedback 305 message with the real monitored time. So that monitored time can be 306 smaller than the current txer preferred monitor time. 308 Then multiple report blocks are followed. One report block describes 309 received packets from one media source that is identified by SSRC. 310 Report block size is not fixed and format is here: 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | SSRC of a Media Source | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Report Packet Count | Start Sequence Number | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Pkt-Element_1 | Pkt-Element_2 | ... | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 . . 322 . . 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Pkt-Element_n | Zero Padding | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 CCFS Report-Block 329 SSRC of a Media Source(4 octets) : RTP SSRC to report. 331 Report Packet Count(2 octets) : The reporting rtp packet count. If 332 this value is zero remain fields of this Report-Block should be 333 ignored. 335 Start Sequence Number(2 octets) : Start RTP sequence number of 336 reported packets. This is the sequence number of the following first 337 Pkt-Elements. 339 Pkt-Element(1 or 2 octets) : Describes for each packet. The count of 340 Pkt-Element is the total report packet count and these are sorted by 341 RTP sequence number order. 343 Pkt-Element format is here: 345 0 1 2 3 4 5 6 7 346 +-+-+-+-+-+-+-+-+ 347 |L|X| Abs-Delta | 348 +-+-+-+-+-+-+-+-+ 350 One octet Pkt-Element. X=0. 352 0 1 353 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 |L|X|E|N| Abs-Delta | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 Two octet Pkt-Element. L=0 and X=1. 360 L(1 bit) : Set for a lost packet. If set, Pkt-Element size is one 361 octet and remain 7 bits must be ignored. 363 X(1 bit) : Set if Pkt-Element size is two octets. 365 E(1 bit) : Set if received packet and ECN of IP header of RTP packet 366 is 0x3. 368 N(1 bit) : Set if packet interval of the received packet is negative. 369 This means the packet was out of ordered. 371 Abs-Delta(6 or 12 bits) : Packet arrival interval millisecond that is 372 presented in absolute value. The interval is the time between the 373 received time of the lower sequenced RTP packet and the received time 374 of the Pkt-Element's RTP packet. 376 If the Pkt-Element is the first, the Abs-Delta is an interval from a 377 monitoring start time and it is always positive. And the monitoring 378 start time is the subtracted monitored time from report time. 380 The Abs-Delta of remain Pkt-Elements is the absolute interval arrival 381 time between two RTP packets. In the most cases, the sequence number 382 of two RTP packets will be successive but it is not always true 383 because of various network conditions. When S sequenced RTP 384 packet(hear in after "S RTP") is lost, Abs-Delta for S+1 RTP means 385 interval time between S-1 RTP and S+1 RTP. Also, S RTP can be arrived 386 before S+1 RTP. In this case, Abs-Delta for S+1 RTP means for 387 interval time between S RTP and S+1 RTP. And N flag for S+1 RTP must 388 be set. 390 If an absolute value of packet arrival interval is bigger than 63, 391 Pkt-Element size must be 2 octets with X set. 393 When an absolute value of packet arrival interval is bigger than 394 4094(2^12 - 2) milliseconds, Abs-Delta must be 4095(2^12 - 1). This 395 means the packet arrival interval is 4095 milliseconds or more. 397 4.2.2 CCFS feedback message size 399 Rxer builds a feedback message based on recent received RTP packets. 400 One rxer aggregates multiple RTP streams. And sometimes, by network 401 condition, many packets should be arrived in a short time. These 402 facts make CCFS feedback message packet big. If the CCFS feedback 403 message size is bigger than an accepted packet size by MTU, which 404 will cause exception cases. So CCFS rxer should consider feedback 405 message size. That is, the CCFS feedback message packet size should 406 be smaller than MTU size. 408 If the feedback message size approaches an available size by MTU, 409 rxer must immediately send the feedback message. The monitored time 410 value within the feedback message will be shorter than a txer 411 preferred monitoring time. After sending the instant feedback 412 message, rxer must re-start monitoring for the next feedback. 414 CCFS feedback message size can be estimated as: 416 FBM-Size = 20 + 8R + 1.5T 418 R means an associated RTP stream count. And T means a total report 419 packet count. 1.5 is the assumed average size of Pkt-Element and this 420 can not be exact. However recommend the constant 1.5 for the 421 simplicity of the implementation. 423 4.2.3 Handle CCFS control messages 425 CCFS control message is a type of RTCP message sent by a txer. This 426 RTCP messages should be defined if the txer requires for a specific 427 feature. If the rxer receives understandable control messages, it 428 should respond accordingly. If not, it should ignore and discard 429 them. 431 4.3 Txer 433 Txer keeps sent rtp packet array(txed_rtps) about rtp streams. The 434 txed_rtps contains sent local timestamp, packet size, RTP sequence 435 number and ssrc. 437 Txer estimates variable metrics when the feedback message is sent for 438 each time txer receives a feedback message. This means that all the 439 estimated metrics are the past of backward one way latency ago but 440 remove the effect of the backward path that is the feedback message's 441 network path. 443 It estimates forward path bandwidth, queue latency and loss ratio 444 using the feedback message and txed_rtps in monitored time. 446 Feedback messages have its own sequence number. Txer can examine 447 there is forward path packet losses between successive feedback 448 messages. Also when the increase of the feedback message's sequence 449 number is over one, which means backward path packet losses, txer 450 must take consider only reported periods to remove affect of the 451 backward path's network impairments. 453 And than it decides forward path status and targeting send rate based 454 on the metrics and current status. 456 The forward path status has four status and described in Section 3. 457 Actually this status affects txer's logic in globally. 459 4.3.1 Constants 461 Txer logic is described using pseudo code. For the simplicity, all 462 the constants used are listed up here. 464 FwdBwEstWei = 0.9 465 I_FwdBwEstWei = (1.0 - FwdBwEstWei) 467 TargetQDelay = 50msec 469 WndBrFract = 1sec 471 TrigProbQDFractMax = 0.8 472 TrigProbBrFractMin = 1.0 473 TrigProbQMRangeMax = 10msec 474 TrigProbLossRtMax = 0.02 475 TrigProbECNRtMax = 0.0 477 TrigStopProbQDFractMin = 1.3 478 TrigStopProbBrFractMin = 1.2 479 TrigStopProbLossRtMax = 0.0 480 TrigStopProbECNRtMax = 0.0 482 TrigCompQDelayMin = 200msec 483 TrigCompQMRangeMi = 100msec 485 TrigStopCompQDelayMax = 100msec 486 TrigStopCompQMRangeMax = 20msec 488 TrigThroQDFractMin = 1.5 489 TrigThroBrFractMax = 0.9 491 Thro2CompQIncrTime = 1sec 493 DfltQDFractLow = 0.5 494 DfltQDFractHi = 1.1 495 DfltBrIncrRate = 1.01 496 DfltBrDecrRate = 0.95 498 CompTargetTxbwRate = 1.3 499 ThroTargetTxbwRate = 0.5 501 ProbingTime = 4sec 503 CompQDFractLow = 0.5 504 CompQDFractHi = 1.0 505 CompBrIncrRate = 1.02 507 4.3.2 Monitoring time on txer 509 Whenever txer receives a feedback message, txer calculates the 510 monitored time that is matched with the monitored time on rxer. 512 The latest end sequence in the feedback message is the base point of 513 time to find out monitored time on txer. However total reported 514 packet could be zero that means there was no received rtp packet for 515 the last monitored time for all receiving rtp streams. 517 In this case, monitoring time on txer must be shifted for monitored 518 time on rxer. 520 -------------------------------------------------------------------- 521 shift_time = fbm.report_time - last_fbm_report_time 522 end_tstmp = last_end_tstmp + shift_time 523 bgn_tstmp = end_tstmp - fbm.monitored_time 524 -------------------------------------------------------------------- 525 The fbm stands for feedback message and tstmp is timestamp of txer. 526 This instance has results from parsed a feedback message. 528 bgn_tstmp is begin timestamp and end_tstamp is end timestamp. They 529 are points of time for a monitored period on txer. 531 For the more general cases, total reported packet count would be more 532 than zero. Txer determines a monitored period on txer using the 533 latest rtp packet in the reported packets. 535 -------------------------------------------------------------------- 536 pkt_key = (ssrc, latest_end_seq) = find_out(fbm) 538 latest_sent_tstmp = txed_rtps.get_tstmp(pkt_key) 539 offset = fbm.report_time - fbm.get_rcvd_time(pkt_key) 541 end_tstmp = latest_sent_tstmp + offset 542 bgn_tstmp = end_tstmp - fbm.monitored_time 543 -------------------------------------------------------------------- 545 First of all, find out the sent local time stamp(latest_sent_tstmp) 546 of the latest rtp packet among the reported. 548 And offset is a time between feedback message report time and the 549 received time of the latest rtp packet. 551 Each received time for reported rtp packets is calculated as follow: 553 -------------------------------------------------------------------- 554 seq = fbm.start_sequence_number 555 sum_received_time = fbm.report_time - fbm.monitored_time 557 for all seq in a SSRC 558 received_time[seq] = sum_received_time + fbm.get_delta(seq) 559 sum_received_time = received_time[seq] 560 -------------------------------------------------------------------- 562 4.3.3 Forward path bandwidth estimation 564 The forward path's bandwidth is estimated based on received rate on 565 the rxer. 567 fwd_bw = tot_rxed_size / fbm.monitored_time 569 The tot_rxed_size is sum of sent packet size that is found from 570 txed_rtps with the reported ssrc and seq. If there are the lost 571 packets, they should be excluded. CCFS updates esti_bw with the 572 fwd_bw using moving average to remove outlier. Unfortunately the 573 moving average calculation causes time penalty. Moreover, if wrong 574 estimated value - too small or too large is used, it would affect 575 esti_bw negatively. So, CCFS checks its validation to minimize the 576 noise. 578 -------------------------------------------------------------------- 579 if( status != Throttled && 580 (status == Competing && target_bw < fwd_bw && lost == 0) && 581 (sent_size > tot_rxed_size) 582 || (sent_size == tot_rxed_size && target_bw < fwd_bw) ) 584 esti_bw = FwdBwEstWei*esti_bw + I_FwdBwEstWei*fwd_bw 585 -------------------------------------------------------------------- 587 First of all, the current status must not be throttled because target 588 bandwidth shrinks during throttled status to empty queue. And if the 589 current status is competing update esti_bw only if it fulfils the 590 certain condition. After status check, sent_size should be larger 591 than tot_rxed_size because it means the sent bitrate is about 592 bottlenecked bandwidth or greater for the period. And if the current 593 target bandwidth is underestimated, it updates esti_bw. 595 4.3.4 Queue delay estimation and find increase pattern 597 CCFS uses LEDBAT[RFC6817]'s queue delay estimation to estimate 598 forward path's queue delay. To do that, received timestamp have to be 599 calculated for each packets using ATO field in the feedback message. 600 And the queue delay is the minimum queue delay among the reported 601 packet's estimated queue delays. 603 The queue delay can not be exact but its relative values and pattern 604 can be used as an important signal. CCFS finds out increasing pattern 605 and its duration as follows. 607 -------------------------------------------------------------------- 608 if( last_qdelay < qdelay ) 609 incr_count++ 611 if(incr_count == 1) 612 incr_start_tstmp = end_tstmp 614 incr_duration = end_tstmp - incr_start_tstmp; 616 if(incr_count >= 3 && duration >= IncrMinDuration) 617 is_increasing = true 618 else 619 incr_count = 0 620 incr_start_tstmp = 0 621 is_increasing = false 623 last_qdelay = qdelay 624 -------------------------------------------------------------------- 626 Above logic can be replaced by others if it shows good performance. 628 4.3.5 Handle by status 630 Update transmitting rate (target_txbw) based on the calculated 631 parameters. 633 -------------------------------------------------------------------- 634 qd_fract = qdelay / target_qdelay 635 br_fract = recved_size_wnd / sent_size_wnd 636 -------------------------------------------------------------------- 638 Above two fractions are used directly to check status and control 639 send rate. The recved_size_wnd means that total received packet size 640 for the last window time(WndBrFract) and the sent_size_wnd is the 641 total sent packet size for the same time. 643 4.3.5.1 Control event 645 Before controlling transmitting rate, a certain condition makes 646 status change and CCFS defines this conditions as control event. The 647 control event list and required condition are presented here. 649 -------------------------------------------------------------------- 650 Control Event | Conditions 651 -------------------------------------------------------------------- 652 CTRL_NOTHING | * default value 653 -------------------------------------------------------------------- 654 |1. qdelay > TrigCompQDelayMin 655 CTRL_START_COMPETE | && qmrange > TrigCompQMRangeMin 656 |2. Throttled status 657 | && incr_duration > Thro2CompQIncrTime 658 -------------------------------------------------------------------- 659 |status is not Probing 660 | && is_increasing == false 661 | && qd_fract < TrigProbQDFractMax 662 CTRL_START_PROBING | && br_fract >= TrigProbBrFractMin 663 | && qmrange < TrigProbQMRangeMax 664 | && ecn_rate < TrigProbECNRtMax 665 | && loss_rate < TrigProbLossRtMax 666 -------------------------------------------------------------------- 667 |is_increasing 668 CTRL_DETECT_THROTTLE | && qd_fract > QDFractMinTrigThro 669 | && br_fract < BrFractMaxTrigThro 670 -------------------------------------------------------------------- 671 |Competing status 672 | && comp_duration > CompMaintainTime 673 CTRL_STOP_COMPETE | && qdelay < QDelayMaxTrigCompStop 674 | && qmrange < QMRangeTrigCompStop 675 -------------------------------------------------------------------- 676 |1. Probing status 677 | && is_increasing 678 |2. Probing status 679 | && qd_fract > TrigStopProbQDFractMin 680 |3. Probing status 681 CTRL_STOP_PROBING | && br_fract > TrigStopProbBrFractMin 682 |4. Probing status 683 | && ecn_rate >= TrigStopProbECNRtMax 684 |5. Probing status 685 | && loss_rate >= TrigStopProbLossRtMax 686 -------------------------------------------------------------------- 687 CTRL_RESOLV_THROTTLE | Throttled status 688 | && qdFract < 1.0 689 -------------------------------------------------------------------- 691 4.3.5.2 Handle control event by status 693 CTRL_START_COMPETE and CTRL_DETECT_THROTTLE are important signals to 694 react promptly irrelevant the forward status. So, extracted handlers 695 are described as follows. 697 -------------------------------------------------------------------- 698 do_start_compete(): 699 target_qdelay = TargetQDelay + TargetXQDelay 700 target_txbw = esti_bw * CompTargetTxbwRate 701 status = Competing 702 return 704 do_detect_throttle(): 705 thro_backup_target_txbw = esti_bw 706 target_txbw = esti_bw * ThroTargetTxbwRate 707 status = Throttled 708 return 709 -------------------------------------------------------------------- 711 Comprehensive handling for each status may seem to be complicated. 712 So, this document supplements the pseudo code with simple available 713 status change diagram. 715 +-------------------+ +---------+ 716 | Default |<====================>| Probing | 717 +-------------------+ +---------+ 718 | ^ | ^ | 719 | | | | | 720 | | | | | 721 | | | | | 722 | | V | | 723 | | +-----------+ | 724 | | | Competing |<--------------------------+ 725 | | +-----------+ | 726 | | | ^ | 727 | | | | | 728 | | | | | 729 | | | | | 730 V | V | | 731 +-------------------+ | 732 | Throttled |<--------------------------+ 733 +-------------------+ 735 +----------------+ 736 | Default status | 737 +----------------+ 738 Event: CTRL_NOTHING 739 if(qd_fract < DfltQDFractLow && target_txbw < esti_bw) 740 target_txbw *= DfltBrIncrRate 741 else if(qd_fract > DfltQDFractHi) 742 target_txbw *= DfltBrDecrRate 744 Event: CTRL_START_PROBING 745 prob_backup_target_txrt = esti_bw 746 target_txbw = esti_bw + prob_bw 747 prob_start_tstmp = curr_tstmp 748 status = Probing 750 Event: CTRL_START_COMPETE 751 do_start_compete() 753 Event: CTRL_DETECT_THROTTLE 754 do_detect_throttle() 756 +------------------+ 757 | Competing status | 758 +------------------+ 759 Event: CTRL_NOTHING 760 if( qd_fract < CompQDFractLow || qd_fract < CompQDFractHi ) 761 target_txrt *= CompBrIncrRate 763 Event: CTRL_SOTP_COMPETE 764 target_qdelay = TargetQDelay 765 status = Default 767 Event: CTRL_DETECT_THROTTLE 768 do_detect_throttle() 770 +----------------+ 771 | Probing status | 772 +----------------+ 773 Event: CTRL_NOTHING 774 if(curr_tstmp - prob_start_tstmp > ProbingTime) 775 status = Default 776 target_txnw = prob_backup_target_txbw + prob_bw 778 Event: CTRL_STOP_PROBING 779 target_txbw = esti_bw 780 status = Default 782 Event: CTRL_START_COMPETE 783 do_start_compete() 785 Event: CTRL_DETECT_THROTTLE 786 do_detect_throttle() 788 +------------------+ 789 | Throttled status | 790 +------------------+ 791 Event: CTRL_RESOLV_THROTTLE 792 target_txbw = thro_backup_target_txbw 793 status = Default 795 Event: CTRL_START_COMPETE 796 do_start_compete() 798 Event: CTRL_DETECT_THROTTLE 799 thro_backup_target_txbw = esti_bw 800 target_txbw = esti_bw * ThroTargetTxbwRate 802 4.4 CCFS Control messages 804 If txer wants to implement a specific feature that needs rxer's help, 805 it can send CCFS control messages. CCFS control message is a RTCP 806 message with FMT=CCFSCTRL value. 808 0 1 2 3 809 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 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 |V=2|P| FMT | PT = 205 | length | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | SSRC (Txer Id) | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | SSRC (Rxer Id) | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 |X| CMT | Length | . . . | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 819 . Control Message Value . 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 SSRC for media source is replaced with Rxer Id. 824 Control message block is followed and it can be multiple. The X bit 825 indicates there is a control message block following the current 826 block. 828 CMT(5 bits) is the control message type to inform rxer which control 829 message value type should be used. If rxer does not understand the 830 CMT, it can discard the message. 832 Length(10 bits) is the octet size of the control message value. 834 Control Message Value is different depending on the CMT value. 836 4.4.1 Update preferred feedback interval 838 Txer can change the preferred feedback interval if need. This message 839 doesn't need to be guaranteed so rxer won't send response message. 841 CMT: 1 842 Length: 2 843 Control Message Value: Interval time(msec) 845 4.4.2 Update preferred monitoring time 847 Txer can change the monitoring time if need. This message doesn't 848 need to be guaranteed so rxer won't send response message but applied 849 feedback message have the updated monitored field value. 851 CMT: 2 852 Length: 2 853 Control Message Value: Monitoring time(msec) 855 5 Implement 857 859 6 Security Considerations 861 863 7 IANA Considerations 865 867 8 References 869 8.1 Normative References 871 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 872 Jacobson, "RTP: A Transport Protocol for Real-Time 873 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 874 July 2003, . 876 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 877 "Extended RTP Profile for Real-time Transport Control 878 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 879 10.17487/RFC4585, July 2006, . 882 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 883 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 884 DOI 10.17487/RFC6817, December 2012, . 887 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 888 Requirement Levels", BCP 14, RFC 2119, DOI 889 10.17487/RFC2119, March 1997, . 892 [RFC1776] Crocker, S., "The Address is the Message", RFC 1776, DOI 893 10.17487/RFC1776, April 1 1995, . 896 [TRUTHS] Callon, R., "The Twelve Networking Truths", RFC 1925, DOI 897 10.17487/RFC1925, April 1 1996, . 900 8.2 Informative References 902 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 903 RFC 2914, DOI 10.17487/RFC2914, September 2000, 904 . 906 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 907 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 908 July 2006, . 910 [RFC5513] Farrel, A., "IANA Considerations for Three Letter 911 Acronyms", RFC 5513, DOI 10.17487/RFC5513, April 1 2009, 912 . 914 [I-D.ietf-dt-rmcat-feedback-message] 915 "RTP Control Protocol (RTCP) Feedback for Congestion 916 Control", 919 [I-D.ietf-dt-rmcat-adaptive-fec] 920 "Congestion Control Using FEC for Conversational Media", 921 924 Authors' Addresses 926 Jungnam Gwock 927 Line Plus 928 South Korea 930 EMail: jungnam.gwock@linecorp.com 932 Sanghyun Lee 933 Line Plus 934 South Korea 936 EMail: sanghyun.lee@linecorp.com