draft-ietf-rmcat-sbd-01.txt | draft-ietf-rmcat-sbd-02.txt | |||
---|---|---|---|---|

RTP Media Congestion Avoidance D. Hayes, Ed. | RTP Media Congestion Avoidance Techniques D. Hayes, Ed. | |||

Techniques University of Oslo | Internet-Draft University of Oslo | |||

Internet-Draft S. Ferlin | Intended status: Experimental S. Ferlin | |||

Intended status: Experimental Simula Research Laboratory | Expires: April 21, 2016 Simula Research Laboratory | |||

Expires: January 2, 2016 M. Welzl | M. Welzl | |||

K. Kiorth | ||||

University of Oslo | University of Oslo | |||

July 1, 2015 | October 19, 2015 | |||

Shared Bottleneck Detection for Coupled Congestion Control for RTP | Shared Bottleneck Detection for Coupled Congestion Control for RTP | |||

Media. | Media. | |||

draft-ietf-rmcat-sbd-01 | draft-ietf-rmcat-sbd-02 | |||

Abstract | Abstract | |||

This document describes a mechanism to detect whether end-to-end data | This document describes a mechanism to detect whether end-to-end data | |||

flows share a common bottleneck. It relies on summary statistics | flows share a common bottleneck. It relies on summary statistics | |||

that are calculated by a data receiver based on continuous | that are calculated by a data receiver based on continuous | |||

measurements and regularly fed to a grouping algorithm that runs | measurements and regularly fed to a grouping algorithm that runs | |||

wherever the knowledge is needed. This mechanism complements the | wherever the knowledge is needed. This mechanism complements the | |||

coupled congestion control mechanism in draft-welzl-rmcat-coupled-cc. | coupled congestion control mechanism in draft-welzl-rmcat-coupled-cc. | |||

Status of this Memo | Status of This Memo | |||

This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||

provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||

Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||

Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||

working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||

Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||

Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||

and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||

time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||

material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||

This Internet-Draft will expire on January 2, 2016. | This Internet-Draft will expire on April 21, 2016. | |||

Copyright Notice | Copyright Notice | |||

Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2015 IETF Trust and the persons identified as the | |||

document authors. All rights reserved. | document authors. All rights reserved. | |||

This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||

Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||

