draft-ietf-avtcore-ecn-for-rtp-04.txt   draft-ietf-avtcore-ecn-for-rtp-05.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: January 12, 2012 C. Perkins Expires: May 3, 2012 C. Perkins
University of Glasgow University of Glasgow
P. O'Hanlon P. O'Hanlon
UCL UCL
K. Carlberg K. Carlberg
G11 G11
July 11, 2011 October 31, 2011
Explicit Congestion Notification (ECN) for RTP over UDP Explicit Congestion Notification (ECN) for RTP over UDP
draft-ietf-avtcore-ecn-for-rtp-04 draft-ietf-avtcore-ecn-for-rtp-05
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 January 12, 2012. This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 3, line 13 skipping to change at page 3, line 13
described in the Simplified BSD License. described in the Simplified BSD License.
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 . . . . . . . . . . . . 12 4. Overview of Use of ECN with RTP/UDP/IP . . . . . . . . . . . . 13
5. RTCP Extensions for ECN feedback . . . . . . . . . . . . . . . 15 5. RTCP Extensions for ECN feedback . . . . . . . . . . . . . . . 15
5.1. RTP/AVPF Transport Layer ECN Feedback packet . . . . . . . 15 5.1. RTP/AVPF Transport Layer ECN Feedback packet . . . . . . . 16
5.2. RTCP XR Report block for ECN summary information . . . . . 18 5.2. RTCP XR Report block for ECN summary information . . . . . 19
6. SDP Signalling Extensions for ECN . . . . . . . . . . . . . . 20 6. SDP Signalling Extensions for ECN . . . . . . . . . . . . . . 21
6.1. Signalling ECN Capability using SDP . . . . . . . . . . . 20 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 . . . . . . . . . . 25 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 . . . . . . . . . 26 7.2. Initiation of ECN Use in an RTP Session . . . . . . . . . 27
7.3. Ongoing Use of ECN Within an RTP Session . . . . . . . . . 33 7.3. Ongoing Use of ECN Within an RTP Session . . . . . . . . . 34
7.4. Detecting Failures . . . . . . . . . . . . . . . . . . . . 36 7.4. Detecting Failures . . . . . . . . . . . . . . . . . . . . 37
8. Processing ECN in RTP Translators and Mixers . . . . . . . . . 40 8. Processing ECN in RTP Translators and Mixers . . . . . . . . . 40
8.1. Transport Translators . . . . . . . . . . . . . . . . . . 40 8.1. Transport Translators . . . . . . . . . . . . . . . . . . 40
8.2. Fragmentation and Reassembly in Translators . . . . . . . 40 8.2. Fragmentation and Reassembly in Translators . . . . . . . 41
8.3. Generating RTCP ECN Feedback in Media Transcoders . . . . 42 8.3. Generating RTCP ECN Feedback in Media Transcoders . . . . 43
8.4. Generating RTCP ECN Feedback in Mixers . . . . . . . . . . 43 8.4. Generating RTCP ECN Feedback in Mixers . . . . . . . . . . 44
9. Implementation considerations . . . . . . . . . . . . . . . . 44 9. Implementation considerations . . . . . . . . . . . . . . . . 44
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
10.1. SDP Attribute Registration . . . . . . . . . . . . . . . . 44 10.1. SDP Attribute Registration . . . . . . . . . . . . . . . . 45
10.2. RTP/AVPF Transport Layer Feedback Message . . . . . . . . 45 10.2. RTP/AVPF Transport Layer Feedback Message . . . . . . . . 45
10.3. RTCP Feedback SDP Parameter . . . . . . . . . . . . . . . 45 10.3. RTCP Feedback SDP Parameter . . . . . . . . . . . . . . . 46
10.4. RTCP XR Report blocks . . . . . . . . . . . . . . . . . . 45 10.4. RTCP XR Report blocks . . . . . . . . . . . . . . . . . . 46
10.5. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 45 10.5. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 46
10.6. STUN attribute . . . . . . . . . . . . . . . . . . . . . . 45 10.6. STUN attribute . . . . . . . . . . . . . . . . . . . . . . 46
10.7. ICE Option . . . . . . . . . . . . . . . . . . . . . . . . 46 10.7. ICE Option . . . . . . . . . . . . . . . . . . . . . . . . 46
11. Security Considerations . . . . . . . . . . . . . . . . . . . 46 11. Security Considerations . . . . . . . . . . . . . . . . . . . 46
12. Examples of SDP Signalling . . . . . . . . . . . . . . . . . . 48 12. Examples of SDP Signalling . . . . . . . . . . . . . . . . . . 49
12.1. Basic SDP Offer/Answer . . . . . . . . . . . . . . . . . . 48 12.1. Basic SDP Offer/Answer . . . . . . . . . . . . . . . . . . 49
12.2. Declarative Multicast SDP . . . . . . . . . . . . . . . . 50 12.2. Declarative Multicast SDP . . . . . . . . . . . . . . . . 51
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
14.1. Normative References . . . . . . . . . . . . . . . . . . . 51 14.1. Normative References . . . . . . . . . . . . . . . . . . . 52
14.2. Informative References . . . . . . . . . . . . . . . . . . 52 14.2. Informative References . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
This memo outlines how Explicit Congestion Notification (ECN) This memo outlines how Explicit Congestion Notification (ECN)
[RFC3168] can be used for Real-time Transport Protocol (RTP) [RFC3168] can be used for Real-time Transport Protocol (RTP)
[RFC3550] flows running over UDP/IP which use RTP Control Protocol [RFC3550] flows running over UDP/IP which use RTP Control Protocol
(RTCP) as a feedback mechanism. The solution consists of feedback of (RTCP) as a feedback mechanism. The solution consists of feedback of
ECN congestion experienced markings to the sender using RTCP, ECN congestion experienced markings to the sender using RTCP,
verification of ECN functionality end-to-end, and procedures for how verification of ECN functionality end-to-end, and procedures for how
to initiate ECN usage. Since the initiation process has some to initiate ECN usage. Since the initiation process has some
skipping to change at page 9, line 8 skipping to change at page 9, line 8
The use of ECN is further dependent on a capability of the RTP media The use of ECN is further dependent on a capability of the RTP media
flow to react to congestion signalled by ECN marked packets. flow to react to congestion signalled by ECN marked packets.
Depending on the application, media codec, and network topology, this Depending on the application, media codec, and network topology, this
adaptation can occur in various forms and at various nodes. As an adaptation can occur in various forms and at various nodes. As an
example, the sender can change the media encoding, or the receiver example, the sender can change the media encoding, or the receiver
can change the subscription to a layered encoding, or either reaction can change the subscription to a layered encoding, or either reaction
can be accomplished by a transcoding middlebox. RFC 5117 identifies can be accomplished by a transcoding middlebox. RFC 5117 identifies
seven topologies in which RTP sessions may be configured, and which seven topologies in which RTP sessions may be configured, and which
may affect the ability to use ECN: may affect the ability to use ECN:
Topo-Point-to-Point: This is a standard unicast flow. ECN may be Topo-Point-to-Point: This utilises standard unicast flows. ECN may
used with RTP in this topology in an analogous manner to its use be used with RTP in this topology in an analogous manner to its
with other unicast transport protocols, with RTCP conveying ECN use with other unicast transport protocols, with RTCP conveying
feedback messages. ECN feedback messages.
Topo-Multicast: This is either an any source multicast (ASM) group Topo-Multicast: This is either an any source multicast (ASM) group
[RFC3569] with potentially several active senders and multicast [RFC3569] with potentially several active senders and multicast
RTCP feedback, or a source specific multicast (SSM) group RTCP feedback, or a source specific multicast (SSM) group
[RFC4607] with a single sender and unicast RTCP feedback from [RFC4607] with a single distribution source and unicast RTCP
receivers. RTCP is designed to scale to large group sizes while feedback from receivers. RTCP is designed to scale to large group
avoiding feedback implosion (see Section 6.2 of [RFC3550], sizes while avoiding feedback implosion (see Section 6.2 of
[RFC4585], and [RFC5760]), and can be used by a sender to [RFC3550], [RFC4585], and [RFC5760]), and can be used by a sender
determine if all its receivers, and the network paths to those to determine if all its receivers, and the network paths to those
receivers, support ECN (see Section 7.2). It is somewhat more receivers, support ECN (see Section 7.2). It is somewhat more
difficult to determine if all network paths from all senders to difficult to determine if all network paths from all senders to
all receivers support ECN. Accordingly, we allow ECN to be used all receivers support ECN. Accordingly, we allow ECN to be used
by an RTP sender using multicast UDP provided the sender has by an RTP sender using multicast UDP provided the sender has
verified that the paths to all its known receivers support ECN, verified that the paths to all its known receivers support ECN,
and irrespective of whether the paths from other senders to their and irrespective of whether the paths from other senders to their
receivers support ECN ("all its known receivers" are all the SSRCs receivers support ECN ("all its known receivers" are all the SSRCs
that the RTP sender has received RTP or RTCP from the last five that the RTP sender has received RTP or RTCP from the last five
reporting intervals, i.e., they have not timed out). Note that reporting intervals, i.e., they have not timed out). Note that
group membership may change during the lifetime of a multicast RTP group membership may change during the lifetime of a multicast RTP
session, potentially introducing new receivers that are not ECN session, potentially introducing new receivers that are not ECN
capable or have a path that doesn't support ECN. Senders must use capable or have a path that doesn't support ECN. Senders must use
the mechanisms described in Section 7.4 to check that all the mechanisms described in Section 7.4 to check that all
receivers, and the network paths traversed to reach those receivers, and the network paths traversed to reach those
receivers, continue to support ECN, and they need to fallback to receivers, continue to support ECN, and they need to fallback to
non-ECN use if any receivers join that do not. non-ECN use if any receivers join that do not.
SSM groups that uses unicast RTCP feedback [RFC5760] do need a few
extra considerations. This topology can have multiple media
senders that provides traffic to the distribution source (DS) and
are separated from the DS. There can also be multiple feedback
targets. The requirement for using ECN for RTP in this topology
is that the media sender must be provided the feedback from the
receivers, it may be in aggregated form from the feedback targets.
We will not mention this SSM use case in the below text
specifically, but when actions are required by the media source,
they do apply also to case of SSM where the RTCP feedback goes to
the Feedback Target.
This specification do support multicast, but has primarily
considered smaller multicast groups and is not optimized for
larger groups and their needs.
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
the changes it makes to the RTP data packets. A legacy, ECN- the changes it makes to the RTP data packets. A legacy, ECN-
skipping to change at page 13, line 15 skipping to change at page 13, line 25
1. Negotiation of the capability to use ECN with RTP/UDP/IP 1. Negotiation of the capability to use ECN with RTP/UDP/IP
2. Initiation and initial verification of ECN capable transport 2. Initiation and initial verification of ECN capable transport
3. Ongoing use of ECN within an RTP session 3. Ongoing use of ECN within an RTP session
4. Handling of dynamic behavior through failure detection, 4. Handling of dynamic behavior through failure detection,
verification and fallback verification and fallback
Before an RTP session can be created, a signalling protocol is used Before an RTP session can be created, a signalling protocol is used
to discover the other participants and negotiate or configure session to negotiate or at least configure session parameters (see
parameters (see Section 7.1). One of the parameters that must be Section 7.1). In some topologies the signalling protocol can also be
agreed is the capability of a participant to support ECN. Note that used to discover the other participants. One of the parameters that
all participants having the capability of supporting ECN does not must be agreed is the capability of a participant to support ECN.
necessarily imply that ECN is usable in an RTP session, since there Note that all participants having the capability of supporting ECN
may be middleboxes on the path between the participants which don't does not necessarily imply that ECN is usable in an RTP session,
pass ECN-marked packets (for example, a firewall that blocks traffic since there may be middleboxes on the path between the participants
with the ECN bits set). This document defines the information that which don't pass ECN-marked packets (for example, a firewall that
needs to be negotiated, and provides a mapping to SDP for use in both blocks traffic with the ECN bits set). This document defines the
declarative and offer/answer contexts. information that needs to be negotiated, and provides a mapping to
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 set to ECT(0) or ECT(1). Each receiver will
then send an RTCP feedback packet indicating the reception of the then send an RTCP feedback packet indicating the reception of the
ECT marked RTP packets. Upon reception of this feedback from each ECT marked RTP packets. Upon reception of this feedback from each
receiver it knows of, the sender can consider ECN functional for receiver it knows of, the sender can consider ECN functional for
skipping to change at page 24, line 49 skipping to change at page 25, line 19
TCP, SCTP, or DCCP transport, or for non-RTP sessions. TCP, SCTP, or DCCP transport, or for non-RTP sessions.
As described in Section 7.3.3, RTP sessions using ECN require rapid As described in Section 7.3.3, RTP sessions using ECN require rapid
RTCP ECN feedback, unless timely feedback is not required due to a RTCP ECN feedback, unless timely feedback is not required due to a
receiver driven congestion control. To ensure that the sender can receiver driven congestion control. To ensure that the sender can
react to ECN-CE marked packets timely feedback is usually required. react to ECN-CE marked packets timely feedback is usually required.
Thus, the use of the Extended RTP Profile for RTCP-Based Feedback Thus, the use of the Extended RTP Profile for RTCP-Based Feedback
(RTP/AVPF) [RFC4585] or other profile that inherits RTP/AVPF's (RTP/AVPF) [RFC4585] or other profile that inherits RTP/AVPF's
signalling rules, MUST be signalled unless timely feedback is not signalling rules, MUST be signalled unless timely feedback is not
required. If timely feedback is not required it is still RECOMMENDED required. If timely feedback is not required it is still RECOMMENDED
to used RTP/AVPF. The signalling of an RTP/AVPF based profile is to use RTP/AVPF. The signalling of an RTP/AVPF based profile is
likely to be required even if the preferred method of initialization likely to be required even if the preferred method of initialization
and the congestion control does not require timely feedback, as the and the congestion control does not require timely feedback, as the
common interoperable method is likely to be signalled or the improved common interoperable method is likely to be signalled or the improved
fault reaction is desired. fault reaction is desired.
6.2. RTCP ECN Feedback SDP Parameter 6.2. RTCP ECN Feedback SDP Parameter
A new "nack" feedback parameter "ecn" is defined to indicate the A new "nack" feedback parameter "ecn" is defined to indicate the
usage of the RTCP ECN feedback packet format (Section 5.1). The ABNF usage of the RTCP ECN feedback packet format (Section 5.1). The ABNF
[RFC5234] definition of the SDP parameter extension is: [RFC5234] definition of the SDP parameter extension is:
skipping to change at page 26, line 37 skipping to change at page 27, line 5
in Section 6.4. Other signalling systems will need to define in Section 6.4. Other signalling systems will need to define
signalling parameters corresponding to those defined for SDP. signalling parameters corresponding to those defined for SDP.
The "ecn-capable-rtp" SDP attribute MUST be used when employing ECN The "ecn-capable-rtp" SDP attribute MUST be used when employing ECN
for RTP according to this specification in systems using SDP. As the for RTP according to this specification in systems using SDP. As the
RTCP XR ECN summary report is required independently of the RTCP XR ECN summary report is required independently of the
initialization method or congestion control scheme, the "rtcp-xr" initialization method or congestion control scheme, the "rtcp-xr"
attribute with the "ecn-sum" parameter MUST also be used. The attribute with the "ecn-sum" parameter MUST also be used. The
"rtcp-fb" attribute with the "nack" parameter "ecn" MUST be used "rtcp-fb" attribute with the "nack" parameter "ecn" MUST be used
whenever the initialization method or a congestion control algorithm whenever the initialization method or a congestion control algorithm
requiring timely sender side knowledge of received CE markings. If requires timely sender side knowledge of received CE markings. If
the congestion control scheme requires additional signalling, this the congestion control scheme requires additional signalling, this
should be indicated as appropriate. should be indicated as appropriate.
7.2. Initiation of ECN Use in an RTP Session 7.2. Initiation of ECN Use in an RTP Session
Once the sender and the receiver(s) have agreed that they have the Once the sender and the receiver(s) have agreed that they have the
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
will need to use the same initiation method. RTP mixers or MUST use the same initiation method. RTP mixers or translators can
translators can use different initiation methods to different use different initiation methods to different participants that are
participants that are connected over different underlying transports. connected over different underlying transports. The mixer or
The mixer or translator will need to do individual signalling with translator will need to do individual signalling with each
each participant to ensure it is consistent with the ECN support in participant to ensure it is consistent with the ECN support in those
those cases where it does not function as one end-point for the ECN cases where it does not function as one end-point for the ECN control
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 packets with ECT are
sent, it is important to verify that IP packets with ECN field values sent, it is important to verify that IP packets with ECN field values
of ECT or ECN-CE will reach their destination(s). There is some risk of ECT or ECN-CE will reach their destination(s). There is some risk
that the use of ECN will result in either reset of the ECN field, or that the use of ECN will result in either reset of the ECN field, or
loss of all packets with ECT or ECN-CE markings. If the path between loss of all packets with ECT or ECN-CE markings. If the path between
the sender and the receivers exhibits either of these behaviours one the sender and the receivers exhibits either of these behaviours one
needs to stop using ECN immediately to protect both the network and needs to stop using ECN immediately to protect both the network and
the application. the application.
skipping to change at page 27, line 27 skipping to change at page 27, line 42
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
faith option if the session supports the limitations provided in faith option if the session supports the limitations provided in
Section 7.2.3. If support for both in-band and out-of-band Section 7.2.3. If support for both in-band and out-of-band
mechanisms is signalled, the sender SHOULD try ECN negotiation using mechanisms are signalled, the sender when negotiating SHOULD offer
STUN with ICE first, and if it fails, fallback to negotiation using detection of ECT using STUN with ICE with higher priority than
RTP and RTCP ECN feedback. detection of ECT using RTP and RTCP.
No matter how ECN usage is initiated, the sender MUST continually No matter how ECN usage is initiated, the sender MUST continually
monitor the ability of the network, and all its receivers, to support monitor the ability of the network, and all its receivers, to support
ECN, following the mechanisms described in Section 7.4. This is ECN, following the mechanisms described in Section 7.4. This is
necessary because path changes or changes in the receiver population necessary because path changes or changes in the receiver population
may invalidate the ability of the system to use ECN. may invalidate the ability of the system to use ECN.
7.2.1. Detection of ECT using RTP and RTCP 7.2.1. Detection of ECT using RTP and RTCP
The ECN initiation phase using RTP and RTCP to detect if the network The ECN initiation phase using RTP and RTCP to detect if the network
skipping to change at page 28, line 19 skipping to change at page 28, line 30
delivery during the ECN initiation phase in those cases where ECN delivery during the ECN initiation phase in those cases where ECN
is not supported by the network path. A secondary reason to send is not supported by the network path. A secondary reason to send
some not-ECT packets are to ensure that the receivers will send some not-ECT packets are to ensure that the receivers will send
RTCP reports on this sender, even if all ECT marked packets are RTCP reports on this sender, even if all ECT marked packets are
lost in transit. The not-ECT packets also provide a base-line to lost in transit. The not-ECT packets also provide a base-line to
compare performance parameters against. A fourth reason for only compare performance parameters against. A fourth reason for only
probing with a small number of packets is to reduce the risk that probing with a small number of packets is to reduce the risk that
significant numbers of congestion markings might be lost if ECT is significant numbers of congestion markings might be lost if ECT is
cleared to Not-ECT by an ECN-Reverting Middlebox. Then any cleared to Not-ECT by an ECN-Reverting Middlebox. Then any
resulting lack of congestion response is likely to have little resulting lack of congestion response is likely to have little
damaging affect on others. An RTP sender is RECOMMENDED to send a damaging effect on others. An RTP sender is RECOMMENDED to send a
minimum of two packets with ECT markings per RTCP reporting minimum of two packets with ECT markings per RTCP reporting
interval. In case a random ECT pattern is intended to be used, at interval. In case a random ECT pattern is intended to be used, at
least one packet with ECT(0) and one with ECT(1) should be sent least one packet with ECT(0) and one with ECT(1) should be sent
per reporting interval; in case a single ECT marking is to be per reporting interval; in case a single ECT marking is to be
used, only that ECT value SHOULD be sent. The RTP sender SHALL used, only that ECT value SHOULD be sent. The RTP sender SHALL
continue to send some ECT marked traffic as long as the ECN continue to send some ECT marked traffic as long as the ECN
initiation phase continues. The sender SHOULD NOT mark all RTP initiation phase continues. The sender SHOULD NOT mark all RTP
packets as ECT during the ECN initiation phase. packets as ECT during the ECN initiation phase.
This memo does not mandate which RTP packets are marked with ECT This memo does not mandate which RTP packets are marked with ECT
during the ECN initiation phase. An implementation should insert during the ECN initiation phase. An implementation should insert
ECT marks in RTP packets in a way that minimises the impact on ECT marks in RTP packets in a way that minimises the impact on
media quality if those packets are lost. The choice of packets to media quality if those packets are lost. The choice of packets to
mark is clearly very media dependent, but the use of RTP NO-OP mark is clearly very media dependent, but the use of RTP NO-OP
payloads [I-D.ietf-avt-rtp-no-op], if supported, would be an payloads [I-D.ietf-avt-rtp-no-op], if supported, would be an
appropriate choice. For audio formats, if would make sense for appropriate choice. For audio formats, if would make sense for
the sender to mark comfort noise packets or similar. For video the sender to mark comfort noise packets or similar. For video
formats, packets containing P- or B-frames, rather than I-frames, formats, packets containing P- or B-frames (rather than I-frames)
would be an appropriate choice. No matter which RTP packets are would be an appropriate choice. No matter which RTP packets are
marked, those packets MUST NOT be sent in duplicate, with and marked, those packets MUST NOT be sent in duplicate, with and
without ECT, since the RTP sequence number is used to identify without ECT, since the RTP sequence number is used to identify
packets that are received with ECN markings. packets that are received with ECN markings.
Generating RTCP ECN Feedback: If ECN capability has been negotiated Generating RTCP ECN Feedback: If ECN capability has been negotiated
in an RTP session, the receivers in the session MUST listen for in an RTP session, the receivers in the session MUST listen for
ECT or ECN-CE marked RTP packets, and generate RTCP ECN feedback ECT or ECN-CE marked RTP packets, and generate RTCP ECN feedback
packets (Section 5.1) to mark their receipt. An immediate or packets (Section 5.1) to mark their receipt. An immediate or
early (depending on the RTP/AVPF mode) ECN feedback packet SHOULD early (depending on the RTP/AVPF mode) ECN feedback packet SHOULD
skipping to change at page 30, line 11 skipping to change at page 30, line 21
transport with several SSRCs multiplexed onto the same flow transport with several SSRCs multiplexed onto the same flow
(e.g., a single participant with two video cameras, or SSRC (e.g., a single participant with two video cameras, or SSRC
multiplexed RTP retransmission [RFC4588]). It is desirable to multiplexed RTP retransmission [RFC4588]). It is desirable to
be able to rapidly negotiate ECN support for such a session, be able to rapidly negotiate ECN support for such a session,
but the optimisation above can fail if there are but the optimisation above can fail if there are
implementations that use the same CNAME for different parts of implementations that use the same CNAME for different parts of
a distributed implementation that have different transport a distributed implementation that have different transport
characteristics (e.g., if a single logical endpoint is split characteristics (e.g., if a single logical endpoint is split
across multiple hosts). across multiple hosts).
ECN initiation is considered to have failed at the instant when ECN initiation is considered to have failed at the instant the
any RTP session participant sends an RTCP packet that doesn't initiating RTP sender received an RTCP packet that doesn't contain
contain an RTCP ECN feedback report or ECN summary report, but has an RTCP ECN feedback report or ECN summary report from any RTP
an RTCP RR with an extended RTP sequence number field that session participant that has an RTCP RR with an extended RTP
indicates that it should have received multiple (>3) ECT marked sequence number field that indicates that it should have received
RTP packets. This can be due to failure to support the ECN multiple (>3) ECT marked RTP packets. This can be due to failure
feedback format by the receiver or some middlebox, or the loss of to support the ECN feedback format by the receiver or some
all ECT marked packets. Both indicate a lack of ECN support. middlebox, or the loss of all ECT marked packets. Both indicate a
lack of ECN support.
If the ECN negotiation succeeds, this indicates that the path can If the ECN negotiation succeeds, this indicates that the path can
pass some ECN-marked traffic, and that the receivers support ECN pass some ECN-marked traffic, and that the receivers support ECN
feedback. This does not necessarily imply that the path can robustly feedback. This does not necessarily imply that the path can robustly
convey ECN feedback; Section 7.3 describes the ongoing monitoring convey ECN feedback; Section 7.3 describes the ongoing monitoring
that must be performed to ensure the path continues to robustly that must be performed to ensure the path continues to robustly
support ECN. support ECN.
When a sender or receiver detects ECN failures on paths they should When a sender or receiver detects ECN failures on paths they should
log these to enable follow up and statistics gathering regarding log these to enable follow up and statistics gathering regarding
skipping to change at page 31, line 22 skipping to change at page 31, line 33
a STUN packet that is ECT marked. On reception of the packet, a STUN a STUN packet that is ECT marked. On reception of the packet, a STUN
server supporting this extension will note the received ECN field server supporting this extension will note the received ECN field
value, and send a STUN/UDP/IP packet in reply with the ECN field set value, and send a STUN/UDP/IP packet in reply with the ECN field set
to not-ECT and including an ECN check attribute. A STUN server that to not-ECT and including an ECN check attribute. A STUN server that
doesn't understand the extension, or is incapable of reading the ECN doesn't understand the extension, or is incapable of reading the ECN
values on incoming STUN packets, should follow the rule in the STUN values 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
ECT marking, but also various other non ECN related reasons 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
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
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
testing for ECN capability on the path. As the ICE agent have
successfully verified the path a RTT measurement for this path can be
performed. To have high probability of succesfully verifying the
path it is RECOMMENDED that the client retransmitt the ECN STUN check
4 times. The interval between the retransmissions will 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 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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |ECF|V| | Reserved |ECF|V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: ECN Check STUN Attribute Figure 6: ECN Check STUN Attribute
skipping to change at page 33, line 23 skipping to change at page 34, line 11
media, it is NOT RECOMMENDED that the leap-of-faith ECT initiation media, it is NOT RECOMMENDED that the leap-of-faith ECT initiation
method be used in environments where ECN-blocking middleboxes are method be used in environments where ECN-blocking middleboxes are
likely to be present. likely to be present.
7.3. Ongoing Use of ECN Within an RTP Session 7.3. Ongoing Use of ECN Within an RTP Session
Once ECN has been successfully initiated for an RTP sender, that Once ECN has been successfully initiated for an RTP sender, that
sender begins sending all RTP data packets as ECT-marked, and its sender begins sending all RTP data packets as ECT-marked, and its
receivers send ECN feedback information via RTCP packets. This receivers send ECN feedback information via RTCP packets. This
section describes procedures for sending ECT-marked data, providing section describes procedures for sending ECT-marked data, providing
ECN feedback information via RTCP, responding to ECN feedback ECN feedback information via RTCP, and responding to ECN feedback
information, and detecting failures and misbehaving receivers. information.
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
skipping to change at page 35, line 14 skipping to change at page 35, line 45
Sender-Driven Congestion Control: The sender is responsible for Sender-Driven Congestion Control: The sender is responsible for
adapting the transmitted bit-rate in response to RTCP ECN adapting the transmitted bit-rate in response to RTCP ECN
feedback. When the sender receives the ECN feedback data it feeds feedback. When the sender receives the ECN feedback data it feeds
this information into its congestion control or bit-rate this information into its congestion control or bit-rate
adaptation mechanism so that it can react as if packet loss was adaptation mechanism so that it can react as if packet loss was
reported. The congestion control algorithm to be used is not reported. The congestion control algorithm to be used is not
specified here, although TFRC [RFC5348] is one example that might specified here, although TFRC [RFC5348] is one example that might
be used. be used.
Receiver-Driven Congestion Control: If a receiver driven congestion Receiver-Driven Congestion Control: In a receiver driven congestion
control mechanism is used, the receiver can react to the ECN-CE control mechanism, the receivers can react to the ECN-CE marks
marks without contacting the sender. This may allow faster themselves without providing ECN-CE feedback to the sender. This
response than sender-driven congestion control in some may allow faster response than sender-driven congestion control in
circumstances. Receiver-driven congestion control is usually some circumstances and also scale to large number of receivers and
implemented by providing the content in a layered way, with each multicast usage. One example of receiver-driven congestion
layer providing improved media quality but also increased control is implemented by providing the content in a layered way,
bandwidth usage. The receiver locally monitors the ECN-CE marks with each layer providing improved media quality but also
on received packets to check if it experiences congestion with the increased bandwidth usage. The receiver locally monitors the
current number of layers. If congestion is experienced, the ECN-CE marks on received packets to check if it experiences
receiver drops one layer, so reducing the resource consumption on congestion with the current number of layers. If congestion is
the path towards itself. For example, if a layered media encoding experienced, the receiver drops one layer, so reducing the
scheme such as H.264 SVC is used, the receiver may change its resource consumption on the path towards itself. For example, if
layer subscription, and so reduce the bit rate it receives. The a layered media encoding scheme such as H.264 SVC is used, the
receiver MUST still send RTCP XR ECN Summary to the sender, even receiver may change its layer subscription, and so reduce the bit
if it can adapt without contact with the sender, so that the rate it receives. The receiver MUST still send RTCP XR ECN
sender can determine if ECN is supported on the network path. The Summary to the sender, even if it can adapt without contact with
timeliness of RTCP feedback is less of a concern with receiver the sender, so that the sender can determine if ECN is supported
driven congestion control, and regular RTCP reporting of ECN on the network path. The timeliness of RTCP feedback is less of a
summary information is sufficient (without using RTP/AVPF concern with receiver driven congestion control, and regular RTCP
immediate or early feedback). reporting of ECN summary information is sufficient (without using
RTP/AVPF immediate or early feedback).
Hybrid: There might be mechanisms that utilize both some receiver Hybrid: There might be mechanisms that utilize both some receiver
behaviors and some sender side monitoring, thus requiring both behaviors and some sender side monitoring, thus requiring both
feedback of congestion events to the sender and taking receiver feedback of congestion events to the sender and taking receiver
decisions and possible signalling to the sender. In this case the decisions and possible signalling to the sender. In this case the
congestion control algorithm needs to use the signalling to congestion control algorithm needs to use the signalling to
indicate which features of ECN for RTP are required. indicate which features of ECN for RTP are required.
Responding to congestion indication in the case of multicast traffic Responding to congestion indication in the case of multicast traffic
is a more complex problem than for unicast traffic. The fundamental is a more complex problem than for unicast traffic. The fundamental
skipping to change at page 38, line 9 skipping to change at page 38, line 40
that is suitable if the impact of ECT probing on the media that is suitable if the impact of ECT probing on the media
quality is noticeable. If multiple initiations have been quality is noticeable. If multiple initiations have been
successful, but the following full usage of ECN has resulted in successful, but the following full usage of ECN has resulted in
the fallback procedures, then disabling of the ECN support is the fallback procedures, then disabling of the ECN support is
RECOMMENDED. RECOMMENDED.
We foresee the possibility of flapping ECN capability due to several We foresee the possibility of flapping ECN capability due to several
reasons: video switching MCU or similar middleboxes that selects to reasons: video switching MCU or similar middleboxes that selects to
deliver media from the sender only intermittently; load balancing deliver media from the sender only intermittently; load balancing
devices may in worst case result in that some packets take a devices may in worst case result in that some packets take a
different network path then the others; mobility solutions that different network path than the others; mobility solutions that
switch underlying network path in a transparent way for the sender or switch underlying network path in a transparent way for the sender or
receiver; and membership changes in a multicast group. It is however receiver; and membership changes in a multicast group. It is however
appropriate to mention that there are also issues such as re-routing appropriate to mention that there are also issues such as re-routing
of traffic due to a flappy route table or excessive reordering and of traffic due to a flappy route table or excessive reordering and
other issues that are not directly ECN related but nevertheless may other issues that are not directly ECN related but nevertheless may
cause problems for ECN. cause problems for ECN.
7.4.2. Interpretation of ECN Summary information 7.4.2. Interpretation of ECN Summary information
This section contains discussion on how the ECN summary report This section contains discussion on how the ECN summary report
skipping to change at page 42, line 21 skipping to change at page 42, line 51
contain active speech data, but passes comfort noise packets contain active speech data, but passes comfort noise packets
unchanged, would have an R values of between 0.5 and 1.0 depending on unchanged, would have an R values of between 0.5 and 1.0 depending on
the amount of active speech. Since the counter values in the the amount of active speech. Since the counter values in the
translated RTCP report are integer values, rounding will be necessary translated RTCP report are integer values, rounding will be necessary
in this case. in this case.
When rounding counter values in the translated RTCP packet, the When rounding counter values in the translated RTCP packet, the
translator should try to ensure that they sum to the number of RTP translator should try to ensure that they sum to the number of RTP
packets in the pre-translation sequence number space (numOrig). The packets in the pre-translation sequence number space (numOrig). The
translator should also try to ensure that no non-zero counter is translator should also try to ensure that no non-zero counter is
rounded to a zero value, since that will lose information that a rounded to a zero value, unless the pre-translated values are zero,
particular type of event has occurred. It is recognised that it may since that will lose information that a particular type of event has
be impossible to satisfy both of these constraints; in such cases, it occurred. It is recognised that it may be impossible to satisfy both
is better to ensure that no non-zero counter is mapped to a zero of these constraints; in such cases, it is better to ensure that no
value, since this preserves congestion adaptation and helps the RTCP- non-zero counter is mapped to a zero value, since this preserves
based ECN initiation process. congestion adaptation and helps the RTCP-based ECN initiation
process.
One should be aware of the impact this type of translators have on One should be aware of the impact this type of translators have on
the measurement of packet duplication. A translator performing the measurement of packet duplication. A translator performing
aggregation and most likely also an fragmenting translator will aggregation and most likely also an fragmenting translator will
suppress any duplication happening prior to itself. Thus the reports suppress any duplication happening prior to itself. Thus the reports
and what is being scaled will only represent packet duplication and what is being scaled will only represent packet duplication
happening from the translator to the receiver reporting on the flow. happening from the translator to the receiver reporting on the flow.
It should be noted that scaling the RTCP counter values in this way It should be noted that scaling the RTCP counter values in this way
is meaningful only on the assumption that the level of congestion in is meaningful only on the assumption that the level of congestion in
skipping to change at page 44, line 18 skipping to change at page 44, line 49
those mixed flows as if it were a standard media sender. A those mixed flows as if it were a standard media sender. A
congestion control loop runs between the mixer and its receivers, congestion control loop runs between the mixer and its receivers,
driven in part by the ECN reports received. driven in part by the ECN reports received.
An RTP mixer MUST NOT forward RTCP ECN feedback packets or RTCP XR An RTP mixer MUST NOT forward RTCP ECN feedback packets or RTCP XR
ECN summary reports from downstream receivers in the upstream ECN summary reports from downstream receivers in the upstream
direction. direction.
9. Implementation considerations 9. Implementation considerations
To allow the use of ECN with RTP over UDP, the RTP implementation To allow the use of ECN with RTP over UDP, an RTP implementation
should be able to set the ECT bits in outgoing UDP datagrams, and desiring to support receiving ECN controlled media streams must
should be able to read the value of the ECT bits on received UDP support reading the value of the ECT bits on received UDP datagrams,
and an RTP implementation desiring to support sending ECN controlled
media streams must support setting the ECT bits in outgoing UDP
datagrams. The standard Berkeley sockets API pre-dates the datagrams. The standard Berkeley sockets API pre-dates the
specification of ECN, and does not provide the functionality which is specification of ECN, and does not provide the functionality which is
required for this mechanism to be used with UDP flows, making this required for this mechanism to be used with UDP flows, making this
specification difficult to implement portably. specification difficult to implement portably.
10. IANA Considerations 10. IANA Considerations
Note to RFC Editor: please replace "RFC XXXX" below with the RFC Note to RFC Editor: please replace "RFC XXXX" below with the RFC
number of this memo, and remove this note. number of this memo, and remove this note.
skipping to change at page 45, line 41 skipping to change at page 46, line 28
defined in Section 5.2: defined in Section 5.2:
Block Type: TBA2 Block Type: TBA2
Name: ECN Summary Report Name: ECN Summary Report
Reference: RFC XXXX Reference: RFC XXXX
10.5. RTCP XR SDP Parameter 10.5. RTCP XR SDP Parameter
The IANA is requested to register one new RTCP XR SDP Parameter "ecn- The IANA is requested to register one new RTCP XR SDP Parameter "ecn-
sum" in the "RTCP XR SDP Parameters" registry. sum" in the "RTCP XR SDP Parameters" registry.
Parameter name XR block (block type and name) Parameter name XR block (block type and name)
-------------- ------------------------------------ -------------- ------------------------------------
ecn-sum TBA2 ECN Summary Report Block ecn-sum TBA2 ECN Summary Report Block
10.6. STUN attribute 10.6. STUN attribute
A new STUN [RFC5389] attribute in the Comprehension-optional range A new STUN [RFC5389] attribute in the Comprehension-optional range
under IETF Review (0x0000 - 0x3FFF) is request to be assigned to the under IETF Review (0x8000-0xFFFF) is request to be assigned to the
STUN attribute defined in Section 7.2.2. The STUN attribute registry STUN attribute defined in Section 7.2.2. The STUN attribute registry
can currently be found at: http://www.iana.org/assignments/ can currently be found at: http://www.iana.org/assignments/
stun-parameters/stun-parameters.xhtml. stun-parameters/stun-parameters.xhtml.
10.7. ICE Option 10.7. ICE Option
A new ICE option "rtp+ecn" is registered in the registry that "IANA A new ICE option "rtp+ecn" is registered in the registry that "IANA
Registry for Interactive Connectivity Establishment (ICE) Options" Registry for Interactive Connectivity Establishment (ICE) Options"
[I-D.ietf-mmusic-ice-options-registry] creates. [RFC6336] creates.
11. Security Considerations 11. Security Considerations
The use of ECN with RTP over UDP as specified in this document has The use of ECN with RTP over UDP as specified in this document has
the following known security issues that need to be considered. the following known security issues that need to be considered.
External threats to the RTP and RTCP traffic: External threats to the RTP and RTCP traffic:
Denial of Service affecting RTCP: An attacker that can modify the Denial of Service affecting RTCP: An attacker that can modify the
traffic between the media sender and a receiver can achieve either traffic between the media sender and a receiver can achieve either
skipping to change at page 49, line 38 skipping to change at page 50, line 38
a=rtcp-xr:ecn-sum a=rtcp-xr:ecn-sum
a=rtcp-rsize a=rtcp-rsize
a=candidate:1 1 UDP 2130706431 10.0.1.4 8998 typ host a=candidate:1 1 UDP 2130706431 10.0.1.4 8998 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
10.0.1.4 rport 8998 10.0.1.4 rport 8998
This SDP offer offers a single media stream with 3 media payload This SDP offer offers a single media stream with 3 media payload
types. It proposes to use ECN with RTP, with the ICE based types. It proposes to use ECN with RTP, with the ICE based
initialization as being preferred over the RTP/RTCP one. Leap of initialization as being preferred over the RTP/RTCP one. Leap of
faith is not suggested to be used. The offerer is capable of both faith is not suggested to be used. The offerer is capable of both
setting and reading the ECN bits. In addition the RTCP ECN feedback setting and reading the ECN bits. In addition the use of both the
packet is configured and the RTCP XR ECN summary report. ICE is also RTCP ECN feedback packet and the RTCP XR ECN summary report are
proposed with two candidates. It also supports reduced size RTCP and supported. ICE is also proposed with two candidates. It also
are willing to use it. supports reduced size RTCP and can to use it.
The Answer: The Answer:
v=0 v=0
o=jdoe 3502844783 3502844783 IN IP4 198.51.100.235 o=jdoe 3502844783 3502844783 IN IP4 198.51.100.235
s=VoIP call s=VoIP call
i=SDP offer for VoIP call with ICE and ECN for RTP i=SDP offer for VoIP call with ICE and ECN for RTP
b=AS:128 b=AS:128
b=RR:2000 b=RR:2000
b=RS:2500 b=RS:2500
skipping to change at page 51, line 35 skipping to change at page 52, line 35
ECN setting and reading capability to take part of this session is at ECN setting and reading capability to take part of this session is at
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, Thomas Frankkila, comments: Thomas Belling, Bob Briscoe, Roni Even, Kevin P. Flemming,
Christian Groves, Cullen Jennings Tom Van Caenegem, Simo Thomas Frankkila, Christian Groves, Christer Holmgren, Cullen
Veikkolainen, Lei Zhu, and Christer Holmgren. Jennings Tom Van Caenegem, Simo Veikkolainen, Bill Ver Steeg, Dan
Wing, Qin Wu, and Lei Zhu.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-mmusic-ice-options-registry]
Westerlund, M. and C. Perkins, "IANA Registry for
Interactive Connectivity Establishment (ICE) Options",
draft-ietf-mmusic-ice-options-registry-02 (work in
progress), May 2011.
[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.
[RFC2762] Rosenberg, J. and H. Schulzrinne, "Sampling of the Group
Membership in RTP", RFC 2762, February 2000.
[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",
RFC 3168, September 2001. RFC 3168, September 2001.
[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, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611, Protocol Extended Reports (RTCP XR)", RFC 3611,
skipping to change at page 52, line 36 skipping to change at page 53, line 29
April 2010. April 2010.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification", Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, September 2008. RFC 5348, September 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for
Interactive Connectivity Establishment (ICE) Options",
RFC 6336, July 2011.
14.2. Informative References 14.2. Informative References
[I-D.ietf-avt-rtp-no-op] [I-D.ietf-avt-rtp-no-op]
Andreasen, F., "A No-Op Payload Format for RTP", Andreasen, F., "A No-Op Payload Format for RTP",
draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007. draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989. RFC 1112, August 1989.
[RFC2762] Rosenberg, J. and H. Schulzrinne, "Sampling of the Group
Membership in RTP", RFC 2762, February 2000.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
 End of changes. 39 change blocks. 
124 lines changed or deleted 168 lines changed or added

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