draft-ietf-rmcat-nada-02.txt   draft-ietf-rmcat-nada-03.txt 
Network Working Group X. Zhu Network Working Group X. Zhu
Internet-Draft R. Pan Internet-Draft R. Pan
Intended status: Experimental M. Ramalho Intended status: Experimental M. Ramalho
Expires: September 19, 2016 S. Mena Expires: March 22, 2017 S. Mena
P. Jones P. Jones
J. Fu J. Fu
Cisco Systems Cisco Systems
S. D'Aronco S. D'Aronco
EPFL EPFL
C. Ganzhorn C. Ganzhorn
March 18, 2016 September 18, 2016
NADA: A Unified Congestion Control Scheme for Real-Time Media NADA: A Unified Congestion Control Scheme for Real-Time Media
draft-ietf-rmcat-nada-02 draft-ietf-rmcat-nada-03
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 45 skipping to change at page 1, line 45
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 19, 2016. This Internet-Draft will expire on March 22, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. System Overview . . . . . . . . . . . . . . . . . . . . . . . 3 3. System Overview . . . . . . . . . . . . . . . . . . . . . . . 3
4. Core Congestion Control Algorithm . . . . . . . . . . . . . . 5 4. Core Congestion Control Algorithm . . . . . . . . . . . . . . 5
4.1. Mathematical Notations . . . . . . . . . . . . . . . . . 5 4.1. Mathematical Notations . . . . . . . . . . . . . . . . . 5
4.2. Receiver-Side Algorithm . . . . . . . . . . . . . . . . . 8 4.2. Receiver-Side Algorithm . . . . . . . . . . . . . . . . . 8
4.3. Sender-Side Algorithm . . . . . . . . . . . . . . . . . . 10 4.3. Sender-Side Algorithm . . . . . . . . . . . . . . . . . . 9
5. Practical Implementation of NADA . . . . . . . . . . . . . . 12 5. Practical Implementation of NADA . . . . . . . . . . . . . . 12
5.1. Receiver-Side Operation . . . . . . . . . . . . . . . . . 12 5.1. Receiver-Side Operation . . . . . . . . . . . . . . . . . 12
5.1.1. Estimation of one-way delay and queuing delay . . . . 12 5.1.1. Estimation of one-way delay and queuing delay . . . . 12
5.1.2. Estimation of packet loss/marking ratio . . . . . . . 12 5.1.2. Estimation of packet loss/marking ratio . . . . . . . 12
5.1.3. Estimation of receiving rate . . . . . . . . . . . . 13 5.1.3. Estimation of receiving rate . . . . . . . . . . . . 13
5.2. Sender-Side Operation . . . . . . . . . . . . . . . . . . 13 5.2. Sender-Side Operation . . . . . . . . . . . . . . . . . . 13
5.2.1. Rate shaping buffer . . . . . . . . . . . . . . . . . 14 5.2.1. Rate shaping buffer . . . . . . . . . . . . . . . . . 14
5.2.2. Adjusting video target rate and sending rate . . . . 15 5.2.2. Adjusting video target rate and sending rate . . . . 15
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 . . . . . . . . . . . . . . . . . . . . 18 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 8. Suggested Experiments . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Network Node Operations . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Network Node Operations . . . . . . . . . . . . . . 22
A.1. Default behavior of drop tail queues . . . . . . . . . . 22 A.1. Default behavior of drop tail queues . . . . . . . . . . 22
A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 22 A.2. RED-based ECN marking . . . . . . . . . . . . . . . . . . 23
A.3. Random Early Marking with Virtual Queues . . . . . . . . 22 A.3. Random Early Marking with Virtual Queues . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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
for real-time media needs to adapt quickly to instantaneous bandwidth for real-time media needs to adapt quickly to instantaneous bandwidth
changes, accommodate fluctuations in the output of video encoder rate changes, accommodate fluctuations in the output of video encoder rate
control, and cause low queuing delay over the network. An ideal control, and cause low queuing delay over the network. An ideal
scheme should also make effective use of all types of congestion scheme should also make effective use of all types of congestion
signals, including packet loss, queuing delay, and explicit signals, including packet loss, queuing delay, and explicit
skipping to change at page 7, line 25 skipping to change at page 7, line 25
| | rate update calculation | | | | rate update calculation | |
| ETA | Scaling parameter for gradual | 2.0 | | ETA | Scaling parameter for gradual | 2.0 |
| | rate update calculation | | | | rate update calculation | |
| TAU | Upper bound of RTT in gradual | 500ms | | TAU | Upper bound of RTT in gradual | 500ms |
| | rate update calculation | | | | rate update calculation | |
| DELTA | Target feedback interval | 100ms | | DELTA | Target feedback interval | 100ms |
| DFILT | Bound on filtering delay | 120ms | | DFILT | Bound on filtering delay | 120ms |
| LOGWIN | Observation window in time for | 500ms | | LOGWIN | Observation window in time for | 500ms |
| | calculating packet summary | | | | calculating packet summary | |
| | statistics at receiver | | | | statistics at receiver | |
| TEXPLOSS | Expiration time for previously | 30s |
| | observed packet loss | |
| QEPS | Threshold for determining queuing| 10ms | | QEPS | Threshold for determining queuing| 10ms |
| | delay build up at receiver | | | | delay build up at receiver | |
+..............+..................................+................+ +..............+..................................+................+
| QTH | Delay threshold for non-linear | 50ms | | QTH | Delay threshold for non-linear | 50ms |
| | warping | | | | warping | |
| QMAX | Delay upper bound for non-linear | 400ms |
| | warping | |
| DLOSS | Delay penalty for loss | 1.0s | | DLOSS | Delay penalty for loss | 1.0s |
| DMARK | Delay penalty for ECN marking | 200ms | | DMARK | Delay penalty for ECN marking | 200ms |
+..............+..................................+................+ +..............+..................................+................+
| GAMMA_MAX | Upper bound on rate increase | 50% | | GAMMA_MAX | Upper bound on rate increase | 50% |
| | ratio for accelerated ramp-up | | | | ratio for accelerated ramp-up | |
| QBOUND | Upper bound on self-inflicted | 50ms | | QBOUND | Upper bound on self-inflicted | 50ms |
| | queuing delay during ramp up | | | | queuing delay during ramp up | |
+..............+..................................+................+ +..............+..................................+................+
| FPS | Frame rate of incoming video | 30 | | FPS | Frame rate of incoming video | 30 |
| BETA_S | Scaling parameter for modulating | 0.1 | | BETA_S | Scaling parameter for modulating | 0.1 |
skipping to change at page 8, line 42 skipping to change at page 8, line 42
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, a moderate queuing delay value below 100ms is likely self- instance, a moderate queuing delay value below 100ms is likely self-
inflicted or induced by other delay-based flows, whereas a high inflicted or induced by other delay-based flows, whereas a high
queuing delay value of several hundreds of milliseconds may indicate queuing delay value of several hundreds of milliseconds may indicate
the presence of a loss-based flow that does not refrain from the presence of a loss-based flow that does not refrain from
increased delay. increased delay.
When packet losses are observed, the estimated queuing delay follows If packet losses are observed within the previous time window of
a non-linear warping inspired by the delay-adaptive congestion window TLOSS, the estimated queuing delay follows a non-linear warping:
backoff policy in [Budzisz-TON11]:
/ d_queue, if d_queue<QTH; / d_queue, if d_queue<QTH;
| |
| (QMAX - d_queue)^4 d_tilde = < (1)
d_tilde = < QTH ------------------, if QTH<d_queue<QMAX (1) | -(d_queue-QTH)
| (QMAX - QTH)^4 \ QTH exp(- ----------------) , otherwise.
| QTH
\ 0, otherwise.
Here, the queuing delay value is unchanged when it is below the first In (1), the queuing delay value is unchanged when it is below the
threshold QTH; it is scaled down following a non-linear curve when first threshold QTH; otherwise it is scaled down following a non-
its value falls between QTH and QMAX; above QMAX, the high queuing linear curve. This non-linear warping is inspired by the delay-
delay value no longer counts toward congestion control. adaptive congestion windown backoff policy in [Budzisz-TON11], so as
to "gradually nudge" the controller to operate based on loss-induced
congestion signals when competing against loss-based flows. The
exact form of the non-linear function has been simplified with
respect to [Budzisz-TON11].
The aggregate congestion signal is: The aggregate congestion signal is:
x_curr = d_tilde + p_mark*DMARK + p_loss*DLOSS. (2) x_curr = d_tilde + p_mark*DMARK + p_loss*DLOSS. (2)
Here, DMARK is prescribed delay penalty associated with ECN markings Here, DMARK is prescribed delay penalty associated with ECN markings
and DLOSS is prescribed delay penalty associated with packet losses. and DLOSS is prescribed delay penalty associated with packet losses.
The value of DLOSS and DMARK does not depend on configurations at the The value of DLOSS and DMARK does not depend on configurations at the
network node. Since ECN-enabled active queue management schemes network node. Since ECN-enabled active queue management schemes
typically mark a packet before dropping it, the value of DLOSS SHOULD typically mark a packet before dropping it, the value of DLOSS SHOULD
skipping to change at page 15, line 47 skipping to change at page 15, line 47
(rmode=0) or gradual update mode (rmode=1). (rmode=0) or gradual update mode (rmode=1).
o Aggregated congestion signal (x_curr): the most recently updated o Aggregated congestion signal (x_curr): the most recently updated
value, calculated by the receiver according to Section 4.2. This value, calculated by the receiver according to Section 4.2. This
information is expressed with a unit of 100 microsecond (i.e., information is expressed with a unit of 100 microsecond (i.e.,
1/10 of a millisecond) in 15 bits. This allows a maximum value of 1/10 of a millisecond) in 15 bits. This allows a maximum value of
x_curr at approximately 3.27 second. x_curr at approximately 3.27 second.
o Receiving rate (r_recv): the most recently measured receiving rate o Receiving rate (r_recv): the most recently measured receiving rate
according to Section 5.1.3. This information is expressed with a according to Section 5.1.3. This information is expressed with a
unit of 10 Kilobits per second (Kbps) in 16 bits. This allows a unit of bits per second (bps) in 32 bits (unsigned int). This
maximum rate of approximately 6.55Mbps. allows a maximum rate of approximately 4.3Gbps.
The above list of information can be accommodated by 32 bits in The above list of information can be accommodated by 48 bits, or 6
total. Choice of the feedback message interval DELTA is discussed in bytes, in total. Choice of the feedback message interval DELTA is
Section 6.3 A target feedback interval of DELTA=100ms is recommended. discussed in Section 6.3 A target feedback interval of DELTA=100ms is
recommended.
6. Discussions and Further Investigations 6. Discussions and Further Investigations
6.1. Choice of delay metrics 6.1. Choice of delay metrics
The current design works with relative one-way-delay (OWD) as the The current design works with relative one-way-delay (OWD) as the
main indication of congestion. The value of the relative OWD is main indication of congestion. The value of the relative OWD is
obtained by maintaining the minimum value of observed OWD over a obtained by maintaining the minimum value of observed OWD over a
relatively long time horizon and subtract that out from the observed relatively long time horizon and subtract that out from the observed
absolute OWD value. Such an approach cancels out the fixed absolute OWD value. Such an approach cancels out the fixed
skipping to change at page 17, line 32 skipping to change at page 17, line 35
adaptation is mostly driven by the change in the congestion signal adaptation is mostly driven by the change in the congestion signal
with a long-term shift towards its equilibrium value driven by the with a long-term shift towards its equilibrium value driven by the
offset term. Finally, the scaling parameter KAPPA determines the offset term. Finally, the scaling parameter KAPPA determines the
overall speed of the adaptation and needs to strike a balance between overall speed of the adaptation and needs to strike a balance between
responsiveness and stability. responsiveness and stability.
The choice of the target feedback interval DELTA needs to strike the The choice of the target feedback interval DELTA needs to strike the
right balance between timely feedback and low RTCP feedback message right balance between timely feedback and low RTCP feedback message
counts. A target feedback interval of DELTA=100ms is recommended, counts. A target feedback interval of DELTA=100ms is recommended,
corresponding to a feedback bandwidth of 16Kbps with 200 bytes per corresponding to a feedback bandwidth of 16Kbps with 200 bytes per
feedback message --- less than 0.1% overhead for a 1 Mbps flow. feedback message --- approximately 1.6% overhead for a 1 Mbps flow.
Furthermore, both simulation studies and frequency-domain analysis Furthermore, both simulation studies and frequency-domain analysis
have established that a feedback interval below 250ms will not break have established that a feedback interval below 250ms will not break
up the feedback control loop of NADA congestion control. up the feedback control loop of NADA congestion control.
In calculating the non-linear warping of delay in (1), the current In calculating the non-linear warping of delay in (1), the current
design uses fixed values of QTH and QMAX. It is possible to adapt design uses fixed values of QTH and TLOSS (for determining whether to
the value of both based on past observations of queuing delay in the perform the non-linear warpming). It is possible to adapt the value
of both based on past observed patterns of queuing delay in the
presence of packet losses. presence of packet losses.
In calculating the aggregate congestion signal x_curr, the choice of In calculating the aggregate congestion signal x_curr, the choice of
DMARK and DLOSS influence the steady-state packet loss/marking ratio DMARK and DLOSS influence the steady-state packet loss/marking ratio
experienced by the flow at a given available bandwidth. Higher experienced by the flow at a given available bandwidth. Higher
values of DMARK and DLOSS result in lower steady-state loss/marking values of DMARK and DLOSS result in lower steady-state loss/marking
ratios, but are more susceptible to the impact of individual packet ratios, but are more susceptible to the impact of individual packet
loss/marking events. While the value of DMARK and DLOSS are fixed loss/marking events. While the value of DMARK and DLOSS are fixed
and predetermined in the current design, a scheme for automatically and predetermined in the current design, a scheme for automatically
tuning these values based on desired bandwidth sharing behavior in tuning these values based on desired bandwidth sharing behavior in
skipping to change at page 19, line 10 skipping to change at page 19, line 13
[I-D.ietf-rmcat-eval-test] have been presented at recent IETF [I-D.ietf-rmcat-eval-test] have been presented at recent IETF
meetings [IETF-90][IETF-91]. Evaluation results of the current draft meetings [IETF-90][IETF-91]. Evaluation results of the current draft
over several test cases in [I-D.ietf-rmcat-wireless-tests] have been over several test cases in [I-D.ietf-rmcat-wireless-tests] have been
presented at [IETF-93]. presented at [IETF-93].
The scheme has also been implemented and evaluated in a lab setting The scheme has also been implemented and evaluated in a lab setting
as described in [IETF-90]. Preliminary evaluation results of NADA in as described in [IETF-90]. Preliminary evaluation results of NADA in
single-flow and multi-flow scenarios have been presented in single-flow and multi-flow scenarios have been presented in
[IETF-91]. [IETF-91].
8. IANA Considerations 8. Suggested Experiments
NADA has been extensively evaluated under various test scenarios,
including the collection of test cases specified by
[I-D.ietf-rmcat-eval-test] and the subset of WiFi-based test cases in
[I-D.ietf-rmcat-wireless-tests]. Additional evaluations have been
carried out to characterize how NADA interacts with various active
queue management (AQM) schemes such as RED, CoDel, and PIE. Most of
these evaluations have been carried out in simulators. A few key
test cases have also bee evaluated in implementations embedded in
video conferencing clients.
Further experiments are suggested for the following scenarios:
o Experiments with ECN marking capability turned on at the network
for existing test cases.
o Experiments with multiple RMCAT streams bearing different user-
specified priorities.
o Experiments with additional access technologies, especially over
cellular networks such as 3G/LTE.
o Experiments with various media source contents, including audio
only, audio and video, and application content sharing (e.g.,
slide shows).
o
9. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
9. Acknowledgements 10. 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, Mirja Kuhlewind, and Karen Elisabeth Egede Nielsen for Safiqul Islam, Mirja Kuhlewind, and Karen Elisabeth Egede Nielsen for
their valuable questions and comments on earlier versions of this their valuable questions and comments on earlier versions of this
draft. draft.
10. References 11. References
10.1. Normative References 11.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,
<http://www.rfc-editor.org/info/rfc2119>. <http://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,
<http://www.rfc-editor.org/info/rfc3168>. <http://www.rfc-editor.org/info/rfc3168>.
skipping to change at page 19, line 47 skipping to change at page 20, line 32
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[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, <http://www.rfc-editor.org/info/rfc6679>. 2012, <http://www.rfc-editor.org/info/rfc6679>.
[I-D.ietf-rmcat-eval-test] [I-D.ietf-rmcat-eval-test]
Sarker, Z., Varun, V., Zhu, X., and M. Ramalho, "Test Sarker, Z., Singh, V., Zhu, X., and D. Ramalho, "Test
Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat- Cases for Evaluating RMCAT Proposals", draft-ietf-rmcat-
eval-test-03 (work in progress), March 2016. eval-test-03 (work in progress), March 2016.
[I-D.ietf-rmcat-cc-requirements] [I-D.ietf-rmcat-cc-requirements]
Jesup, R. and Z. Sarker, "Congestion Control Requirements Jesup, R. and Z. Sarker, "Congestion Control Requirements
for Interactive Real-Time Media", draft-ietf-rmcat-cc- for Interactive Real-Time Media", draft-ietf-rmcat-cc-
requirements-09 (work in progress), December 2014. requirements-09 (work in progress), December 2014.
[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-00 (work in progress), January 2016. traffic-model-01 (work in progress), July 2016.
[I-D.ietf-rmcat-cc-codec-interactions] [I-D.ietf-rmcat-cc-codec-interactions]
Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker, Zanaty, M., Singh, V., Nandakumar, S., and Z. Sarker,
"Congestion Control and Codec interactions in RTP "Congestion Control and Codec interactions in RTP
Applications", draft-ietf-rmcat-cc-codec-interactions-01 Applications", draft-ietf-rmcat-cc-codec-interactions-02
(work in progress), October 2015. (work in progress), March 2016.
[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-01 (work in progress), November 2015. wireless-tests-02 (work in progress), May 2016.
10.2. Informative References 11.2. Informative References
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, [RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
S., Wroclawski, J., and L. Zhang, "Recommendations on S., Wroclawski, J., and L. Zhang, "Recommendations on
Queue Management and Congestion Avoidance in the Queue Management and Congestion Avoidance in the
Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998, Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998,
<http://www.rfc-editor.org/info/rfc2309>. <http://www.rfc-editor.org/info/rfc2309>.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
 End of changes. 25 change blocks. 
46 lines changed or deleted 80 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/