draft-ietf-rmcat-coupled-cc-04.txt   draft-ietf-rmcat-coupled-cc-05.txt 
RTP Media Congestion Avoidance S. Islam RTP Media Congestion Avoidance S. Islam
Techniques (rmcat) M. Welzl Techniques (rmcat) M. Welzl
Internet-Draft S. Gjessing Internet-Draft S. Gjessing
Intended status: Experimental University of Oslo Intended status: Experimental University of Oslo
Expires: May 4, 2017 October 31, 2016 Expires: June 10, 2017 December 7, 2016
Coupled congestion control for RTP media Coupled congestion control for RTP media
draft-ietf-rmcat-coupled-cc-04 draft-ietf-rmcat-coupled-cc-05
Abstract Abstract
When multiple congestion controlled RTP sessions traverse the same When multiple congestion controlled RTP sessions traverse the same
network bottleneck, combining their controls can improve the total network bottleneck, combining their controls can improve the total
on-the-wire behavior in terms of delay, loss and fairness. This on-the-wire behavior in terms of delay, loss and fairness. This
document describes such a method for flows that have the same sender, document describes such a method for flows that have the same sender,
in a way that is as flexible and simple as possible while minimizing in a way that is as flexible and simple as possible while minimizing
the amount of changes needed to existing RTP applications. It the amount of changes needed to existing RTP applications. It
specifies how to apply the method for both the NADA and Google specifies how to apply the method for the NADA congestion control
algorithm, and provides suggestions on how to apply it to other
congestion 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 May 4, 2017. This Internet-Draft will expire on June 10, 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
skipping to change at page 2, line 23 skipping to change at page 2, line 24
3. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Architectural overview . . . . . . . . . . . . . . . . . . . . 4 4. Architectural overview . . . . . . . . . . . . . . . . . . . . 4
5. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. SBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. SBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. FSE . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. FSE . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3.1. Example algorithm 1 - Active FSE . . . . . . . . . . . 8 5.3.1. Example algorithm 1 - Active FSE . . . . . . . . . . . 8
5.3.2. Example algorithm 2 - Conservative Active FSE . . . . 9 5.3.2. Example algorithm 2 - Conservative Active FSE . . . . 9
6. Application . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Application . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. NADA . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. NADA . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2. GCC . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. General recommendations . . . . . . . . . . . . . . . . . 11
6.3. General recommendations . . . . . . . . . . . . . . . . . 11 7. Expected feedback from experiments . . . . . . . . . . . . . . 12
7. Expected feedback from experiments . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Scheduling . . . . . . . . . . . . . . . . . . . . . 15 Appendix A. Application to GCC . . . . . . . . . . . . . . . . . 15
Appendix B. Example algorithm - Passive FSE . . . . . . . . . . . 15 Appendix B. Scheduling . . . . . . . . . . . . . . . . . . . . . 15
B.1. Example operation (passive) . . . . . . . . . . . . . . . 18 Appendix C. Example algorithm - Passive FSE . . . . . . . . . . . 15
Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 22 C.1. Example operation (passive) . . . . . . . . . . . . . . . 18
C.1. draft-welzl-rmcat-coupled-cc . . . . . . . . . . . . . . . 22 Appendix D. Change log . . . . . . . . . . . . . . . . . . . . . 22
C.1.1. Changes from -00 to -01 . . . . . . . . . . . . . . . 22 D.1. draft-welzl-rmcat-coupled-cc . . . . . . . . . . . . . . . 22
C.1.2. Changes from -01 to -02 . . . . . . . . . . . . . . . 22 D.1.1. Changes from -00 to -01 . . . . . . . . . . . . . . . 22
C.1.3. Changes from -02 to -03 . . . . . . . . . . . . . . . 22 D.1.2. Changes from -01 to -02 . . . . . . . . . . . . . . . 22
C.1.4. Changes from -03 to -04 . . . . . . . . . . . . . . . 22 D.1.3. Changes from -02 to -03 . . . . . . . . . . . . . . . 23
C.1.5. Changes from -04 to -05 . . . . . . . . . . . . . . . 22 D.1.4. Changes from -03 to -04 . . . . . . . . . . . . . . . 23
C.2. draft-ietf-rmcat-coupled-cc . . . . . . . . . . . . . . . 23 D.1.5. Changes from -04 to -05 . . . . . . . . . . . . . . . 23
C.2.1. Changes from draft-welzl-rmcat-coupled-cc-05 . . . . . 23 D.2. draft-ietf-rmcat-coupled-cc . . . . . . . . . . . . . . . 23
C.2.2. Changes from -00 to -01 . . . . . . . . . . . . . . . 23 D.2.1. Changes from draft-welzl-rmcat-coupled-cc-05 . . . . . 23
C.2.3. Changes from -01 to -02 . . . . . . . . . . . . . . . 23 D.2.2. Changes from -00 to -01 . . . . . . . . . . . . . . . 23
C.2.4. Changes from -02 to -03 . . . . . . . . . . . . . . . 23 D.2.3. Changes from -01 to -02 . . . . . . . . . . . . . . . 23
C.2.5. Changes from -03 to -04 . . . . . . . . . . . . . . . 23 D.2.4. Changes from -02 to -03 . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 D.2.5. Changes from -03 to -04 . . . . . . . . . . . . . . . 24
D.2.6. Changes from -04 to -05 . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
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 when multiple congestion controlled creates undesirable queuing delay when multiple congestion controlled
connections traverse the same network bottleneck. connections traverse the same network bottleneck.
skipping to change at page 11, line 20 skipping to change at page 11, line 20
reference rate, it calculates a video target rate r_vin and a sending reference rate, it calculates a video target rate r_vin and a sending
rate for the flows, r_send. rate for the flows, r_send.
When applying the FSE to NADA, the UPDATE function call described in When applying the FSE to NADA, the UPDATE function call described in
Section 5.3 gives the FSE NADA's reference rate r_ref. The Section 5.3 gives the FSE NADA's reference rate r_ref. The
recommended algorithm for NADA is the Active FSE in Section 5.3.1. recommended algorithm for NADA is the Active FSE in Section 5.3.1.
In step 3 (c), when the FSE_R(i) is "sent" to the flow i, this means In step 3 (c), when the FSE_R(i) is "sent" to the flow i, this means
updating r_ref(r_vin and r_send) of flow i with the value of updating r_ref(r_vin and r_send) of flow i with the value of
FSE_R(i). FSE_R(i).
6.2. GCC 6.2. General recommendations
Google Congestion Control (GCC) [I-D.ietf-rmcat-gcc] is another
congestion control scheme for rtcweb. The rate control of GCC
employs two parts: controlling the bandwidth estimate based on delay,
and controlling the bandwidth estimate based on loss. Both are
designed to estimate the available bandwidth, A_hat.
When applying the FSE to GCC, the UPDATE function call described in
Section 5.3 gives the FSE GCC's estimate of available bandwidth
A_hat. The recommended algorithm for GCC is the Active FSE in
Section 5.3.1. In step 3 (c), when the FSE_R(i) is "sent" to the
flow i, this means updating A_hat of flow i with the value of
FSE_R(i).
6.3. General recommendations
This section provides general advice for applying the FSE to This section provides general advice for applying the FSE to
congestion control mechanisms. congestion control mechanisms.
Receiver-side calculations: Receiver-side calculations:
When receiver-side calculations make assumptions about the rate When receiver-side calculations make assumptions about the rate
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].
Stateful algorithms:
When a congestion control algorithm is stateful (e.g., TCP,
with Slow Start, Congestion Avoidance and Fast Recovery), these
states should be carefully considered such that the overall
state of the aggregate flow is correct. This may require
sharing more information in the UPDATE call.
Rate jumps:
The FSE-based coupling algorithms can let a flow quickly
increase its rate to its fair share, e.g. when a new flow joins
or after a quiescent period. In case of window-based
congestion controls, this may produce a burst which should be
mitigated in some way. An example of how this could be done
without using a timer is presented in [anrw2016], using TCP as
an example.
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 the NADA congestion
congestion control algorithms (GCC or NADA) with real-life code control algorithm with real-life code (e.g., browsers communicating
(e.g., browsers communicating over an emulated network covering the over an emulated network covering the conditions in
conditions in [I-D.ietf-rmcat-eval-test]. The tests with real-life [I-D.ietf-rmcat-eval-test]. The tests with real-life code should be
code should be repeated afterwards in real network environments and repeated afterwards in real network environments and monitored.
monitored. Experiments should investigate cases where the media Experiments should investigate cases where the media coder's output
coder's output rate is below the rate that is calculated by the rate is below the rate that is calculated by the coupling algorithm
coupling algorithm (FSE_R in algorithms 1 and 2, section 5.3). (FSE_R in algorithms 1 and 2, section 5.3). Implementers and testers
Implementers and testers are invited to document their findings in an are invited to document their findings in an Internet draft.
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
Andreas Petlund, Anna Brunstrom, David Hayes, David Ros (who also Andreas Petlund, Anna Brunstrom, David Hayes, David Ros (who also
gave the FSE its name), Ingemar Johansson, Karen Nielsen, Kristian gave the FSE its name), Ingemar Johansson, Karen Nielsen, Kristian
Hiorth, Mirja Kuehlewind, Martin Stiemerling, Varun Singh , Xiaoqing Hiorth, Mirja Kuehlewind, Martin Stiemerling, Varun Singh, Xiaoqing
Zhu, and Zaheduzzaman Sarker. The authors would like to especially Zhu, and Zaheduzzaman Sarker. The authors would like to especially
thank Xiaoqing Zhu and Stefan Holmer for 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.
skipping to change at page 13, line 15 skipping to change at page 13, line 19
may not be given, and one could imagine the worst case of an "arms may not be given, and one could imagine the worst case of an "arms
race" situation, where applications end up setting their priorities race" situation, where applications end up setting their priorities
to the maximum value. If all applications do this, the end result is to the maximum value. If all applications do this, the end result is
a fair allocation in which the priority mechanism is implicitly a fair allocation in which the priority mechanism is implicitly
eliminated, and no major harm is done. eliminated, and no major harm is done.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-rmcat-gcc]
Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S.
Mascolo, "A Google Congestion Control Algorithm for Real-
Time Communication", draft-ietf-rmcat-gcc-02 (work in
progress), July 2016.
[I-D.ietf-rmcat-nada] [I-D.ietf-rmcat-nada]
Zhu, X., Pan, R., Ramalho, M., 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", Congestion Control Scheme for Real-Time Media",
draft-ietf-rmcat-nada-03 (work in progress), draft-ietf-rmcat-nada-03 (work in progress),
September 2016. 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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
skipping to change at page 13, line 50 skipping to change at page 13, line 48
<http://www.rfc-editor.org/info/rfc5348>. <http://www.rfc-editor.org/info/rfc5348>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-rmcat-eval-test] [I-D.ietf-rmcat-eval-test]
Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test Sarker, Z., Singh, V., Zhu, X., and M. Ramalho, "Test
Cases for Evaluating RMCAT Proposals", Cases for Evaluating RMCAT Proposals",
draft-ietf-rmcat-eval-test-04 (work in progress), draft-ietf-rmcat-eval-test-04 (work in progress),
October 2016. October 2016.
[I-D.ietf-rmcat-gcc]
Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S.
Mascolo, "A Google Congestion Control Algorithm for Real-
Time Communication", draft-ietf-rmcat-gcc-02 (work in
progress), July 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", Alvestrand, H., "Transports for WebRTC",
draft-ietf-rtcweb-transports-11.txt (work in progress), draft-ietf-rtcweb-transports-11.txt (work in progress),
January 2016. January 2016.
skipping to change at page 14, line 27 skipping to change at page 14, line 30
[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/rmcat.html>. <https://www.ietf.org/proceedings/94/rmcat.html>.
[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>.
[anrw2016]
Islam, S. and M. Welzl, "Start Me Up:Determining and
Sharing TCP's Initial Congestion Window", ACM, IRTF, ISOC
Applied Networking Research Workshop 2016 (ANRW 2016) ,
2016.
[fse] Islam, S., Welzl, M., Gjessing, S., and N. Khademi, [fse] Islam, S., Welzl, M., Gjessing, S., and N. Khademi,
"Coupled Congestion Control for RTP Media", ACM SIGCOMM "Coupled Congestion Control for RTP Media", ACM SIGCOMM
Capacity Sharing Workshop (CSWS 2014) and ACM SIGCOMM CCR Capacity Sharing Workshop (CSWS 2014) and ACM SIGCOMM CCR
44(4) 2014; extended version available as a technical 44(4) 2014; extended version available as a technical
report from report from
http://safiquli.at.ifi.uio.no/paper/fse-tech-report.pdf , http://safiquli.at.ifi.uio.no/paper/fse-tech-report.pdf ,
2014. 2014.
[fse-noms] [fse-noms]
Islam, S., Welzl, M., Hayes, D., and S. Gjessing, Islam, S., Welzl, M., Hayes, D., and S. Gjessing,
skipping to change at page 15, line 5 skipping to change at page 15, line 13
Communication (WebRTC): Media Transport and Use of RTP", Communication (WebRTC): Media Transport and Use of RTP",
draft-ietf-rtcweb-rtp-usage-26.txt (work in progress), draft-ietf-rtcweb-rtp-usage-26.txt (work in progress),
March 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", Single Lower-Layer Transport",
draft-westerlund-avtcore-transport-multiplexing-07.txt draft-westerlund-avtcore-transport-multiplexing-07.txt
(work in progress), October 2013. (work in progress), October 2013.
Appendix A. Scheduling Appendix A. Application to GCC
Google Congestion Control (GCC) [I-D.ietf-rmcat-gcc] is another
congestion control scheme for RTP flows that is under development.
GCC is not yet finalised, but at the time of this writing, the rate
control of GCC employs two parts: controlling the bandwidth estimate
based on delay, and controlling the bandwidth estimate based on loss.
Both are designed to estimate the available bandwidth, A_hat.
When applying the FSE to GCC, the UPDATE function call described in
Section 5.3 gives the FSE GCC's estimate of available bandwidth
A_hat. The recommended algorithm for GCC is the Active FSE in
Section 5.3.1. In step 3 (c), when the FSE_R(i) is "sent" to the
flow i, this means updating A_hat of flow i with the value of
FSE_R(i).
Appendix B. 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.
Appendix B. Example algorithm - Passive FSE Appendix C. Example algorithm - Passive FSE
Active algorithms calculate the rates for all the flows in the FG and Active algorithms calculate the rates for all the flows in the FG and
actively distribute them. In a passive algorithm, UPDATE returns a actively distribute them. In a passive algorithm, UPDATE returns a
rate that should be used instead of the rate that the congestion rate that should be used instead of the rate that the congestion
controller has determined. This can make a passive algorithm easier controller has determined. This can make a passive algorithm easier
to implement; however, when round-trip times of flows are unequal, to implement; however, when round-trip times of flows are unequal,
shorter-RTT flows will update and react to the overall FSE state more shorter-RTT flows may (depending on the congestion control algorithm)
often than longer-RTT flows, which can produce unwanted side effects. update and react to the overall FSE state more often than longer-RTT
This problem is more significant when the congestion control flows, which can produce unwanted side effects. This problem is more
convergence depends on the RTT. While the passive algorithm works significant when the congestion control convergence depends on the
better for congestion controls with RTT-independent convergence, it RTT. While the passive algorithm works better for congestion
can still produce oscillations on short time scales. The algorithm controls with RTT-independent convergence, it can still produce
described below is therefore considered as highly experimental. oscillations on short time scales. The algorithm described below is
Results of a simplified passive FSE algorithm with both NADA and GCC therefore considered as highly experimental. Results of a simplified
can be found in [fse-noms]. passive FSE algorithm with both NADA and GCC can be found in
[fse-noms].
This passive version of the FSE stores the following information in This passive version of the FSE stores the following information in
addition to the variables described in Section 5.2: addition to the variables described in Section 5.2:
o The desired rate DR. This can be smaller than the calculated rate o The desired rate DR. This can be smaller than the calculated rate
if the application feeding into the flow has less data to send if the application feeding into the flow has less data to send
than the congestion controller would allow. In case of a bulk than the congestion controller would allow. In case of a bulk
transfer, DR must be set to CC_R received from the flow's transfer, DR must be set to CC_R received from the flow's
congestion module. congestion module.
skipping to change at page 18, line 7 skipping to change at page 18, line 28
homogeneous controllers being in different states, are also subject homogeneous controllers being in different states, are also subject
to experimentation. to experimentation.
This algorithm gives all the leftover rate of application-limited This algorithm gives all the leftover rate of application-limited
flows to the first flow that updates its sending rate, provided that flows to the first flow that updates its sending rate, provided that
this flow needs it all (otherwise, its own leftover rate can be taken this flow needs it all (otherwise, its own leftover rate can be taken
by the next flow that updates its rate). Other policies could be by the next flow that updates its rate). Other policies could be
applied, e.g. to divide the leftover rate of a flow equally among all applied, e.g. to divide the leftover rate of a flow equally among all
other flows in the FGI. other flows in the FGI.
B.1. Example operation (passive) C.1. Example operation (passive)
In order to illustrate the operation of the passive coupled In order to illustrate the operation of the passive coupled
congestion control algorithm, this section presents a toy example of congestion control algorithm, this section presents a toy example of
two flows that use it. Let us assume that both flows traverse a two flows that use it. Let us assume that both flows traverse a
common 10 Mbit/s bottleneck and use a simplistic congestion common 10 Mbit/s bottleneck and use a simplistic congestion
controller that starts out with 1 Mbit/s, increases its rate by 1 controller that starts out with 1 Mbit/s, increases its rate by 1
Mbit/s in the absence of congestion and decreases it by 2 Mbit/s in Mbit/s in the absence of congestion and decreases it by 2 Mbit/s in
the presence of congestion. For simplicity, flows are assumed to the presence of congestion. For simplicity, flows are assumed to
always operate in a round-robin fashion. Rate numbers below without always operate in a round-robin fashion. Rate numbers below without
units are assumed to be in Mbit/s. For illustration purposes, the units are assumed to be in Mbit/s. For illustration purposes, the
skipping to change at page 22, line 6 skipping to change at page 22, line 25
3 e) FSE_R(f) = DR(f) = 9.33. 3 e) FSE_R(f) = DR(f) = 9.33.
The resulting FSE looks as follows: The resulting FSE looks as follows:
------------------------------------------- -------------------------------------------
| # | FGI | P | FSE_R | DR | Rate | | # | FGI | P | FSE_R | DR | Rate |
| | | | | | | | | | | | | |
| 2 | 1 | 0.5 | 9.33 | 9.33 | 9.33 | | 2 | 1 | 0.5 | 9.33 | 9.33 | 9.33 |
------------------------------------------- -------------------------------------------
S_CR = 9.33, TLO = 0 S_CR = 9.33, TLO = 0
Appendix C. Change log Appendix D. Change log
C.1. draft-welzl-rmcat-coupled-cc D.1. draft-welzl-rmcat-coupled-cc
C.1.1. Changes from -00 to -01 D.1.1. Changes from -00 to -01
o Added change log. o Added change log.
o Updated the example algorithm and its operation. o Updated the example algorithm and its operation.
C.1.2. Changes from -01 to -02 D.1.2. Changes from -01 to -02
o Included an active version of the algorithm which is simpler. o Included an active version of the algorithm which is simpler.
o Replaced "greedy flow" with "bulk data transfer" and "non-greedy" o Replaced "greedy flow" with "bulk data transfer" and "non-greedy"
with "application-limited". with "application-limited".
o Updated new_CR to CC_R, and CR to FSE_R for better understanding. o Updated new_CR to CC_R, and CR to FSE_R for better understanding.
C.1.3. Changes from -02 to -03 D.1.3. Changes from -02 to -03
o Included an active conservative version of the algorithm which o Included an active conservative version of the algorithm which
reduces queue growth and packet loss; added a reference to a reduces queue growth and packet loss; added a reference to a
technical report that shows these benefits with simulations. technical report that shows these benefits with simulations.
o Moved the passive variant of the algorithm to appendix. o Moved the passive variant of the algorithm to appendix.
C.1.4. Changes from -03 to -04 D.1.4. Changes from -03 to -04
o Extended SBD section. o Extended SBD section.
o Added a note about window-based controllers. o Added a note about window-based controllers.
C.1.5. Changes from -04 to -05 D.1.5. Changes from -04 to -05
o Added a section about applying the FSE to specific congestion o Added a section about applying the FSE to specific congestion
control algorithms, with a subsection specifying its use with control algorithms, with a subsection specifying its use with
NADA. NADA.
C.2. draft-ietf-rmcat-coupled-cc D.2. draft-ietf-rmcat-coupled-cc
C.2.1. Changes from draft-welzl-rmcat-coupled-cc-05 D.2.1. Changes from draft-welzl-rmcat-coupled-cc-05
o Moved scheduling section to the appendix. o Moved scheduling section to the appendix.
C.2.2. Changes from -00 to -01 D.2.2. Changes from -00 to -01
o Included how to apply the algorithm to GCC. o Included how to apply the algorithm to GCC.
o Updated variable names of NADA to be in line with the latest o Updated variable names of NADA to be in line with the latest
version. version.
o Added a reference to [I-D.ietf-rtcweb-transports] to make a o Added a reference to [I-D.ietf-rtcweb-transports] to make a
connection to the prioritization text there. connection to the prioritization text there.
C.2.3. Changes from -01 to -02 D.2.3. Changes from -01 to -02
o Minor changes. o Minor changes.
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 D.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 D.2.5. Changes from -03 to -04
o Described the names of variables used in the algorithms. o Described the names of variables used in the algorithms.
o Added a diagram to illustrate the interaction between flows and o Added a diagram to illustrate the interaction between flows and
the FSE. the FSE.
o Added text on the trade-off of using the configuration based o Added text on the trade-off of using the configuration based
approach. approach.
o Minor changes to enhance the readability. o Minor changes to enhance the readability.
D.2.6. Changes from -04 to -05
o Changed several occurrences of "NADA and GCC" to "NADA", including
the abstract.
o Moved the application to GCC to an appendix, and made the GCC
reference informative.
o Provided a few more general recommendations on applying the
coupling algorithm.
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
 End of changes. 32 change blocks. 
83 lines changed or deleted 118 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/