(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||

publication of this document. Please review these documents | publication of this document. Please review these documents | |||

carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||

to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||

include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||

the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||

described in the Simplified BSD License. | described in the Simplified BSD License. | |||

Table of Contents | Table of Contents | |||

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||

1.1. The signals . . . . . . . . . . . . . . . . . . . . . . . 3 | 1.1. The signals . . . . . . . . . . . . . . . . . . . . . . . 3 | |||

1.1.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . 3 | 1.1.1. Packet Loss . . . . . . . . . . . . . . . . . . . . . 3 | |||

1.1.2. Packet Delay . . . . . . . . . . . . . . . . . . . . . 3 | 1.1.2. Packet Delay . . . . . . . . . . . . . . . . . . . . 3 | |||

1.1.3. Path Lag . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.1.3. Path Lag . . . . . . . . . . . . . . . . . . . . . . 4 | |||

2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||

2.1. Parameters and their Effect . . . . . . . . . . . . . . . 5 | 2.1. Parameters and their Effect . . . . . . . . . . . . . . . 6 | |||

2.2. Recommended Parameter Values . . . . . . . . . . . . . . . 7 | 2.2. Recommended Parameter Values . . . . . . . . . . . . . . 7 | |||

3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||

3.1. Key metrics and their calculation . . . . . . . . . . . . 9 | 3.1. Key metrics and their calculation . . . . . . . . . . . . 9 | |||

3.1.1. Mean delay . . . . . . . . . . . . . . . . . . . . . . 9 | 3.1.1. Mean delay . . . . . . . . . . . . . . . . . . . . . 9 | |||

3.1.2. Skewness Estimate . . . . . . . . . . . . . . . . . . 9 | 3.1.2. Skewness Estimate . . . . . . . . . . . . . . . . . . 9 | |||

3.1.3. Variability Estimate . . . . . . . . . . . . . . . . . 10 | 3.1.3. Variability Estimate . . . . . . . . . . . . . . . . 10 | |||

3.1.4. Oscillation Estimate . . . . . . . . . . . . . . . . . 11 | 3.1.4. Oscillation Estimate . . . . . . . . . . . . . . . . 11 | |||

3.1.5. Packet loss . . . . . . . . . . . . . . . . . . . . . 11 | 3.1.5. Packet loss . . . . . . . . . . . . . . . . . . . . . 11 | |||

3.2. Flow Grouping . . . . . . . . . . . . . . . . . . . . . . 12 | 3.2. Flow Grouping . . . . . . . . . . . . . . . . . . . . . . 12 | |||

3.2.1. Flow Grouping Algorithm . . . . . . . . . . . . . . . 12 | 3.2.1. Flow Grouping Algorithm . . . . . . . . . . . . . . . 12 | |||

3.2.2. Using the flow group signal . . . . . . . . . . . . . 13 | 3.2.2. Using the flow group signal . . . . . . . . . . . . . 13 | |||

3.3. Removing Noise from the Estimates . . . . . . . . . . . . 13 | 3.3. Removing Noise from the Estimates . . . . . . . . . . . . 13 | |||

3.3.1. PDV noise . . . . . . . . . . . . . . . . . . . . . . 14 | 3.3.1. Oscillation noise . . . . . . . . . . . . . . . . . . 14 | |||

3.3.2. Oscillation noise . . . . . . . . . . . . . . . . . . 14 | 3.3.2. Clock skew . . . . . . . . . . . . . . . . . . . . . 14 | |||

3.3.3. Clock skew . . . . . . . . . . . . . . . . . . . . . . 15 | 3.4. Reducing lag and Improving Responsiveness . . . . 14 | |||

3.4. Reducing lag and Improving Responsiveness . . . . . . . . 15 | 3.4.1. Improving the response of the skewness estimate . 15 | |||

3.4.1. Improving the response of the skewness estimate . . . 16 | 3.4.2. Improving the response of the variability estimate 17 | |||

3.4.2. Improving the response of the variability estimate . . 16 | 4. Measuring OWD . . . . . . . . . . . . . . . . . . . . . . . . 17 | |||

4. Measuring OWD . . . . . . . . . . . . . . . . . . . . . . . . 17 | 4.1. Time stamp resolution . . . . . . . . . . . . . . . . . . 17 | |||

4.1. Time stamp resolution . . . . . . . . . . . . . . . . . . 17 | 5. Implementation status . . . . . . . . . . . . . . . . . . . . 18 | |||

5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 | 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 | |||

6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 | |||

7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 | |||

8. Change history . . . . . . . . . . . . . . . . . . . . . . . . 18 | 9. Change history . . . . . . . . . . . . . . . . . . . . . . . 18 | |||

9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||

9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 | |||

9.2. Informative References . . . . . . . . . . . . . . . . . . 18 | 10.2. Informative References . . . . . . . . . . . . . . . . . 19 | |||

Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 | |||

1. Introduction | 1. Introduction | |||

In the Internet, it is not normally known if flows (e.g., TCP | In the Internet, it is not normally known if flows (e.g., TCP | |||

connections or UDP data streams) traverse the same bottlenecks. Even | connections or UDP data streams) traverse the same bottlenecks. Even | |||

flows that have the same sender and receiver may take different paths | flows that have the same sender and receiver may take different paths | |||

and share a bottleneck or not. Flows that share a bottleneck link | and share a bottleneck or not. Flows that share a bottleneck link | |||

usually compete with one another for their share of the capacity. | usually compete with one another for their share of the capacity. | |||

This competition has the potential to increase packet loss and | This competition has the potential to increase packet loss and | |||

delays. This is especially relevant for interactive applications | delays. This is especially relevant for interactive applications | |||

skipping to change at page 3, line 50 | skipping to change at page 3, line 50 | |||

device. The noise is often significantly increased if the round-trip | device. The noise is often significantly increased if the round-trip | |||

time is used. The cleanest signal is obtained by using One-Way-Delay | time is used. The cleanest signal is obtained by using One-Way-Delay | |||

(OWD). | (OWD). | |||

Measuring absolute OWD is difficult since it requires both the sender | Measuring absolute OWD is difficult since it requires both the sender | |||

and receiver clocks to be synchronised. However, since the | and receiver clocks to be synchronised. However, since the | |||

statistics being collected are relative to the mean OWD, a relative | statistics being collected are relative to the mean OWD, a relative | |||

OWD measurement is sufficient. Clock skew is not usually significant | OWD measurement is sufficient. Clock skew is not usually significant | |||

over the time intervals used by this SBD mechanism (see [RFC6817] A.2 | over the time intervals used by this SBD mechanism (see [RFC6817] A.2 | |||

for a discussion on clock skew and OWD measurements). However, in | for a discussion on clock skew and OWD measurements). However, in | |||

circumstances where it is significant, Section 3.3.3 outlines a way | circumstances where it is significant, Section 3.3.2 outlines a way | |||

of adjusting the calculations to cater for it. | of adjusting the calculations to cater for it. | |||

Each packet arriving at the bottleneck buffer may experience very | Each packet arriving at the bottleneck buffer may experience very | |||

different queue lengths, and therefore different waiting times. A | different queue lengths, and therefore different waiting times. A | |||

single OWD sample does not, therefore, characterize the path well. | single OWD sample does not, therefore, characterize the path well. | |||

However, multiple OWD measurements do reflect the distribution of | However, multiple OWD measurements do reflect the distribution of | |||

delays experienced at the bottleneck. | delays experienced at the bottleneck. | |||

1.1.3. Path Lag | 1.1.3. Path Lag | |||

skipping to change at page 4, line 29 | skipping to change at page 4, line 29 | |||

2. Definitions | 2. Definitions | |||

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||

"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||

document are to be interpreted as described in RFC 2119 [RFC2119]. | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||

Acronyms used in this document: | Acronyms used in this document: | |||

OWD -- One Way Delay | OWD -- One Way Delay | |||

PDV -- Packet Delay Variation | ||||

MAD -- Mean Absolute Deviation | MAD -- Mean Absolute Deviation | |||

RTT -- Round Trip Time | RTT -- Round Trip Time | |||

SBD -- Shared Bottleneck Detection | SBD -- Shared Bottleneck Detection | |||

Conventions used in this document: | Conventions used in this document: | |||

T -- the base time interval over which measurements are | T -- the base time interval over which measurements are | |||

made. | made. | |||

skipping to change at page 5, line 30 | skipping to change at page 5, line 26 | |||

min_T(...) -- the minimum recorded measurement of the variable in | min_T(...) -- the minimum recorded measurement of the variable in | |||

parentheses taken over the interval T | parentheses taken over the interval T | |||

num_T(...) -- the count of measurements of the variable in | num_T(...) -- the count of measurements of the variable in | |||

parentheses taken in the interval T | parentheses taken in the interval T | |||

num_VM(...) -- the count of valid values of the variable in | num_VM(...) -- the count of valid values of the variable in | |||

parentheses given M records | parentheses given M records | |||

PC -- a boolean variable indicating the particular flow | PB -- a boolean variable indicating the particular flow | |||

was identified as experiencing congestion in the | was identified transiting a bottleneck in the | |||

previous interval T (i.e. Previously Congested) | previous interval T (i.e. Previously Bottleneck) | |||

skew_est -- a measure of skewness in a OWD distribution. | skew_est -- a measure of skewness in a OWD distribution. | |||

skew_base_T -- a variable used as an intermediate step in | ||||

calculating skew_est. | ||||

var_est -- a measure of variability in OWD measurements. | var_est -- a measure of variability in OWD measurements. | |||

var_base_T -- a variable used as an intermediate step in | ||||

calculating var_est. | ||||

freq_est -- a measure of low frequency oscillation in the OWD | freq_est -- a measure of low frequency oscillation in the OWD | |||

measurements. | measurements. | |||

p_l, p_f, p_pdv, p_mad, c_s, c_h, p_s, p_d, p_v -- various | p_l, p_f, p_mad, c_s, c_h, p_s, p_d, p_v -- various thresholds | |||

thresholds used in the mechanism | used in the mechanism | |||

M and F -- number of values related to N | M and F -- number of values related to N | |||

. | ||||

2.1. Parameters and their Effect | 2.1. Parameters and their Effect | |||

T T should be long enough so that there are enough packets | T T should be long enough so that there are enough packets | |||

received during T for a useful estimate of short term mean | received during T for a useful estimate of short term mean | |||

OWD and variation statistics. Making T too large can limit | OWD and variation statistics. Making T too large can limit | |||

the efficacy of PDV and freq_est. It will also increase the | the efficacy of freq_est. It will also increase the response | |||

response time of the mechanism. Making T too small will make | time of the mechanism. Making T too small will make the | |||

the metrics noisier. | metrics noisier. | |||

N & M N should be large enough provide a stable estimate of | N & M N should be large enough to provide a stable estimate of | |||

oscillations in OWD and average PDV. Usually M=N, though | oscillations in OWD. Usually M=N, though having M<N may be | |||

having M<N may be beneficial in certain circumstances. M*T | beneficial in certain circumstances. M*T needs to be long | |||

needs to be long enough provide stable estimates of skewness | enough to provide stable estimates of skewness and MAD. | |||

and MAD (if used). | ||||

F F determines the number of intervals over which statistics | F F determines the number of intervals over which statistics | |||

are considered to be equally weighted. When F=M recent and | are considered to be equally weighted. When F=M recent and | |||

older measurements are considered equal. Making F<M can | older measurements are considered equal. Making F<M can | |||

increase the responsiveness of the SBD mechanism. If F is | increase the responsiveness of the SBD mechanism. If F is | |||

too small, statistics will be too noisy. | too small, statistics will be too noisy. | |||

c_s c_s is the threshold in skew_est used for determining whether | c_s c_s is the threshold in skew_est used for determining whether | |||

a flow is experiencing congestion or not. It should be | a flow is transiting a bottleneck or not. It should be | |||

slightly negative so that a very lightly loaded path does not | slightly negative so that a very lightly loaded path does not | |||

give a false indication. Setting c_s more negative makes the | give a false indication. Setting c_s more negative makes the | |||

SBD mechanism less sensitive to transient and light | SBD mechanism less sensitive to transient and slight | |||

congestion episodes. | bottlenecks. | |||

c_s c_h adds hysteresis to the congestion determination. It | c_h c_h adds hysteresis to the botteneck determination. It | |||

should be large enough to avoid constant switching in the | should be large enough to avoid constant switching in the | |||

determination, but low enough to ensure that grouping is not | determination, but low enough to ensure that grouping is not | |||

attempted when there is no congestion and the delay and loss | attempted when there is no bottleneck and the delay and loss | |||

signals cannot be relied upon. | signals cannot be relied upon. | |||

p_v p_v determines the sensitivity of freq_est to noise. Making | p_v p_v determines the sensitivity of freq_est to noise. Making | |||

it smaller will yield higher but noisier values for freq_est. | it smaller will yield higher but noisier values for freq_est. | |||

Making it too large will render it ineffective for | Making it too large will render it ineffective for | |||

determining groups. | determining groups. | |||

p_* Flows are separated when the skew_est|var_est|freq_est | p_* Flows are separated when the skew_est|var_est|freq_est | |||

measure is greater than p_s|p_f|p_d|(p_pdv|p_mad). Adjusting | measure is greater than p_s|p_f|p_d|p_mad. Adjusting these | |||

these is a compromise between false grouping of flows that do | is a compromise between false grouping of flows that do not | |||

not share a bottleneck and false splitting of flows that do. | share a bottleneck and false splitting of flows that do. | |||

Making them larger can help if the measures are very noisy, | Making them larger can help if the measures are very noisy, | |||

but reducing the noise in the statistical measures by | but reducing the noise in the statistical measures by | |||

adjusting T and N|M may be a better solution. | adjusting T and N|M may be a better solution. | |||

2.2. Recommended Parameter Values | 2.2. Recommended Parameter Values | |||

Reference [Hayes-LCN14] uses T=350ms, N=50, p_l = 0.1. The other | Reference [Hayes-LCN14] uses T=350ms, N=50, p_l=0.1. The other | |||

parameters have been tightened to reflect minor enhancements to the | parameters have been tightened to reflect minor enhancements to the | |||

algorithm outlined in Section 3.3: c_s = -0.01, p_f = p_s = p_d = | algorithm outlined in Section 3.3: c_s=-0.01, p_f=p_d=0.1, p_s=0.15, | |||

0.1, p_pdv = 0.2, p_v = 0.2 (or p_mad=0.1, p_v=0.7). M=50, F=25, and | p_mad=0.1, p_v=0.7. M=30, F=20, and c_h = 0.3 are additional | |||

c_h = 0.3 are additional parameters defined in the document. These | parameters defined in the document. These are values that seem to | |||

are values that seem to work well over a wide range of practical | work well over a wide range of practical Internet conditions. | |||

Internet conditions. | ||||

3. Mechanism | 3. Mechanism | |||

The mechanism described in this document is based on the observation | The mechanism described in this document is based on the observation | |||

that the distribution of delay measurements of packets that traverse | that the distribution of delay measurements of packets that traverse | |||

a common bottleneck have similar shape characteristics. These shape | a common bottleneck have similar shape characteristics. These shape | |||

characteristics are described using 3 key summary statistics: | characteristics are described using 3 key summary statistics: | |||

variability (estimate var_est, see Section 3.1.3) | variability (estimate var_est, see Section 3.1.3) | |||

skewness (estimate skew_est, see Section 3.1.2) | skewness (estimate skew_est, see Section 3.1.2) | |||

oscillation (estimate freq_est, see Section 3.1.4) | oscillation (estimate freq_est, see Section 3.1.4) | |||

with packet loss (estimate pkt_loss, see Section 3.1.5) used as a | with packet loss (estimate pkt_loss, see Section 3.1.5) used as a | |||

supplementary statistic. | supplementary statistic. | |||

Summary statistics help to address both the noise and the path lag | Summary statistics help to address both the noise and the path lag | |||

problems by describing the general shape over a relatively long | problems by describing the general shape over a relatively long | |||

period of time. This is sufficient for their application in coupled | period of time. Each summary statistic portrays a "view" of the | |||

congestion control for RTP Media. They can be signalled from a | bottleneck link characteristics, and when used together, they provide | |||

receiver, which measures the OWD and calculates the summary | a robust discrimination for grouping flows. They can be signalled | |||

from a receiver, which measures the OWD and calculates the summary | ||||

statistics, to a sender, which is the entity that is transmitting the | statistics, to a sender, which is the entity that is transmitting the | |||

media stream. An RTP Media device may be both a sender and a | media stream. An RTP Media device may be both a sender and a | |||

receiver. SBD can be performed at either a sender or a receiver or | receiver. SBD can be performed at either a sender or a receiver or | |||

both. | both. | |||

+----+ | +----+ | |||

| H2 | | | H2 | | |||

+----+ | +----+ | |||

| | | | |||

| L2 | | L2 | |||

skipping to change at page 8, line 25 | skipping to change at page 8, line 25 | |||

A network with 3 hosts (H1, H2, H3) and 3 links (L1, L2, L3). | A network with 3 hosts (H1, H2, H3) and 3 links (L1, L2, L3). | |||

Figure 1 | Figure 1 | |||

In Figure 1, there are two possible cases for shared bottleneck | In Figure 1, there are two possible cases for shared bottleneck | |||

detection: a sender-based and a receiver-based case. | detection: a sender-based and a receiver-based case. | |||

1. Sender-based: consider a situation where host H1 sends media | 1. Sender-based: consider a situation where host H1 sends media | |||

streams to hosts H2 and H3, and L1 is a shared bottleneck. H2 | streams to hosts H2 and H3, and L1 is a shared bottleneck. H2 | |||

and H3 measure the OWD and calculate summary statistics, which | and H3 measure the OWD and calculate summary statistics, which | |||

they send to H1 every T. H1, having this knowledge, can determine | they send to H1 every T. H1, having this knowledge, can | |||

the shared bottleneck and accordingly control the send rates. | determine the shared bottleneck and accordingly control the send | |||

rates. | ||||

2. Receiver-based: consider that H2 is also sending media to H3, and | 2. Receiver-based: consider that H2 is also sending media to H3, and | |||

L3 is a shared bottleneck. If H3 sends summary statistics to H1 | L3 is a shared bottleneck. If H3 sends summary statistics to H1 | |||

and H2, neither H1 nor H2 alone obtain enough knowledge to detect | and H2, neither H1 nor H2 alone obtain enough knowledge to detect | |||

this shared bottleneck; H3 can however determine it by combining | this shared bottleneck; H3 can however determine it by combining | |||

the summary statistics related to H1 and H2, respectively. This | the summary statistics related to H1 and H2, respectively. This | |||

case is applicable when send rates are controlled by the | case is applicable when send rates are controlled by the | |||

receiver; then, the signal from H3 to the senders contains the | receiver; then, the signal from H3 to the senders contains the | |||

sending rate. | sending rate. | |||

A discussion of the required signalling for the receiver-based case | A discussion of the required signalling for the receiver-based case | |||

is beyond the scope of this document. For the sender-based case, the | is beyond the scope of this document. For the sender-based case, the | |||

messages and their data format will be defined here in future | messages and their data format will be defined here in future | |||

versions of this document. We envision that an initialization | versions of this document. | |||

message from the sender to the receiver could specify which key | ||||

metrics are requested out of a possibly extensible set (pkt_loss, | We envisige the following exchange during initialisation: | |||

var_est, skew_est, freq_est). The grouping algorithm described in | ||||

this document requires all four of these metrics, and receivers MUST | o An initialization message from the sender to the receiver will | |||

be able to provide them, but future algorithms may be able to exploit | contain the following information: | |||

other metrics (e.g. metrics based on explicit network signals). | ||||

Moreover, the initialization message could specify T, N, and the | * A protocol identifier (SBD=01). This is to future proof the | |||

necessary resolution and precision (number of bits per field). | message exchange so that potential advances in SBD technology | |||

can be easily deployed. All following initialisation elements | ||||

relate to the mechanism outlined in this document which will | ||||

have the identifier SBD=01. | ||||

* A list of which key metrics should be collected and relayed | ||||

back to the sender out of a possibly extensible set (pkt_loss, | ||||

var_est, skew_est, freq_est). The grouping algorithm described | ||||

in this document requires all four of these metrics, and | ||||

receivers MUST be able to provide them, but future algorithms | ||||

may be able to exploit other metrics (e.g. metrics based on | ||||

explicit network signals). | ||||

* 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. | ||||

o This initialisation exchange may be repeated to finalize the | ||||

agreed metrics should not all be supported by all receivers. | ||||

3.1. Key metrics and their calculation | 3.1. Key metrics and their calculation | |||

Measurements are calculated over a base interval, T. T should be long | Measurements are calculated over a base interval, T and summarized | |||

enough to provide enough samples for a good estimate of skewness, but | over N or M such intervals. All summary statistics can be calculated | |||

short enough so that a measure of the oscillation can be made from N | incrementally. | |||

of these estimates. Reference [Hayes-LCN14] uses T = 350ms and | ||||

N=M=50, which are values that seem to work well over a wide range of | ||||

practical Internet conditions. | ||||

3.1.1. Mean delay | 3.1.1. Mean delay | |||

The mean delay is not a useful signal for comparisons between flows | The mean delay is not a useful signal for comparisons between flows | |||

since flows may traverse quite different paths and clocks will not | since flows may traverse quite different paths and clocks will not | |||

necessarily be synchronized. However, it is a base measure for the 3 | necessarily be synchronized. However, it is a base measure for the 3 | |||

summary statistics. The mean delay, E_T(OWD), is the average one way | summary statistics. The mean delay, E_T(OWD), is the average one way | |||

delay measured over T. | delay measured over T. | |||

To facilitate the other calculations, the last N E_T(OWD) values will | To facilitate the other calculations, the last N E_T(OWD) values will | |||

need to be stored in a cyclic buffer along with the moving average of | need to be stored in a cyclic buffer along with the moving average of | |||

E_T(OWD): | E_T(OWD): | |||

mean_delay = E_M(E_T(OWD)) = sum_M(E_T(OWD)) / M | mean_delay = E_M(E_T(OWD)) = sum_M(E_T(OWD)) / M | |||

where M <= N. Generally M=N: setting M to be less than N allows the | where M <= N. Setting M to be less than N allows the mechanism to be | |||

mechanism to be more responsive to changes, but potentially at the | more responsive to changes, but potentially at the expense of a | |||

expense of a higher error rate (see Section 3.4 for a discussion on | higher error rate (see Section 3.4 for a discussion on improving the | |||

improving the responsiveness of the mechanism.) | responsiveness of the mechanism.) | |||

3.1.2. Skewness Estimate | 3.1.2. Skewness Estimate | |||

Skewness is difficult to calculate efficiently and accurately. | Skewness is difficult to calculate efficiently and accurately. | |||

Ideally it should be calculated over the entire period (M * T) from | Ideally it should be calculated over the entire period (M * T) from | |||

the mean OWD over that period. However this would require storing | the mean OWD over that period. However this would require storing | |||

every delay measurement over the period. Instead, an estimate is | every delay measurement over the period. Instead, an estimate is | |||

made over M * T based on a calculation every T using the previous T's | made over M * T based on a calculation every T using the previous T's | |||

calculation of mean_delay. | calculation of mean_delay. | |||

The skewness is estimated using two counters, counting the number of | The base for the skewness calculation is estimated using a counter | |||

one way delay samples (OWD) above and below the mean: | initialised every T. It increments for one way delay samples (OWD) | |||

below the mean and decrements for OWD above the mean. So for each | ||||

skew_base_T = sum_T(OWD < mean_delay) - sum_T(OWD > mean_delay) | OWD sample: | |||

where | ||||

if (OWD < mean_delay) 1 else 0 | if (OWD < mean_delay) skew_base_T++ | |||

if (OWD > mean_delay) 1 else 0 | if (OWD > mean_delay) skew_base_T-- | |||

and mean_delay does not include the mean of the current T | The mean_delay does not include the mean of the current T interval to | |||

interval. | enable it to be calculated iteratively. | |||

skew_est = sum_MT(skew_base_T)/num_MT(OWD) | skew_est = sum_MT(skew_base_T)/num_MT(OWD) | |||

where skew_est is a number between -1 and 1 | where skew_est is a number between -1 and 1 | |||

Note: Care must be taken when implementing the comparisons to ensure | Note: Care must be taken when implementing the comparisons to ensure | |||

that rounding does not bias skew_est. It is important that the mean | that rounding does not bias skew_est. It is important that the mean | |||

is calculated with a higher precision than the samples. | is calculated with a higher precision than the samples. | |||

3.1.3. Variability Estimate | 3.1.3. Variability Estimate | |||

Packet Delay Variation (PDV) ([RFC5481] and [ITU-Y1540]) is used as | Mean Absolute Deviation (MAD) delay is a robust variability measure | |||

an estimator of the variability of the delay signal. We define PDV | that copes well with different send rates. It can be implemented in | |||

as follows: | an online manner as follows: | |||

PDV = PDV_max = max_T(OWD) - E_T(OWD) | var_base_T = sum_T(|OWD - E_T(OWD)|) | |||

var_est = E_M(PDV) = sum_M(PDV) / M | where | |||

This modifies PDV as outlined in [RFC5481] to provide a summary | |x| is the absolute value of x | |||

statistic version that best aids the grouping decisions of the | ||||

algorithm (see [Hayes-LCN14] section IVB). | ||||

Generally the maximum is sampled well during congestion, though it is | E_T(OWD) is the mean OWD calculated in the previous T | |||

more sensitive to path and operating system noise. The use of PDV = | ||||

PDV_min = E_T(OWD) - min_T(OWD) would be less sensitive to this | var_est = MAD_MT = sum_MT(var_base_T)/num_MT(OWD) | |||

noise, but is not well sampled during congestion at the bottleneck | ||||

and therefore not recommended. | For calculation of freq_est p_v=0.7 | |||

For the grouping threshold p_mad=0.1 | ||||

3.1.4. Oscillation Estimate | 3.1.4. Oscillation Estimate | |||

An estimate of the low frequency oscillation of the delay signal is | An estimate of the low frequency oscillation of the delay signal is | |||

calculated by counting and normalising the significant mean, | calculated by counting and normalising the significant mean, | |||

E_T(OWD), crossings of mean_delay: | E_T(OWD), crossings of mean_delay: | |||

freq_est = number_of_crossings / N | freq_est = number_of_crossings / N | |||

where we define a significant mean crossing as a crossing that | where we define a significant mean crossing as a crossing that | |||

extends p_v * var_est from mean_delay. In our experiments we | extends p_v * var_est from mean_delay. In our experiments we | |||

have found that p_v = 0.2 is a good value. | have found that p_v = 0.7 is a good value. | |||

Freq_est is a number between 0 and 1. Freq_est can be approximated | Freq_est is a number between 0 and 1. Freq_est can be approximated | |||

incrementally as follows: | incrementally as follows: | |||

With each new calculation of E_T(OWD) a decision is made as to | With each new calculation of E_T(OWD) a decision is made as to | |||

whether this value of E_T(OWD) significantly crosses the current | whether this value of E_T(OWD) significantly crosses the current | |||

long term mean, mean_delay, with respect to the previous | long term mean, mean_delay, with respect to the previous | |||

significant mean crossing. | significant mean crossing. | |||

A cyclic buffer, last_N_crossings, records a 1 if there is a | A cyclic buffer, last_N_crossings, records a 1 if there is a | |||

skipping to change at page 11, line 40 | skipping to change at page 11, line 40 | |||

removed from the last_N_crossings. | removed from the last_N_crossings. | |||

This approximation of freq_est was not used in [Hayes-LCN14], which | This approximation of freq_est was not used in [Hayes-LCN14], which | |||

calculated freq_est every T using the current E_N(E_T(OWD)). Our | calculated freq_est every T using the current E_N(E_T(OWD)). Our | |||

tests show that this approximation of freq_est yields results that | tests show that this approximation of freq_est yields results that | |||

are almost identical to when the full calculation is performed every | are almost identical to when the full calculation is performed every | |||

T. | T. | |||

3.1.5. Packet loss | 3.1.5. Packet loss | |||

The proportion of packets lost is used as a supplementary measure: | The proportion of packets lost over the period NT is used as a | |||

supplementary measure: | ||||

pkt_loss = sum_NT(lost packets) / sum_NT(total packets) | pkt_loss = sum_NT(lost packets) / sum_NT(total packets) | |||

Note: When pkt_loss is small it is very variable, however, when | Note: When pkt_loss is small it is very variable, however, when | |||

pkt_loss is high it becomes a stable measure for making grouping | pkt_loss is high it becomes a stable measure for making grouping | |||

decisions.. | decisions. | |||

3.2. Flow Grouping | 3.2. Flow Grouping | |||

3.2.1. Flow Grouping Algorithm | 3.2.1. Flow Grouping Algorithm | |||

The following grouping algorithm is RECOMMENDED for SBD in the RMCAT | The following grouping algorithm is RECOMMENDED for SBD in the RMCAT | |||

context and is sufficient and efficient for small to moderate numbers | context and is sufficient and efficient for small to moderate numbers | |||

of flows. For very large numbers of flows (e.g. hundreds), a more | of flows. For very large numbers of flows (e.g. hundreds), a more | |||

complex clustering algorithm may be substituted. | complex clustering algorithm may be substituted. | |||

Since no single metric is precise enough to group flows (due to | Since no single metric is precise enough to group flows (due to | |||

noise), the algorithm uses multiple metrics. Each metric offers a | noise), the algorithm uses multiple metrics. Each metric offers a | |||

different "view" of the bottleneck link characteristics, and used | different "view" of the bottleneck link characteristics, and used | |||

together they enable a more precise grouping of flows than would | together they enable a more precise grouping of flows than would | |||

otherwise be possible. | otherwise be possible. | |||

Flows determined to be experiencing congestion are successively | Flows determined to be transiting a bottleneck are successively | |||

divided into groups based on freq_est, var_est, and skew_est. | divided into groups based on freq_est, var_est, skew_est and | |||

pkt_loss. | ||||

The first step is to determine which flows are experiencing | The first step is to determine which flows are transiting a | |||

congestion. This is important, since if a flow is not experiencing | bottleneck. This is important, since if a flow is not transiting a | |||

congestion its delay based metrics will not describe the bottleneck, | bottleneck its delay based metrics will not describe the bottleneck, | |||

but the "noise" from the rest of the path. Skewness, with proportion | but the "noise" from the rest of the path. Skewness, with proportion | |||

of packets loss as a supplementary measure, is used to do this: | of packet loss as a supplementary measure, is used to do this: | |||

1. Grouping will be performed on flows where: | 1. Grouping will be performed on flows that are inferred to be | |||

traversing a bottleneck by: | ||||

skew_est < c_s | skew_est < c_s | |||

|| ( skew_est < c_h && PC ) | || ( skew_est < c_h & PB ) || pkt_loss > p_l | |||

|| pkt_loss > p_l | ||||

The parameter c_s controls how sensitive the mechanism is in | The parameter c_s controls how sensitive the mechanism is in | |||

detecting congestion. C_s = 0.0 was used in [Hayes-LCN14]. A value | detecting a bottleneck. C_s = 0.0 was used in [Hayes-LCN14]. A | |||

of c_s = 0.05 is a little more sensitive, and c_s = -0.05 is a little | value of c_s = 0.05 is a little more sensitive, and c_s = -0.05 is a | |||

less sensitive. C_h controls the hysteresis on flows that were | little less sensitive. C_h controls the hysteresis on flows that | |||

grouped as experiencing congestion last time. | were grouped as transiting a bottleneck last time. If the test | |||

result is TRUE, PB=TRUE, otherwise PB=FALSE. | ||||

These flows, flows experiencing congestion, are then progressively | These flows, flows transiting a bottleneck, are then progressively | |||

divided into groups based on the freq_est, PDV, and skew_est summary | divided into groups based on the freq_est, var_est, and skew_est | |||

statistics. The process proceeds according to the following steps: | summary statistics. The process proceeds according to the following | |||

steps: | ||||

2. Group flows whose difference in sorted freq_est is less than a | 2. Group flows whose difference in sorted freq_est is less than a | |||

threshold: | threshold: | |||

diff(freq_est) < p_f | diff(freq_est) < p_f | |||

3. Group flows whose difference in sorted E_N(PDV) (highest to | 3. Group flows whose difference in sorted E_M(var_est) (highest to | |||

lowest) is less than a threshold: | lowest) is less than a threshold: | |||

diff(var_est) < (p_pdv * var_est) | diff(var_est) < (p_mad * var_est) | |||

The threshold, (p_pdv * var_est), is with respect to the highest | The threshold, (p_mad * var_est), is with respect to the highest | |||

value in the difference. | value in the difference. | |||

4. Group flows whose difference in sorted skew_est or pkt_loss is | 4. Group flows whose difference in sorted skew_est is less than a | |||

less than a threshold: | threshold: | |||

if pkt_loss < p_l | ||||

diff(skew_est) < p_s | diff(skew_est) < p_s | |||

otherwise | 5. When packet loss is high enough to be reliable (pkt_loss > p_l), | |||

group flows whose difference is less than a threshold | ||||

diff(pkt_loss) < (p_d * pkt_loss) | diff(pkt_loss) < (p_d * pkt_loss) | |||

The threshold, (p_d * pkt_loss), is with respect to the | The threshold, (p_d * pkt_loss), is with respect to the highest | |||

highest value in the difference. | value in the difference. | |||

This procedure involves sorting estimates from highest to lowest. It | This procedure involves sorting estimates from highest to lowest. It | |||

is simple to implement, and efficient for small numbers of flows (up | is simple to implement, and efficient for small numbers of flows (up | |||

to 10-20). | to 10-20). | |||

3.2.2. Using the flow group signal | 3.2.2. Using the flow group signal | |||

A grouping decisions is made every T from the second T, though they | Grouping decisions can be made every T from the second T, however | |||

will not attain their full design accuracy until after the N'th T | they will not attain their full design accuracy until after the | |||

interval. | 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 | Network conditions, and even the congestion controllers, can cause | |||

bottlenecks to fluctuate. A coupled congestion controller MAY decide | bottlenecks to fluctuate. A coupled congestion controller MAY decide | |||

only to couple groups that remain stable, say grouped together 90% of | only to couple groups that remain stable, say grouped together 90% of | |||

the time, depending on its objectives. Recommendations concerning | the time, depending on its objectives. Recommendations concerning | |||

this are beyond the scope of this draft and will be specific to the | this are beyond the scope of this draft and will be specific to the | |||

coupled congestion controllers objectives. | coupled congestion controllers objectives. | |||

3.3. Removing Noise from the Estimates | 3.3. Removing Noise from the Estimates | |||

The following describe small changes to the calculation of the key | The following describe small changes to the calculation of the key | |||

metrics that help remove noise from them. Currently these "tweaks" | metrics that help remove noise from them. Currently these "tweaks" | |||

are described separately to keep the main description succinct. In | are described separately to keep the main description succinct. In | |||

future revisions of the draft these enhancements may replace the | future revisions of the draft these enhancements may replace the | |||

original key metric calculations. | original key metric calculations. | |||

3.3.1. PDV noise | 3.3.1. Oscillation noise | |||

Usually during congestion the max_T(OWD) is quite well sampled as the | ||||

delay distribution is skewed toward the maximum. However max_T(OWD) | ||||

is subject to delay noise from other queues along the path as well as | ||||

the host operating system. Min_T(OWD) is less prone to noise along | ||||

the path and from the host operating system, but is not well sampled | ||||

during congestion (i.e. when there is a bottleneck). Flows with very | ||||

different packet send rates exacerbate the problem. | ||||

An alternative delay variation measure that is less sensitive to | ||||

extreme values and different send rates is Mean Absolute Deviation | ||||

(MAD). It can be implemented in an online manner as follows: | ||||

var_base_T = sum_T(|OWD - E_T(OWD)|) | ||||

where | ||||

|x| is the absolute value of x | ||||

E_T(OWD) is the mean OWD calculated in the previous T | ||||

var_est = MAD_MT = sum_MT(var_base_T)/num_MT(OWD) | ||||

For calculation of freq_est p_v=0.7 (MAD is a smaller number than | ||||

PDV) | ||||

For the grouping threshold p_mad=0.1 instead of p_pdv (MAD is less | ||||

noisy so the test can be tighter) | ||||

Note that the method for improving responsiveness of MAD_MT is the | ||||

same as that described in Section 3.4.1 for skew_est. | ||||

3.3.2. Oscillation noise | ||||

When a path has no congestion, var_est will be very small and the | When a path has no bottleneck, var_est will be very small and the | |||

recorded significant mean crossings will be the result of path noise. | recorded significant mean crossings will be the result of path noise. | |||

Thus up to N-1 meaningless mean crossings can be a source of error at | Thus up to N-1 meaningless mean crossings can be a source of error at | |||

the point a link becomes a bottleneck and flows traversing it begin | the point a link becomes a bottleneck and flows traversing it begin | |||

to be grouped. | to be grouped. | |||

To remove this source of noise from freq_est: | To remove this source of noise from freq_est: | |||

1. Set the current PDV to PDV = NaN (a value representing an invalid | 1. Set the current var_base_T = NaN (a value representing an invalid | |||

record, i.e. Not a Number) for flows that are deemed to not be | record, i.e. Not a Number) for flows that are deemed to not be | |||

experiencing congestion by the first skew_est based grouping test | transiting a bottleneck by the first skew_est based grouping test | |||

(see Section 3.2.1). | (see Section 3.2.1). | |||

2. Then var_est = sum_M(PDV != NaN) / num_VM(PDV) | 2. Then var_est = sum_MT(var_base_T != NaN) / num_MT(OWD) | |||

3. For freq_est, only record a significant mean crossing if flow is | 3. For freq_est, only record a significant mean crossing if flow | |||

experiencing congestion. | deemed to be transiting a bottleneck. | |||

These three changes will remove the non-congestion noise from | These three changes can help to remove the non-bottleneck noise from | |||

freq_est. A similar adjustment can be made for MAD based var_est. | freq_est. | |||

3.3.3. Clock skew | 3.3.2. Clock skew | |||

Generally sender and receiver clock skew will be too small to cause | Generally sender and receiver clock skew will be too small to cause | |||

significant errors in the estimators. Skew_est is most sensitive to | significant errors in the estimators. Skew_est is most sensitive to | |||

this type of noise. In circumstances where clock skew is high, | this type of noise. In circumstances where clock skew is high, | |||

making M < N can reduce this error. | basing skew_est only on the previous T's mean provides a noisier but | |||

reliable signal. | ||||

A better method is to estimate the effect the clock skew is having on | A better method is to estimate the effect the clock skew is having on | |||

the summary statistics, and then adjust statistics accordingly. A | the summary statistics, and then adjust statistics accordingly. A | |||

simple online method of doing this based on min_T(OWD) will be | simple online method of doing this based on min_T(OWD) will be | |||

described here in a subsequent version of the draft. | described here in a subsequent version of the draft. | |||

3.4. Reducing lag and Improving Responsiveness | 3.4. Reducing lag and Improving Responsiveness | |||

Measurement based shared bottleneck detection makes decisions in the | Measurement based shared bottleneck detection makes decisions in the | |||

present based on what has been measured in the past. This means that | present based on what has been measured in the past. This means that | |||

skipping to change at page 16, line 25 | skipping to change at page 16, line 5 | |||

+ sum([(M-F):1].*numsampT(F+1:M))) | + sum([(M-F):1].*numsampT(F+1:M))) | |||

