draft-ietf-rmcat-coupled-cc-03.txt   draft-ietf-rmcat-coupled-cc-04.txt 
RTP Media Congestion Avoidance Techniques (rmcat) S. Islam RTP Media Congestion Avoidance S. Islam
Internet-Draft M. Welzl Techniques (rmcat) M. Welzl
Intended status: Experimental S. Gjessing Internet-Draft S. Gjessing
Expires: January 29, 2017 University of Oslo Intended status: Experimental University of Oslo
July 28, 2016 Expires: May 4, 2017 October 31, 2016
Coupled congestion control for RTP media Coupled congestion control for RTP media
draft-ietf-rmcat-coupled-cc-03 draft-ietf-rmcat-coupled-cc-04
Abstract Abstract
When multiple congestion controlled RTP sessions traverse the same When multiple congestion controlled RTP sessions traverse the same
network bottleneck, it can be beneficial to combine their controls network bottleneck, combining their controls can improve the total
such that the total on-the-wire behavior is improved. This document on-the-wire behavior in terms of delay, loss and fairness. This
describes such a method for flows that have the same sender, in a way document describes such a method for flows that have the same sender,
that is as flexible and simple as possible while minimizing the in a way that is as flexible and simple as possible while minimizing
amount of changes needed to existing RTP applications. It specifies the amount of changes needed to existing RTP applications. It
how to apply the method for both the NADA and Google congestion specifies how to apply the method for both the NADA and Google
control algorithms. congestion control algorithms.
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 29, 2017. This Internet-Draft will expire on May 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Architectural overview . . . . . . . . . . . . . . . . . . . 4 4. Architectural overview . . . . . . . . . . . . . . . . . . . . 4
5. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. SBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. SBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. FSE . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. FSE . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3.1. Example algorithm 1 - Active FSE . . . . . . . . . . 7 5.3.1. Example algorithm 1 - Active FSE . . . . . . . . . . . 8
5.3.2. Example algorithm 2 - Conservative Active FSE . . . . 8 5.3.2. Example algorithm 2 - Conservative Active FSE . . . . 9
6. Application . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Application . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. NADA . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. NADA . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2. GCC . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.2. GCC . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.3. General recommendations . . . . . . . . . . . . . . . . . 10 6.3. General recommendations . . . . . . . . . . . . . . . . . 11
7. Expected feedback from experiments . . . . . . . . . . . . . 11 7. Expected feedback from experiments . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Scheduling . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Scheduling . . . . . . . . . . . . . . . . . . . . . 15
Appendix B. Example algorithm - Passive FSE . . . . . . . . . . 14 Appendix B. Example algorithm - Passive FSE . . . . . . . . . . . 15
B.1. Example operation (passive) . . . . . . . . . . . . . . . 17 B.1. Example operation (passive) . . . . . . . . . . . . . . . 18
Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 21 Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 22
C.1. draft-welzl-rmcat-coupled-cc . . . . . . . . . . . . . . 21 C.1. draft-welzl-rmcat-coupled-cc . . . . . . . . . . . . . . . 22
C.1.1. Changes from -00 to -01 . . . . . . . . . . . . . . . 21 C.1.1. Changes from -00 to -01 . . . . . . . . . . . . . . . 22
C.1.2. Changes from -01 to -02 . . . . . . . . . . . . . . . 21 C.1.2. Changes from -01 to -02 . . . . . . . . . . . . . . . 22
C.1.3. Changes from -02 to -03 . . . . . . . . . . . . . . . 21 C.1.3. Changes from -02 to -03 . . . . . . . . . . . . . . . 22
C.1.4. Changes from -03 to -04 . . . . . . . . . . . . . . . 22 C.1.4. Changes from -03 to -04 . . . . . . . . . . . . . . . 22
C.1.5. Changes from -04 to -05 . . . . . . . . . . . . . . . 22 C.1.5. Changes from -04 to -05 . . . . . . . . . . . . . . . 22
C.2. draft-ietf-rmcat-coupled-cc . . . . . . . . . . . . . . . 22 C.2. draft-ietf-rmcat-coupled-cc . . . . . . . . . . . . . . . 23
C.2.1. Changes from draft-welzl-rmcat-coupled-cc-05 . . . . 22 C.2.1. Changes from draft-welzl-rmcat-coupled-cc-05 . . . . . 23
C.2.2. Changes from -00 to -01 . . . . . . . . . . . . . . . 22 C.2.2. Changes from -00 to -01 . . . . . . . . . . . . . . . 23
C.2.3. Changes from -01 to -02 . . . . . . . . . . . . . . . 22 C.2.3. Changes from -01 to -02 . . . . . . . . . . . . . . . 23
C.2.4. Changes from -02 to -03 . . . . . . . . . . . . . . . 22 C.2.4. Changes from -02 to -03 . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 C.2.5. Changes from -03 to -04 . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
When there is enough data to send, a congestion controller must When there is enough data to send, a congestion controller must
increase its sending rate until the path's capacity has been reached; increase its sending rate until the path's capacity has been reached;
depending on the controller, sometimes the rate is increased further, depending on the controller, sometimes the rate is increased further,
until packets are ECN-marked or dropped. This process inevitably until packets are ECN-marked or dropped. This process inevitably
creates undesirable queuing delay -- an effect that is amplified when creates undesirable queuing delay when multiple congestion controlled
multiple congestion controlled connections traverse the same network connections traverse the same network bottleneck.
bottleneck.
The Congestion Manager (CM) [RFC3124] couples flows by providing a The Congestion Manager (CM) [RFC3124] couples flows by providing a
single congestion controller. It is hard to implement because it single congestion controller. It is hard to implement because it
requires an additional congestion controller and removes all per- requires an additional congestion controller and removes all per-
connection congestion control functionality, which is quite a connection congestion control functionality, which is quite a
significant change to existing RTP based applications. This document significant change to existing RTP based applications. This document
presents a method to combine the behavior of congestion control presents a method to combine the behavior of congestion control
mechanisms that is easier to implement than the Congestion Manager mechanisms that is easier to implement than the Congestion Manager
[RFC3124] and also requires less significant changes to existing RTP [RFC3124] and also requires less significant changes to existing RTP
based applications. It attempts to roughly approximate the CM based applications. It attempts to roughly approximate the CM
skipping to change at page 4, line 23 skipping to change at page 4, line 23
The entity that determines which flows traverse the same The entity that determines which flows traverse the same
bottleneck in the network, or the process of doing so. bottleneck in the network, or the process of doing so.
3. Limitations 3. Limitations
Sender-side only: Sender-side only:
Coupled congestion control as described here only operates Coupled congestion control as described here only operates
inside a single host on the sender side. This is because, inside a single host on the sender side. This is because,
irrespective of where the major decisions for congestion irrespective of where the major decisions for congestion
control are taken, the sender of a flow needs to eventually control are taken, the sender of a flow needs to eventually
decide the transmission rate. Additionally, the necessary decide on the transmission rate. Additionally, the necessary
information about how much data an application can currently information about how much data an application can currently
send on a flow is often only available at the sender side, send on a flow is often only available at the sender side,
making the sender an obvious choice for placement of the making the sender an obvious choice for placement of the
elements and mechanisms described here. elements and mechanisms described here.
Shared bottlenecks do not change quickly: Shared bottlenecks do not change quickly:
As per the definition above, a bottleneck depends on cross As per the definition above, a bottleneck depends on cross
traffic, and since such traffic can heavily fluctuate, traffic, and since such traffic can heavily fluctuate,
bottlenecks can change at a high frequency (e.g., there can be bottlenecks can change at a high frequency (e.g., there can be
oscillation between two or more links). This means that, when oscillation between two or more links). This means that, when
skipping to change at page 5, line 15 skipping to change at page 5, line 17
flows and SBD; its only active role is internal state maintenance flows and SBD; its only active role is internal state maintenance
(e.g., an implementation could use soft state to remove a flow's data (e.g., an implementation could use soft state to remove a flow's data
after long periods of inactivity). Every time a flow's congestion after long periods of inactivity). Every time a flow's congestion
control mechanism would normally update its sending rate, the flow control mechanism would normally update its sending rate, the flow
instead updates information in the FSE and performs a query on the instead updates information in the FSE and performs a query on the
FSE, leading to a sending rate that can be different from what the FSE, leading to a sending rate that can be different from what the
congestion controller originally determined. Using information congestion controller originally determined. Using information
about/from the currently active flows, SBD updates the FSE with the about/from the currently active flows, SBD updates the FSE with the
correct Flow State Identifiers (FSIs). This document describes both correct Flow State Identifiers (FSIs). This document describes both
active and passive versions, however the passive version is put into active and passive versions, however the passive version is put into
the appendix as it is extremely experimental. the appendix as it is extremely experimental. Figure 2 shows the
interaction between flows and the FSE, using the variable names
defined in Section 5.2.
------- <--- Flow 1 ------- <--- Flow 1
| FSE | <--- Flow 2 .. | FSE | <--- Flow 2 ..
------- <--- .. Flow N ------- <--- .. Flow N
^ ^
| | | |
------- | ------- |
| SBD | <-------| | SBD | <-------|
------- -------
Figure 1: Coupled congestion control architecture Figure 1: Coupled congestion control architecture
Flow#1(cc) FSE Flow#2(cc)
---------- --- ----------
#1 JOIN ----register--> REGISTER
REGISTER <--register-- JOIN #1
#2 CC_R ----UPDATE----> UPDATE (in)
#3 NEW RATE <---FSE_R------ UPDATE (out) --FSE_R----> #3 NEW RATE
Figure 2: Flow-FSE interaction
Since everything shown in Figure 1 is assumed to operate on a single Since everything shown in Figure 1 is assumed to operate on a single
host (the sender) only, this document only describes aspects that host (the sender) only, this document only describes aspects that
have an influence on the resulting on-the-wire behavior. It does, have an influence on the resulting on-the-wire behavior. It does,
for instance, not define how many bits must be used to represent for instance, not define how many bits must be used to represent
FSIs, or in which way the entities communicate. Implementations can FSIs, or in which way the entities communicate. Implementations can
take various forms: for instance, all the elements in the figure take various forms: for instance, all the elements in the figure
could be implemented within a single application, thereby operating could be implemented within a single application, thereby operating
on flows generated by that application only. Another alternative on flows generated by that application only. Another alternative
could be to implement both the FSE and SBD together in a separate could be to implement both the FSE and SBD together in a separate
process which different applications communicate with via some form process which different applications communicate with via some form
skipping to change at page 6, line 34 skipping to change at page 7, line 4
is also a shared bottleneck. is also a shared bottleneck.
3. From measurements: e.g. by considering correlations among 3. From measurements: e.g. by considering correlations among
measured delay and loss as an indication of a shared bottleneck. measured delay and loss as an indication of a shared bottleneck.
The methods above have some essential trade-offs: e.g., multiplexing The methods above have some essential trade-offs: e.g., multiplexing
is a completely reliable measure, however it is limited in scope to is a completely reliable measure, however it is limited in scope to
two end points (i.e., it cannot be applied to couple congestion two end points (i.e., it cannot be applied to couple congestion
controllers of one sender talking to multiple receivers). A controllers of one sender talking to multiple receivers). A
measurement-based SBD mechanism is described in [I-D.ietf-rmcat-sbd]. measurement-based SBD mechanism is described in [I-D.ietf-rmcat-sbd].
Measurements can never be 100% reliable, in particular because they Measurements can never be 100% reliable, in particular because they
are based on the past but applying coupled congestion control means are based on the past but applying coupled congestion control means
to make an assumption about the future; it is therefore recommended to make an assumption about the future; it is therefore recommended
to implement cautionary measures, e.g. by disabling coupled to implement cautionary measures, e.g. by disabling coupled
congestion control if enabling it causes a significant increase in congestion control if enabling it causes a significant increase in
delay and/or packet loss. Measurements also take time, which entails delay and/or packet loss. Measurements also take time, which entails
a certain delay for turning on coupling (refer to a certain delay for turning on coupling (refer to
[I-D.ietf-rmcat-sbd] for details). [I-D.ietf-rmcat-sbd] for details). Using system configuration to
decide about shared bottlenecks can be more efficient (faster to
obtain) than using measurements, but it relies on assumptions about
the network environment.
5.2. FSE 5.2. FSE
The FSE contains a list of all flows that have registered with it. The FSE contains a list of all flows that have registered with it.
For each flow, it stores the following: For each flow, it stores the following:
o a unique flow number to identify the flow o a unique flow number to identify the flow
o the FGI of the FG that it belongs to (based on the definitions in o the FGI of the FG that it belongs to (based on the definitions in
this document, a flow has only one bottleneck, and can therefore this document, a flow has only one bottleneck, and can therefore
skipping to change at page 7, line 40 skipping to change at page 8, line 17
Flows register themselves with SBD and FSE when they start, Flows register themselves with SBD and FSE when they start,
deregister from the FSE when they stop, and carry out an UPDATE deregister from the FSE when they stop, and carry out an UPDATE
function call every time their congestion controller calculates a new function call every time their congestion controller calculates a new
sending rate. Via UPDATE, they provide the newly calculated rate and sending rate. Via UPDATE, they provide the newly calculated rate and
optionally (if the algorithm supports it) the desired rate. The optionally (if the algorithm supports it) the desired rate. The
desired rate is less than the calculated rate in case of application- desired rate is less than the calculated rate in case of application-
limited flows; otherwise, it is the same as the calculated rate. limited flows; otherwise, it is the same as the calculated rate.
Below, two example algorithms are described. While other algorithms Below, two example algorithms are described. While other algorithms
could be used instead, the same algorithm must be applied to all could be used instead, the same algorithm must be applied to all
flows. flows. Names of variables used in the algorithms are explained
below.
o CC_R - The rate received from a flow's congestion controller when
it calls UPDATE.
o FSE_R - The rate calculated by the FSE for a flow.
o S_CR - The sum of the calculated rates of all flows in the same
FG; this value is used to calculate the sending rate.
o FG - A group of flows having the same FGI, and hence sharing the
same bottleneck.
o P - The priority of a flow which is received from the flow's
congestion controller; the FSE uses this variable for calculating
FSE R.
o S_P - The sum of all the priorities.
5.3.1. Example algorithm 1 - Active FSE 5.3.1. Example algorithm 1 - Active FSE
This algorithm was designed to be the simplest possible method to This algorithm was designed to be the simplest possible method to
assign rates according to the priorities of flows. Simulations assign rates according to the priorities of flows. Simulations
results in [fse] indicate that it does however not significantly results in [fse] indicate that it does however not significantly
reduce queuing delay and packet loss. reduce queuing delay and packet loss.
(1) When a flow f starts, it registers itself with SBD and the FSE. (1) When a flow f starts, it registers itself with SBD and the FSE.
FSE_R is initialized with the congestion controller's initial FSE_R is initialized with the congestion controller's initial
skipping to change at page 9, line 12 skipping to change at page 10, line 7
(2) When a flow f stops or pauses, its entry is removed from the (2) When a flow f stops or pauses, its entry is removed from the
list. list.
(3) Every time the congestion controller of the flow f determines a (3) Every time the congestion controller of the flow f determines a
new sending rate CC_R, the flow calls UPDATE, which carries out new sending rate CC_R, the flow calls UPDATE, which carries out
the tasks listed below to derive the new sending rates for all the tasks listed below to derive the new sending rates for all
the flows in the FG. A flow's UPDATE function uses a local the flows in the FG. A flow's UPDATE function uses a local
(i.e. per-flow) temporary variable S_P, which is the sum of all (i.e. per-flow) temporary variable S_P, which is the sum of all
the priorities, and a local variable DELTA, which is used to the priorities, and a local variable DELTA, which is used to
calculate the difference between CC_R and the previously stored calculate the difference between CC_R and the previously stored
FSE_R. To prevent flows from either ignoring congestion or FSE_R. To prevent flows from either ignoring congestion or
overreacting, a timer keeps them from changing their rates overreacting, a timer keeps them from changing their rates
immediately after the common rate reduction that follows a immediately after the common rate reduction that follows a
congestion event. This timer is set to 2 RTTs of the flow that congestion event. This timer is set to 2 RTTs of the flow that
experienced congestion because it is assumed that a congestion experienced congestion because it is assumed that a congestion
event can persist for up to one RTT of that flow, with another event can persist for up to one RTT of that flow, with another
RTT added to compensate for fluctuations in the measured RTT RTT added to compensate for fluctuations in the measured RTT
value. value.
(a) It updates S_CR based on DELTA. (a) It updates S_CR based on DELTA.
skipping to change at page 11, line 9 skipping to change at page 12, line 4
of the sender, the calculations need to be synchronized or the of the sender, the calculations need to be synchronized or the
receiver needs to be updated accordingly. This applies to TFRC receiver needs to be updated accordingly. This applies to TFRC
[RFC5348], for example, where simulations showed somewhat less [RFC5348], for example, where simulations showed somewhat less
favorable results when using the FSE without a receiver-side favorable results when using the FSE without a receiver-side
change [fse]. change [fse].
7. Expected feedback from experiments 7. Expected feedback from experiments
The algorithm described in this memo has so far been evaluated using The algorithm described in this memo has so far been evaluated using
simulations covering all the tests for more than one flow from simulations covering all the tests for more than one flow from
[I-D.ietf-rmcat-eval-test] (see [IETF-93], [IETF-94]). Experiments [I-D.ietf-rmcat-eval-test] (see [IETF-93], [IETF-94]). Experiments
should confirm these results using at least one of the same should confirm these results using at least one of the same
congestion control algorithms (GCC or NADA) with real-life code congestion control algorithms (GCC or NADA) with real-life code
(e.g., browsers communicating over an emulated network covering the (e.g., browsers communicating over an emulated network covering the
conditions in [I-D.ietf-rmcat-eval-test]. The tests with real-life conditions in [I-D.ietf-rmcat-eval-test]. The tests with real-life
code should be repeated afterwards in real network environments and code should be repeated afterwards in real network environments and
monitored. Implementers and testers are invited to document their monitored. Experiments should investigate cases where the media
findings in an Internet draft. coder's output rate is below the rate that is calculated by the
coupling algorithm (FSE_R in algorithms 1 and 2, section 5.3).
Implementers and testers are invited to document their findings in an
Internet draft.
8. Acknowledgements 8. Acknowledgements
This document has benefitted from discussions with and feedback from This document has benefitted from discussions with and feedback from
David Hayes, Mirja Kuehlewind, Karen Nielsen, Andreas Petlund, David Andreas Petlund, Anna Brunstrom, David Hayes, David Ros (who also
Ros (who also gave the FSE its name), Zaheduzzaman Sarker, Varun gave the FSE its name), Ingemar Johansson, Karen Nielsen, Kristian
Singh, Anna Brunstrom, Martin Stiemerling, and Kristian Hiorth. The Hiorth, Mirja Kuehlewind, Martin Stiemerling, Varun Singh , Xiaoqing
authors would like to thank Xiaoqing Zhu and Stefan Holmer for Zhu, and Zaheduzzaman Sarker. The authors would like to especially
helping with NADA and GCC. thank Xiaoqing Zhu and Stefan Holmer for helping with NADA and GCC.
This work was partially funded by the European Community under its This work was partially funded by the European Community under its
Seventh Framework Programme through the Reducing Internet Transport Seventh Framework Programme through the Reducing Internet Transport
Latency (RITE) project (ICT-317700). Latency (RITE) project (ICT-317700).
9. IANA Considerations 9. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
10. Security Considerations 10. Security Considerations
skipping to change at page 12, line 20 skipping to change at page 13, line 22
11.1. Normative References 11.1. Normative References
[I-D.ietf-rmcat-gcc] [I-D.ietf-rmcat-gcc]
Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S. Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S.
Mascolo, "A Google Congestion Control Algorithm for Real- Mascolo, "A Google Congestion Control Algorithm for Real-
Time Communication", draft-ietf-rmcat-gcc-02 (work in Time Communication", draft-ietf-rmcat-gcc-02 (work in
progress), July 2016. progress), July 2016.
[I-D.ietf-rmcat-nada] [I-D.ietf-rmcat-nada]
Zhu, X., Pan, R., Ramalho, D., Cruz, S., Jones, P., Fu, Zhu, X., Pan, R., Ramalho, M., Cruz, S., Jones, P., Fu,
J., D'Aronco, S., and C. Ganzhorn, "NADA: A Unified J., D'Aronco, S., and C. Ganzhorn, "NADA: A Unified
Congestion Control Scheme for Real-Time Media", draft- Congestion Control Scheme for Real-Time Media",
ietf-rmcat-nada-02 (work in progress), March 2016. draft-ietf-rmcat-nada-03 (work in progress),
September 2016.
[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, Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
DOI 10.17487/RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager",
RFC 3124, DOI 10.17487/RFC3124, June 2001, RFC 3124, DOI 10.17487/RFC3124, June 2001,
<http://www.rfc-editor.org/info/rfc3124>. <http://www.rfc-editor.org/info/rfc3124>.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification", Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, DOI 10.17487/RFC5348, September 2008, RFC 5348, DOI 10.17487/RFC5348, September 2008,
<http://www.rfc-editor.org/info/rfc5348>. <http://www.rfc-editor.org/info/rfc5348>.
11.2. Informative References 11.2. Informative References
[fse] Islam, S., Welzl, M., Gjessing, S., and N. Khademi,
"Coupled Congestion Control for RTP Media", ACM SIGCOMM
Capacity Sharing Workshop (CSWS 2014) and ACM SIGCOMM CCR
44(4) 2014; extended version available as a technical
report from
http://safiquli.at.ifi.uio.no/paper/fse-tech-report.pdf ,
2014.
[fse-noms]
Islam, S., Welzl, M., Hayes, D., and S. Gjessing,
"Managing Real-Time Media Flows through a Flow State
Exchange", IEEE NOMS 2016, Istanbul, Turkey , 2016.
[I-D.ietf-rmcat-eval-test] [I-D.ietf-rmcat-eval-test]
Sarker, Z., Singh, V., Zhu, X., and D. Ramalho, "Test Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test
Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat- Cases for Evaluating RMCAT Proposals",
eval-test-03 (work in progress), March 2016. draft-ietf-rmcat-eval-test-04 (work in progress),
October 2016.
[I-D.ietf-rmcat-sbd] [I-D.ietf-rmcat-sbd]
Hayes, D., Ferlin, S., Welzl, M., and K. Hiorth, "Shared Hayes, D., Ferlin, S., Welzl, M., and K. Hiorth, "Shared
Bottleneck Detection for Coupled Congestion Control for Bottleneck Detection for Coupled Congestion Control for
RTP Media.", draft-ietf-rmcat-sbd-04 (work in progress), RTP Media.", draft-ietf-rmcat-sbd-04 (work in progress),
March 2016. March 2016.
[I-D.ietf-rtcweb-transports] [I-D.ietf-rtcweb-transports]
Alvestrand, H., "Transports for WebRTC", Internet-draft Alvestrand, H., "Transports for WebRTC",
draft-ietf-rtcweb-transports-11.txt, January 2016. draft-ietf-rtcweb-transports-11.txt (work in progress),
January 2016.
[IETF-93] Islam, S., Welzl, M., and S. Gjessing, "Updates on Coupled [IETF-93] Islam, S., Welzl, M., and S. Gjessing, "Updates on Coupled
Congestion Control for RTP Media", July 2015, Congestion Control for RTP Media", July 2015,
<http://www.ietf.org/proceedings/93/slides/ <https://www.ietf.org/proceedings/93/rmcat.html>.
slides-93-rmcat-3.pptx>.
[IETF-94] Islam, S., Welzl, M., and S. Gjessing, "Updates on Coupled [IETF-94] Islam, S., Welzl, M., and S. Gjessing, "Updates on Coupled
Congestion Control for RTP Media", November 2015, Congestion Control for RTP Media", November 2015,
<https://www.ietf.org/proceedings/94/slides/slides-94- <https://www.ietf.org/proceedings/94/rmcat.html>.
rmcat-5.pdf>.
[RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- [RFC7478] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
Time Communication Use Cases and Requirements", RFC 7478, Time Communication Use Cases and Requirements", RFC 7478,
DOI 10.17487/RFC7478, March 2015, DOI 10.17487/RFC7478, March 2015,
<http://www.rfc-editor.org/info/rfc7478>. <http://www.rfc-editor.org/info/rfc7478>.
[fse] Islam, S., Welzl, M., Gjessing, S., and N. Khademi,
"Coupled Congestion Control for RTP Media", ACM SIGCOMM
Capacity Sharing Workshop (CSWS 2014) and ACM SIGCOMM CCR
44(4) 2014; extended version available as a technical
report from
http://safiquli.at.ifi.uio.no/paper/fse-tech-report.pdf ,
2014.
[fse-noms]
Islam, S., Welzl, M., Hayes, D., and S. Gjessing,
"Managing Real-Time Media Flows through a Flow State
Exchange", IEEE NOMS 2016, Istanbul, Turkey , 2016.
[rtcweb-rtp-usage] [rtcweb-rtp-usage]
Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time
Communication (WebRTC): Media Transport and Use of RTP", Communication (WebRTC): Media Transport and Use of RTP",
Internet-draft draft-ietf-rtcweb-rtp-usage-26.txt, March draft-ietf-rtcweb-rtp-usage-26.txt (work in progress),
2016. March 2016.
[transport-multiplex] [transport-multiplex]
Westerlund, M. and C. Perkins, "Multiple RTP Sessions on a Westerlund, M. and C. Perkins, "Multiple RTP Sessions on a
Single Lower-Layer Transport", Internet-draft draft- Single Lower-Layer Transport",
westerlund-avtcore-transport-multiplexing-07.txt, October draft-westerlund-avtcore-transport-multiplexing-07.txt
2013. (work in progress), October 2013.
Appendix A. Scheduling Appendix A. Scheduling
When connections originate from the same host, it would be possible When connections originate from the same host, it would be possible
to use only one single sender-side congestion controller which to use only one single sender-side congestion controller which
determines the overall allowed sending rate, and then use a local determines the overall allowed sending rate, and then use a local
scheduler to assign a proportion of this rate to each RTP session. scheduler to assign a proportion of this rate to each RTP session.
This way, priorities could also be implemented as a function of the This way, priorities could also be implemented as a function of the
scheduler. The Congestion Manager (CM) [RFC3124] also uses such a scheduler. The Congestion Manager (CM) [RFC3124] also uses such a
scheduling function. scheduling function.
skipping to change at page 22, line 47 skipping to change at page 23, line 35
o Moved references of NADA and GCC from informative to normative. o Moved references of NADA and GCC from informative to normative.
o Added a reference for the passive variant of the algorithm. o Added a reference for the passive variant of the algorithm.
C.2.4. Changes from -02 to -03 C.2.4. Changes from -02 to -03
o Minor changes. o Minor changes.
o Added a section about expected feedback from experiments. o Added a section about expected feedback from experiments.
C.2.5. Changes from -03 to -04
o Described the names of variables used in the algorithms.
o Added a diagram to illustrate the interaction between flows and
the FSE.
o Added text on the trade-off of using the configuration based
approach.
o Minor changes to enhance the readability.
Authors' Addresses Authors' Addresses
Safiqul Islam Safiqul Islam
University of Oslo University of Oslo
PO Box 1080 Blindern PO Box 1080 Blindern
Oslo N-0316 Oslo, N-0316
Norway Norway
Phone: +47 22 84 08 37 Phone: +47 22 84 08 37
Email: safiquli@ifi.uio.no Email: safiquli@ifi.uio.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 22 85 24 20 Phone: +47 22 85 24 20
Email: michawe@ifi.uio.no Email: michawe@ifi.uio.no
Stein Gjessing Stein Gjessing
University of Oslo University of Oslo
PO Box 1080 Blindern PO Box 1080 Blindern
Oslo N-0316 Oslo, N-0316
Norway Norway
Phone: +47 22 85 24 44 Phone: +47 22 85 24 44
Email: steing@ifi.uio.no Email: steing@ifi.uio.no
 End of changes. 34 change blocks. 
110 lines changed or deleted 164 lines changed or added

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