--- 1/draft-ietf-rmcat-sbd-06.txt 2017-06-08 09:13:11.912823248 -0700 +++ 2/draft-ietf-rmcat-sbd-07.txt 2017-06-08 09:13:11.960824390 -0700 @@ -1,22 +1,22 @@ RTP Media Congestion Avoidance Techniques D. Hayes, Ed. Internet-Draft S. Ferlin Intended status: Experimental Simula Research Laboratory -Expires: August 19, 2017 M. Welzl +Expires: December 10, 2017 M. Welzl K. Hiorth University of Oslo - February 15, 2017 + June 8, 2017 Shared Bottleneck Detection for Coupled Congestion Control for RTP Media. - draft-ietf-rmcat-sbd-06 + draft-ietf-rmcat-sbd-07 Abstract This document describes a mechanism to detect whether end-to-end data flows share a common bottleneck. It relies on summary statistics that are calculated based on continuous measurements and used as input to a grouping algorithm that runs wherever the knowledge is needed. This mechanism complements the coupled congestion control mechanism in draft-ietf-rmcat-coupled-cc. @@ -28,21 +28,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 19, 2017. + This Internet-Draft will expire on December 10, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -62,47 +62,47 @@ 1.2.3. Path lag . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Parameters and their effect . . . . . . . . . . . . . . . 7 2.2. Recommended parameter values . . . . . . . . . . . . . . 8 3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. SBD feedback requirements . . . . . . . . . . . . . . . . 9 3.1.1. Feedback when all the logic is placed at the sender . 9 3.1.2. Feedback when the statistics are calculated at the receiver and SBD performed at the sender . . . . . . 10 3.1.3. Feedback when bottlenecks can be determined at both - senders and receivers . . . . . . . . . . . . . . . . 10 + senders and receivers . . . . . . . . . . . . . . . . 11 3.2. Key metrics and their calculation . . . . . . . . . . . . 11 3.2.1. Mean delay . . . . . . . . . . . . . . . . . . . . . 11 3.2.2. Skewness estimate . . . . . . . . . . . . . . . . . . 11 3.2.3. Variability estimate . . . . . . . . . . . . . . . . 12 3.2.4. Oscillation estimate . . . . . . . . . . . . . . . . 12 3.2.5. Packet loss . . . . . . . . . . . . . . . . . . . . . 13 3.3. Flow Grouping . . . . . . . . . . . . . . . . . . . . . . 13 3.3.1. Flow grouping algorithm . . . . . . . . . . . . . . . 13 - 3.3.2. Using the flow group signal . . . . . . . . . . . . . 15 - 4. Enhancements to the basic SBD algorithm . . . . . . . . . . . 15 - 4.1. Reducing lag and improving responsiveness . . . . . . . . 15 - 4.1.1. Improving the response of the skewness estimate . . . 16 - 4.1.2. Improving the response of the variability estimate . 18 - 4.2. Removing oscillation noise . . . . . . . . . . . . . . . 18 - 5. Measuring OWD . . . . . . . . . . . . . . . . . . . . . . . . 19 - 5.1. Time stamp resolution . . . . . . . . . . . . . . . . . . 19 - 5.2. Clock skew . . . . . . . . . . . . . . . . . . . . . . . 19 - 6. Expected feedback from experiments . . . . . . . . . . . . . 19 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 - 10. Change history . . . . . . . . . . . . . . . . . . . . . . . 20 - 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 - 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 - 11.2. Informative References . . . . . . . . . . . . . . . . . 21 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 + 3.3.2. Using the flow group signal . . . . . . . . . . . . . 16 + 4. Enhancements to the basic SBD algorithm . . . . . . . . . . . 17 + 4.1. Reducing lag and improving responsiveness . . . . . . . . 17 + 4.1.1. Improving the response of the skewness estimate . . . 18 + 4.1.2. Improving the response of the variability estimate . 20 + 4.2. Removing oscillation noise . . . . . . . . . . . . . . . 20 + 5. Measuring OWD . . . . . . . . . . . . . . . . . . . . . . . . 21 + 5.1. Time stamp resolution . . . . . . . . . . . . . . . . . . 21 + 5.2. Clock skew . . . . . . . . . . . . . . . . . . . . . . . 21 + 6. Expected feedback from experiments . . . . . . . . . . . . . 21 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 + 10. Change history . . . . . . . . . . . . . . . . . . . . . . . 22 + 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 + 11.2. Informative References . . . . . . . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction In the Internet, it is not normally known if flows (e.g., TCP connections or UDP data streams) traverse the same bottlenecks. Even flows that have the same sender and receiver may take different paths and may or may not share a bottleneck. Flows that share a bottleneck link usually compete with one another for their share of the capacity. This competition has the potential to increase packet loss and delays. This is especially relevant for interactive applications @@ -360,49 +360,50 @@ and H2, neither H1 nor H2 alone obtain enough knowledge to detect this shared bottleneck; H3 can however determine it by combining the summary statistics related to H1 and H2, respectively. 3.1. SBD feedback requirements There are three possible scenarios each with different feedback requirements: 1. Both summary statistic calculations and SBD are performed at - senders only. + senders only. When sender-based congestion control is + implemented, this method is RECOMMENDED. 2. Summary statistics calculated on the receivers and SBD at the senders. 3. Summary statistic calculations on receivers, and SBD performed at both senders and receivers (beyond the current scope, but allows cooperative detection of bottlenecks). - Note that the mechanism bases its calculations on the interval T. It - does not require T to be the feedback interval, only that - calculations can be performed over measurements made in that - interval. + All three possibilities are discussed for completeness in this + document, however, it is expected that feedback will take the form + scenario 1 and operate in conjunction with sender-based congestion + control mechanisms. 3.1.1. Feedback when all the logic is placed at the sender Having the sender calculate the summary statistics and determine the shared bottlenecks based on them has the advantage of placing most of the functionality in one place -- the sender. - The sender requires precise accurate OWD measurements for every - packet, along with an indication of lost packets (or the proportion - of packets lost over the interval T). The mechanism performs its - calculations every T and requires measurements to be available for - this. + For every packet, the sender requires accurate OWD measurements of + adequate precision, along with an indication of lost packets (or the + proportion of packets lost over an interval). These can be provided + by [I-D.dt-rmcat-feedback-message]. - It is expected that the draft-ietf-rmcat-feedback-message will - provide the necessary feedback for both SBD and congestion - controllers. + The mechanism performs its calculation whenever it has received + sufficient measurements in the feedback messages to cover the T base + time interval. The exact timing of these calculations will depend on + the frequency of the feedback message. 3.1.2. Feedback when the statistics are calculated at the receiver and SBD performed at the sender This scenario minimizes feedback, but requires receivers to send selected summary statistics at an agreed regular interval. We envisage the following exchange of information to initialize the system: o An initialization message from the sender to the receiver will @@ -425,21 +426,21 @@ * The values of T, N, M, and the necessary resolution and precision of the relayed statistics. o A response message from the receiver acknowledges this message with a list of key metrics it supports (subset of the senders list) and is able to relay back to the sender. This initialization exchange may be repeated to finalize the agreed metrics should not all be supported by all receivers. - After initialization the agreed summary statistics will be fed back + After initialization the agreed summary statistics SHOULD be fed back to the sender (nominally every T). 3.1.3. Feedback when bottlenecks can be determined at both senders and receivers This type of mechanism is currently beyond the scope of SBD in RMCAT. It is mentioned here to ensure more advanced sender/receiver cooperative shared bottleneck determination mechanisms remain possible in the future. @@ -609,45 +609,84 @@ These flows, flows transiting a bottleneck, are then progressively divided into groups based on the freq_est, var_est, and skew_est summary statistics. The process proceeds according to the following steps: 2. Group flows whose difference in sorted freq_est is less than a threshold: diff(freq_est) < p_f - 3. Subdivide freq_est groups by grouping flows whose difference in - sorted E_M(var_est) (highest to lowest) is less than a threshold: + 3. Subdivide the groups obtained in 2. by grouping flows whose + difference in sorted E_M(var_est) (highest to lowest) is less + than a threshold: diff(var_est) < (p_mad * var_est) The threshold, (p_mad * var_est), is with respect to the highest value in the difference. - 4. Subdivide var_est groups by grouping flows whose difference in - sorted skew_est is less than a threshold: + 4. Subdivide the groups obtained in 3. by grouping flows whose + difference in sorted skew_est is less than a threshold: diff(skew_est) < p_s 5. When packet loss is high enough to be reliable (pkt_loss > p_l), - Subdivide skew_est groups by grouping flows whose difference is - less than a threshold + Subdivide the groups obtained in 4. by grouping flows whose + difference is less than a threshold diff(pkt_loss) < (p_d * pkt_loss) The threshold, (p_d * pkt_loss), is with respect to the highest value in the difference. This procedure involves sorting estimates from highest to lowest. It is simple to implement, and efficient for small numbers of flows (up - to 10-20). + to 10-20).Figure 2 illustrates this algorithm + ********* + * Flows * + ***.**.** + / ' + / '--. + / \ + .---v--. .----v---. + 1. Flows traversing | Cong | | UnCong | + a bottleneck '-.--.-' '--------' + / \ + / \ + / \ + .--v--. v-----. + 2. Divide by | g_1 | ... | g_n | + freq_est '---.-. '----.. + / \ / \ + / '--. v '------. + / \ \ + .----v-. .-v----. .---v--. + 3. Divide by | g_1a | ... | g_1z | ... | g_nz | + var_est '---.-.' '-----.. '-.-.--' + / \ / \ / | + / '-----. v v v | + / \ | + .-v-----. .-v-----. .---v---. + 4. Divide by | g_1ai | ... | g_1ax | ... | g_nzx | + skew_est '----.-.' '------.. '-.-.---' + / \ / \ / | + / '--. v v v | + / \ | + .-----v--. .-v------. .----v---. + 5. Divide by | g_1aiA | ... | g_1aiZ | ... | g_nzxZ | + pkt_loss '--------' '--------' '--------' + (when applicable) + + Simple grouping algorithm. + + Figure 2 3.3.2. Using the flow group signal Grouping decisions can be made every T from the second T, however they will not attain their full design accuracy until after the 2*N'th T interval. We recommend that grouping decisions are not made until 2*M T intervals. Network conditions, and even the congestion controllers, can cause bottlenecks to fluctuate. A coupled congestion controller MAY decide @@ -821,24 +860,22 @@ clock offsets should be approximately constant over the measurement periods, the offset is subtracted out in the calculation. 5.1. Time stamp resolution The SBD mechanism requires timing information precise enough to be able to make comparisons. As a rule of thumb, the time resolution should be less than one hundredth of a typical path's range of delays. In general, the coarser the time resolution, the more care that needs to be taken to ensure rounding errors do not bias the - skewness calculation. - - Typical RTP media flows use sub-millisecond timers, which should be - adequate in most situations. + skewness calculation. Time stamp resolution such as that described + by [I-D.dt-rmcat-feedback-message] should be sufficient. 5.2. Clock skew Generally sender and receiver clock skew will be too small to cause significant errors in the estimators. Skew_est and freq_est are the most sensitive to this type of noise due to their use of a mean OWD calculated over a longer interval. In circumstances where clock skew is high, basing skew_est only on the previous T's mean and ignoring freq_est provides a noisier but reliable signal. @@ -874,20 +911,26 @@ Non-authenticated RTCP packets carrying OWD measurements, shared bottleneck indications, and/or summary statistics could allow attackers to alter the bottleneck sharing characteristics for private gain or disruption of other parties communication. 10. Change history Changes made to this document: + WG-06->WG-07 : Updates addressing + https://mailarchive.ietf.org/arch/msg/ + rmcat/80B6q4nI7carGcf_ddBwx7nKvOw. Mainly + clarifications. Figure 2 to supplement grouping + algorithm description. + WG-05->WG-06 : Updates addressing WG reviews https://mailarchive.ietf.org/arch/msg/rmcat/- 1JdrTMq1Y5T6ZNlOkrQJQ27TzE and https://mailarchive.ietf.org/arch/msg/rmcat/ eI2Q1f8NL2SxbJgjFLR4_rEmJ_g. This has mainly involved minor clarifications, including the moving of 3.4.1 and 3.5 into the new Section 4, and 3.4.1 into Section 5 WG-04->WG-05 : Fix ToC formatting. Add section on expected @@ -943,24 +986,30 @@ 11.2. Informative References [Hayes-LCN14] Hayes, D., Ferlin, S., and M. Welzl, "Practical Passive Shared Bottleneck Detection using Shape Summary Statistics", Proc. the IEEE Local Computer Networks (LCN) pp150-158, September 2014, . + [I-D.dt-rmcat-feedback-message] + Sarker, Z., Perkins, C., Singh, V., and M. Ramalho, "RTP + Control Protocol (RTCP) Feedback for Congestion Control", + draft-dt-rmcat-feedback-message-02 (work in progress), May + 2017. + [I-D.ietf-rmcat-coupled-cc] Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion - control for RTP media", draft-ietf-rmcat-coupled-cc-00 - (work in progress), September 2015. + control for RTP media", draft-ietf-rmcat-coupled-cc-06 + (work in progress), March 2017. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, . [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006,