where numsampT is an array of the number of OWD samples in each T | where numsampT is an array of the number of OWD samples in each T | |||

(i.e. num_T(OWD)), and numsampT(1) is the most recent; skew_base_T(1) | (i.e. num_T(OWD)), and numsampT(1) is the most recent; skew_base_T(1) | |||

is the most recent calculation of skew_base_T; 1:F refers to the | is the most recent calculation of skew_base_T; 1:F refers to the | |||

integer values 1 through to F, and [(M-F):1] refers to an array of | integer values 1 through to F, and [(M-F):1] refers to an array of | |||

the integer values (M-F) declining through to 1; and ".*" is the | the integer values (M-F) declining through to 1; and ".*" is the | |||

array scalar dot product operator. | array scalar dot product operator. | |||

To calculate this weighted skew_est incrementally: | ||||

Notation: F_ - flat portion, D_ - declining portion, W_ - weighted | ||||

component | ||||

Initialise: sum_skewbase = 0, F_skewbase=0, W_D_skewbase=0 | ||||

skewbase_hist = buffer length M initialize to 0 | ||||

numsampT = buffer length M initialzed to 0 | ||||

Steps per iteration: | ||||

1. old_skewbase = skewbase_hist(M) | ||||

2. old_numsampT = numsampT(M) | ||||

