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