draft-ietf-avtcore-ecn-for-rtp-05.txt   draft-ietf-avtcore-ecn-for-rtp-06.txt 
Network Working Group M. Westerlund Network Working Group M. Westerlund
Internet-Draft I. Johansson Internet-Draft I. Johansson
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: May 3, 2012 C. Perkins Expires: August 20, 2012 C. Perkins
University of Glasgow University of Glasgow
P. O'Hanlon P. O'Hanlon
UCL UCL
K. Carlberg K. Carlberg
G11 G11
October 31, 2011 February 17, 2012
Explicit Congestion Notification (ECN) for RTP over UDP Explicit Congestion Notification (ECN) for RTP over UDP
draft-ietf-avtcore-ecn-for-rtp-05 draft-ietf-avtcore-ecn-for-rtp-06
Abstract Abstract
This memo specifies how Explicit Congestion Notification (ECN) can be This memo specifies how Explicit Congestion Notification (ECN) can be
used with the Real-time Transport Protocol (RTP) running over UDP, used with the Real-time Transport Protocol (RTP) running over UDP,
using RTP Control Protocol (RTCP) as a feedback mechanism. It using RTP Control Protocol (RTCP) as a feedback mechanism. It
defines a new RTCP Extended Report (XR) block for periodic ECN defines a new RTCP Extended Report (XR) block for periodic ECN
feedback, a new RTCP transport feedback message for timely reporting feedback, a new RTCP transport feedback message for timely reporting
of congestion events, and a Session Traversal Utilities for NAT of congestion events, and a Session Traversal Utilities for NAT
(STUN) extension used in the optional initialization method using (STUN) extension used in the optional initialization method using
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 3, 2012. This Internet-Draft will expire on August 20, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 14 skipping to change at page 3, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 5 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 5
3. Discussion, Requirements, and Design Rationale . . . . . . . . 6 3. Discussion, Requirements, and Design Rationale . . . . . . . . 6
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Interoperability . . . . . . . . . . . . . . . . . . . . . 12 3.3. Interoperability . . . . . . . . . . . . . . . . . . . . . 12
4. Overview of Use of ECN with RTP/UDP/IP . . . . . . . . . . . . 13 4. Overview of Use of ECN with RTP/UDP/IP . . . . . . . . . . . . 13
5. RTCP Extensions for ECN feedback . . . . . . . . . . . . . . . 15 5. RTCP Extensions for ECN feedback . . . . . . . . . . . . . . . 16
5.1. RTP/AVPF Transport Layer ECN Feedback packet . . . . . . . 16 5.1. RTP/AVPF Transport Layer ECN Feedback packet . . . . . . . 16
5.2. RTCP XR Report block for ECN summary information . . . . . 19 5.2. RTCP XR Report block for ECN summary information . . . . . 19
6. SDP Signalling Extensions for ECN . . . . . . . . . . . . . . 21 6. SDP Signalling Extensions for ECN . . . . . . . . . . . . . . 21
6.1. Signalling ECN Capability using SDP . . . . . . . . . . . 21 6.1. Signalling ECN Capability using SDP . . . . . . . . . . . 21
6.2. RTCP ECN Feedback SDP Parameter . . . . . . . . . . . . . 25 6.2. RTCP ECN Feedback SDP Parameter . . . . . . . . . . . . . 25
6.3. XR Block ECN SDP Parameter . . . . . . . . . . . . . . . . 25 6.3. XR Block ECN SDP Parameter . . . . . . . . . . . . . . . . 25
6.4. ICE Parameter to Signal ECN Capability . . . . . . . . . . 26 6.4. ICE Parameter to Signal ECN Capability . . . . . . . . . . 26
7. Use of ECN with RTP/UDP/IP . . . . . . . . . . . . . . . . . . 26 7. Use of ECN with RTP/UDP/IP . . . . . . . . . . . . . . . . . . 26
7.1. Negotiation of ECN Capability . . . . . . . . . . . . . . 26 7.1. Negotiation of ECN Capability . . . . . . . . . . . . . . 26
7.2. Initiation of ECN Use in an RTP Session . . . . . . . . . 27 7.2. Initiation of ECN Use in an RTP Session . . . . . . . . . 27
7.3. Ongoing Use of ECN Within an RTP Session . . . . . . . . . 34 7.3. Ongoing Use of ECN Within an RTP Session . . . . . . . . . 34
7.4. Detecting Failures . . . . . . . . . . . . . . . . . . . . 37 7.4. Detecting Failures . . . . . . . . . . . . . . . . . . . . 37
8. Processing ECN in RTP Translators and Mixers . . . . . . . . . 40 8. Processing ECN in RTP Translators and Mixers . . . . . . . . . 41
8.1. Transport Translators . . . . . . . . . . . . . . . . . . 40 8.1. Transport Translators . . . . . . . . . . . . . . . . . . 41
8.2. Fragmentation and Reassembly in Translators . . . . . . . 41 8.2. Fragmentation and Reassembly in Translators . . . . . . . 41
8.3. Generating RTCP ECN Feedback in Media Transcoders . . . . 43 8.3. Generating RTCP ECN Feedback in Media Transcoders . . . . 44
8.4. Generating RTCP ECN Feedback in Mixers . . . . . . . . . . 44 8.4. Generating RTCP ECN Feedback in Mixers . . . . . . . . . . 45
9. Implementation considerations . . . . . . . . . . . . . . . . 44 9. Implementation considerations . . . . . . . . . . . . . . . . 45
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
10.1. SDP Attribute Registration . . . . . . . . . . . . . . . . 45 10.1. SDP Attribute Registration . . . . . . . . . . . . . . . . 46
10.2. RTP/AVPF Transport Layer Feedback Message . . . . . . . . 45 10.2. RTP/AVPF Transport Layer Feedback Message . . . . . . . . 46
10.3. RTCP Feedback SDP Parameter . . . . . . . . . . . . . . . 46 10.3. RTCP Feedback SDP Parameter . . . . . . . . . . . . . . . 46
10.4. RTCP XR Report blocks . . . . . . . . . . . . . . . . . . 46 10.4. RTCP XR Report blocks . . . . . . . . . . . . . . . . . . 46
10.5. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 46 10.5. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 47
10.6. STUN attribute . . . . . . . . . . . . . . . . . . . . . . 46 10.6. STUN attribute . . . . . . . . . . . . . . . . . . . . . . 47
10.7. ICE Option . . . . . . . . . . . . . . . . . . . . . . . . 46 10.7. ICE Option . . . . . . . . . . . . . . . . . . . . . . . . 47
11. Security Considerations . . . . . . . . . . . . . . . . . . . 46 11. Security Considerations . . . . . . . . . . . . . . . . . . . 47
12. Examples of SDP Signalling . . . . . . . . . . . . . . . . . . 49 12. Examples of SDP Signalling . . . . . . . . . . . . . . . . . . 50
12.1. Basic SDP Offer/Answer . . . . . . . . . . . . . . . . . . 49 12.1. Basic SDP Offer/Answer . . . . . . . . . . . . . . . . . . 50
12.2. Declarative Multicast SDP . . . . . . . . . . . . . . . . 51 12.2. Declarative Multicast SDP . . . . . . . . . . . . . . . . 51
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
14.1. Normative References . . . . . . . . . . . . . . . . . . . 52 14.1. Normative References . . . . . . . . . . . . . . . . . . . 52
14.2. Informative References . . . . . . . . . . . . . . . . . . 53 14.2. Informative References . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
This memo outlines how Explicit Congestion Notification (ECN) This memo outlines how Explicit Congestion Notification (ECN)
skipping to change at page 7, line 18 skipping to change at page 7, line 18
supports Source Specific Multicast (SSM) [RFC3569] with unicast supports Source Specific Multicast (SSM) [RFC3569] with unicast
feedback [RFC5760]). feedback [RFC5760]).
Application Awareness: When ECN support is provided within the Application Awareness: When ECN support is provided within the
transport protocol, the ability of the application to react to transport protocol, the ability of the application to react to
congestion is limited, since it has little visibility into the congestion is limited, since it has little visibility into the
transport layer. By adding support of ECN to RTP using RTCP transport layer. By adding support of ECN to RTP using RTCP
feedback, the application is made aware of congestion, allowing a feedback, the application is made aware of congestion, allowing a
wider range of reactions in response to that loss. wider range of reactions in response to that loss.
Counting vs Detecting Congestion: TCP and the protocols derived from Counting vs Detecting Congestion: TCP, and the protocols derived
it are mainly designed to respond the same whether they experience from, it are mainly designed to respond in the same way whether
a burst of congestion indications within one RTT or just one. they experience a burst of congestion indications within one RTT,
Whereas real-time applications may be concerned with the amount of or just a single congestion indication. Whereas real-time
congestion experienced, whether it is distributed smoothly or in applications may be concerned with the amount of congestion
bursts. When feedback of ECN was added to TCP [RFC3168], the experienced, whether it is distributed smoothly or in bursts.
receiver was designed to flip the echo congestion experienced When feedback of ECN was added to TCP [RFC3168], the receiver was
(ECE) flag to 1 for a whole RTT then flop it back to zero. designed to flip the echo congestion experienced (ECE) flag to 1
Whereas ECN feedback in RTCP will need to report a count of how for a whole RTT then flop it back to zero. Whereas ECN feedback
much congestion has been experienced within an RTCP reporting in RTCP will need to report a count of how much congestion has
period, irrespective of round trip times. been experienced within an RTCP reporting period, irrespective of
round trip times.
These differences will significantly alter the shape of ECN support These differences will significantly alter the shape of ECN support
in RTP-over-UDP compared to ECN support in TCP, SCTP, and DCCP, but in RTP-over-UDP compared to ECN support in TCP, SCTP, and DCCP, but
do not invalidate the need for ECN support. do not invalidate the need for ECN support.
ECN support is more important for RTP sessions than, for instance, is ECN support is more important for RTP sessions than, for instance, is
the case for TCP. This is because the impact of packet loss in real- the case for TCP. This is because the impact of packet loss in real-
time audio-visual media flows is highly visible to users. Effective time audio-visual media flows is highly visible to users. Effective
ECN support for RTP flows running over UDP will allow real-time ECN support for RTP flows running over UDP will allow real-time
audio-visual applications to respond to the onset of congestion audio-visual applications to respond to the onset of congestion
skipping to change at page 10, line 5 skipping to change at page 10, line 5
senders that provides traffic to the distribution source (DS) and senders that provides traffic to the distribution source (DS) and
are separated from the DS. There can also be multiple feedback are separated from the DS. There can also be multiple feedback
targets. The requirement for using ECN for RTP in this topology targets. The requirement for using ECN for RTP in this topology
is that the media sender must be provided the feedback from the is that the media sender must be provided the feedback from the
receivers, it may be in aggregated form from the feedback targets. receivers, it may be in aggregated form from the feedback targets.
We will not mention this SSM use case in the below text We will not mention this SSM use case in the below text
specifically, but when actions are required by the media source, specifically, but when actions are required by the media source,
they do apply also to case of SSM where the RTCP feedback goes to they do apply also to case of SSM where the RTCP feedback goes to
the Feedback Target. the Feedback Target.
This specification do support multicast, but has primarily The mechanisms defined in this memo support multicast groups, but
considered smaller multicast groups and is not optimized for are known to be conservative, and don't scale to large groups.
larger groups and their needs. This is primarily because we require all members of the group to
demonstrate that they can make use of ECN before the sender is
allowed to send ECN-marked packets, since allowing some non-ECN
capable receivers causes fairness issues when the bottleneck link
is shared by ECN and non-ECN flows that we have not (yet) been
able to satisfactorily address. The rules regarding Determination
of ECN Support in Section 7.2.1 may be relaxed in a future version
of this specification to improve scaling once these issues have
been resolved.
Topo-Translator: An RTP translator is an RTP-level middlebox that is Topo-Translator: An RTP translator is an RTP-level middlebox that is
invisible to the other participants in the RTP session (although invisible to the other participants in the RTP session (although
it is usually visible in the associated signalling session). it is usually visible in the associated signalling session).
There are two types of RTP translator: those that do not modify There are two types of RTP translator: those that do not modify
the media stream, and are concerned with transport parameters, for the media stream, and are concerned with transport parameters, for
example a multicast to unicast gateway; and those that do modify example a multicast to unicast gateway; and those that do modify
the media stream, for example transcoding between different media the media stream, for example transcoding between different media
codecs. A single RTP session traverses the translator, and the codecs. A single RTP session traverses the translator, and the
translator must rewrite RTCP messages passing through it to match translator must rewrite RTCP messages passing through it to match
skipping to change at page 13, line 42 skipping to change at page 14, line 6
which don't pass ECN-marked packets (for example, a firewall that which don't pass ECN-marked packets (for example, a firewall that
blocks traffic with the ECN bits set). This document defines the blocks traffic with the ECN bits set). This document defines the
information that needs to be negotiated, and provides a mapping to information that needs to be negotiated, and provides a mapping to
SDP for use in both declarative and offer/answer contexts. SDP for use in both declarative and offer/answer contexts.
When a sender joins a session for which all participants claim to When a sender joins a session for which all participants claim to
support ECN, it must verify if that support is usable. There are support ECN, it must verify if that support is usable. There are
three ways in which this verification can be done: three ways in which this verification can be done:
o The sender may generate a (small) subset of its RTP data packets o The sender may generate a (small) subset of its RTP data packets
with the ECN field set to ECT(0) or ECT(1). Each receiver will with the ECN field of the IP header set to ECT(0) or ECT(1). Each
then send an RTCP feedback packet indicating the reception of the receiver will then send an RTCP feedback packet indicating the
ECT marked RTP packets. Upon reception of this feedback from each reception of the ECT marked RTP packets. Upon reception of this
receiver it knows of, the sender can consider ECN functional for feedback from each receiver it knows of, the sender can consider
its traffic. Each sender does this verification independently. ECN functional for its traffic. Each sender does this
When a new receiver joins an existing RTP session, it will send verification independently. When a new receiver joins an existing
RTCP reports in the usual manner. If those RTCP reports include RTP session, it will send RTCP reports in the usual manner. If
ECN information, verification will have succeeded and sources can those RTCP reports include ECN information, verification will have
continue to send ECT packets. If not, verification fails and each succeeded and sources can continue to send ECT packets. If not,
sender MUST stop using ECN (see Section 7.2.1 for details). verification fails and each sender MUST stop using ECN (see
Section 7.2.1 for details).
o Alternatively, ECN support can be verified during an initial end- o Alternatively, ECN support can be verified during an initial end-
to-end STUN exchange (for example, as part of ICE connection to-end STUN exchange (for example, as part of ICE connection
establishment). After having verified connectivity without ECN establishment). After having verified connectivity without ECN
capability an extra STUN exchange, this time with the ECN field capability an extra STUN exchange, this time with the ECN field
set to ECT(0) or ECT(1), is performed on the candidate path that set to ECT(0) or ECT(1), is performed on the candidate path that
is about to be used. If successful the path's capability to is about to be used. If successful the path's capability to
convey ECN marked packets is verified. A new STUN attribute is convey ECN marked packets is verified. A new STUN attribute is
defined to convey feedback that the ECT marked STUN request was defined to convey feedback that the ECT marked STUN request was
received (see Section 7.2.2), along with an ICE signalling option received (see Section 7.2.2), along with an ICE signalling option
skipping to change at page 15, line 49 skipping to change at page 16, line 12
ECN-CE marked and lost packets. If these numbers do not agree, it ECN-CE marked and lost packets. If these numbers do not agree, it
can be inferred that the path does not reliably pass ECN-marked can be inferred that the path does not reliably pass ECN-marked
packets. A sender detecting a possible ECN non-compliance issue packets. A sender detecting a possible ECN non-compliance issue
should then stop sending ECT marked packets to determine if that should then stop sending ECT marked packets to determine if that
allows the packets to be correctly delivered. If the issues can be allows the packets to be correctly delivered. If the issues can be
connected to ECN, then ECN usage is suspended. connected to ECN, then ECN usage is suspended.
5. RTCP Extensions for ECN feedback 5. RTCP Extensions for ECN feedback
This memo defines two new RTCP extensions: one RTP/AVPF [RFC4585] This memo defines two new RTCP extensions: one RTP/AVPF [RFC4585]
transport layer feedback format for urgent ECN information, and one transport layer feedback format for reporting urgent ECN information,
RTCP XR [RFC3611] ECN summary report block type for regular reporting and one RTCP XR [RFC3611] ECN summary report block type for regular
of the ECN marking information. reporting of the ECN marking information.
5.1. RTP/AVPF Transport Layer ECN Feedback packet 5.1. RTP/AVPF Transport Layer ECN Feedback packet
This RTP/AVPF transport layer feedback format is intended for use in This RTP/AVPF transport layer feedback format is intended for use in
RTP/AVPF early or immediate feedback modes when information needs to RTP/AVPF early or immediate feedback modes when information needs to
urgently reach the sender. Thus its main use is to report reception urgently reach the sender. Thus its main use is to report reception
of an ECN-CE marked RTP packet so that the sender may perform of an ECN-CE marked RTP packet so that the sender may perform
congestion control, or to speed up the initiation procedures by congestion control, or to speed up the initiation procedures by
rapidly reporting that the path can support ECN-marked traffic. The rapidly reporting that the path can support ECN-marked traffic. The
feedback format is also defined with reduced size RTCP [RFC5506] in feedback format is also defined with reduced size RTCP [RFC5506] in
skipping to change at page 27, line 22 skipping to change at page 27, line 22
capability to use ECN within a session, they may attempt to initiate capability to use ECN within a session, they may attempt to initiate
ECN use. All session participants connected over the same transport ECN use. All session participants connected over the same transport
MUST use the same initiation method. RTP mixers or translators can MUST use the same initiation method. RTP mixers or translators can
use different initiation methods to different participants that are use different initiation methods to different participants that are
connected over different underlying transports. The mixer or connected over different underlying transports. The mixer or
translator will need to do individual signalling with each translator will need to do individual signalling with each
participant to ensure it is consistent with the ECN support in those participant to ensure it is consistent with the ECN support in those
cases where it does not function as one end-point for the ECN control cases where it does not function as one end-point for the ECN control
loop. loop.
At the start of the RTP session, when the first packets with ECT are At the start of the RTP session, when the first few packets with ECT
sent, it is important to verify that IP packets with ECN field values are sent, it is important to verify that IP packets with ECN field
of ECT or ECN-CE will reach their destination(s). There is some risk values of ECT or ECN-CE will reach their destination(s). There is
that the use of ECN will result in either reset of the ECN field, or some risk that the use of ECN will result in either reset of the ECN
loss of all packets with ECT or ECN-CE markings. If the path between field, or loss of all packets with ECT or ECN-CE markings. If the
the sender and the receivers exhibits either of these behaviours one path between the sender and the receivers exhibits either of these
needs to stop using ECN immediately to protect both the network and behaviours, the sender needs to stop using ECN immediately to protect
the application. both the network and the application.
The RTP senders and receivers SHALL NOT ECT mark their RTCP traffic The RTP senders and receivers SHALL NOT ECT mark their RTCP traffic
at any time. This is to ensure that packet loss due to ECN marking at any time. This is to ensure that packet loss due to ECN marking
will not effect the RTCP traffic and the necessary feedback will not effect the RTCP traffic and the necessary feedback
information it carries. information it carries.
An RTP system that supports ECN MUST implement the initiation of ECN An RTP system that supports ECN MUST implement the initiation of ECN
using in-band RTP and RTCP described in Section 7.2.1. It MAY also using in-band RTP and RTCP described in Section 7.2.1. It MAY also
implement other mechanisms to initiate ECN support, for example the implement other mechanisms to initiate ECN support, for example the
STUN-based mechanism described in Section 7.2.2, or use the leap of STUN-based mechanism described in Section 7.2.2, or use the leap of
skipping to change at page 31, line 18 skipping to change at page 31, line 18
distribute received packets to more than one other receiver must distribute received packets to more than one other receiver must
either disallow this method (and use the RTP/RTCP method instead), or either disallow this method (and use the RTP/RTCP method instead), or
implement additional handling as discussed below. This is because implement additional handling as discussed below. This is because
the ICE initialization method verifies the underlying transport to the ICE initialization method verifies the underlying transport to
one particular address and port. If the receiver at that address and one particular address and port. If the receiver at that address and
port intends to use the received packets in a multi-point session port intends to use the received packets in a multi-point session
then the tested capabilities and the actual session behavior are not then the tested capabilities and the actual session behavior are not
matched. matched.
To minimise the impact of set-up delay, and to prioritise the fact To minimise the impact of set-up delay, and to prioritise the fact
that one has a working connectivity rather than necessarily finding that one has working connectivity rather than necessarily finding the
the best ECN capable network path, this procedure is applied after best ECN capable network path, this procedure is applied after having
having performed a successful connectivity check for a candidate, performed a successful connectivity check for a candidate, which is
which is nominated for usage. At that point an additional nominated for usage. At that point an additional connectivity check
connectivity check is performed, sending the "ECN Check" attribute in is performed, sending the "ECN Check" attribute in a STUN packet that
a STUN packet that is ECT marked. On reception of the packet, a STUN is ECT marked. On reception of the packet, a STUN server supporting
server supporting this extension will note the received ECN field this extension will note the received ECN field value, and send a
value, and send a STUN/UDP/IP packet in reply with the ECN field set STUN/UDP/IP packet in reply with the ECN field set to not-ECT and
to not-ECT and including an ECN check attribute. A STUN server that including an ECN check attribute. A STUN server that doesn't
doesn't understand the extension, or is incapable of reading the ECN understand the extension, or is incapable of reading the ECN values
values on incoming STUN packets, should follow the rule in the STUN on incoming STUN packets, should follow the rule in the STUN
specification for unknown comprehension-optional attributes, and specification for unknown comprehension-optional attributes, and
ignore the attribute, resulting in the sender receiving a STUN ignore the attribute, resulting in the sender receiving a STUN
response without the ECN Check STUN attribute. response without the ECN Check STUN attribute.
The ECN STUN checks can be lost on the path, for example due to the The ECN STUN checks can be lost on the path, for example due to the
ECT marking, but also various other non ECN related reasons causing ECT marking, but also due to various other non ECN related reasons
packet loss. The goal is to detect when the ECT markings are causing packet loss. The goal is to detect when the ECT markings are
rewritten or if it is the ECT marking that causes packet loss so that rewritten or if it is the ECT marking that causes packet loss so that
the path can be determined as not ECT. Other reasons for packet loss the path can be determined as not ECT. Other reasons for packet loss
should not result in a failure to verify the path as ECT. Therefore should not result in a failure to verify the path as ECT. Therefore
a number of retransmissions should be attempted. But, the sender of a number of retransmissions should be attempted. But, the sender of
ECN STUN checks will also have to set a criteria for when it gives up ECN STUN checks will also have to set a criteria for when it gives up
testing for ECN capability on the path. As the ICE agent have testing for ECN capability on the path. Since the ICE agent has
successfully verified the path a RTT measurement for this path can be successfully verified the path an RTT measurement for this path can
performed. To have high probability of succesfully verifying the be performed. To have a high probability of successfully verifying
path it is RECOMMENDED that the client retransmitt the ECN STUN check the path it is RECOMMENDED that the client retransmit the ECN STUN
4 times. The interval between the retransmissions will be based on check at least 4 times. The transmission for that flow is stopped
the Ta timer as defined in Section 16.1 for RTP Media Streams in ICE when an ECN Check STUN response has been received, which doesn't
[RFC5245]. The number of ECN STUN checks needing to be sent will indicate a retransmission of the request due to a temporary error, or
depend on the number of ECN capable flows (N) that is to be the maximum number of retransmissions has been sent. The ICE agent
established. The interval between each transmission of an ECN check is recommended to give up on the ECN verification MAX(1.5*RTT, 20 ms)
packet MUST be Ta. In other words for a given flow being verified
for ECT the RTO is set to Ta*N. The transmission for that flow is
stopped when an ECN Check STUN response has been received, which
don't indicate to retransmit the request due to temporary error, the
maximum number of retransmissions has been sent. The ICE agent is
recommended to give up on the ECN verification MAX(1.5*RTT, 20 ms)
after the last ECN STUN check was sent. after the last ECN STUN check was sent.
The transmission of the ECT marked STUN connectivity checks
containing the ECN Check attribute can be done prior as well in
parallel to actual media transmission. Both cases are supported,
where the main difference is how aggressively the transmission of the
STUN checks are done. The reason for this is to avoid adding
additional startup delay until media can flow. If media is required
immeditely after nomination has occured the STUN checks SHALL be done
in parallel. If the application does not require media transmission
immediately the verification of ECT SHOULD start using the aggresive
mode. At any point in the process until ECT has been verified or
found to not work media transmission MAY be started and the ICE agent
SHALL transition from the aggressive mode to the parallel mode.
The aggressive mode uses an interval between the retransmissions be
based on the Ta timer as defined in Section 16.1 for RTP Media
Streams in ICE [RFC5245]. The number of ECN STUN checks needing to
be sent will depend on the number of ECN capable flows (N) that is to
be established. The interval between each transmission of an ECN
check packet MUST be Ta. In other words for a given flow being
verified for ECT the RTO is set to Ta*N.
The parallel mode uses transmission intervals that targets that the
bit-rate increase due to the ECT verification checks shall not
increase the total bit-rate more than 10% in addition to the media.
As ICE's regular transmission schedule is mimicking a common voice
call in amount, to meet that goal for most media flows, setting the
retransmission interval to Ta*N*k where k=10 fulfills that goal.
Thus the default behavior SHALL be to use k=10 when in parallel mode.
In cases where the bit-rate of the STUN connectivity checks can be
determined they MAY be sent with smaller values of k, but k MUST NOT
be smaller than 1, as long as the total bit-rate for the connectivity
checks are less than 10% of the used media bit-rate. The RTP media
packets being sent in parallel mode SHALL NOT be ECT marked prior to
verification of the path as ECT.
The STUN ECN check attribute contains one field and a flag, as shown The STUN ECN check attribute contains one field and a flag, as shown
in Figure 6. The flag indicates whether the echo field contains a in Figure 6. The flag indicates whether the echo field contains a
valid value or not. The field is the ECN echo field, and when valid valid value or not. The field is the ECN echo field, and when valid
contains the two ECN bits from the packet it echoes back. The ECN contains the two ECN bits from the packet it echoes back. The ECN
check attribute is a comprehension optional attribute. check attribute is a comprehension optional attribute.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 34, line 24 skipping to change at page 34, line 50
7.3.1. Transmission of ECT-marked RTP Packets 7.3.1. Transmission of ECT-marked RTP Packets
After a sender has successfully initiated ECN use, it SHOULD mark all After a sender has successfully initiated ECN use, it SHOULD mark all
the RTP data packets it sends as ECT. The sender SHOULD mark packets the RTP data packets it sends as ECT. The sender SHOULD mark packets
as ECT(0) unless the receiver expresses a preference for ECT(1) or as ECT(0) unless the receiver expresses a preference for ECT(1) or
random using the "ect" parameter in the "a=ecn-capable-rtp" random using the "ect" parameter in the "a=ecn-capable-rtp"
attribute. attribute.
The sender SHALL NOT include ECT marks on outgoing RTCP packets, and The sender SHALL NOT include ECT marks on outgoing RTCP packets, and
SHOULD NOT include ECT marks on any other outgoing control messages SHOULD NOT include ECT marks on any other outgoing control messages
(e.g., STUN [RFC5389] packets, DTLS [RFC4347] handshake packets, or (e.g., STUN [RFC5389] packets, DTLS [RFC6347] handshake packets, or
ZRTP [RFC6189] control packets) that are multiplexed on the same UDP ZRTP [RFC6189] control packets) that are multiplexed on the same UDP
port. For control packets there might be exceptions, like the STUN port. For control packets there might be exceptions, like the STUN
based ECN check defined in Section 7.2.2. based ECN check defined in Section 7.2.2.
7.3.2. Reporting ECN Feedback via RTCP 7.3.2. Reporting ECN Feedback via RTCP
An RTP receiver that receives a packet with an ECN-CE mark, or that An RTP receiver that receives a packet with an ECN-CE mark, or that
detects a packet loss, MUST schedule the transmission of an RTCP ECN detects a packet loss, MUST schedule the transmission of an RTCP ECN
feedback packet as soon as possible (subject to the constraints of feedback packet as soon as possible (subject to the constraints of
[RFC4585] and [RFC3550]) to report this back to the sender unless no [RFC4585] and [RFC3550]) to report this back to the sender unless no
skipping to change at page 37, line 8 skipping to change at page 37, line 35
user experience by allowing the RTP application to control how the user experience by allowing the RTP application to control how the
quality is reduced. An application which ignores ECN Congestion quality is reduced. An application which ignores ECN Congestion
Experienced feedback is not immune to congestion: the network will Experienced feedback is not immune to congestion: the network will
eventually begin to discard packets if traffic doesn't respond. It eventually begin to discard packets if traffic doesn't respond. It
is in the best interest of an application to respond to ECN is in the best interest of an application to respond to ECN
congestion feedback promptly, to avoid packet loss. congestion feedback promptly, to avoid packet loss.
7.4. Detecting Failures 7.4. Detecting Failures
Senders and receivers can deliberately ignore ECN-CE and thus get a Senders and receivers can deliberately ignore ECN-CE and thus get a
benefit over behaving flows (cheating). Th ECN Nonce [RFC3540] is an benefit over behaving flows (cheating). The ECN Nonce [RFC3540] is
addition to TCP that attempts to solve this issue as long as the an addition to TCP that attempts to solve this issue as long as the
sender acts on behalf of the network. The assumption about the sender acts on behalf of the network. The assumption about the
senders acting on the behalf of the network may be reduced due to the senders acting on the behalf of the network may be reduced due to the
nature of peer-to-peer use of RTP. Still a significant portion of nature of peer-to-peer use of RTP. Still a significant portion of
RTP senders are infrastructure devices (for example, streaming media RTP senders are infrastructure devices (for example, streaming media
servers) that do have an interest in protecting both service quality servers) that do have an interest in protecting both service quality
and the network. Even though there may be cases where nonce can be and the network. Even though there may be cases where the nonce may
applicable also for RTP, it is not included in this specification. be applicable for RTP, it is not included in this specification.
This as a receiver interested in cheating would simple claim to not This is because a receiver interested in cheating would simply claim
support nonce, or even ECN itself. It is, however, worth mentioning to not support the nonce, or even ECN itself. It is, however, worth
that, as real-time media is commonly sensitive to increased delay and mentioning that, as real-time media is commonly sensitive to
packet loss, it will be in both the media sender and receivers increased delay and packet loss, it will be in both the media sender
interest to minimise the number and duration of any congestion events and receivers interest to minimise the number and duration of any
as they will adversely affect media quality. congestion events as they will adversely affect media quality.
RTP sessions can also suffer from path changes resulting in a non-ECN RTP sessions can also suffer from path changes resulting in a non-ECN
compliant node becoming part of the path. That node may perform compliant node becoming part of the path. That node may perform
either of two actions that has effect on the ECN and application either of two actions that has an effect on the ECN and application
functionality. The gravest is if the node drops packets with the ECN functionality. The gravest is if the node drops packets with the ECN
field set to ECT(0), ECT(1), or ECN-CE. This can be detected by the field set to ECT(0), ECT(1), or ECN-CE. This can be detected by the
receiver when it receives an RTCP SR packet indicating that a sender receiver when it receives an RTCP SR packet indicating that a sender
has sent a number of packets that it has not received. The sender has sent a number of packets that it has not received. The sender
may also detect such a middlebox based on the receiver's RTCP RR may also detect such a middlebox based on the receiver's RTCP RR
packet, when the extended sequence number is not advanced due to the packet, when the extended sequence number is not advanced due to the
failure to receive packets. If the packet loss is less than 100%, failure to receive packets. If the packet loss is less than 100%,
then packet loss reporting in either the ECN feedback information or then packet loss reporting in either the ECN feedback information or
RTCP RR will indicate the situation. The other action is to re-mark RTCP RR will indicate the situation. The other action is to re-mark
a packet from ECT or ECN-CE to not-ECT. That has less dire results, a packet from ECT or ECN-CE to not-ECT. That has less dire results,
however it should be detected so that ECN usage can be suspended to however it should be detected so that ECN usage can be suspended to
prevent misusing the network. prevent misusing the network.
The RTCP XR ECN summary packet and the ECN feedback packet allow the The RTCP XR ECN summary packet and the ECN feedback packet allow the
sender to compare the number of ECT marked packets of different types sender to compare the number of ECT marked packets of different types
received with the number it actually sent. The number of ECT packets received with the number it actually sent. The number of ECT packets
received, plus the number of ECN-CE marked and lost packets, should received, plus the number of ECN-CE marked and lost packets, should
correspond to the number of sent ECT marked packets plus the number correspond to the number of sent ECT marked packets plus the number
of received duplicates. If these numbers doesn't agree there are two of received duplicates. If these numbers don't agree there are two
likely reasons, a translator changing the stream or not carrying the likely reasons, a translator changing the stream or not carrying the
ECN markings forward, or that some node re-marks the packets. In ECN markings forward, or that some node re-marks the packets. In
both cases the usage of ECN is broken on the path. By tracking all both cases the usage of ECN is broken on the path. By tracking all
the different possible ECN field values a sender can quickly detect the different possible ECN field values a sender can quickly detect
if some non-compliant behavior is happening on the path. if some non-compliant behavior is happening on the path.
Thus packet losses and non-matching ECN field value statistics are Thus packet losses and non-matching ECN field value statistics are
possible indication of issues with using ECN over the path. The next possible indications of issues with using ECN over the path. The
section defines both sender and receiver reactions to these cases. next section defines both sender and receiver reactions to these
cases.
7.4.1. Fallback mechanisms 7.4.1. Fallback mechanisms
Upon the detection of a potential failure, both the sender and the Upon the detection of a potential failure, both the sender and the
receiver can react to mitigate the situation. receiver can react to mitigate the situation.
A receiver that detects a packet loss burst MAY schedule an early A receiver that detects a packet loss burst MAY schedule an early
feedback packet that includes at least the RTCP RR and the ECN feedback packet that includes at least the RTCP RR and the ECN
feedback message to report this to the sender. This will speed up feedback message to report this to the sender. This will speed up
the detection of the loss at the sender, thus triggering sender side the detection of the loss at the sender, thus triggering sender side
skipping to change at page 39, line 27 skipping to change at page 40, line 9
Lost Packets counter: The number of RTP packets that where expected Lost Packets counter: The number of RTP packets that where expected
based on sequence numbers but never received. based on sequence numbers but never received.
Duplication Counter: The number of received RTP packets that are Duplication Counter: The number of received RTP packets that are
duplicates of already received ones. duplicates of already received ones.
Extended Highest Sequence number: The highest sequence number seen Extended Highest Sequence number: The highest sequence number seen
when sending this report, but with additional bits, to handle when sending this report, but with additional bits, to handle
disambiguation when wrapping the RTP sequence number field. disambiguation when wrapping the RTP sequence number field.
The counters will be initialised to zero to provide value for the RTP The counters will be initialised to zero to provide values for the
stream sender from the first report. After the first report, the RTP stream sender from the first report. After the first report, the
changes between the last received report and the previous report are changes between the last received report and the previous report are
determined by simply taking the values of the latest minus the determined by simply taking the values of the latest minus the
previous, taking wrapping into account. This definition is also previous, taking wrapping into account. This definition is also
robust to packet losses, since if one report is missing, the robust to packet losses, since if one report is missing, the
reporting interval becomes longer, but is otherwise equally valid. reporting interval becomes longer, but is otherwise equally valid.
In a perfect world, the number of not-ECT packets received should be In a perfect world, the number of not-ECT packets received should be
equal to the number sent minus the lost packets counter, and the sum equal to the number sent minus the lost packets counter, and the sum
of the ECT(0), ECT(1), and ECN-CE counters should be equal to the of the ECT(0), ECT(1), and ECN-CE counters should be equal to the
number of ECT marked packet sent. Two issues may cause a mismatch in number of ECT marked packet sent. Two issues may cause a mismatch in
skipping to change at page 48, line 50 skipping to change at page 49, line 37
discussion of this issue. discussion of this issue.
We note that the end-point security functions needed to prevent an We note that the end-point security functions needed to prevent an
external attacker from inferring with the signalling are source external attacker from inferring with the signalling are source
authentication and integrity protection. To prevent information authentication and integrity protection. To prevent information
leakage from the feedback packets encryption of the RTCP is also leakage from the feedback packets encryption of the RTCP is also
needed. For RTP there exist multiple solutions possible depending on needed. For RTP there exist multiple solutions possible depending on
the application context. Secure RTP (SRTP) [RFC3711] does satisfy the application context. Secure RTP (SRTP) [RFC3711] does satisfy
the requirement to protect this mechanism despite only providing the requirement to protect this mechanism despite only providing
authentication if a entity is within the security context or not. authentication if a entity is within the security context or not.
IPsec [RFC4301] and DTLS [RFC4347] can also provide the necessary IPsec [RFC4301] and DTLS [RFC6347] can also provide the necessary
security functions. security functions.
The signalling protocols used to initiate an RTP session also need to The signalling protocols used to initiate an RTP session also need to
be source authenticated and integrity protected to prevent an be source authenticated and integrity protected to prevent an
external attacker from modifying any signalling. Here an appropriate external attacker from modifying any signalling. Here an appropriate
mechanism to protect the used signalling needs to be used. For SIP/ mechanism to protect the used signalling needs to be used. For SIP/
SDP ideally S/MIME [RFC5751] would be used. However, with the SDP ideally S/MIME [RFC5751] would be used. However, with the
limited deployment a minimal mitigation strategy is to require use of limited deployment a minimal mitigation strategy is to require use of
SIPS (SIP over TLS) [RFC3261] [RFC5630] to at least accomplish hop- SIPS (SIP over TLS) [RFC3261] [RFC5630] to at least accomplish hop-
by-hop protection. by-hop protection.
skipping to change at page 52, line 36 skipping to change at page 52, line 36
least read. If one is capable of setting that is good, but not least read. If one is capable of setting that is good, but not
required as one can skip using ECN for anything one sends oneself. required as one can skip using ECN for anything one sends oneself.
The ECT value is recommended to be set to 0 always. The ECN usage in The ECT value is recommended to be set to 0 always. The ECN usage in
this session requires both ECN feedback and the XR ECN summary this session requires both ECN feedback and the XR ECN summary
report, so their use is also indicated. report, so their use is also indicated.
13. Acknowledgments 13. Acknowledgments
The authors wish to thank the following persons for their reviews and The authors wish to thank the following persons for their reviews and
comments: Thomas Belling, Bob Briscoe, Roni Even, Kevin P. Flemming, comments: Thomas Belling, Bob Briscoe, Roni Even, Kevin P. Flemming,
Thomas Frankkila, Christian Groves, Christer Holmgren, Cullen Tomas Frankkila, Christian Groves, Christer Holmgren, Cullen Jennings
Jennings Tom Van Caenegem, Simo Veikkolainen, Bill Ver Steeg, Dan Tom Van Caenegem, Simo Veikkolainen, Bill Ver Steeg, Dan Wing, Qin
Wing, Qin Wu, and Lei Zhu. Wu, and Lei Zhu.
14. References 14. References
14.1. Normative References 14.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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
skipping to change at page 54, line 30 skipping to change at page 54, line 30
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006. Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"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,
July 2006. July 2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588, Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
skipping to change at page 55, line 25 skipping to change at page 55, line 22
Specification", RFC 5751, January 2010. Specification", RFC 5751, January 2010.
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Protocol (RTCP) Extensions for Single-Source Multicast Protocol (RTCP) Extensions for Single-Source Multicast
Sessions with Unicast Feedback", RFC 5760, February 2010. Sessions with Unicast Feedback", RFC 5760, February 2010.
[RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media [RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media
Path Key Agreement for Unicast Secure RTP", RFC 6189, Path Key Agreement for Unicast Secure RTP", RFC 6189,
April 2011. April 2011.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
Authors' Addresses Authors' Addresses
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Farogatan 6 Farogatan 6
SE-164 80 Kista SE-164 80 Kista
Sweden Sweden
Phone: +46 10 714 82 87 Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
 End of changes. 30 change blocks. 
106 lines changed or deleted 146 lines changed or added

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