3. cycle(skewbase_hist) | ||||

4. cycle(numsampT) | ||||

5. numsampT(1) = num_T(OWD) | ||||

6. skewbase_hist(1) = skew_base_T | ||||

7. F_skewbase = F_skewbase + skew_base_T - skewbase_hist(F+1) | ||||

8. W_D_skewbase = W_D_skewbase + (M-F)*skewbase_hist(F+1) | ||||

- sum_skewbase | ||||

9. W_D_numsamp = W_D_numsamp + (M-F)*numsampT(F+1) - sum_numsamp | ||||

+ F_numsamp | ||||

10. F_numsamp = F_numsamp + numsampT(1) - numsampT(F+1) | ||||

11. sum_skewbase = sum_skewbase + skewbase_hist(F+1) - old_skewbase | ||||

12. sum_numsamp = sum_numsamp + numsampT(1) - old_numsampT | ||||

13. skew_est = ((M-F+1)*F_skewbase + W_D_skewbase) / | ||||

((M-F+1)*F_numsamp+W_D_numsamp) | ||||

Where cycle(....) refers to the operation on a cyclic buffer where | ||||

the start of the buffer is now the next element in the buffer. | ||||

3.4.2. Improving the response of the variability estimate | 3.4.2. Improving the response of the variability estimate | |||

