draft-ietf-rmcat-coupled-cc-01.txt   draft-ietf-rmcat-coupled-cc-02.txt 
RTP Media Congestion Avoidance S. Islam RTP Media Congestion Avoidance Techniques (rmcat) S. Islam
Techniques (rmcat) M. Welzl Internet-Draft M. Welzl
Internet-Draft S. Gjessing Intended status: Experimental S. Gjessing
Intended status: Experimental University of Oslo Expires: October 16, 2016 University of Oslo
Expires: September 22, 2016 March 21, 2016 April 14, 2016
Coupled congestion control for RTP media Coupled congestion control for RTP media
draft-ietf-rmcat-coupled-cc-01 draft-ietf-rmcat-coupled-cc-02
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, it can be beneficial to combine their controls
such that the total on-the-wire behavior is improved. This document such that the total on-the-wire behavior is improved. This document
describes such a method for flows that have the same sender, in a way describes such a method for flows that have the same sender, in a way
that is as flexible and simple as possible while minimizing the that is as flexible and simple as possible while minimizing the
amount of changes needed to existing RTP applications. It specifies amount of changes needed to existing RTP applications. It specifies
how to apply the method for both the NADA and Google congestion how to apply the method for both the NADA and Google congestion
control algorithms. 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 September 22, 2016. This Internet-Draft will expire on October 16, 2016.
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Architectural overview . . . . . . . . . . . . . . . . . . . . 5 4. Architectural overview . . . . . . . . . . . . . . . . . . . 4
5. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. SBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. SBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. FSE . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2. FSE . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3. Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3.1. Example algorithm 1 - Active FSE . . . . . . . . . . . 8 5.3.1. Example algorithm 1 - Active FSE . . . . . . . . . . 7
5.3.2. Example algorithm 2 - Conservative Active FSE . . . . 8 5.3.2. Example algorithm 2 - Conservative Active FSE . . . . 8
6. Application . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Application . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. NADA . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. NADA . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2. GCC . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.2. GCC . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.3. General recommendations . . . . . . . . . . . . . . . . . 11 6.3. General recommendations . . . . . . . . . . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Scheduling . . . . . . . . . . . . . . . . . . . . . 13 Appendix A. Scheduling . . . . . . . . . . . . . . . . . . . . . 13
Appendix B. Example algorithm - Passive FSE . . . . . . . . . . . 13 Appendix B. Example algorithm - Passive FSE . . . . . . . . . . 13
B.1. Example operation (passive) . . . . . . . . . . . . . . . 16 B.1. Example operation (passive) . . . . . . . . . . . . . . . 16
Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 20 Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 20
C.1. draft-welzl-rmcat-coupled-cc . . . . . . . . . . . . . . . 20 C.1. draft-welzl-rmcat-coupled-cc . . . . . . . . . . . . . . 20
C.1.1. Changes from -00 to -01 . . . . . . . . . . . . . . . 20 C.1.1. Changes from -00 to -01 . . . . . . . . . . . . . . . 20
C.1.2. Changes from -01 to -02 . . . . . . . . . . . . . . . 20 C.1.2. Changes from -01 to -02 . . . . . . . . . . . . . . . 20
C.1.3. Changes from -02 to -03 . . . . . . . . . . . . . . . 21 C.1.3. Changes from -02 to -03 . . . . . . . . . . . . . . . 20
C.1.4. Changes from -03 to -04 . . . . . . . . . . . . . . . 21 C.1.4. Changes from -03 to -04 . . . . . . . . . . . . . . . 21
C.1.5. Changes from -04 to -05 . . . . . . . . . . . . . . . 21 C.1.5. Changes from -04 to -05 . . . . . . . . . . . . . . . 21
C.2. draft-ietf-rmcat-coupled-cc . . . . . . . . . . . . . . . 21 C.2. draft-ietf-rmcat-coupled-cc . . . . . . . . . . . . . . . 21
C.2.1. Changes from draft-welzl-rmcat-coupled-cc-05 . . . . . 21 C.2.1. Changes from draft-welzl-rmcat-coupled-cc-05 . . . . 21
C.2.2. Changes from -00 to -01 . . . . . . . . . . . . . . . 21 C.2.2. Changes from -00 to -01 . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 C.2.3. Changes from -01 to -02 . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
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 -- an effect that is amplified when
multiple congestion controlled connections traverse the same network multiple congestion controlled connections traverse the same network
bottleneck. bottleneck.
skipping to change at page 5, line 25 skipping to change at page 5, line 12
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.
------- <--- 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
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
skipping to change at page 7, line 20 skipping to change at page 7, line 8
o a priority P, which here is assumed to be represented as a o a priority P, which here is assumed to be represented as a
floating point number in the range from 0.1 (unimportant) to 1 floating point number in the range from 0.1 (unimportant) to 1
(very important). (very important).
o The rate used by the flow in bits per second, FSE_R. o The rate used by the flow in bits per second, FSE_R.
Note that the priority does not need to be a floating point value and Note that the priority does not need to be a floating point value and
its value range does not matter for this algorithm: the algorithm its value range does not matter for this algorithm: the algorithm
works with a flow's priority portion of the sum of all priority works with a flow's priority portion of the sum of all priority
values. Priority values can therefore also be mapped to the "very- values. Priorities can therefore be mapped to the "very-low", "low",
low", "low", "medium" or "high" priority levels described in "medium" or "high" priority levels described in
[I-D.ietf-rtcweb-transports]. [I-D.ietf-rtcweb-transports] using the values 1, 2, 4 and 8,
respectively.
The FSE can operate on window-based as well as rate-based congestion The FSE can operate on window-based as well as rate-based congestion
controllers (TEMPORARY NOTE: and probably -- not yet tested -- controllers. In case of a window-based controller, FSE_R is a
combinations thereof, with calculations to convert from one to the window, and all the text below should be considered to refer to
other). In case of a window-based controller, FSE_R is a window, and window, not rates.
all the text below should be considered to refer to window, not
rates.
In the FSE, each FG contains one static variable S_CR which is the In the FSE, each FG contains one static variable S_CR which is the
sum of the calculated rates of all flows in the same FG. This value sum of the calculated rates of all flows in the same FG. This value
is used to calculate the sending rate. is used to calculate the sending rate.
The information listed here is enough to implement the sample flow The information listed here is enough to implement the sample flow
algorithm given below. FSE implementations could easily be extended algorithm given below. FSE implementations could easily be extended
to store, e.g., a flow's current sending rate for statistics to store, e.g., a flow's current sending rate for statistics
gathering or future potential optimizations. gathering or future potential optimizations.
skipping to change at page 9, line 20 skipping to change at page 9, line 8
(2) When a flow f stops, its entry is removed from the list. (2) When a flow f stops, its entry is removed from the 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 7 skipping to change at page 10, line 37
When applying the FSE to GCC, the UPDATE function call described in When applying the FSE to GCC, the UPDATE function call described in
Section 5.3 gives the FSE GCC's estimate of available bandwidth Section 5.3 gives the FSE GCC's estimate of available bandwidth
A_hat. The recommended algorithm for GCC is the Active FSE in 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 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 flow i, this means updating A_hat of flow i with the value of
FSE_R(i). FSE_R(i).
6.3. General recommendations 6.3. General recommendations
This section will provides general advice for applying the FSE to This section provides general advice for applying the FSE to
congestion control mechanisms. TEMPORARY NOTE: Future versions of congestion control mechanisms.
this document will contain a longer list.
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].
7. Acknowledgements 7. Acknowledgements
skipping to change at page 12, line 16 skipping to change at page 11, line 42
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.
10. References 10. References
10.1. Normative References 10.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-01 (work in
progress), October 2015.
[I-D.ietf-rmcat-nada]
Zhu, X., Pan, R., Ramalho, M., Cruz, S., Jones, P., Fu,
J., D'Aronco, S., and C. Ganzhorn, "NADA: A Unified
Congestion Control Scheme for Real-Time Media", draft-
ietf-rmcat-nada-02 (work in progress), March 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,
<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
RFC 5348, DOI 10.17487/RFC5348, September 2008, 5348, DOI 10.17487/RFC5348, September 2008,
<http://www.rfc-editor.org/info/rfc5348>. <http://www.rfc-editor.org/info/rfc5348>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-rmcat-gcc] [fse] Islam, S., Welzl, M., Gjessing, S., and N. Khademi,
Holmer, S., Lundin, H., Carlucci, G., Cicco, L., and S. "Coupled Congestion Control for RTP Media", ACM SIGCOMM
Mascolo, "A Google Congestion Control Algorithm for Real- Capacity Sharing Workshop (CSWS 2014) and ACM SIGCOMM CCR
Time Communication", draft-ietf-rmcat-gcc-01 (work in 44(4) 2014; extended version available as a technical
progress), October 2015. report from
http://safiquli.at.ifi.uio.no/paper/fse-tech-report.pdf ,
2014.
[I-D.ietf-rmcat-nada] [fse-noms]
Zhu, X., Pan, R., Ramalho, M., Cruz, S., Jones, P., Fu, Islam, S., Welzl, M., Hayes, D., and S. Gjessing,
J., D'Aronco, S., and C. Ganzhorn, "NADA: A Unified "Managing Real-Time Media Flows through a Flow State
Congestion Control Scheme for Real-Time Media", Exchange", IEEE NOMS 2016, Istanbul, Turkey , 2016.
draft-ietf-rmcat-nada-02 (work in progress), March 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", Internet-draft
draft-ietf-rtcweb-transports-11.txt (work in progress), draft-ietf-rtcweb-transports-11.txt, January 2016.
January 2016.
[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.
[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",
draft-ietf-rtcweb-rtp-usage-26.txt (work in progress), Internet-draft draft-ietf-rtcweb-rtp-usage-26.txt, March
March 2016. 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", Internet-draft draft-
draft-westerlund-avtcore-transport-multiplexing-07.txt westerlund-avtcore-transport-multiplexing-07.txt, October
(work in progress), October 2013. 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 14, line 11 skipping to change at page 13, line 46
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 will update and react to the overall FSE state more
often than longer-RTT flows, which can produce unwanted side effects. often than longer-RTT flows, which can produce unwanted side effects.
This problem is more significant when the congestion control This problem is more significant when the congestion control
convergence depends on the RTT. While the passive algorithm works convergence depends on the RTT. While the passive algorithm works
better for congestion controls with RTT-independent convergence, it better for congestion controls with RTT-independent convergence, it
can still produce oscillations on short time scales. The algorithm can still produce oscillations on short time scales. The algorithm
described below is therefore considered as highly experimental. described below is therefore considered as highly experimental.
Results of a simplified 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 17, line 4 skipping to change at page 16, line 44
Flow #1 begins. It is a bulk data transfer and considers itself to Flow #1 begins. It is a bulk data transfer and considers itself to
have top priority. This is the FSE after the flow algorithm's step have top priority. This is the FSE after the flow algorithm's step
1: 1:
---------------------------------------- ----------------------------------------
| # | FGI | P | FSE_R | DR | Rate | | # | FGI | P | FSE_R | DR | Rate |
| | | | | | | | | | | | | |
| 1 | 1 | 1 | 1 | 1 | 1 | | 1 | 1 | 1 | 1 | 1 | 1 |
---------------------------------------- ----------------------------------------
S_CR = 1, TLO = 0 S_CR = 1, TLO = 0
Its congestion controller gradually increases its rate. Eventually, Its congestion controller gradually increases its rate. Eventually,
at some point, the FSE should look like this: at some point, the FSE should look like this:
-------------------------------------- -----------------------------------------
| # | FGI | P | FSE_R | DR | Rate | | # | FGI | P | FSE_R | DR | Rate |
| | | | | | | | | | | | | |
| 1 | 1 | 1 | 10 | 10 | 10 | | 1 | 1 | 1 | 10 | 10 | 10 |
----------------------------------------- -----------------------------------------
S_CR = 10, TLO = 0 S_CR = 10, TLO = 0
Now another flow joins. It is also a bulk data transfer, and has a Now another flow joins. It is also a bulk data transfer, and has a
lower priority (0.5): lower priority (0.5):
---------------------------------------- ------------------------------------------
| # | FGI | P | FSE_R | DR | Rate | | # | FGI | P | FSE_R | DR | Rate |
| | | | | | | | | | | | | |
| 1 | 1 | 1 | 10 | 10 | 10 | | 1 | 1 | 1 | 10 | 10 | 10 |
| 2 | 1 | 0.5 | 1 | 1 | 1 | | 2 | 1 | 0.5 | 1 | 1 | 1 |
------------------------------------------ ------------------------------------------
S_CR = 11, TLO = 0 S_CR = 11, TLO = 0
Now assume that the first flow updates its rate to 8, because the Now assume that the first flow updates its rate to 8, because the
total sending rate of 11 exceeds the total capacity. Let us take a total sending rate of 11 exceeds the total capacity. Let us take a
closer look at what happens in step 3 of the flow algorithm. closer look at what happens in step 3 of the flow algorithm.
CC_R = 8. new_DR = infinity. CC_R = 8. new_DR = infinity.
3 a) new_S_CR = 11; DELTA = 8 - 10 = -2. 3 a) new_S_CR = 11; DELTA = 8 - 10 = -2.
3 b) FSE_Rf) = 8. DELTA is negative, hence S_CR = 9; 3 b) FSE_Rf) = 8. DELTA is negative, hence S_CR = 9;
DR(f) = 8. DR(f) = 8.
3 c) S_P = 1.5. 3 c) S_P = 1.5.
3 d) new sending rate = min(infinity, 1/1.5 * 9 + 0) = 6. 3 d) new sending rate = min(infinity, 1/1.5 * 9 + 0) = 6.
3 e) FSE_R(f) = 6. 3 e) FSE_R(f) = 6.
The resulting FSE looks as follows: The resulting FSE looks as follows:
---------------------------------------- -------------------------------------------
| # | FGI | P | FSE_R | DR | Rate | | # | FGI | P | FSE_R | DR | Rate |
| | | | | | | | | | | | | |
| 1 | 1 | 1 | 6 | 8 | 6 | | 1 | 1 | 1 | 6 | 8 | 6 |
| 2 | 1 | 0.5 | 1 | 1 | 1 | | 2 | 1 | 0.5 | 1 | 1 | 1 |
------------------------------------------- -------------------------------------------
S_CR = 9, TLO = 0 S_CR = 9, TLO = 0
The effect is that flow #1 is sending with 6 Mbit/s instead of the 8 The effect is that flow #1 is sending with 6 Mbit/s instead of the 8
Mbit/s that the congestion controller derived. Let us now assume Mbit/s that the congestion controller derived. Let us now assume
that flow #2 updates its rate. Its congestion controller detects that flow #2 updates its rate. Its congestion controller detects
that the network is not fully saturated (the actual total sending that the network is not fully saturated (the actual total sending
skipping to change at page 21, line 41 skipping to change at page 21, line 35
C.2.2. Changes from -00 to -01 C.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
o Minor changes.
o Moved references of NADA and GCC from informative to normative.
o Added a reference for the passive variant of the 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
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. 27 change blocks. 
96 lines changed or deleted 110 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/