draft-ietf-avtcore-rtp-circuit-breakers-14.txt   draft-ietf-avtcore-rtp-circuit-breakers-15.txt 
AVTCORE Working Group C. Perkins AVTCORE Working Group C. 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 callstats.io Intended status: Standards Track callstats.io
Expires: September 18, 2016 March 17, 2016 Expires: November 1, 2016 April 30, 2016
Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions
draft-ietf-avtcore-rtp-circuit-breakers-14 draft-ietf-avtcore-rtp-circuit-breakers-15
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 these applications, then network congestion can is not implemented in these applications, then network congestion can
lead to uncontrolled packet loss, and a resulting deterioration of lead to uncontrolled packet loss, and a resulting deterioration of
the user's multimedia experience. The congestion control algorithm the user's multimedia experience. The congestion control algorithm
acts as a safety measure, stopping RTP flows from using excessive acts as a safety measure, stopping RTP flows from using excessive
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 18, 2016. This Internet-Draft will expire on November 1, 2016.
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 40 skipping to change at page 2, line 40
4.4. RTP/AVP Circuit Breaker #4: Media Usability . . . . . . . 15 4.4. RTP/AVP Circuit Breaker #4: Media Usability . . . . . . . 15
4.5. Ceasing Transmission . . . . . . . . . . . . . . . . . . 16 4.5. Ceasing Transmission . . . . . . . . . . . . . . . . . . 16
5. RTP Circuit Breakers and the RTP/AVPF and RTP/SAVPF Profiles 17 5. RTP Circuit Breakers and the RTP/AVPF and RTP/SAVPF Profiles 17
6. Impact of RTCP Extended Reports (XR) . . . . . . . . . . . . 18 6. Impact of RTCP Extended Reports (XR) . . . . . . . . . . . . 18
7. Impact of Explicit Congestion Notification (ECN) . . . . . . 19 7. Impact of Explicit Congestion Notification (ECN) . . . . . . 19
8. Impact of Bundled Media and Layered Coding . . . . . . . . . 19 8. Impact of Bundled Media and Layered Coding . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
12.1. Normative References . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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
skipping to change at page 16, line 51 skipping to change at page 16, line 51
intention is that the application will stop sending RTP data packets intention is that the application will stop sending RTP data packets
to a particular destination 3-tuple (transport protocol, destination to a particular destination 3-tuple (transport protocol, destination
port, IP address), until the user makes an explicit attempt to port, IP address), until the user makes an explicit attempt to
restart the call. It is important that a human user is involved in restart the call. It is important that a human user is involved in
the decision to try to restart the call, since that user will the decision to try to restart the call, since that user will
eventually give up if the calls repeatedly trigger the circuit eventually give up if the calls repeatedly trigger the circuit
breaker. This will help avoid problems with automatic redial systems breaker. This will help avoid problems with automatic redial systems
from congesting the network. Accordingly, RTP flows halted by the from congesting the network. Accordingly, RTP flows halted by the
circuit breaker SHOULD NOT be restarted automatically unless the circuit breaker SHOULD NOT be restarted automatically unless the
sender has received information that the congestion has dissipated, sender has received information that the congestion has dissipated,
or can reasonably be expected to have dissipated. This is or can reasonably be expected to have dissipated. What could trigger
necessarily application dependent, but could be, for example, an this expectation is necessarily application dependent, but could be,
indication that a competing flow has finished, freeing up some for example, an indication that a competing flow has finished and
capacity, or that the device has moved so the flow would traverse a freed up some capacity, or -- for an application that is running on a
different path if restarted. mobile device -- that the device moved to a new location so the flow
would traverse a different path if restarted.
It is recognised that the RTP implementation in some systems might It is recognised that the RTP implementation in some systems might
not be able to determine if a call set-up request was initiated by a not be able to determine if a call set-up request was initiated by a
human user, or automatically by some scripted higher-level component human user, or automatically by some scripted higher-level component
of the system. These implementations MUST rate limit attempts to of the system. These implementations MUST rate limit attempts to
restart a call to the same destination 3-tuple as used by a call that restart a call to the same destination 3-tuple as used by a call that
triggered the circuit breaker, so that the reaction to a triggered triggered the circuit breaker, so that the reaction to a triggered
circuit breaker lasts for at least the triggering interval circuit breaker lasts for at least the triggering interval
[I-D.ietf-tsvwg-circuit-breaker]. The chosen rate limit ought to not [I-D.ietf-tsvwg-circuit-breaker]. The chosen rate limit ought to not
exceed the rate at which an annoyed human caller might redial a exceed the rate at which an annoyed human caller might redial a
skipping to change at page 19, line 12 skipping to change at page 19, line 12
SR packets, RTCP RR packets, or RTCP XR ECN Summary Report packets, SR packets, RTCP RR packets, or RTCP XR ECN Summary Report packets,
are used by the RTP circuit breaker algorithm. are used by the RTP circuit breaker algorithm.
7. Impact of Explicit Congestion Notification (ECN) 7. Impact of Explicit Congestion Notification (ECN)
The use of ECN for RTP flows does not affect the media timeout RTP The use of ECN for RTP flows does not affect the media timeout RTP
circuit breaker (Section 4.2) or the RTCP timeout circuit breaker circuit breaker (Section 4.2) or the RTCP timeout circuit breaker
(Section 4.1), since these are both connectivity checks that simply (Section 4.1), since these are both connectivity checks that simply
determinate if any packets are being received. determinate if any packets are being received.
ECN-CE marked packets SHOULD be treated as if it were lost for the ECN-CE marked packets SHOULD be treated as if they were lost for the
purposes of congestion control, when determining the optimal media purposes of congestion control, when determining the optimal media
sending rate for an RTP flow. If an RTP sender has negotiated ECN sending rate for an RTP flow. If an RTP sender has negotiated ECN
support for an RTP session, and has successfully initiated ECN use on support for an RTP session, and has successfully initiated ECN use on
the path to the receiver [RFC6679], then ECN-CE marked packets SHOULD the path to the receiver [RFC6679], then ECN-CE marked packets SHOULD
be treated as if they were lost when calculating if the congestion- be treated as if they were lost when calculating if the congestion-
based RTP circuit breaker (Section 4.3) has been met. The count of based RTP circuit breaker (Section 4.3) has been met, unless the RTP
ECN-CE marked RTP packets is returned in RTCP XR ECN summary report implementation can determine that the ECN-CE marking on this path is
packets if support for ECN has been initiated for an RTP session. not reliable. The count of ECN-CE marked RTP packets is returned in
RTCP XR ECN summary report packets if support for ECN has been
initiated for an RTP session.
8. Impact of Bundled Media and Layered Coding 8. Impact of Bundled Media and Layered Coding
The RTP circuit breaker operates on a per-RTP session basis. An RTP The RTP circuit breaker operates on a per-RTP session basis. An RTP
sender that participates in several RTP sessions MUST treat each RTP sender that participates in several RTP sessions MUST treat each RTP
session independently with regards to the RTP circuit breaker. session independently with regards to the RTP circuit breaker.
An RTP sender can generate several media streams within a single RTP An RTP sender can generate several media streams within a single RTP
session, with each stream using a different SSRC. This can happen if session, with each stream using a different SSRC. This can happen if
bundled media are in use, when using simulcast, or when using layered bundled media are in use, when using simulcast, or when using layered
skipping to change at page 20, line 41 skipping to change at page 20, line 41
session bandwidth and RTCP bandwidth fraction) when using the RTP session bandwidth and RTCP bandwidth fraction) when using the RTP
circuit breaker, as discussed in Section 4.3. circuit breaker, as discussed in Section 4.3.
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,
Gorry Fairhurst, Nazila Fough, Kevin Gross, Cullen Jennings, Randell Spencer Dawkins, Gorry Fairhurst, Nazila Fough, Kevin Gross, Cullen
Jesup, Jonathan Lennox, Matt Mathis, Stephen McQuistin, Simon Jennings, Randell Jesup, Jonathan Lennox, Matt Mathis, Stephen
Perreault, Eric Rescorla, Abheek Saha, Meral Shirazipour, Fabio McQuistin, Simon Perreault, Eric Rescorla, Abheek Saha, Meral
Verdicchio, and Magnus Westerlund for their valuable feedback. Shirazipour, Fabio Verdicchio, and Magnus Westerlund for their
valuable feedback.
12. References 12. References
12.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,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[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 22, line 7 skipping to change at page 22, line 13
conference, 2000, DOI 10.1145/347059.347397, August 2000. conference, 2000, DOI 10.1145/347059.347397, August 2000.
[I-D.ietf-avtcore-rtp-multi-stream] [I-D.ietf-avtcore-rtp-multi-stream]
Lennox, J., Westerlund, M., Wu, Q., and C. Perkins, Lennox, J., Westerlund, M., Wu, Q., and C. Perkins,
"Sending Multiple RTP Streams in a Single RTP Session", "Sending Multiple RTP Streams in a Single RTP Session",
draft-ietf-avtcore-rtp-multi-stream-11 (work in progress), draft-ietf-avtcore-rtp-multi-stream-11 (work in progress),
December 2015. December 2015.
[I-D.ietf-tsvwg-circuit-breaker] [I-D.ietf-tsvwg-circuit-breaker]
Fairhurst, G., "Network Transport Circuit Breakers", Fairhurst, G., "Network Transport Circuit Breakers",
draft-ietf-tsvwg-circuit-breaker-13 (work in progress), draft-ietf-tsvwg-circuit-breaker-15 (work in progress),
February 2016. April 2016.
[I-D.ietf-tsvwg-rtcweb-qos] [I-D.ietf-tsvwg-rtcweb-qos]
Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP
and other packet markings for WebRTC QoS", draft-ietf- and other packet markings for WebRTC QoS", draft-ietf-
tsvwg-rtcweb-qos-14 (work in progress), March 2016. tsvwg-rtcweb-qos-15 (work in progress), March 2016.
[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 algorithm", ACM SIGCOMM Computer Communication
Review 27(3), DOI 10.1145/263932.264023, July 1997. Review 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 Validation", Proceedings of the ACM SIGCOMM
conference, 1998, DOI 10.1145/285237.285291, August 1998. conference, 1998, DOI 10.1145/285237.285291, August 1998.
 End of changes. 11 change blocks. 
21 lines changed or deleted 24 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/