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/ |