draft-ietf-rmcat-nada-06.txt   draft-ietf-rmcat-nada-07.txt 
Network Working Group X. Zhu Network Working Group X. Zhu
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Experimental R. Pan Intended status: Experimental R. Pan
Expires: June 6, 2018 Pensando Systems Expires: December 7, 2018 Pensando Systems
M. Ramalho M. Ramalho
S. Mena S. Mena
P. Jones P. Jones
J. Fu J. Fu
Cisco Systems Cisco Systems
S. D'Aronco S. D'Aronco
EPFL EPFL
December 3, 2017 June 5, 2018
NADA: A Unified Congestion Control Scheme for Real-Time Media NADA: A Unified Congestion Control Scheme for Real-Time Media
draft-ietf-rmcat-nada-06 draft-ietf-rmcat-nada-07
Abstract Abstract
This document describes NADA (network-assisted dynamic adaptation), a This document describes NADA (network-assisted dynamic adaptation), a
novel congestion control scheme for interactive real-time media novel congestion control scheme for interactive real-time media
applications, such as video conferencing. In the proposed scheme, applications, such as video conferencing. In the proposed scheme,
the sender regulates its sending rate based on either implicit or the sender regulates its sending rate based on either implicit or
explicit congestion signaling, in a unified approach. The scheme can explicit congestion signaling, in a unified approach. The scheme can
benefit from explicit congestion notification (ECN) markings from benefit from explicit congestion notification (ECN) markings from
network nodes. It also maintains consistent sender behavior in the network nodes. It also maintains consistent sender behavior in the
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 June 6, 2018. This Internet-Draft will expire on December 7, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 2, line 47 skipping to change at page 2, line 47
5.3. Feedback Message Requirements . . . . . . . . . . . . . . 15 5.3. Feedback Message Requirements . . . . . . . . . . . . . . 15
6. Discussions and Further Investigations . . . . . . . . . . . 16 6. Discussions and Further Investigations . . . . . . . . . . . 16
6.1. Choice of delay metrics . . . . . . . . . . . . . . . . . 16 6.1. Choice of delay metrics . . . . . . . . . . . . . . . . . 16
6.2. Method for delay, loss, and marking ratio estimation . . 16 6.2. Method for delay, loss, and marking ratio estimation . . 16
6.3. Impact of parameter values . . . . . . . . . . . . . . . 17 6.3. Impact of parameter values . . . . . . . . . . . . . . . 17
6.4. Sender-based vs. receiver-based calculation . . . . . . . 18 6.4. Sender-based vs. receiver-based calculation . . . . . . . 18
6.5. Incremental deployment . . . . . . . . . . . . . . . . . 18 6.5. Incremental deployment . . . . . . . . . . . . . . . . . 18
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 19 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 19
8. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 19 8. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 19
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . 20
12.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Network Node Operations . . . . . . . . . . . . . . 23 Appendix A. Network Node Operations . . . . . . . . . . . . . . 23
A.1. Default behavior of drop tail queues . . . . . . . . . . 23 A.1. Default behavior of drop tail queues . . . . . . . . . . 23
A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 23 A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 23
A.3. Random Early Marking with Virtual Queues . . . . . . . . 24 A.3. Random Early Marking with Virtual Queues . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
Interactive real-time media applications introduce a unique set of Interactive real-time media applications introduce a unique set of
challenges for congestion control. Unlike TCP, the mechanism used challenges for congestion control. Unlike TCP, the mechanism used
skipping to change at page 3, line 39 skipping to change at page 3, line 40
path round-trip-times (RTTs) below a prescribed bound (e.g., 250ms path round-trip-times (RTTs) below a prescribed bound (e.g., 250ms
with default parameter choices). It further supports weighted with default parameter choices). It further supports weighted
bandwidth sharing among competing video flows with different bandwidth sharing among competing video flows with different
priorities. The signaling mechanism consists of standard RTP priorities. The signaling mechanism consists of standard RTP
timestamp [RFC3550] and RTCP feedback reports with non-standard timestamp [RFC3550] and RTCP feedback reports with non-standard
messages. messages.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. System Overview 3. System Overview
Figure 1 shows the end-to-end system for real-time media transport Figure 1 shows the end-to-end system for real-time media transport
that NADA operates in. Note that there also exist network nodes that NADA operates in. Note that there also exist network nodes
along the reverse (potentially uncongested) path that the RTCP along the reverse (potentially uncongested) path that the RTCP
feedback reports traverse. Those network nodes are not shown in the feedback reports traverse. Those network nodes are not shown in the
figure for sake of abrevity. figure for sake of abrevity.
+---------+ r_vin +--------+ +--------+ +----------+ +---------+ r_vin +--------+ +--------+ +----------+
skipping to change at page 8, line 9 skipping to change at page 8, line 9
| | smoothing of packet loss and | | | | smoothing of packet loss and | |
| | marking ratios | | | marking ratios |
+--------------+----------------------------------+----------------+ +--------------+----------------------------------+----------------+
Figure 3: List of algorithm parameters. Figure 3: List of algorithm parameters.
4.2. Receiver-Side Algorithm 4.2. Receiver-Side Algorithm
The receiver-side algorithm can be outlined as below: The receiver-side algorithm can be outlined as below:
On initialization: On initialization:
set d_base = +INFINITY set d_base = +INFINITY
set p_loss = 0 set p_loss = 0
set p_mark = 0 set p_mark = 0
set r_recv = 0 set r_recv = 0
set both t_last and t_curr as current time set both t_last and t_curr as current time
On receiving a media packet: On receiving a media packet:
obtain current timestamp t_curr from system clock obtain current timestamp t_curr from system clock
obtain from packet header sending time stamp t_sent obtain from packet header sending time stamp t_sent
obtain one-way delay measurement: d_fwd = t_curr - t_sent obtain one-way delay measurement: d_fwd = t_curr - t_sent
update baseline delay: d_base = min(d_base, d_fwd) update baseline delay: d_base = min(d_base, d_fwd)
update queuing delay: d_queue = d_fwd - d_base update queuing delay: d_queue = d_fwd - d_base
update packet loss ratio estimate p_loss update packet loss ratio estimate p_loss
update packet marking ratio estimate p_mark update packet marking ratio estimate p_mark
update measurement of receiving rate r_recv update measurement of receiving rate r_recv
On time to send a new feedback report (t_curr - t_last > DELTA): On time to send a new feedback report (t_curr - t_last > DELTA):
calculate non-linear warping of delay d_tilde if packet loss exists calculate non-linear warping of delay d_tilde if packet loss exists
calculate current aggregate congestion signal x_curr calculate current aggregate congestion signal x_curr
determine mode of rate adaptation for sender: rmode determine mode of rate adaptation for sender: rmode
send RTCP feedback report containing values of: rmode, x_curr, and r_recv send feedback containing values of: rmode, x_curr, and r_recv
update t_last = t_curr update t_last = t_curr
In order for a delay-based flow to hold its ground when competing In order for a delay-based flow to hold its ground when competing
against loss-based flows (e.g., loss-based TCP), it is important to against loss-based flows (e.g., loss-based TCP), it is important to
distinguish between different levels of observed queuing delay. For distinguish between different levels of observed queuing delay. For
instance, over wired connections, a moderate queuing delay value instance, over wired connections, a moderate queuing delay value
below 100ms is likely self-inflicted or induced by other delay-based below 100ms is likely self-inflicted or induced by other delay-based
flows, whereas a high queuing delay value of several hundreds of flows, whereas a high queuing delay value of several hundreds of
milliseconds may indicate the presence of a loss-based flow that does milliseconds may indicate the presence of a loss-based flow that does
not refrain from increased delay. not refrain from increased delay.
skipping to change at page 9, line 37 skipping to change at page 9, line 37
Estimation of the average loss interval loss_int, in turn, follows Estimation of the average loss interval loss_int, in turn, follows
Section 5.4 of the TCP Friendly Rate Control (TFRC) protocol Section 5.4 of the TCP Friendly Rate Control (TFRC) protocol
[RFC5348]. [RFC5348].
In practice, it is recommended to linearly interpolate between the In practice, it is recommended to linearly interpolate between the
warped (d_tilde) and non-warped (d_queue) values of the queuing delay warped (d_tilde) and non-warped (d_queue) values of the queuing delay
during the transitional period lasting for the duration of loss_int. during the transitional period lasting for the duration of loss_int.
The aggregate congestion signal is: The aggregate congestion signal is:
x_curr = d_tilde + DMARK*(p_mark/PMRREF)^2 + DLOSS*(p_loss/PLRREF)^2. (2) / p_mark \^2 / p_loss \^2
x_curr = d_tilde + DMARK*|--------| + DLOSS*|--------|. (2)
\ PMRREF / \ PLRREF /
Here, DMARK is prescribed reference delay penalty associated with ECN Here, DMARK is prescribed reference delay penalty associated with ECN
markings at the reference marking ratio of PMRREF; DLOSS is markings at the reference marking ratio of PMRREF; DLOSS is
prescribed reference delay penalty associated with packet losses at prescribed reference delay penalty associated with packet losses at
the reference packet loss ratio of PLRREF. The value of DLOSS and the reference packet loss ratio of PLRREF. The value of DLOSS and
DMARK does not depend on configurations at the network node. Since DMARK does not depend on configurations at the network node. Since
ECN-enabled active queue management schemes typically mark a packet ECN-enabled active queue management schemes typically mark a packet
before dropping it, the value of DLOSS SHOULD be higher than that of before dropping it, the value of DLOSS SHOULD be higher than that of
DMARK. Furthermore, the values of DLOSS and DMARK need to be set DMARK. Furthermore, the values of DLOSS and DMARK need to be set
consistently across all NADA flows for them to compete fairly. consistently across all NADA flows for them to compete fairly.
skipping to change at page 10, line 41 skipping to change at page 10, line 43
on receiving feedback report: on receiving feedback report:
obtain current timestamp from system clock: t_curr obtain current timestamp from system clock: t_curr
obtain values of rmode, x_curr, and r_recv from feedback report obtain values of rmode, x_curr, and r_recv from feedback report
update estimation of rtt update estimation of rtt
measure feedback interval: delta = t_curr - t_last measure feedback interval: delta = t_curr - t_last
if rmode == 0: if rmode == 0:
update r_ref following accelerated ramp-up rules update r_ref following accelerated ramp-up rules
else: else:
update r_ref following gradual update rules update r_ref following gradual update rules
clip rate r_ref within the range of [RMIN, RMAX] clip rate r_ref within the range of minimum rate (RMIN)
and maximum rate (RMAX).
x_prev = x_curr x_prev = x_curr
t_last = t_curr t_last = t_curr
In accelerated ramp-up mode, the rate r_ref is updated as follows: In accelerated ramp-up mode, the rate r_ref is updated as follows:
QBOUND QBOUND
gamma = min(GAMMA_MAX, ------------------) (3) gamma = min(GAMMA_MAX, ------------------) (3)
rtt+DELTA+DFILT rtt+DELTA+DFILT
r_ref = max(r_ref, (1+gamma) r_recv) (4) r_ref = max(r_ref, (1+gamma) r_recv) (4)
skipping to change at page 11, line 41 skipping to change at page 11, line 47
Calculation of x_offset depends on maximum rate of the flow (RMAX), Calculation of x_offset depends on maximum rate of the flow (RMAX),
its weight of priority (PRIO), as well as a reference congestion its weight of priority (PRIO), as well as a reference congestion
signal (XREF). The value of XREF is chosen so that the maximum rate signal (XREF). The value of XREF is chosen so that the maximum rate
of RMAX can be achieved when the observed congestion signal level is of RMAX can be achieved when the observed congestion signal level is
below PRIO*XREF. below PRIO*XREF.
At equilibrium, the aggregated congestion signal stablizes at x_curr At equilibrium, the aggregated congestion signal stablizes at x_curr
= PRIO*XREF*RMAX/r_ref. This ensures that when multiple flows share = PRIO*XREF*RMAX/r_ref. This ensures that when multiple flows share
the same bottleneck and observe a common value of x_curr, their rates the same bottleneck and observe a common value of x_curr, their rates
at equilibrium will be proportional to their respective priority at equilibrium will be proportional to their respective priority
levels (PRIO) and maximum rate (RMAX). Values of RMIN and RMAX will levels (PRIO) and the range between minimum and maximum rate. Values
be provided by the media codec, as specified in of the minimum rate (RMIN) and maximum rate (RMAX) will be provided
by the media codec, as specified in
[I-D.ietf-rmcat-cc-codec-interactions]. In the absense of such [I-D.ietf-rmcat-cc-codec-interactions]. In the absense of such
information, NADA sender will choose a default value of 0 for RMIN, information, NADA sender will choose a default value of 0 for RMIN,
and 2Mbps for RMAX. and 2Mbps for RMAX.
As mentioned in the sender-side algorithm, the final rate is clipped As mentioned in the sender-side algorithm, the final rate is clipped
within the dynamic range specified by the application: within the dynamic range specified by the application:
r_ref = min(r_ref, RMAX) (8) r_ref = min(r_ref, RMAX) (8)
r_ref = max(r_ref, RMIN) (9) r_ref = max(r_ref, RMIN) (9)
skipping to change at page 20, line 9 skipping to change at page 20, line 9
cellular networks such as 3G/LTE. cellular networks such as 3G/LTE.
o Experiments with various media source contents, including audio o Experiments with various media source contents, including audio
only, audio and video, and application content sharing (e.g., only, audio and video, and application content sharing (e.g.,
slide shows). slide shows).
9. IANA Considerations 9. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
10. Acknowledgements 10. Security Considerations
TBD
11. Acknowledgements
The authors would like to thank Randell Jesup, Luca De Cicco, Piers The authors would like to thank Randell Jesup, Luca De Cicco, Piers
O'Hanlon, Ingemar Johansson, Stefan Holmer, Cesar Ilharco Magalhaes, O'Hanlon, Ingemar Johansson, Stefan Holmer, Cesar Ilharco Magalhaes,
Safiqul Islam, Michael Welzl, Mirja Kuhlewind, Karen Elisabeth Egede Safiqul Islam, Michael Welzl, Mirja Kuhlewind, Karen Elisabeth Egede
Nielsen, Julius Flohr, Roland Bless, and Andreas Smas for their Nielsen, Julius Flohr, Roland Bless, and Andreas Smas for their
various valuable review comments and feedback. Thanks to Charles various valuable review comments and feedback. Thanks to Charles
Ganzhorn for contributing to the testbed-based evaluation of NADA Ganzhorn for contributing to the testbed-based evaluation of NADA
during an early stage of its development. during an early stage of its development.
11. References 12. References
11.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
skipping to change at page 20, line 48 skipping to change at page 21, line 5
[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,
<https://www.rfc-editor.org/info/rfc5348>. <https://www.rfc-editor.org/info/rfc5348>.
[RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., [RFC6679] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P.,
and K. Carlberg, "Explicit Congestion Notification (ECN) and K. Carlberg, "Explicit Congestion Notification (ECN)
for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August for RTP over UDP", RFC 6679, DOI 10.17487/RFC6679, August
2012, <https://www.rfc-editor.org/info/rfc6679>. 2012, <https://www.rfc-editor.org/info/rfc6679>.
11.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References
[Budzisz-TON11] [Budzisz-TON11]
Budzisz, L., Stanojevic, R., Schlote, A., Baker, F., and Budzisz, L., Stanojevic, R., Schlote, A., Baker, F., and
R. Shorten, "On the Fair Coexistence of Loss- and Delay- R. Shorten, "On the Fair Coexistence of Loss- and Delay-
Based TCP", IEEE/ACM Transactions on Networking vol. 19, Based TCP", IEEE/ACM Transactions on Networking vol. 19,
no. 6, pp. 1811-1824, December 2011. no. 6, pp. 1811-1824, December 2011.
[Floyd-CCR00] [Floyd-CCR00]
Floyd, S., Handley, M., Padhye, J., and J. Widmer, Floyd, S., Handley, M., Padhye, J., and J. Widmer,
"Equation-based Congestion Control for Unicast "Equation-based Congestion Control for Unicast
skipping to change at page 21, line 36 skipping to change at page 21, line 42
requirements-09 (work in progress), December 2014. requirements-09 (work in progress), December 2014.
[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", draft-ietf-rmcat- Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat-
eval-test-05 (work in progress), April 2017. eval-test-05 (work in progress), April 2017.
[I-D.ietf-rmcat-video-traffic-model] [I-D.ietf-rmcat-video-traffic-model]
Zhu, X., Cruz, S., and Z. Sarker, "Modeling Video Traffic Zhu, X., Cruz, S., and Z. Sarker, "Modeling Video Traffic
Sources for RMCAT Evaluations", draft-ietf-rmcat-video- Sources for RMCAT Evaluations", draft-ietf-rmcat-video-
traffic-model-03 (work in progress), July 2017. traffic-model-04 (work in progress), January 2018.
[I-D.ietf-rmcat-wireless-tests] [I-D.ietf-rmcat-wireless-tests]
Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and Sarker, Z., Johansson, I., Zhu, X., Fu, J., Tan, W., and
M. Ramalho, "Evaluation Test Cases for Interactive Real- M. Ramalho, "Evaluation Test Cases for Interactive Real-
Time Media over Wireless Networks", draft-ietf-rmcat- Time Media over Wireless Networks", draft-ietf-rmcat-
wireless-tests-04 (work in progress), May 2017. wireless-tests-04 (work in progress), May 2017.
[IETF-90] Zhu, X., Ramalho, M., Ganzhorn, C., Jones, P., and R. Pan, [IETF-90] Zhu, X., Ramalho, M., Ganzhorn, C., Jones, P., and R. Pan,
"NADA Update: Algorithm, Implementation, and Test Case "NADA Update: Algorithm, Implementation, and Test Case
Evalua6on Results", July 2014, Evalua6on Results", July 2014,
skipping to change at page 22, line 26 skipping to change at page 22, line 32
[ns-2] "The Network Simulator - ns-2", [ns-2] "The Network Simulator - ns-2",
<http://www.isi.edu/nsnam/ns/>. <http://www.isi.edu/nsnam/ns/>.
[ns-3] "The Network Simulator - ns-3", <https://www.nsnam.org/>. [ns-3] "The Network Simulator - ns-3", <https://www.nsnam.org/>.
[ns3-rmcat] [ns3-rmcat]
Fu, J., Mena, S., and X. Zhu, "NS3 open source module of Fu, J., Mena, S., and X. Zhu, "NS3 open source module of
IETF RMCAT congestion control protocols", November 2017, IETF RMCAT congestion control protocols", November 2017,
<https://github.com/cisco/ns3-rmcat>. <https://github.com/cisco/ns3-rmcat>.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
S., Wroclawski, J., and L. Zhang, "Recommendations on
Queue Management and Congestion Avoidance in the
Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998,
<https://www.rfc-editor.org/info/rfc2309>.
[RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three [RFC6660] Briscoe, B., Moncaster, T., and M. Menth, "Encoding Three
Pre-Congestion Notification (PCN) States in the IP Header Pre-Congestion Notification (PCN) States in the IP Header
Using a Single Diffserv Codepoint (DSCP)", RFC 6660, Using a Single Diffserv Codepoint (DSCP)", RFC 6660,
DOI 10.17487/RFC6660, July 2012, DOI 10.17487/RFC6660, July 2012,
<https://www.rfc-editor.org/info/rfc6660>. <https://www.rfc-editor.org/info/rfc6660>.
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
"Low Extra Delay Background Transport (LEDBAT)", RFC 6817, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
DOI 10.17487/RFC6817, December 2012, DOI 10.17487/RFC6817, December 2012,
<https://www.rfc-editor.org/info/rfc6817>. <https://www.rfc-editor.org/info/rfc6817>.
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF
Recommendations Regarding Active Queue Management",
BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
<https://www.rfc-editor.org/info/rfc7567>.
[Zhu-PV13] [Zhu-PV13]
Zhu, X. and R. Pan, "NADA: A Unified Congestion Control Zhu, X. and R. Pan, "NADA: A Unified Congestion Control
Scheme for Low-Latency Interactive Video", in Proc. IEEE Scheme for Low-Latency Interactive Video", in Proc. IEEE
International Packet Video Workshop (PV'13) San Jose, CA, International Packet Video Workshop (PV'13) San Jose, CA,
USA, December 2013. USA, December 2013.
Appendix A. Network Node Operations Appendix A. Network Node Operations
NADA can work with different network queue management schemes and NADA can work with different network queue management schemes and
does not assume any specific network node operation. As an example, does not assume any specific network node operation. As an example,
skipping to change at page 23, line 31 skipping to change at page 23, line 31
In a conventional network with drop tail or RED queues, congestion is In a conventional network with drop tail or RED queues, congestion is
inferred from the estimation of end-to-end delay and/or packet loss. inferred from the estimation of end-to-end delay and/or packet loss.
Packet drops at the queue are detected at the receiver, and Packet drops at the queue are detected at the receiver, and
contributes to the calculation of the aggregated congestion signal contributes to the calculation of the aggregated congestion signal
x_curr. No special action is required at network node. x_curr. No special action is required at network node.
A.2. RED-based ECN marking A.2. RED-based ECN marking
In this mode, the network node randomly marks the ECN field in the IP In this mode, the network node randomly marks the ECN field in the IP
packet header following the Random Early Detection (RED) algorithm packet header following the Random Early Detection (RED) algorithm
[RFC2309]. Calculation of the marking probability involves the [RFC7567]. Calculation of the marking probability involves the
following steps: following steps:
on packet arrival: on packet arrival:
update smoothed queue size q_avg as: update smoothed queue size q_avg as:
q_avg = w*q + (1-w)*q_avg. q_avg = w*q + (1-w)*q_avg.
calculate marking probability p as: calculate marking probability p as:
/ 0, if q < q_lo; / 0, if q < q_lo;
| |
 End of changes. 21 change blocks. 
50 lines changed or deleted 62 lines changed or added

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