draft-ietf-avtcore-rtp-circuit-breakers-05.txt   draft-ietf-avtcore-rtp-circuit-breakers-06.txt 
AVTCORE Working Group C. S. Perkins AVTCORE Working Group C. S. Perkins
Internet-Draft University of Glasgow Internet-Draft University of Glasgow
Updates: 3550 (if approved) V. Singh Updates: 3550 (if approved) V. Singh
Intended status: Standards Track Aalto University Intended status: Standards Track Aalto University
Expires: August 18, 2014 February 14, 2014 Expires: January 05, 2015 July 04, 2014
Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions
draft-ietf-avtcore-rtp-circuit-breakers-05 draft-ietf-avtcore-rtp-circuit-breakers-06
Abstract Abstract
The Real-time Transport Protocol (RTP) is widely used in telephony, The Real-time Transport Protocol (RTP) is widely used in telephony,
video conferencing, and telepresence applications. Such applications video conferencing, and telepresence applications. Such applications
are often run on best-effort UDP/IP networks. If congestion control are often run on best-effort UDP/IP networks. If congestion control
is not implemented in the applications, then network congestion will is not implemented in the applications, then network congestion will
deteriorate the user's multimedia experience. This document does not deteriorate the user's multimedia experience. This document does not
propose a congestion control algorithm; instead, it defines a minimal propose a congestion control algorithm; instead, it defines a minimal
set of RTP "circuit-breakers". Circuit-breakers are conditions under set of RTP "circuit-breakers". Circuit-breakers are conditions under
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 August 18, 2014. This Internet-Draft will expire on January 05, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 35 skipping to change at page 2, line 35
4.5. Ceasing Transmission . . . . . . . . . . . . . . . . . . 13 4.5. Ceasing Transmission . . . . . . . . . . . . . . . . . . 13
5. RTP Circuit Breakers for Systems Using the RTP/AVPF Profile . 13 5. RTP Circuit Breakers for Systems Using the RTP/AVPF Profile . 13
6. Impact of RTCP XR . . . . . . . . . . . . . . . . . . . . . . 14 6. Impact of RTCP XR . . . . . . . . . . . . . . . . . . . . . . 14
7. Impact of RTCP Reporting Groups . . . . . . . . . . . . . . . 15 7. Impact of RTCP Reporting Groups . . . . . . . . . . . . . . . 15
8. Impact of Explicit Congestion Notification (ECN) . . . . . . 15 8. Impact of Explicit Congestion Notification (ECN) . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
The Real-time Transport Protocol (RTP) [RFC3550] is widely used in The Real-time Transport Protocol (RTP) [RFC3550] is widely used in
voice-over-IP, video teleconferencing, and telepresence systems. voice-over-IP, video teleconferencing, and telepresence systems.
Many of these systems run over best-effort UDP/IP networks, and can Many of these systems run over best-effort UDP/IP networks, and can
suffer from packet loss and increased latency if network congestion suffer from packet loss and increased latency if network congestion
occurs. Designing effective RTP congestion control algorithms, to occurs. Designing effective RTP congestion control algorithms, to
adapt the transmission of RTP-based media to match the available adapt the transmission of RTP-based media to match the available
skipping to change at page 5, line 24 skipping to change at page 5, line 24
loss, discard, and burst metrics [RFC3611], [RFC7002], [RFC7097], loss, discard, and burst metrics [RFC3611], [RFC7002], [RFC7097],
[RFC7003], [RFC6958]; and the extended delay metrics [RFC6843], [RFC7003], [RFC6958]; and the extended delay metrics [RFC6843],
[RFC6798]. Other RTCP Extended Reports that could be helpful for [RFC6798]. Other RTCP Extended Reports that could be helpful for
congestion control purposes might be developed in future. congestion control purposes might be developed in future.
o Rapid feedback about the occurrence of congestion events can be o Rapid feedback about the occurrence of congestion events can be
achieved using the Extended RTP Profile for RTCP-Based Feedback achieved using the Extended RTP Profile for RTCP-Based Feedback
(RTP/AVPF) [RFC4585] in place of the more common RTP/AVP profile (RTP/AVPF) [RFC4585] in place of the more common RTP/AVP profile
[RFC3551]. This modifies the RTCP timing rules to allow RTCP [RFC3551]. This modifies the RTCP timing rules to allow RTCP
reports to be sent early, in some cases immediately, provided the reports to be sent early, in some cases immediately, provided the
average RTCP reporting interval remains unchanged. It also RTCP transmission keeps within its bandwidth allocation. It also
defines new transport-layer feedback messages, including negative defines new transport-layer feedback messages, including negative
acknowledgements (NACKs), that can be used to report on specific acknowledgements (NACKs), that can be used to report on specific
congestion events. The use of the RTP/AVPF profile is dependent congestion events. The use of the RTP/AVPF profile is dependent
on signalling, but is otherwise generally backwards compatible on signalling. The RTP Codec Control Messages [RFC5104] extend
with the RTP/AVP profile, as it keeps the same average RTCP the RTP/AVPF profile with additional feedback messages that can be
reporting interval as the base RTP specification. The RTP Codec used to influence that way in which rate adaptation occurs. The
Control Messages [RFC5104] extend the RTP/AVPF profile with dynamics of how rapidly feedback can be sent are unchanged.
additional feedback messages that can be used to influence that
way in which rate adaptation occurs. The dynamics of how rapidly
feedback can be sent are unchanged.
o Finally, Explicit Congestion Notification (ECN) for RTP over UDP o Finally, Explicit Congestion Notification (ECN) for RTP over UDP
[RFC6679] can be used to provide feedback on the number of packets [RFC6679] can be used to provide feedback on the number of packets
that received an ECN Congestion Experienced (CE) mark. This RTCP that received an ECN Congestion Experienced (CE) mark. This RTCP
extension builds on the RTP/AVPF profile to allow rapid congestion extension builds on the RTP/AVPF profile to allow rapid congestion
feedback when ECN is supported. feedback when ECN is supported.
In addition to these mechanisms for providing feedback, the sender In addition to these mechanisms for providing feedback, the sender
can include an RTP header extension in each packet to record packet can include an RTP header extension in each packet to record packet
transmission times. There are two methods: [RFC5450] represents the transmission times. There are two methods: [RFC5450] represents the
skipping to change at page 7, line 26 skipping to change at page 7, line 22
insufficient information to estimate the extent or persistence of insufficient information to estimate the extent or persistence of
congestion. Jitter reports are a useful early warning of potential congestion. Jitter reports are a useful early warning of potential
network congestion, but provide an insufficiently strong signal to be network congestion, but provide an insufficiently strong signal to be
used as a circuit breaker. used as a circuit breaker.
The remaining congestion signals are the packet loss fraction and the The remaining congestion signals are the packet loss fraction and the
cumulative number of packets lost. If considered carefully, these cumulative number of packets lost. If considered carefully, these
can be effective indicators that congestion is occurring in networks can be effective indicators that congestion is occurring in networks
where packet loss is primarily due to queue overflows, although loss where packet loss is primarily due to queue overflows, although loss
caused by non-congestive packet corruption can distort the result in caused by non-congestive packet corruption can distort the result in
some networks. TCP congestion control intentionally tries to fill some networks. TCP congestion control [RFC5681] intentionally tries
the router queues, and uses the resulting packet loss as congestion to fill the router queues, and uses the resulting packet loss as
feedback. An RTP flow competing with TCP traffic will therefore congestion feedback. An RTP flow competing with TCP traffic will
expect to see a non-zero packet loss fraction that has to be related therefore expect to see a non-zero packet loss fraction that has to
to TCP dynamics to estimate available capacity. This behaviour of be related to TCP dynamics to estimate available capacity. This
TCP is reflected in the congestion circuit breaker below, and will behaviour of TCP is reflected in the congestion circuit breaker
affect the design of any RTP congestion control protocol. below, and will affect the design of any RTP congestion control
protocol.
Two packet loss regimes can be observed: 1) RTCP RR packets show a Two packet loss regimes can be observed: 1) RTCP RR packets show a
non-zero packet loss fraction, while the extended highest sequence non-zero packet loss fraction, while the extended highest sequence
number received continues to increment; and 2) RR packets show a loss number received continues to increment; and 2) RR packets show a loss
fraction of zero, but the extended highest sequence number received fraction of zero, but the extended highest sequence number received
does not increment even though the sender has been transmitting RTP does not increment even though the sender has been transmitting RTP
data packets. The former corresponds to the TCP congestion avoidance data packets. The former corresponds to the TCP congestion avoidance
state, and indicates a congested path that is still delivering data; state, and indicates a congested path that is still delivering data;
the latter corresponds to a TCP timeout, and is most likely due to a the latter corresponds to a TCP timeout, and is most likely due to a
path failure. A third condition is that data is being sent but no path failure. A third condition is that data is being sent but no
skipping to change at page 8, line 10 skipping to change at page 8, line 8
If RTP data packets are being sent, but the RTCP SR or RR packets If RTP data packets are being sent, but the RTCP SR or RR packets
reporting on that SSRC indicate a non-increasing extended highest reporting on that SSRC indicate a non-increasing extended highest
sequence number received, this is an indication that those RTP data sequence number received, this is an indication that those RTP data
packets are not reaching the receiver. This could be a short-term packets are not reaching the receiver. This could be a short-term
issue affecting only a few packets, perhaps caused by a slow-to-open issue affecting only a few packets, perhaps caused by a slow-to-open
firewall or a transient connectivity problem, but if the issue firewall or a transient connectivity problem, but if the issue
persists, it is a sign of a more ongoing and significant problem. persists, it is a sign of a more ongoing and significant problem.
Accordingly, if a sender of RTP data packets receives two or more Accordingly, if a sender of RTP data packets receives two or more
consecutive RTCP SR or RR packets from the same receiver, and those consecutive RTCP SR or RR packets from the same receiver, and those
packets correspond to its transmission and have a non-increasing packets correspond to its transmission and have a non-increasing
extended highest sequence number received field (i.e., the sender extended highest sequence number received field, then that sender
receivers at least three RTCP SR or RR packets that report the same SHOULD cease transmission (see Section 4.5). The extended highest
value in the extended highest sequence number received field for an sequence number received field is non-increasing if the sender
SSRC, but the sender has sent RTP data packets for that SSRC that receives at least three RTCP SR or RR packets that report the same
would have caused an increase in the reported value of the extended value for this field, but it has sent RTP data packets that would
highest sequence number received if they had reached the receiver), have caused an increase in the reported value if they had reached the
then that sender SHOULD cease transmission (see Section 4.5). receiver.
The reason for waiting for two or more consecutive RTCP packets with The reason for waiting for two or more consecutive RTCP packets with
a non-increasing extended highest sequence number is to give enough a non-increasing extended highest sequence number is to give enough
time for transient reception problems to resolve themselves, but to time for transient reception problems to resolve themselves, but to
stop problem flows quickly enough to avoid causing serious ongoing stop problem flows quickly enough to avoid causing serious ongoing
network congestion. A single RTCP report showing no reception could network congestion. A single RTCP report showing no reception could
be caused by a transient fault, and so will not cease transmission. be caused by a transient fault, and so will not cease transmission.
Waiting for more than two consecutive RTCP reports before stopping a Waiting for more than two consecutive RTCP reports before stopping a
flow might avoid some false positives, but could lead to problematic flow might avoid some false positives, but could lead to problematic
flows running for a long time period (potentially tens of seconds, flows running for a long time period (potentially tens of seconds,
depending on the RTCP reporting interval) before being cut off. depending on the RTCP reporting interval) before being cut off.
Equally, an application that sends few packets when the packet loss
rate is high runs the risk that the media timeout circuit breaker
triggers inadvertently. The chosen timeout interval is a trade-off
between these extremes.
4.2. RTP/AVP Circuit Breaker #2: RTCP Timeout 4.2. RTP/AVP Circuit Breaker #2: RTCP Timeout
In addition to media timeouts, as were discussed in Section 4.1, an In addition to media timeouts, as were discussed in Section 4.1, an
RTP session has the possibility of an RTCP timeout. This can occur RTP session has the possibility of an RTCP timeout. This can occur
when RTP data packets are being sent, but there are no RTCP reports when RTP data packets are being sent, but there are no RTCP reports
returned from the receiver. This is either due to a failure of the returned from the receiver. This is either due to a failure of the
receiver to send RTCP reports, or a failure of the return path that receiver to send RTCP reports, or a failure of the return path that
is preventing those RTCP reporting from being delivered. In either is preventing those RTCP reporting from being delivered. In either
case, it is not safe to continue transmission, since the sender has case, it is not safe to continue transmission, since the sender has
no way of knowing if it is causing congestion. Accordingly, an RTP no way of knowing if it is causing congestion. Accordingly, an RTP
sender that has not received any RTCP SR or RTCP RR packets reporting sender that has not received any RTCP SR or RTCP RR packets reporting
on the SSRC it is using for three or more RTCP reporting intervals on the SSRC it is using for three or more of its RTCP reporting
SHOULD cease transmission (see Section 4.5). When calculating the intervals SHOULD cease transmission (see Section 4.5). When
timeout, the fixed minimum RTCP reporting interval SHOULD be used calculating the timeout, the deterministic RTCP reporting interval,
(based on the rationale in Section 6.2 of RFC 3550 [RFC3550]). Td, without the randomization factor, and with a fixed minimum
interval Tmin=5 seconds) SHOULD be used. The rationale for this
choice of timeout is as described in Section 6.2 of RFC 3550
[RFC3550].
The choice of three RTCP reporting intervals as the timeout is made The choice of three RTCP reporting intervals as the timeout is made
following Section 6.3.5 of RFC 3550 [RFC3550]. This specifies that following Section 6.3.5 of RFC 3550 [RFC3550]. This specifies that
participants in an RTP session will timeout and remove an RTP sender participants in an RTP session will timeout and remove an RTP sender
from the list of active RTP senders if no RTP data packets have been from the list of active RTP senders if no RTP data packets have been
received from that RTP sender within the last two RTCP reporting received from that RTP sender within the last two RTCP reporting
intervals. Using a timeout of three RTCP reporting intervals is intervals. Using a timeout of three RTCP reporting intervals is
therefore large enough that the other participants will have timed therefore large enough that the other participants will have timed
out the sender if a network problem stops the data packets it is out the sender if a network problem stops the data packets it is
sending from reaching the receivers, even allowing for loss of some sending from reaching the receivers, even allowing for loss of some
skipping to change at page 15, line 51 skipping to change at page 16, line 11
If the RTP/AVPF profile is used to provide rapid RTCP feedback, the If the RTP/AVPF profile is used to provide rapid RTCP feedback, the
security considerations of [RFC4585] apply. If ECN feedback for RTP security considerations of [RFC4585] apply. If ECN feedback for RTP
over UDP/IP is used, the security considerations of [RFC6679] apply. over UDP/IP is used, the security considerations of [RFC6679] apply.
If non-authenticated RTCP reports are used, an on-path attacker can If non-authenticated RTCP reports are used, an on-path attacker can
trivially generate fake RTCP packets that indicate high packet loss trivially generate fake RTCP packets that indicate high packet loss
rates, causing the circuit breaker to trigger and disrupting an RTP rates, causing the circuit breaker to trigger and disrupting an RTP
session. This is somewhat more difficult for an off-path attacker, session. This is somewhat more difficult for an off-path attacker,
due to the need to guess the randomly chosen RTP SSRC value and the due to the need to guess the randomly chosen RTP SSRC value and the
RTP sequence number. This attack can be avoided if RTCP packets are RTP sequence number. This attack can be avoided if RTCP packets are
authenticated, for example using the Secure RTP profile [RFC3711]. authenticated; authentication options are discussed in [RFC7201].
10. IANA Considerations 10. IANA Considerations
There are no actions for IANA. There are no actions for IANA.
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Bernard Aboba, Harald Alvestrand, The authors would like to thank Bernard Aboba, Harald Alvestrand,
Kevin Gross, Cullen Jennings, Randell Jesup, Jonathan Lennox, Matt Kevin Gross, Cullen Jennings, Randell Jesup, Jonathan Lennox, Matt
Mathis, Stephen McQuistin, Eric Rescorla, and Abheek Saha for their Mathis, Stephen McQuistin, Eric Rescorla, and Abheek Saha for their
skipping to change at page 17, line 7 skipping to change at page 17, line 16
[Floyd] Floyd, S., Handley, M., Padhye, J., and J. Widmer, [Floyd] Floyd, S., Handley, M., Padhye, J., and J. Widmer,
"Equation-Based Congestion Control for Unicast "Equation-Based Congestion Control for Unicast
Applications", Proceedings of the ACM SIGCOMM conference, Applications", Proceedings of the ACM SIGCOMM conference,
2000, DOI 10.1145/347059.347397, August 2000. 2000, DOI 10.1145/347059.347397, August 2000.
[I-D.ietf-avtcore-rtp-multi-stream-optimisation] [I-D.ietf-avtcore-rtp-multi-stream-optimisation]
Lennox, J., Westerlund, M., Wu, W., and C. Perkins, Lennox, J., Westerlund, M., Wu, W., and C. Perkins,
"Sending Multiple Media Streams in a Single RTP Session: "Sending Multiple Media Streams in a Single RTP Session:
Grouping RTCP Reception Statistics and Other Feedback", Grouping RTCP Reception Statistics and Other Feedback",
draft-ietf-avtcore-rtp-multi-stream-optimisation-01 (work draft-ietf-avtcore-rtp-multi-stream-optimisation-03 (work
in progress), January 2014. in progress), July 2014.
[Mathis] Mathis, M., Semke, J., Mahdavi, J., and T. Ott, "The [Mathis] Mathis, M., Semke, J., Mahdavi, J., and T. Ott, "The
macroscopic behavior of the TCP congestion avoidance macroscopic behavior of the TCP congestion avoidance
algorithm", ACM SIGCOMM Computer Communication Review algorithm", ACM SIGCOMM Computer Communication Review
27(3), DOI 10.1145/263932.264023, July 1997. 27(3), DOI 10.1145/263932.264023, July 1997.
[Padhye] Padhye, J., Firoiu, V., Towsley, D., and J. Kurose, [Padhye] Padhye, J., Firoiu, V., Towsley, D., and J. Kurose,
"Modeling TCP Throughput: A Simple Model and its Empirical "Modeling TCP Throughput: A Simple Model and its Empirical
Validation", Proceedings of the ACM SIGCOMM conference, Validation", Proceedings of the ACM SIGCOMM conference,
1998, DOI 10.1145/285237.285291, August 1998. 1998, DOI 10.1145/285237.285291, August 1998.
[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", RFC of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001. 3168, September 2001.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, [RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman,
"Codec Control Messages in the RTP Audio-Visual Profile "Codec Control Messages in the RTP Audio-Visual Profile
with Feedback (AVPF)", RFC 5104, February 2008. with Feedback (AVPF)", RFC 5104, February 2008.
[RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in [RFC5450] Singer, D. and H. Desineni, "Transmission Time Offsets in
RTP Streams", RFC 5450, March 2009. RTP Streams", RFC 5450, March 2009.
[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, April 2009. and Consequences", RFC 5506, April 2009.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, September 2009.
[RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP [RFC6051] Perkins, C. and T. Schierl, "Rapid Synchronisation of RTP
Flows", RFC 6051, November 2010. Flows", RFC 6051, November 2010.
[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, August 2012. for RTP over UDP", RFC 6679, August 2012.
[RFC6798] Clark, A. and Q. Wu, "RTP Control Protocol (RTCP) Extended [RFC6798] Clark, A. and Q. Wu, "RTP Control Protocol (RTCP) Extended
Report (XR) Block for Packet Delay Variation Metric Report (XR) Block for Packet Delay Variation Metric
Reporting", RFC 6798, November 2012. Reporting", RFC 6798, November 2012.
skipping to change at page 18, line 25 skipping to change at page 18, line 29
Reporting", RFC 7002, September 2013. Reporting", RFC 7002, September 2013.
[RFC7003] Clark, A., Huang, R., and Q. Wu, "RTP Control Protocol [RFC7003] Clark, A., Huang, R., and Q. Wu, "RTP Control Protocol
(RTCP) Extended Report (XR) Block for Burst/Gap Discard (RTCP) Extended Report (XR) Block for Burst/Gap Discard
Metric Reporting", RFC 7003, September 2013. Metric Reporting", RFC 7003, September 2013.
[RFC7097] Ott, J., Singh, V., and I. Curcio, "RTP Control Protocol [RFC7097] Ott, J., Singh, V., and I. Curcio, "RTP Control Protocol
(RTCP) Extended Report (XR) for RLE of Discarded Packets", (RTCP) Extended Report (XR) for RLE of Discarded Packets",
RFC 7097, January 2014. RFC 7097, January 2014.
[RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP
Sessions", RFC 7201, April 2014.
[Sarker] Sarker, Z., Singh, V., and C.S. Perkins, "An Evaluation of [Sarker] Sarker, Z., Singh, V., and C.S. Perkins, "An Evaluation of
RTP Circuit Breaker Performance on LTE Networks", RTP Circuit Breaker Performance on LTE Networks",
Proceedings of the IEEE Infocom workshop on Communication Proceedings of the IEEE Infocom workshop on Communication
and Networking Techniques for Contemporary Video, 2014, and Networking Techniques for Contemporary Video, 2014,
April 2014. April 2014.
[Singh] Singh, V., McQuistin, S., Ellis, M., and C.S. Perkins, [Singh] Singh, V., McQuistin, S., Ellis, M., and C.S. Perkins,
"Circuit Breakers for Multimedia Congestion Control", "Circuit Breakers for Multimedia Congestion Control",
Proceedings of the International Packet Video Workshop, Proceedings of the International Packet Video Workshop,
2013, DOI 10.1109/PV.2013.6691439, December 2013. 2013, DOI 10.1109/PV.2013.6691439, December 2013.
 End of changes. 15 change blocks. 
37 lines changed or deleted 44 lines changed or added

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