idnits 2.17.1 draft-ietf-rmcat-sbd-04.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 == Line 89 has weird spacing: '...onse of the...' == Line 90 has weird spacing: '...onse of the...' -- The document date (March 21, 2016) is 2958 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-09) exists of draft-ietf-rmcat-coupled-cc-00 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTP Media Congestion Avoidance Techniques D. Hayes, Ed. 3 Internet-Draft University of Oslo 4 Intended status: Experimental S. Ferlin 5 Expires: September 22, 2016 Simula Research Laboratory 6 M. Welzl 7 K. Hiorth 8 University of Oslo 9 March 21, 2016 11 Shared Bottleneck Detection for Coupled Congestion Control for RTP 12 Media. 13 draft-ietf-rmcat-sbd-04 15 Abstract 17 This document describes a mechanism to detect whether end-to-end data 18 flows share a common bottleneck. It relies on summary statistics 19 that are calculated by a data receiver based on continuous 20 measurements and regularly fed to a grouping algorithm that runs 21 wherever the knowledge is needed. This mechanism complements the 22 coupled congestion control mechanism in draft-ietf-rmcat-coupled-cc. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 22, 2016. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. The signals . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . 3 61 1.1.2. Packet Delay . . . . . . . . . . . . . . . . . . . . 3 62 1.1.3. Path Lag . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2.1. Parameters and their Effect . . . . . . . . . . . . . . . 7 65 2.2. Recommended Parameter Values . . . . . . . . . . . . . . 8 66 3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 3.1. SBD feedback requirements . . . . . . . . . . . . . . . . 9 68 3.1.1. Feedback when all the logic is placed at 69 the sender . . . . . . . . . . . . . . . . . . . . . 10 70 3.1.2. Feedback when the statistics are 71 calculated at the receiver and SBD at 72 the sender . . . . . . . . . . . . . . . . . . . . . 10 73 3.1.3. Feedback when bottlenecks can be 74 determined at both senders and 75 receivers . . . . . . . . . . . . . . . . . . . . . . 11 76 3.2. Key metrics and their calculation . . . . . . . . . . . . 11 77 3.2.1. Mean delay . . . . . . . . . . . . . . . . . . . . . 11 78 3.2.2. Skewness Estimate . . . . . . . . . . . . . . . . . . 11 79 3.2.3. Variability Estimate . . . . . . . . . . . . . . . . 12 80 3.2.4. Oscillation Estimate . . . . . . . . . . . . . . . . 12 81 3.2.5. Packet loss . . . . . . . . . . . . . . . . . . . . . 13 82 3.3. Flow Grouping . . . . . . . . . . . . . . . . . . . . . . 13 83 3.3.1. Flow Grouping Algorithm . . . . . . . . . . . . . . . 13 84 3.3.2. Using the flow group signal . . . . . . . . . . . . . 15 85 3.4. Removing Noise from the Estimates . . . . . . . . . . . . 15 86 3.4.1. Oscillation noise . . . . . . . . . . . . . . . . . . 15 87 3.4.2. Clock skew . . . . . . . . . . . . . . . . . . . . . 16 88 3.5. Reducing lag and Improving Responsiveness . . . . 16 89 3.5.1. Improving the response of the skewness estimate . 17 90 3.5.2. Improving the response of the variability estimate 19 91 4. Measuring OWD . . . . . . . . . . . . . . . . . . . . . . . . 19 92 4.1. Time stamp resolution . . . . . . . . . . . . . . . . . . 19 93 5. Implementation status . . . . . . . . . . . . . . . . . . . . 20 94 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 95 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 96 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 97 9. Change history . . . . . . . . . . . . . . . . . . . . . . . 20 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 99 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 100 10.2. Informative References . . . . . . . . . . . . . . . . . 21 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 103 1. Introduction 105 In the Internet, it is not normally known if flows (e.g., TCP 106 connections or UDP data streams) traverse the same bottlenecks. Even 107 flows that have the same sender and receiver may take different paths 108 and share a bottleneck or not. Flows that share a bottleneck link 109 usually compete with one another for their share of the capacity. 110 This competition has the potential to increase packet loss and 111 delays. This is especially relevant for interactive applications 112 that communicate simultaneously with multiple peers (such as multi- 113 party video). For RTP media applications such as RTCWEB, 114 [I-D.ietf-rmcat-coupled-cc] describes a scheme that combines the 115 congestion controllers of flows in order to honor their priorities 116 and avoid unnecessary packet loss as well as delay. This mechanism 117 relies on some form of Shared Bottleneck Detection (SBD); here, a 118 measurement-based SBD approach is described. 120 1.1. The signals 122 The current Internet is unable to explicitly inform endpoints as to 123 which flows share bottlenecks, so endpoints need to infer this from 124 whatever information is available to them. The mechanism described 125 here currently utilises packet loss and packet delay, but is not 126 restricted to these. 128 1.1.1. Packet Loss 130 Packet loss is often a relatively rare signal. Therefore, on its own 131 it is of limited use for SBD, however, it is a valuable supplementary 132 measure when it is more prevalent. 134 1.1.2. Packet Delay 136 End-to-end delay measurements include noise from every device along 137 the path in addition to the delay perturbation at the bottleneck 138 device. The noise is often significantly increased if the round-trip 139 time is used. The cleanest signal is obtained by using One-Way-Delay 140 (OWD). 142 Measuring absolute OWD is difficult since it requires both the sender 143 and receiver clocks to be synchronised. However, since the 144 statistics being collected are relative to the mean OWD, a relative 145 OWD measurement is sufficient. Clock skew is not usually significant 146 over the time intervals used by this SBD mechanism (see [RFC6817] A.2 147 for a discussion on clock skew and OWD measurements). However, in 148 circumstances where it is significant, Section 3.4.2 outlines a way 149 of adjusting the calculations to cater for it. 151 Each packet arriving at the bottleneck buffer may experience very 152 different queue lengths, and therefore different waiting times. A 153 single OWD sample does not, therefore, characterize the path well. 154 However, multiple OWD measurements do reflect the distribution of 155 delays experienced at the bottleneck. 157 1.1.3. Path Lag 159 Flows that share a common bottleneck may traverse different paths, 160 and these paths will often have different base delays. This makes it 161 difficult to correlate changes in delay or loss. This technique uses 162 the long term shape of the delay distribution as a base for 163 comparison to counter this. 165 2. Definitions 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in RFC 2119 [RFC2119]. 171 Acronyms used in this document: 173 OWD -- One Way Delay 175 MAD -- Mean Absolute Deviation 177 RTT -- Round Trip Time 179 SBD -- Shared Bottleneck Detection 181 Conventions used in this document: 183 T -- the base time interval over which measurements are 184 made. 186 N -- the number of base time, T, intervals used in some 187 calculations. 189 M -- the number of base time, T, intervals used in some 190 calculations. 192 sum_T(...) -- summation of all the measurements of the variable 193 in parentheses taken over the interval T 195 sum(...) -- summation of terms of the variable in parentheses 197 sum_N(...) -- summation of N terms of the variable in parentheses 199 sum_NT(...) -- summation of all measurements taken over the 200 interval N*T 202 E_T(...) -- the expectation or mean of the measurements of the 203 variable in parentheses over T 205 E_N(...) -- the expectation or mean of the last N values of the 206 variable in parentheses 208 E_M(...) -- the expectation or mean of the last M values of the 209 variable in parentheses, where M <= N. 211 max_T(...) -- the maximum recorded measurement of the variable in 212 parentheses taken over the interval T 214 min_T(...) -- the minimum recorded measurement of the variable in 215 parentheses taken over the interval T 217 num_T(...) -- the count of measurements of the variable in 218 parentheses taken in the interval T 220 num_VM(...) -- the count of valid values of the variable in 221 parentheses given M records 223 PB -- a boolean variable indicating the particular flow 224 was identified transiting a bottleneck in the 225 previous interval T (i.e. Previously Bottleneck) 227 skew_est -- a measure of skewness in a OWD distribution. 229 skew_base_T -- a variable used as an intermediate step in 230 calculating skew_est. 232 var_est -- a measure of variability in OWD measurements. 234 var_base_T -- a variable used as an intermediate step in 235 calculating var_est. 237 freq_est -- a measure of low frequency oscillation in the OWD 238 measurements. 240 p_l, p_f, p_mad, c_s, c_h, p_s, p_d, p_v -- various thresholds 241 used in the mechanism 243 M and F -- number of values related to N 245 . 247 2.1. Parameters and their Effect 249 T T should be long enough so that there are enough packets 250 received during T for a useful estimate of short term mean 251 OWD and variation statistics. Making T too large can limit 252 the efficacy of freq_est. It will also increase the response 253 time of the mechanism. Making T too small will make the 254 metrics noisier. 256 N & M N should be large enough to provide a stable estimate of 257 oscillations in OWD. Usually M=N, though having M mean_delay) skew_base_T-- 482 The mean_delay does not include the mean of the current T interval to 483 enable it to be calculated iteratively. 485 skew_est = sum_MT(skew_base_T)/num_MT(OWD) 487 where skew_est is a number between -1 and 1 489 Note: Care must be taken when implementing the comparisons to ensure 490 that rounding does not bias skew_est. It is important that the mean 491 is calculated with a higher precision than the samples. 493 3.2.3. Variability Estimate 495 Mean Absolute Deviation (MAD) delay is a robust variability measure 496 that copes well with different send rates. It can be implemented in 497 an online manner as follows: 499 var_base_T = sum_T(|OWD - E_T(OWD)|) 501 where 503 |x| is the absolute value of x 505 E_T(OWD) is the mean OWD calculated in the previous T 507 var_est = MAD_MT = sum_MT(var_base_T)/num_MT(OWD) 509 For calculation of freq_est p_v=0.7 511 For the grouping threshold p_mad=0.1 513 3.2.4. Oscillation Estimate 515 An estimate of the low frequency oscillation of the delay signal is 516 calculated by counting and normalising the significant mean, 517 E_T(OWD), crossings of mean_delay: 519 freq_est = number_of_crossings / N 521 where we define a significant mean crossing as a crossing that 522 extends p_v * var_est from mean_delay. In our experiments we 523 have found that p_v = 0.7 is a good value. 525 Freq_est is a number between 0 and 1. Freq_est can be approximated 526 incrementally as follows: 528 With each new calculation of E_T(OWD) a decision is made as to 529 whether this value of E_T(OWD) significantly crosses the current 530 long term mean, mean_delay, with respect to the previous 531 significant mean crossing. 533 A cyclic buffer, last_N_crossings, records a 1 if there is a 534 significant mean crossing, otherwise a 0. 536 The counter, number_of_crossings, is incremented when there is a 537 significant mean crossing and decremented when a non-zero value is 538 removed from the last_N_crossings. 540 This approximation of freq_est was not used in [Hayes-LCN14], which 541 calculated freq_est every T using the current E_N(E_T(OWD)). Our 542 tests show that this approximation of freq_est yields results that 543 are almost identical to when the full calculation is performed every 544 T. 546 3.2.5. Packet loss 548 The proportion of packets lost over the period NT is used as a 549 supplementary measure: 551 pkt_loss = sum_NT(lost packets) / sum_NT(total packets) 553 Note: When pkt_loss is small it is very variable, however, when 554 pkt_loss is high it becomes a stable measure for making grouping 555 decisions. 557 3.3. Flow Grouping 559 3.3.1. Flow Grouping Algorithm 561 The following grouping algorithm is RECOMMENDED for SBD in the RMCAT 562 context and is sufficient and efficient for small to moderate numbers 563 of flows. For very large numbers of flows (e.g. hundreds), a more 564 complex clustering algorithm may be substituted. 566 Since no single metric is precise enough to group flows (due to 567 noise), the algorithm uses multiple metrics. Each metric offers a 568 different "view" of the bottleneck link characteristics, and used 569 together they enable a more precise grouping of flows than would 570 otherwise be possible. 572 Flows determined to be transiting a bottleneck are successively 573 divided into groups based on freq_est, var_est, skew_est and 574 pkt_loss. 576 The first step is to determine which flows are transiting a 577 bottleneck. This is important, since if a flow is not transiting a 578 bottleneck its delay based metrics will not describe the bottleneck, 579 but the "noise" from the rest of the path. Skewness, with proportion 580 of packet loss as a supplementary measure, is used to do this: 582 1. Grouping will be performed on flows that are inferred to be 583 traversing a bottleneck by: 585 skew_est < c_s 587 || ( skew_est < c_h & PB ) || pkt_loss > p_l 589 The parameter c_s controls how sensitive the mechanism is in 590 detecting a bottleneck. C_s = 0.0 was used in [Hayes-LCN14]. A 591 value of c_s = 0.05 is a little more sensitive, and c_s = -0.05 is a 592 little less sensitive. C_h controls the hysteresis on flows that 593 were grouped as transiting a bottleneck last time. If the test 594 result is TRUE, PB=TRUE, otherwise PB=FALSE. 596 These flows, flows transiting a bottleneck, are then progressively 597 divided into groups based on the freq_est, var_est, and skew_est 598 summary statistics. The process proceeds according to the following 599 steps: 601 2. Group flows whose difference in sorted freq_est is less than a 602 threshold: 604 diff(freq_est) < p_f 606 3. Group flows whose difference in sorted E_M(var_est) (highest to 607 lowest) is less than a threshold: 609 diff(var_est) < (p_mad * var_est) 611 The threshold, (p_mad * var_est), is with respect to the highest 612 value in the difference. 614 4. Group flows whose difference in sorted skew_est is less than a 615 threshold: 617 diff(skew_est) < p_s 619 5. When packet loss is high enough to be reliable (pkt_loss > p_l), 620 group flows whose difference is less than a threshold 622 diff(pkt_loss) < (p_d * pkt_loss) 624 The threshold, (p_d * pkt_loss), is with respect to the highest 625 value in the difference. 627 This procedure involves sorting estimates from highest to lowest. It 628 is simple to implement, and efficient for small numbers of flows (up 629 to 10-20). 631 3.3.2. Using the flow group signal 633 Grouping decisions can be made every T from the second T, however 634 they will not attain their full design accuracy until after the 635 2*N'th T interval. We recommend that grouping decisions are not made 636 until 2*M T intervals. 638 Network conditions, and even the congestion controllers, can cause 639 bottlenecks to fluctuate. A coupled congestion controller MAY decide 640 only to couple groups that remain stable, say grouped together 90% of 641 the time, depending on its objectives. Recommendations concerning 642 this are beyond the scope of this draft and will be specific to the 643 coupled congestion controllers objectives. 645 3.4. Removing Noise from the Estimates 647 The following describe small changes to the calculation of the key 648 metrics that help remove noise from them. Currently these "tweaks" 649 are described separately to keep the main description succinct. In 650 future revisions of the draft these enhancements may replace the 651 original key metric calculations. 653 3.4.1. Oscillation noise 655 When a path has no bottleneck, var_est will be very small and the 656 recorded significant mean crossings will be the result of path noise. 657 Thus up to N-1 meaningless mean crossings can be a source of error at 658 the point a link becomes a bottleneck and flows traversing it begin 659 to be grouped. 661 To remove this source of noise from freq_est: 663 1. Set the current var_base_T = NaN (a value representing an invalid 664 record, i.e. Not a Number) for flows that are deemed to not be 665 transiting a bottleneck by the first skew_est based grouping test 666 (see Section 3.3.1). 668 2. Then var_est = sum_MT(var_base_T != NaN) / num_MT(OWD) 670 3. For freq_est, only record a significant mean crossing if flow 671 deemed to be transiting a bottleneck. 673 These three changes can help to remove the non-bottleneck noise from 674 freq_est. 676 3.4.2. Clock skew 678 Generally sender and receiver clock skew will be too small to cause 679 significant errors in the estimators. Skew_est and freq_est are the 680 most sensitive to this type of noise due to their use of a mean OWD 681 calculated over a longer interval. In circumstances where clock skew 682 is high, basing skew_est only on the previous T's mean and ignoring 683 freq_est provides a noisier but reliable signal. 685 A more sophisticated method is to estimate the effect the clock skew 686 is having on the summary statistics, and then adjust statistics 687 accordingly. There are a number of techniques in the literature, 688 including [Zhang-Infocom02]. 690 3.5. Reducing lag and Improving Responsiveness 692 Measurement based shared bottleneck detection makes decisions in the 693 present based on what has been measured in the past. This means that 694 there is always a lag in responding to changing conditions. This 695 mechanism is based on summary statistics taken over (N*T) seconds. 696 This mechanism can be made more responsive to changing conditions by: 698 1. Reducing N and/or M -- but at the expense of having less accurate 699 metrics, and/or 701 2. Exploiting the fact that more recent measurements are more 702 valuable than older measurements and weighting them accordingly. 704 Although more recent measurements are more valuable, older 705 measurements are still needed to gain an accurate estimate of the 706 distribution descriptor we are measuring. Unfortunately, the simple 707 exponentially weighted moving average weights drop off too quickly 708 for our requirements and have an infinite tail. A simple linearly 709 declining weighted moving average also does not provide enough weight 710 to the most recent measurements. We propose a piecewise linear 711 distribution of weights, such that the first section (samples 1:F) is 712 flat as in a simple moving average, and the second section (samples 713 F+1:M) is linearly declining weights to the end of the averaging 714 window. We choose integer weights, which allows incremental 715 calculation without introducing rounding errors. 717 3.5.1. Improving the response of the skewness estimate 719 The weighted moving average for skew_est, based on skew_est in 720 Section 3.2.2, can be calculated as follows: 722 skew_est = ((M-F+1)*sum(skew_base_T(1:F)) 724 + sum([(M-F):1].*skew_base_T(F+1:M))) 726 / ((M-F+1)*sum(numsampT(1:F)) 728 + sum([(M-F):1].*numsampT(F+1:M))) 730 where numsampT is an array of the number of OWD samples in each T 731 (i.e. num_T(OWD)), and numsampT(1) is the most recent; skew_base_T(1) 732 is the most recent calculation of skew_base_T; 1:F refers to the 733 integer values 1 through to F, and [(M-F):1] refers to an array of 734 the integer values (M-F) declining through to 1; and ".*" is the 735 array scalar dot product operator. 737 To calculate this weighted skew_est incrementally: 739 Notation: F_ - flat portion, D_ - declining portion, W_ - weighted 740 component 742 Initialise: sum_skewbase = 0, F_skewbase=0, W_D_skewbase=0 744 skewbase_hist = buffer length M initialize to 0 746 numsampT = buffer length M initialzed to 0 748 Steps per iteration: 750 1. old_skewbase = skewbase_hist(M) 752 2. old_numsampT = numsampT(M) 754 3. cycle(skewbase_hist) 756 4. cycle(numsampT) 758 5. numsampT(1) = num_T(OWD) 760 6. skewbase_hist(1) = skew_base_T 762 7. F_skewbase = F_skewbase + skew_base_T - skewbase_hist(F+1) 764 8. W_D_skewbase = W_D_skewbase + (M-F)*skewbase_hist(F+1) 765 - sum_skewbase 767 9. W_D_numsamp = W_D_numsamp + (M-F)*numsampT(F+1) - sum_numsamp 768 + F_numsamp 770 10. F_numsamp = F_numsamp + numsampT(1) - numsampT(F+1) 772 11. sum_skewbase = sum_skewbase + skewbase_hist(F+1) - old_skewbase 774 12. sum_numsamp = sum_numsamp + numsampT(1) - old_numsampT 776 13. skew_est = ((M-F+1)*F_skewbase + W_D_skewbase) / 777 ((M-F+1)*F_numsamp+W_D_numsamp) 779 Where cycle(....) refers to the operation on a cyclic buffer where 780 the start of the buffer is now the next element in the buffer. 782 3.5.2. Improving the response of the variability estimate 784 Similarly the weighted moving average for var_est can be calculated 785 as follows: 787 var_est = ((M-F+1)*sum(var_base_T(1:F)) 789 + sum([(M-F):1].*var_base_T(F+1:M))) 791 / ((M-F+1)*sum(numsampT(1:F)) 793 + sum([(M-F):1].*numsampT(F+1:M))) 795 where numsampT is an array of the number of OWD samples in each T 796 (i.e. num_T(OWD)), and numsampT(1) is the most recent; skew_base_T(1) 797 is the most recent calculation of skew_base_T; 1:F refers to the 798 integer values 1 through to F, and [(M-F):1] refers to an array of 799 the integer values (M-F) declining through to 1; and ".*" is the 800 array scalar dot product operator. When removing oscillation noise 801 (see Section 3.4.1) this calculation must be adjusted to allow for 802 invalid var_base_T records. 804 Var_est can be calculated incrementally in the same way as skew_est 805 in Section 3.5.1. However, note that the buffer numsampT is used for 806 both calculations so the operations on it should not be repeated. 808 4. Measuring OWD 810 This section discusses the OWD measurements required for this 811 algorithm to detect shared bottlenecks. 813 The SBD mechanism described in this draft relies on differences 814 between OWD measurements to avoid the practical problems with 815 measuring absolute OWD (see [Hayes-LCN14] section IIIC). Since all 816 summary statistics are relative to the mean OWD and sender/receiver 817 clock offsets should be approximately constant over the measurement 818 periods, the offset is subtracted out in the calculation. 820 4.1. Time stamp resolution 822 The SBD mechanism requires timing information precise enough to be 823 able to make comparisons. As a rule of thumb, the time resolution 824 should be less than one hundredth of a typical path's range of 825 delays. In general, the lower the time resolution, the more care 826 that needs to be taken to ensure rounding errors do not bias the 827 skewness calculation. 829 Typical RTP media flows use sub-millisecond timers, which should be 830 adequate in most situations. 832 5. Implementation status 834 The University of Oslo is currently working on an implementation of 835 this in the Chromium browser. 837 6. Acknowledgements 839 This work was part-funded by the European Community under its Seventh 840 Framework Programme through the Reducing Internet Transport Latency 841 (RITE) project (ICT-317700). The views expressed are solely those of 842 the authors. 844 7. IANA Considerations 846 This memo includes no request to IANA. 848 8. Security Considerations 850 The security considerations of RFC 3550 [RFC3550], RFC 4585 851 [RFC4585], and RFC 5124 [RFC5124] are expected to apply. 853 Non-authenticated RTCP packets carrying shared bottleneck indications 854 and summary statistics could allow attackers to alter the bottleneck 855 sharing characteristics for private gain or disruption of other 856 parties communication. 858 9. Change history 860 Changes made to this document: 862 WG-03->WG-04 : Add M to terminology table, suggest skew_est based 863 on previous T and no freq_est in clock skew 864 section, feedback requirements as a separate sub 865 section. 867 WG-02->WG-03 : Correct misspelled author 869 WG-01->WG-02 : Removed ambiguity associated with the term 870 "congestion". Expanded the description of 871 initialisation messages. Removed PDV metric. 872 Added description of incremental weighted metric 873 calculations for skew_est. Various clarifications 874 based on implementation work. Fixed typos and 875 tuned parameters. 877 WG-00->WG-01 : Moved unbiased skew section to replace skew 878 estimate, more robust variability estimator, the 879 term variance replaced with variability, clock 880 drift term corrected to clock skew, revision to 881 clock skew section with a place holder, description 882 of parameters. 884 02->WG-00 : Fixed missing 0.5 in 3.3.2 and missing brace in 885 3.3.3 887 01->02 : New section describing improvements to the key 888 metric calculations that help to remove noise, 889 bias, and reduce lag. Some revisions to the 890 notation to make it clearer. Some tightening of 891 the thresholds. 893 00->01 : Revisions to terminology for clarity 895 10. References 897 10.1. Normative References 899 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 900 Requirement Levels", BCP 14, RFC 2119, 901 DOI 10.17487/RFC2119, March 1997, 902 . 904 10.2. Informative References 906 [Hayes-LCN14] 907 Hayes, D., Ferlin, S., and M. Welzl, "Practical Passive 908 Shared Bottleneck Detection using Shape Summary 909 Statistics", Proc. the IEEE Local Computer Networks 910 (LCN) pp150-158, September 2014, 911 . 914 [I-D.ietf-rmcat-coupled-cc] 915 Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion 916 control for RTP media", draft-ietf-rmcat-coupled-cc-00 917 (work in progress), September 2015. 919 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 920 Jacobson, "RTP: A Transport Protocol for Real-Time 921 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 922 July 2003, . 924 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 925 "Extended RTP Profile for Real-time Transport Control 926 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 927 DOI 10.17487/RFC4585, July 2006, 928 . 930 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 931 Real-time Transport Control Protocol (RTCP)-Based Feedback 932 (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 933 2008, . 935 [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, 936 "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, 937 DOI 10.17487/RFC6817, December 2012, 938 . 940 [Zhang-Infocom02] 941 Zhang, L., Liu, Z., and H. Xia, "Clock synchronization 942 algorithms for network measurements", Proc. the IEEE 943 International Conference on Computer Communications 944 (INFOCOM) pp160-169, September 2002, 945 . 947 Authors' Addresses 949 David Hayes (editor) 950 University of Oslo 951 PO Box 1080 Blindern 952 Oslo N-0316 953 Norway 955 Phone: +47 2284 5566 956 Email: davihay@ifi.uio.no 958 Simone Ferlin 959 Simula Research Laboratory 960 P.O.Box 134 961 Lysaker 1325 962 Norway 964 Phone: +47 4072 0702 965 Email: ferlin@simula.no 966 Michael Welzl 967 University of Oslo 968 PO Box 1080 Blindern 969 Oslo N-0316 970 Norway 972 Phone: +47 2285 2420 973 Email: michawe@ifi.uio.no 975 Kristian Hiorth 976 University of Oslo 977 PO Box 1080 Blindern 978 Oslo N-0316 979 Norway 981 Email: kristahi@ifi.uio.no