draft-ietf-rmcat-eval-test-09.txt   draft-ietf-rmcat-eval-test-10.txt 
Network Working Group Z. Sarker Network Working Group Z. Sarker
Internet-Draft Ericsson AB Internet-Draft Ericsson AB
Intended status: Informational V. Singh Intended status: Informational V. Singh
Expires: August 12, 2019 callstats.io Expires: November 24, 2019 callstats.io
X. Zhu X. Zhu
M. Ramalho M. Ramalho
Cisco Systems Cisco Systems
February 08, 2019 May 23, 2019
Test Cases for Evaluating RMCAT Proposals Test Cases for Evaluating RMCAT Proposals
draft-ietf-rmcat-eval-test-09 draft-ietf-rmcat-eval-test-10
Abstract Abstract
The Real-time Transport Protocol (RTP) is used to transmit media in The Real-time Transport Protocol (RTP) is used to transmit media in
multimedia telephony applications. These applications are typically multimedia telephony applications. These applications are typically
required to implement congestion control. This document describes required to implement congestion control. This document describes
the test cases to be used in the performance evaluation of such the test cases to be used in the performance evaluation of such
congestion control algorithms in a controlled environment. congestion control algorithms in a controlled environment.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 August 12, 2019. This Internet-Draft will expire on November 24, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 2, line 44 skipping to change at page 2, line 44
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
11.1. Normative References . . . . . . . . . . . . . . . . . . 30 11.1. Normative References . . . . . . . . . . . . . . . . . . 30
11.2. Informative References . . . . . . . . . . . . . . . . . 32 11.2. Informative References . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
This memo describes a set of test cases for evaluating congestion This memo describes a set of test cases for evaluating congestion
control algorithm proposals in controlled environment for real-time control algorithm proposals in controlled environments for real-time
interactive media. It is based on the guidelines enumerated in interactive media. It is based on the guidelines enumerated in
[I-D.ietf-rmcat-eval-criteria] and the requirements discussed in [I-D.ietf-rmcat-eval-criteria] and the requirements discussed in
[I-D.ietf-rmcat-cc-requirements]. The test cases cover basic usage [I-D.ietf-rmcat-cc-requirements]. The test cases cover basic usage
scenarios and are described using a common structure, which allows scenarios and are described using a common structure, which allows
for additional test cases to be added to those described herein to for additional test cases to be added to those described herein to
accommodate other topologies and/or the modelling of different path accommodate other topologies and/or the modelling of different path
characteristics. The described test cases in this memo should be characteristics. The described test cases in this memo should be
used to evaluate any proposed congestion control algorithm for real- used to evaluate any proposed congestion control algorithm for real-
time interactive media. time interactive media.
skipping to change at page 5, line 9 skipping to change at page 5, line 9
Two sets of attributes describe the path characteristics, one Two sets of attributes describe the path characteristics, one
for the forward path and the other for the backward path. The for the forward path and the other for the backward path. The
path characteristics for a particular path direction is path characteristics for a particular path direction is
applicable to all the Sources "S" sending traffic on that path. applicable to all the Sources "S" sending traffic on that path.
If only one attribute is specified, it is used for both path If only one attribute is specified, it is used for both path
directions, however, unless specified the reverse path has no directions, however, unless specified the reverse path has no
capacity restrictions and no path loss. capacity restrictions and no path loss.
+ Path direction: forward or backward. + Path direction: forward or backward.
+ Bottleneck-link capacity: defines minimum capacity of the + Minimum bottleneck-link capacity: defines minimum capacity
end-to-end path of the end-to-end path
+ Reference bottleneck capacity: defines a reference value for + Reference bottleneck capacity: defines a reference value for
the bottleneck capacity for test cases with time-varying the bottleneck capacity for test cases with time-varying
bottleneck capacities. All bottleneck capacities will be bottleneck capacities. All bottleneck capacities will be
specified as a ratio with respect to the reference capacity specified as a ratio with respect to the reference capacity
value. value.
+ One-way propagation delay: describes the end-to-end latency + One-way propagation delay: describes the end-to-end latency
along the path when network queues are empty, i.e., the time along the path when network queues are empty, i.e., the time
it takes for a packet to go from the sender to the receiver it takes for a packet to go from the sender to the receiver
without encountering any queuing delay. without encountering any queuing delay.
+ Maximum end-to-end jitter: defines the maximum jitter that + Maximum end-to-end jitter: defines the maximum jitter that
can be observed along the path. can be observed along the path.
+ Bottleneck queue type: for example, "tail drop" [RFC7567], + Bottleneck queue type: for example, "tail drop" [RFC7567],
FQ-CoDel[RFC8290], or PIE[RFC8033]. Flow Queue -CoDel (FQ-CoDel)[RFC8290], or Proportional
Integral controller Enhanced (PIE)[RFC8033].
+ Bottleneck queue size: defines the size of queue in terms of + Bottleneck queue size: defines the size of queue in terms of
queuing time when the queue is full (in milliseconds). queuing time when the queue is full (in milliseconds).
+ Path loss ratio: characterizes the non-congested, additive, + Path loss ratio: characterizes the non-congested, additive,
losses to be generated on the end-to-end path. This must losses to be generated on the end-to-end path. This must
describe the loss pattern or loss model used to generate the describe the loss pattern or loss model used to generate the
losses. losses.
* Application-related: defines the traffic source behavior for * Application-related: defines the traffic source behavior for
skipping to change at page 8, line 19 skipping to change at page 8, line 19
4.1. Evaluation metrics 4.1. Evaluation metrics
To evaluate the performance of the candidate algorithms the To evaluate the performance of the candidate algorithms the
implementers must log enough information to visualize the following implementers must log enough information to visualize the following
metrics at a fine enough time granularity: metrics at a fine enough time granularity:
1. Flow level: 1. Flow level:
A. End-to-end delay for the congestion controlled media flow(s). A. End-to-end delay for the congestion controlled media flow(s).
For example - end-to-end delay overserved on IP packet level, For example - end-to-end delay observed on IP packet level,
video frame level. video frame level.
B. Variation in sending bit rate and throughput. Mainly B. Variation in sending bit rate and throughput. Mainly
observing the frequency and magnitude of oscillations. observing the frequency and magnitude of oscillations.
C. Packet losses observed at the receiving endpoint. C. Packet losses observed at the receiving endpoint.
D. Feedback message overhead. D. Feedback message overhead.
E. Convergence time - time to reach steady state for the E. Convergence time - time to reach steady state for the
congestion controlled media flow(s). Each occurance of congestion controlled media flow(s). Each occurrence of
convergence during the test period need to be presented. convergence during the test period need to be presented.
2. Transport level: 2. Transport level:
A. Bandwidth utilization. A. Bandwidth utilization.
B. Queue length (milliseconds at specified path capacity). B. Queue length (milliseconds at specified path capacity).
4.2. Path characteristics 4.2. Path characteristics
skipping to change at page 10, line 34 skipping to change at page 10, line 34
+ Responsiveness to new bit rate request: 100ms + Responsiveness to new bit rate request: 100ms
* Media content: The media content should represent a typical * Media content: The media content should represent a typical
video conversational scenario with head and shoulder movement. video conversational scenario with head and shoulder movement.
We recommend to use Foreman video sequence[xiph-seq]. We recommend to use Foreman video sequence[xiph-seq].
* Media startup behavior: 150Kbps. It should be noted that * Media startup behavior: 150Kbps. It should be noted that
applications can use smart ways to select an optimal startup applications can use smart ways to select an optimal startup
bit rate value for a certain network condition. In such cases bit rate value for a certain network condition. In such cases
the candidate proposals MAY show the effectiveness of such the candidate proposals may show the effectiveness of such
smart approach as an additional information for the evaluation smart approach as an additional information for the evaluation
process. process.
o Media type: Audio o Media type: Audio
* Media codec: CBR * Media codec: CBR
* Media bit rate: 20Kbps * Media bit rate: 20Kbps
5. Basic Test Cases 5. Basic Test Cases
5.1. Variable Available Capacity with a Single Flow 5.1. Variable Available Capacity with a Single Flow
In this test case the bottleneck-link capacity between the two In this test case the minimum bottleneck-link capacity between the
endpoints varies over time. This test is designed to measure the two endpoints varies over time. This test is designed to measure the
responsiveness of the candidate algorithm. This test tries to responsiveness of the candidate algorithm. This test tries to
address the requirements in [I-D.ietf-rmcat-cc-requirements], which address the requirements in [I-D.ietf-rmcat-cc-requirements], which
requires the algorithm to adapt the flow(s) and provide lower end-to- requires the algorithm to adapt the flow(s) and provide lower end-to-
end latency when there exists: end latency when there exists:
o an intermediate bottleneck o an intermediate bottleneck
o change in available capacity (e.g., due to interface change, o change in available capacity (e.g., due to interface change,
routing change, abrupt arrival/departure of background non- routing change, abrupt arrival/departure of background non-
adaptive traffic). adaptive traffic).
skipping to change at page 19, line 44 skipping to change at page 19, line 44
but the one-way propagation delay for each flow is different. For but the one-way propagation delay for each flow is different. For
the sake of simplicity it is assumed that there are no other the sake of simplicity it is assumed that there are no other
competing traffic sources in the bottleneck link and that there is competing traffic sources in the bottleneck link and that there is
sufficient capacity to accommodate all the flows. While this appears sufficient capacity to accommodate all the flows. While this appears
to be a variant of test case 5.2, it focuses on the capacity sharing to be a variant of test case 5.2, it focuses on the capacity sharing
aspect of the candidate algorithm under different RTTs. aspect of the candidate algorithm under different RTTs.
Expected behavior: It is expected that the competing flows will Expected behavior: It is expected that the competing flows will
converge to bit rates to accommodate all the flows with minimum converge to bit rates to accommodate all the flows with minimum
possible latency and loss. The effectiveness of the algorithm possible latency and loss. The effectiveness of the algorithm
depends on how fast and fairly the comepting flows converge to their depends on how fast and fairly the competing flows converge to their
steady states irrespective of the RTT overserved. steady states irrespective of the RTT observed.
Evaluation metrics : as described in Section 4.1. Evaluation metrics : as described in Section 4.1.
Testbed Topology: Five (5) media sources S1,S2,..,S5 are connected to Testbed Topology: Five (5) media sources S1,S2,..,S5 are connected to
their corresponding media sinks R1,R2,..,R5. The media traffic is their corresponding media sinks R1,R2,..,R5. The media traffic is
transported over the forward path and corresponding feedback/control transported over the forward path and corresponding feedback/control
traffic is transported over the backward path. The topology is the traffic is transported over the backward path. The topology is the
same as in Section 5.4. same as in Section 5.4.
Testbed attributes: Testbed attributes:
skipping to change at page 23, line 24 skipping to change at page 23, line 24
* Additionally, implementers are encouraged to run the experiment * Additionally, implementers are encouraged to run the experiment
with multiple media sources. with multiple media sources.
* Competing traffic: * Competing traffic:
+ Number and Types of sources : one (1) and long-lived TCP + Number and Types of sources : one (1) and long-lived TCP
+ Traffic direction : forward + Traffic direction : forward
+ Congestion control: default TCP congestion control[RFC5681]. + Congestion control: default TCP congestion control[RFC5681].
Implementers are also encouraged to run the experiment with
alternative TCP congestion control algorithm.
+ Traffic timeline: + Traffic timeline:
- Start time: 0s. - Start time: 0s.
- End time: 119s. - End time: 119s.
o Test Specific Information: none o Test Specific Information: none
5.7. Media Flow Competing with Short TCP Flows 5.7. Media Flow Competing with Short TCP Flows
skipping to change at page 25, line 20 skipping to change at page 25, line 20
o End time: 299s. o End time: 299s.
* Competing traffic: * Competing traffic:
+ Number and Types of sources : ten (10), short-lived TCP + Number and Types of sources : ten (10), short-lived TCP
flows. flows.
+ Traffic direction : forward + Traffic direction : forward
+ Congestion algorithm: default TCP Congestion control + Congestion algorithm: default TCP Congestion control
[RFC5681]. [RFC5681]. Implementers are also encouraged to run the
experiment with alternative TCP congestion control
algorithm.
+ Traffic timeline: each short TCP flow is modeled as a + Traffic timeline: each short TCP flow is modeled as a
sequence of file downloads interleaved with idle periods. sequence of file downloads interleaved with idle periods.
Not all short TCP flows start at the same time, 2 of them Not all short TCP flows start at the same time, 2 of them
start in the ON state while rest of the 8 flows start in an start in the ON state while rest of the 8 flows start in an
OFF state. For description of short TCP flow model see test OFF state. For description of short TCP flow model see test
specific information below. specific information below.
o Test Specific Information: o Test Specific Information:
skipping to change at page 26, line 18 skipping to change at page 26, line 20
paused, the two remaining flows are expected to increase their rates paused, the two remaining flows are expected to increase their rates
and reach the maximum media bit rate. When the third stream resumes, and reach the maximum media bit rate. When the third stream resumes,
all three flows are expected to converge to the same original fair all three flows are expected to converge to the same original fair
share of rates prior to the media pause/resume event. share of rates prior to the media pause/resume event.
Evaluation metrics : following metrics in addition to as described in Evaluation metrics : following metrics in addition to as described in
Section 4.1. Section 4.1.
1. Flow level: 1. Flow level:
A. Variation in sending bit rate and goodput. Mainly observing A. Variation in sending bit rate and throughput. Mainly
the frequency and magnitude of oscillations. observing the frequency and magnitude of oscillations.
Testbed Topology: Same as test case defined in Section 5.4 Testbed Topology: Same as test case defined in Section 5.4
Testbed attributes: The general description of the testbed parameters Testbed attributes: The general description of the testbed parameters
are same as Section 5.4 with changes in the test specific setup as are same as Section 5.4 with changes in the test specific setup as
below- below-
o Other test specific setup: o Other test specific setup:
* Media flow timeline: * Media flow timeline:
skipping to change at page 27, line 48 skipping to change at page 27, line 49
scheduler for the bandwidth distribution according to the respective scheduler for the bandwidth distribution according to the respective
media flow priority or use. media flow priority or use.
6.2. Explicit Congestion Notification Usage 6.2. Explicit Congestion Notification Usage
This test case requires to run all the basic test cases with the This test case requires to run all the basic test cases with the
availability of Explicit Congestion Notification (ECN) [RFC6679] availability of Explicit Congestion Notification (ECN) [RFC6679]
feature enabled. The goal of this test is to exhibit that the feature enabled. The goal of this test is to exhibit that the
candidate algorithms do not fail when ECN signals are available. candidate algorithms do not fail when ECN signals are available.
With ECN signals enabled the algorithms are expected to perform With ECN signals enabled the algorithms are expected to perform
better than their delay based variants. better than their delay-based variants.
6.3. Multiple Bottlenecks 6.3. Multiple Bottlenecks
In this test case one congestion controlled media flow, S1->R1, In this test case one congestion controlled media flow, S1->R1,
traverses a path with multiple bottlenecks. As illustrated in traverses a path with multiple bottlenecks. As illustrated in
Figure 7, the first flow (S1->R1) competes with the second congestion Figure 7, the first flow (S1->R1) competes with the second congestion
controlled media flow (S2->R2) over the link between A and B which is controlled media flow (S2->R2) over the link between A and B which is
close to the sender side; again, that flow (S1->R1) competes with the close to the sender side; again, that flow (S1->R1) competes with the
third congestion controlled media flow (S3->R3) over the link between third congestion controlled media flow (S3->R3) over the link between
C and D which is close to the receiver side. The goal of this test C and D which is close to the receiver side. The goal of this test
is to ensure that the candidate algorithms work properly in the is to ensure that the candidate algorithms work properly in the
presence of multiple bottleneck links on the end to end path. presence of multiple bottleneck links on the end to end path.
Expected behavior: The candidate algorithm is expected to achieve Expected behavior: The candidate algorithm is expected to achieve
full utilization at both bottleneck links without starving any of the full utilization at both bottleneck links without starving any of the
three congestion controlled media flows and esuring fair share of the three congestion controlled media flows and ensuring fair share of
available bandwidth at each bottlenecks. the available bandwidth at each bottlenecks.
Forward ----> Forward ---->
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
|S2 | |R2 | |S3 | |R3 | |S2 | |R2 | |S3 | |R3 |
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
| | | | | | | |
| | | | | | | |
+---+ +-----+ +-----+ +-----+ +-----+ +---+ +---+ +-----+ +-----+ +-----+ +-----+ +---+
|S1 |=======| A |------>| B |----->| C |---->| D |=======|R1 | |S1 |=======| A |------>| B |----->| C |---->| D |=======|R1 |
skipping to change at page 30, line 25 skipping to change at page 30, line 25
The security considerations in [I-D.ietf-rmcat-eval-criteria] and the The security considerations in [I-D.ietf-rmcat-eval-criteria] and the
relevant congestion control algorithms apply. The principles for relevant congestion control algorithms apply. The principles for
congestion control are described in [RFC2914], and in particular any congestion control are described in [RFC2914], and in particular any
new method must implement safeguards to avoid congestion collapse of new method must implement safeguards to avoid congestion collapse of
the Internet. the Internet.
The evaluation of the test cases are intended to be run in a The evaluation of the test cases are intended to be run in a
controlled lab environment. Hence, the applications, simulators and controlled lab environment. Hence, the applications, simulators and
network nodes ought to be well-behaved and should not impact the network nodes ought to be well-behaved and should not impact the
desired results. Moreover, proper measures must be taked to avoid desired results. Moreover, proper measures must be taken to avoid
leaking non-responsive traffic from unproven congestion avoidance leaking non-responsive traffic from unproven congestion avoidance
techniques onto the open Internet. techniques onto the open Internet.
9. IANA Considerations 9. IANA Considerations
There are no IANA impacts in this memo. There are no IANA impacts in this memo.
10. Acknowledgements 10. Acknowledgements
Much of this document is derived from previous work on congestion Much of this document is derived from previous work on congestion
skipping to change at page 31, line 13 skipping to change at page 31, line 13
requirements-09 (work in progress), December 2014. requirements-09 (work in progress), December 2014.
[I-D.ietf-rmcat-eval-criteria] [I-D.ietf-rmcat-eval-criteria]
Singh, V., Ott, J., and S. Holmer, "Evaluating Congestion Singh, V., Ott, J., and S. Holmer, "Evaluating Congestion
Control for Interactive Real-time Media", draft-ietf- Control for Interactive Real-time Media", draft-ietf-
rmcat-eval-criteria-08 (work in progress), November 2018. rmcat-eval-criteria-08 (work in progress), November 2018.
[I-D.ietf-rmcat-video-traffic-model] [I-D.ietf-rmcat-video-traffic-model]
Zhu, X., Cruz, S., and Z. Sarker, "Video Traffic Models Zhu, X., Cruz, S., and Z. Sarker, "Video Traffic Models
for RTP Congestion Control Evaluations", draft-ietf-rmcat- for RTP Congestion Control Evaluations", draft-ietf-rmcat-
video-traffic-model-06 (work in progress), November 2018. video-traffic-model-07 (work in progress), February 2019.
[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-06 (work in progress), December 2018. wireless-tests-06 (work in progress), December 2018.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
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,
skipping to change at page 31, line 47 skipping to change at page 31, line 47
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
DOI 10.17487/RFC4585, July 2006, DOI 10.17487/RFC4585, July 2006,
<https://www.rfc-editor.org/info/rfc4585>. <https://www.rfc-editor.org/info/rfc4585>.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, DOI 10.17487/RFC5506, April and Consequences", RFC 5506, DOI 10.17487/RFC5506, April
2009, <https://www.rfc-editor.org/info/rfc5506>. 2009, <https://www.rfc-editor.org/info/rfc5506>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/info/rfc5681>.
[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 11.2. Informative References
[HEVC-seq] [HEVC-seq]
HEVC, "Test Sequences", HEVC, "Test Sequences",
http://www.netlab.tkk.fi/~varun/test_sequences/ . http://www.netlab.tkk.fi/~varun/test_sequences/ .
[I-D.ietf-rmcat-coupled-cc] [I-D.ietf-rmcat-coupled-cc]
Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion
control for RTP media", draft-ietf-rmcat-coupled-cc-08 control for RTP media", draft-ietf-rmcat-coupled-cc-08
(work in progress), January 2019. (work in progress), January 2019.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, DOI 10.17487/RFC2914, September 2000, RFC 2914, DOI 10.17487/RFC2914, September 2000,
<https://www.rfc-editor.org/info/rfc2914>. <https://www.rfc-editor.org/info/rfc2914>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/info/rfc5681>.
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF [RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF
Recommendations Regarding Active Queue Management", Recommendations Regarding Active Queue Management",
BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
<https://www.rfc-editor.org/info/rfc7567>. <https://www.rfc-editor.org/info/rfc7567>.
[RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, [RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White,
"Proportional Integral Controller Enhanced (PIE): A "Proportional Integral Controller Enhanced (PIE): A
Lightweight Control Scheme to Address the Bufferbloat Lightweight Control Scheme to Address the Bufferbloat
Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017, Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017,
<https://www.rfc-editor.org/info/rfc8033>. <https://www.rfc-editor.org/info/rfc8033>.
skipping to change at page 33, line 6 skipping to change at page 33, line 6
DOI 10.17487/RFC8290, January 2018, DOI 10.17487/RFC8290, January 2018,
<https://www.rfc-editor.org/info/rfc8290>. <https://www.rfc-editor.org/info/rfc8290>.
[xiph-seq] [xiph-seq]
Xiph.org, "Video Test Media", Xiph.org, "Video Test Media",
http://media.xiph.org/video/derf/ . http://media.xiph.org/video/derf/ .
Authors' Addresses Authors' Addresses
Zaheduzzaman Sarker Zaheduzzaman Sarker
Ericsson AB Ericsson AB
Luleae, SE 977 53 Torshamnsgatan 23
Stockholm, SE 164 83
Sweden Sweden
Phone: +46 10 717 37 43 Phone: +46 10 717 37 43
Email: zaheduzzaman.sarker@ericsson.com Email: zaheduzzaman.sarker@ericsson.com
Varun Singh Varun Singh
Nemu Dialogue Systems Oy Nemu Dialogue Systems Oy
Runeberginkatu 4c A 4 Runeberginkatu 4c A 4
Helsinki 00100 Helsinki 00100
Finland Finland
 End of changes. 22 change blocks. 
28 lines changed or deleted 34 lines changed or added

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