The weighted moving average for var_est can be calculated as follows: | Similarly the weighted moving average for var_est can be calculated | |||

as follows: | ||||

var_est = ((M-F+1)*sum(PDV(1:F)) + sum([(M-F):1].*PDV(F+1:M))) | var_est = ((M-F+1)*sum(var_base_T(1:F)) | |||

/ (F*(M-F+1) + sum([(M-F):1]) | + sum([(M-F):1].*var_base_T(F+1:M))) | |||

where 1:F refers to the integer values 1 through to F, and [(M-F):1] | / ((M-F+1)*sum(numsampT(1:F)) | |||

refers to an array of the integer values (M-F) declining through to | ||||

1; and ".*" is the array scalar dot product operator. When removing | + sum([(M-F):1].*numsampT(F+1:M))) | |||

oscillation noise (see Section 3.3.2) this calculation must be | ||||

adjusted to allow for invalid PDV records. | where numsampT is an array of the number of OWD samples in each T | |||

(i.e. num_T(OWD)), and numsampT(1) is the most recent; skew_base_T(1) | ||||

is the most recent calculation of skew_base_T; 1:F refers to the | ||||

integer values 1 through to F, and [(M-F):1] refers to an array of | ||||

the integer values (M-F) declining through to 1; and ".*" is the | ||||

array scalar dot product operator. When removing oscillation noise | ||||

(see Section 3.3.1) this calculation must be adjusted to allow for | ||||

invalid var_base_T records. | ||||

Var_est can be calculated incrementally in the same way as skew_est | ||||

in Section 3.4.1. However, note that the buffer numsampT is used for | ||||

both calculations so the operations on it should not be repeated. | ||||

4. Measuring OWD | 4. Measuring OWD | |||

This section discusses the OWD measurements required for this | This section discusses the OWD measurements required for this | |||

algorithm to detect shared bottlenecks. | algorithm to detect shared bottlenecks. | |||

The SBD mechanism described in this draft relies on differences | The SBD mechanism described in this draft relies on differences | |||

between OWD measurements to avoid the practical problems with | between OWD measurements to avoid the practical problems with | |||

measuring absolute OWD (see [Hayes-LCN14] section IIIC). Since all | measuring absolute OWD (see [Hayes-LCN14] section IIIC). Since all | |||

summary statistics are relative to the mean OWD and sender/receiver | summary statistics are relative to the mean OWD and sender/receiver | |||

skipping to change at page 17, line 29 | skipping to change at page 18, line 8 | |||

The SBD mechanism requires timing information precise enough to be | The SBD mechanism requires timing information precise enough to be | |||

able to make comparisons. As a rule of thumb, the time resolution | 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 | should be less than one hundredth of a typical path's range of | |||

delays. In general, the lower the time resolution, the more care | delays. In general, the lower the time resolution, the more care | |||

that needs to be taken to ensure rounding errors do not bias the | that needs to be taken to ensure rounding errors do not bias the | |||

skewness calculation. | skewness calculation. | |||

Typical RTP media flows use sub-millisecond timers, which should be | Typical RTP media flows use sub-millisecond timers, which should be | |||

adequate in most situations. | adequate in most situations. | |||

5. Acknowledgements | 5. Implementation status | |||

The University of Oslo is currently working on an implementation of | ||||

this in the Chromium browser. | ||||

6. Acknowledgements | ||||

This work was part-funded by the European Community under its Seventh | This work was part-funded by the European Community under its Seventh | |||

Framework Programme through the Reducing Internet Transport Latency | Framework Programme through the Reducing Internet Transport Latency | |||

(RITE) project (ICT-317700). The views expressed are solely those of | (RITE) project (ICT-317700). The views expressed are solely those of | |||

the authors. | the authors. | |||

6. IANA Considerations | 7. IANA Considerations | |||

This memo includes no request to IANA. | This memo includes no request to IANA. | |||

7. Security Considerations | 8. Security Considerations | |||

The security considerations of RFC 3550 [RFC3550], RFC 4585 | The security considerations of RFC 3550 [RFC3550], RFC 4585 | |||

[RFC4585], and RFC 5124 [RFC5124] are expected to apply. | [RFC4585], and RFC 5124 [RFC5124] are expected to apply. | |||

Non-authenticated RTCP packets carrying shared bottleneck indications | Non-authenticated RTCP packets carrying shared bottleneck indications | |||

and summary statistics could allow attackers to alter the bottleneck | and summary statistics could allow attackers to alter the bottleneck | |||

sharing characteristics for private gain or disruption of other | sharing characteristics for private gain or disruption of other | |||

parties communication. | parties communication. | |||

8. Change history | 9. Change history | |||

Changes made to this document: | Changes made to this document: | |||

WG-01->WG-02 : Removed ambiguity associated with the term | ||||

"congestion". Expanded the description of | ||||

initialisation messages. Removed PDV metric. | ||||

Added description of incremental weighted metric | ||||

calculations for skew_est. Various clarifications | ||||

based on implementation work. Fixed typos and | ||||

tuned parameters. | ||||

WG-00->WG-01 : Moved unbiased skew section to replace skew | WG-00->WG-01 : Moved unbiased skew section to replace skew | |||

estimate, more robust variability estimator, the | estimate, more robust variability estimator, the | |||

term variance replaced with variability, clock | term variance replaced with variability, clock | |||

drift term corrected to clock skew, revision to | drift term corrected to clock skew, revision to | |||

clock skew section with a place holder, description | clock skew section with a place holder, description | |||

of parameters. | of parameters. | |||

02->WG-00 : Fixed missing 0.5 in 3.3.2 and missing brace in | 02->WG-00 : Fixed missing 0.5 in 3.3.2 and missing brace in | |||

3.3.3 | 3.3.3 | |||

01->02 : New section describing improvements to the key | 01->02 : New section describing improvements to the key | |||

metric calculations that help to remove noise, | metric calculations that help to remove noise, | |||

bias, and reduce lag. Some revisions to the | bias, and reduce lag. Some revisions to the | |||

notation to make it clearer. Some tightening of | notation to make it clearer. Some tightening of | |||

the thresholds. | the thresholds. | |||

00->01 : Revisions to terminology for clarity | 00->01 : Revisions to terminology for clarity | |||

9. References | 10. References | |||

9.1. Normative References | 10.1. Normative References | |||

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||

Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ | |||

RFC2119, March 1997, | ||||

<http://www.rfc-editor.org/info/rfc2119>. | ||||

9.2. Informative References | 10.2. Informative References | |||

[Hayes-LCN14] | [Hayes-LCN14] | |||

Hayes, D., Ferlin, S., and M. Welzl, "Practical Passive | Hayes, D., Ferlin, S., and M. Welzl, "Practical Passive | |||

Shared Bottleneck Detection using Shape Summary | Shared Bottleneck Detection using Shape Summary | |||

Statistics", Proc. the IEEE Local Computer Networks | Statistics", Proc. the IEEE Local Computer Networks (LCN) | |||

(LCN) p150-158, September 2014, <http://heim.ifi.uio.no/ | p150-158, September 2014, <http://heim.ifi.uio.no/davihay/ | |||

davihay/ | ||||

hayes14__pract_passiv_shared_bottl_detec-abstract.html>. | hayes14__pract_passiv_shared_bottl_detec-abstract.html>. | |||

[I-D.welzl-rmcat-coupled-cc] | [I-D.welzl-rmcat-coupled-cc] | |||

Welzl, M., Islam, S., and S. Gjessing, "Coupled congestion | Welzl, M., Islam, S., and S. Gjessing, "Coupled congestion | |||

control for RTP media", draft-welzl-rmcat-coupled-cc-04 | control for RTP media", draft-welzl-rmcat-coupled-cc-04 | |||

(work in progress), October 2014. | (work in progress), October 2014. | |||

[ITU-Y1540] | [ITU-Y1540] | |||

ITU-T, "Internet Protocol Data Communication Service - IP | ITU-T, "Internet Protocol Data Communication Service - IP | |||

Packet Transfer and Availability Performance Parameters", | Packet Transfer and Availability Performance Parameters", | |||

Series Y: Global Information Infrastructure, Internet | Series Y: Global Information Infrastructure, Internet | |||

Protocol Aspects and Next-Generation Networks , | Protocol Aspects and Next-Generation Networks , March | |||

March 2011, | 2011, <http://www.itu.int/rec/T-REC-Y.1540-201103-I/en>. | |||

<http://www.itu.int/rec/T-REC-Y.1540-201103-I/en>. | ||||

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. | |||

Jacobson, "RTP: A Transport Protocol for Real-Time | Jacobson, "RTP: A Transport Protocol for Real-Time | |||

Applications", STD 64, RFC 3550, July 2003. | Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, | |||

July 2003, <http://www.rfc-editor.org/info/rfc3550>. | ||||

[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, | [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, | |||

"Extended RTP Profile for Real-time Transport Control | "Extended RTP Profile for Real-time Transport Control | |||

Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, | Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI | |||

July 2006. | 10.17487/RFC4585, July 2006, | |||

<http://www.rfc-editor.org/info/rfc4585>. | ||||

[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for | [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for | |||

Real-time Transport Control Protocol (RTCP)-Based Feedback | Real-time Transport Control Protocol (RTCP)-Based Feedback | |||

(RTP/SAVPF)", RFC 5124, February 2008. | (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February | |||

2008, <http://www.rfc-editor.org/info/rfc5124>. | ||||

[RFC5481] Morton, A. and B. Claise, "Packet Delay Variation | [RFC5481] Morton, A. and B. Claise, "Packet Delay Variation | |||

Applicability Statement", RFC 5481, March 2009. | Applicability Statement", RFC 5481, DOI 10.17487/RFC5481, | |||

March 2009, <http://www.rfc-editor.org/info/rfc5481>. | ||||

[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, | [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, | |||

"Low Extra Delay Background Transport (LEDBAT)", RFC 6817, | "Low Extra Delay Background Transport (LEDBAT)", RFC 6817, | |||

December 2012. | DOI 10.17487/RFC6817, December 2012, | |||

<http://www.rfc-editor.org/info/rfc6817>. | ||||

Authors' Addresses | Authors' Addresses | |||

David Hayes (editor) | David Hayes (editor) | |||

University of Oslo | University of Oslo | |||

PO Box 1080 Blindern | PO Box 1080 Blindern | |||

Oslo, N-0316 | Oslo N-0316 | |||

Norway | Norway | |||

Phone: +47 2284 5566 | Phone: +47 2284 5566 | |||

Email: davihay@ifi.uio.no | Email: davihay@ifi.uio.no | |||

Simone Ferlin | Simone Ferlin | |||

Simula Research Laboratory | Simula Research Laboratory | |||

P.O.Box 134 | P.O.Box 134 | |||

Lysaker, 1325 | Lysaker 1325 | |||

Norway | Norway | |||

Phone: +47 4072 0702 | Phone: +47 4072 0702 | |||

Email: ferlin@simula.no | Email: ferlin@simula.no | |||

Michael Welzl | Michael Welzl | |||

University of Oslo | University of Oslo | |||

PO Box 1080 Blindern | PO Box 1080 Blindern | |||

Oslo, N-0316 | Oslo N-0316 | |||

Norway | Norway | |||

Phone: +47 2285 2420 | Phone: +47 2285 2420 | |||

Email: michawe@ifi.uio.no | Email: michawe@ifi.uio.no | |||

Kristian Hiorth | ||||

University of Oslo | ||||

PO Box 1080 Blindern | ||||

Oslo N-0316 | ||||

Norway | ||||

Email: kristahi@ifi.uio.no | ||||

End of changes. 91 change blocks. | ||||

234 lines changed or deleted | | 304 lines changed or added | ||

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |