draft-ietf-avtcore-rtp-circuit-breakers-07.txt   draft-ietf-avtcore-rtp-circuit-breakers-08.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: April 30, 2015 October 27, 2014 Expires: June 07, 2015 December 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-07 draft-ietf-avtcore-rtp-circuit-breakers-08
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 April 30, 2015. This Internet-Draft will expire on June 07, 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 30 skipping to change at page 2, line 30
4. RTP Circuit Breakers for Systems Using the RTP/AVP Profile . 6 4. RTP Circuit Breakers for Systems Using the RTP/AVP Profile . 6
4.1. RTP/AVP Circuit Breaker #1: Media Timeout . . . . . . . . 8 4.1. RTP/AVP Circuit Breaker #1: Media Timeout . . . . . . . . 8
4.2. RTP/AVP Circuit Breaker #2: RTCP Timeout . . . . . . . . 8 4.2. RTP/AVP Circuit Breaker #2: RTCP Timeout . . . . . . . . 8
4.3. RTP/AVP Circuit Breaker #3: Congestion . . . . . . . . . 9 4.3. RTP/AVP Circuit Breaker #3: Congestion . . . . . . . . . 9
4.4. RTP/AVP Circuit Breaker #4: Media Usability . . . . . . . 13 4.4. RTP/AVP Circuit Breaker #4: Media Usability . . . . . . . 13
4.5. Ceasing Transmission . . . . . . . . . . . . . . . . . . 14 4.5. Ceasing Transmission . . . . . . . . . . . . . . . . . . 14
5. RTP Circuit Breakers for Systems Using the RTP/AVPF Profile . 14 5. RTP Circuit Breakers for Systems Using the RTP/AVPF Profile . 14
6. Impact of RTCP Extended Reports (XR) . . . . . . . . . . . . 15 6. Impact of RTCP Extended Reports (XR) . . . . . . . . . . . . 15
7. Impact of RTCP Reporting Groups . . . . . . . . . . . . . . . 15 7. Impact of RTCP Reporting Groups . . . . . . . . . . . . . . . 15
8. Impact of Explicit Congestion Notification (ECN) . . . . . . 16 8. Impact of Explicit Congestion Notification (ECN) . . . . . . 16
9. Impact of Layered Coding . . . . . . . . . . . . . . . . . . 16 9. Impact of Bundled Media and Layered Coding . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
14.1. Normative References . . . . . . . . . . . . . . . . . . 18 14.1. Normative References . . . . . . . . . . . . . . . . . . 18
14.2. Informative References . . . . . . . . . . . . . . . . . 18 14.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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
skipping to change at page 11, line 42 skipping to change at page 11, line 42
fraction of packets lost, and does not report when the packet losses fraction of packets lost, and does not report when the packet losses
occurred). Using the loss fraction in place of the loss event rate occurred). Using the loss fraction in place of the loss event rate
can overestimate the loss. We believe that this overestimate will can overestimate the loss. We believe that this overestimate will
not be significant, given that we are only interested in order of not be significant, given that we are only interested in order of
magnitude comparison ([Floyd] section 3.2.1 shows that the difference magnitude comparison ([Floyd] section 3.2.1 shows that the difference
is small for steady-state conditions and random loss, but using the is small for steady-state conditions and random loss, but using the
loss fraction is more conservative in the case of bursty loss). loss fraction is more conservative in the case of bursty loss).
The congestion circuit breaker is therefore: when a sender receives The congestion circuit breaker is therefore: when a sender receives
an RTCP SR or RR packet that contains a report block for an SSRC it an RTCP SR or RR packet that contains a report block for an SSRC it
is using, that sender has to check the fraction lost field in that is using, the sender MUST check the fraction lost field in the report
report block to determine if there is a non-zero packet loss rate. block to determine if there is a non-zero packet loss rate. If the
If the fraction lost field is zero, then continue sending as normal. fraction lost field is zero, then continue sending as normal. If the
If the fraction lost is greater than zero, then estimate the TCP fraction lost is greater than zero, then estimate the TCP throughput
throughput using the simplified equation above, and the measured R, p that would be achieved over the path using the chosen TCP throughput
(approximated by the fraction lost), and s. Compare this with the equation and the measured values of the round-trip time, R, the loss
actual sending rate. If the actual sending rate is more than ten event rate, p (as approximated by the fraction lost), and the packet
times the estimated sending rate derived from the TCP throughput size, s. Compare this with the actual sending rate. If the actual
equation for three consecutive RTCP reporting intervals, the sender sending rate has been more than ten times the TCP throughput estimate
SHOULD cease transmission (see Section 4.5). for three (or more) consecutive RTCP reporting intervals, then the
congestion circuit breaker is triggered.
Systems that usually send at a high data rate, but that can reduce When the congestion circuit breaker is triggered, the sender SHOULD
their data rate significantly (i.e., by at least a factor of ten), cease transmission (see Section 4.5). However, if the sender is able
MAY first reduce their sending rate to this lower value to see if to reduce its sending rate by a factor of (approximately) ten, then
this resolves the congestion, but MUST then cease transmission if the it MAY first reduce its sending rate by this factor (or some larger
problem does not resolve itself within a further two RTCP reporting amount) to see if that resolves the congestion. If the sending rate
intervals (see Section 4.5). An example of this might be a video is reduced in this way and the congestion circuit breaker triggers
conferencing system that backs off to sending audio only, before again after the next three RTCP reporting intervals, the sender MUST
completely dropping the call. If such a reduction in sending rate then cease transmission. An example of such a rate reduction might
resolves the congestion problem, the sender MAY gradually increase be a video conferencing system that backs off to sending audio only,
the rate at which it sends data after a reasonable amount of time has before completely dropping the call. If such a reduction in sending
passed, provided it takes care not to cause the problem to recur rate resolves the congestion problem, the sender MAY gradually
("reasonable" is intentionally not defined here). increase the rate at which it sends data after a reasonable amount of
time has passed, provided it takes care not to cause the problem to
recur ("reasonable" is intentionally not defined here).
The congestion circuit breaker depends on the fraction of RTP data The congestion circuit breaker depends on the fraction of RTP data
packets lost in a reporting interval. If the number of packets sent packets lost in a reporting interval. If the number of packets sent
in the reporting interval is too low, this statistic loses meaning, in the reporting interval is too low, this statistic loses meaning,
and it is possible that a sampling error can give the appearance of and it is possible that a sampling error can give the appearance of
high packet loss rates. Following the guidelines in [RFC5405], an high packet loss rates. Following the guidelines in [RFC5405], an
RTP sender that sends not more than one RTP packet per RTT MAY ignore RTP sender that sends not more than one RTP packet per RTT MAY ignore
a single trigger of the congestion circuit breaker, on the basis that a single trigger of the congestion circuit breaker, on the basis that
the packet loss rate estimate is unreliable with so few samples. the packet loss rate estimate is unreliable with so few samples.
However, if the congestion circuit breaker triggers again after the However, if the congestion circuit breaker triggers again after the
skipping to change at page 16, line 22 skipping to change at page 16, line 27
ECN-CE marked packets SHOULD be treated as if it were lost for the ECN-CE marked packets SHOULD be treated as if it 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. The count of
ECN-CE marked RTP packets is returned in RTCP XR ECN summary report 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. packets if support for ECN has been initiated for an RTP session.
9. Impact of Layered Coding 9. Impact of Bundled Media and Layered Coding
Layered coding is a method of encoding a single media stream into
disparate layers, such that a receiver can decode a subset of the
layers to vary the quality of the media. Layered coding is often
used to aid congestion control in group communication systems, where
a different subset of the layers is sent to each receiver, depending
on the available network capacity.
Media using layered coding can be transported within RTP in several
ways: each layer can be sent as a separate RTP session; each layer
can be sent using a separate SSRC within a single RTP session; or
each layer can be identified by some payload-specific header field,
with all layers being sent by a single SSRC within a single RTP
session. The choice depends on the features provided by the RTP
payload format for the layered encoding, and on the application
requirements.
The RTP circuit breaker operates on a per-RTP session basis. If a
layered encoding is split across multiple RTP sessions, then each
session MUST be treated independently for the RTP circuit breaker.
Within an RTP session, if an application that sends a layered media The RTP circuit breaker operates on a per-RTP session basis. An RTP
encoding using a single SSRC, with the layers identified using some sender that participates in several RTP sessions MUST treat each RTP
payload-specific mechanism, then it MUST apply the RTP circuit session independently with regards to the RTP circuit breaker.
breaker to that layered flow as a whole, considering RTCP feedback
for the SSRC sending the layered flow and applying the RTP circuit
breaker as usual.
Within an RTP session, if the layered coding is sent using several An RTP sender can generate several media streams within a single RTP
SSRC values within a single RTP session, the flows for those SSRCs session, with each stream using a different SSRC. This can happen if
MAY be treated together, so that a circuit breaker trigger for any bundled media are in use, when using simulcast, or when using layered
SSRC in the layered media flow causes the entire layered flow to media coding. By default, each SSRC will be treated independently by
either cease transmission or reduce its sending rate by a factor of the RTP circuit breaker. However, the sender MAY choose to treat the
ten. The intent of this is to allow a layered flow to reduce its flows (or a subset thereof) as a group, such that a circuit breaker
sending rate by dropping higher layers if the circuit breaker fails, trigger for one flow applies to the group of flows as a whole, and
rather than requiring the layer that triggered the RTP circuit either causes the entire group to cease transmission, or the sending
breaker to cease transmission (layers are additive in many layered rate of the group to reduce by a factor of ten, depending on the RTP
codecs, so forcing a lower layer to cease transmission while allowing circuit breaker triggered. Grouping flows in this way is expected to
higher layers to continue is pointless). be especially useful for layered flows sent using multiple SSRCs, as
it allows the layered flow to react as a whole, ceasing transmission
on the enhancement layers first to reduce sending rate if necessary,
rather than treating each layer independently.
10. Security Considerations 10. Security Considerations
The security considerations of [RFC3550] apply. The security considerations of [RFC3550] apply.
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
 End of changes. 10 change blocks. 
67 lines changed or deleted 50 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/