draft-ietf-avtcore-ecn-for-rtp-06.txt   draft-ietf-avtcore-ecn-for-rtp-07.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: August 20, 2012 C. Perkins Expires: October 1, 2012 C. Perkins
University of Glasgow University of Glasgow
P. O'Hanlon P. O'Hanlon
UCL University of Oxford
K. Carlberg K. Carlberg
G11 G11
February 17, 2012 March 30, 2012
Explicit Congestion Notification (ECN) for RTP over UDP Explicit Congestion Notification (ECN) for RTP over UDP
draft-ietf-avtcore-ecn-for-rtp-06 draft-ietf-avtcore-ecn-for-rtp-07
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 August 20, 2012. This Internet-Draft will expire on October 1, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 3, line 29 skipping to change at page 3, line 29
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 . . . . . . . . . 41 8. Processing ECN in RTP Translators and Mixers . . . . . . . . . 41
8.1. Transport Translators . . . . . . . . . . . . . . . . . . 41 8.1. Transport Translators . . . . . . . . . . . . . . . . . . 41
8.2. Fragmentation and Reassembly in Translators . . . . . . . 41 8.2. Fragmentation and Reassembly in Translators . . . . . . . 42
8.3. Generating RTCP ECN Feedback in Media Transcoders . . . . 44 8.3. Generating RTCP ECN Feedback in Media Transcoders . . . . 44
8.4. Generating RTCP ECN Feedback in Mixers . . . . . . . . . . 45 8.4. Generating RTCP ECN Feedback in Mixers . . . . . . . . . . 45
9. Implementation considerations . . . . . . . . . . . . . . . . 45 9. Implementation considerations . . . . . . . . . . . . . . . . 45
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
10.1. SDP Attribute Registration . . . . . . . . . . . . . . . . 46 10.1. SDP Attribute Registration . . . . . . . . . . . . . . . . 46
10.2. RTP/AVPF Transport Layer Feedback Message . . . . . . . . 46 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 . . . . . . . . . . . . . . . . . . 47
10.5. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 47 10.5. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 47
10.6. STUN attribute . . . . . . . . . . . . . . . . . . . . . . 47 10.6. STUN attribute . . . . . . . . . . . . . . . . . . . . . . 47
10.7. ICE Option . . . . . . . . . . . . . . . . . . . . . . . . 47 10.7. ICE Option . . . . . . . . . . . . . . . . . . . . . . . . 47
11. Security Considerations . . . . . . . . . . . . . . . . . . . 47 11. Security Considerations . . . . . . . . . . . . . . . . . . . 47
12. Examples of SDP Signalling . . . . . . . . . . . . . . . . . . 50 12. Examples of SDP Signalling . . . . . . . . . . . . . . . . . . 50
12.1. Basic SDP Offer/Answer . . . . . . . . . . . . . . . . . . 50 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
skipping to change at page 4, line 18 skipping to change at page 4, line 18
[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
dependencies on the signalling mechanism used to establish the RTP dependencies on the signalling mechanism used to establish the RTP
session, a specification for signalling mechanisms using Session session, a specification for signalling mechanisms using Session
Description Protocol (SDP) [RFC4566] is included. Description Protocol (SDP) [RFC4566] is included.
ECN is getting attention as a method to minimise the impact of ECN can be used to minimise the impact of congestion on real-time
congestion on real-time multimedia traffic. The use of ECN provides multimedia traffic. The use of ECN provides a way for the network to
a way for the network to send a congestion control signal to a media send a congestion control signal to a media transport without having
transport without having to impair the media. Unlike packet loss, to impair the media. Unlike packet loss, ECN signals unambiguously
ECN signals unambiguously indicate congestion to the transport as indicate congestion to the transport as quickly as feedback delays
quickly as feedback delays allow, and without confusing congestion allow, and without confusing congestion with losses that might have
with losses that might have occurred for other reasons such as occurred for other reasons such as transmission errors, packet-size
transmission errors, packet-size errors, routing errors, badly errors, routing errors, badly implemented middleboxes, policy
implemented middleboxes, policy violations and so forth. violations and so forth.
The introduction of ECN into the Internet requires changes to both The introduction of ECN into the Internet requires changes to both
the network and transport layers. At the network layer, IP the network and transport layers. At the network layer, IP
forwarding has to be updated to allow routers to mark packets, rather forwarding has to be updated to allow routers to mark packets, rather
than discarding them in times of congestion [RFC3168]. In addition, than discarding them in times of congestion [RFC3168]. In addition,
transport protocols have to be modified to inform the sender that ECN transport protocols have to be modified to inform the sender that ECN
marked packets are being received, so it can respond to the marked packets are being received, so it can respond to the
congestion. The Transmission Control Protocol (TCP) [RFC3168], congestion. The Transmission Control Protocol (TCP) [RFC3168],
Stream Control Transmission Protocol (SCTP) [RFC4960] and Datagram Stream Control Transmission Protocol (SCTP) [RFC4960] and Datagram
Congestion Control Protocol (DCCP) [RFC4340] have been updated to Congestion Control Protocol (DCCP) [RFC4340] have been updated to
skipping to change at page 18, line 32 skipping to change at page 18, line 32
multiple ECN Feedback Reports packets in an compound RTCP packet. multiple ECN Feedback Reports packets in an compound RTCP packet.
The counters SHALL be initiated to 0 for each new SSRC received. The counters SHALL be initiated to 0 for each new SSRC received.
This to enable detection of ECN-CE marks or Packet loss on the This to enable detection of ECN-CE marks or Packet loss on the
initial report from a specific participant. initial report from a specific participant.
The use of at least 32-bit counters allows even extremely high packet The use of at least 32-bit counters allows even extremely high packet
volume applications to not have wrapping of counters within any volume applications to not have wrapping of counters within any
timescale close to the RTCP reporting intervals. However, 32-bits timescale close to the RTCP reporting intervals. However, 32-bits
are not sufficiently large to disregard the fact that wrappings may are not sufficiently large to disregard the fact that wrappings may
happen during the life time of a long-lived RTP session. Thus happen during the life time of a long-lived RTP session, and
handling of wrapping of these counters MUST be supported. It is implementations need to be written to handle wrapping of the
recommended that implementations uses local representation of these counters. It is recommended that implementations uses local
counters that are longer than 32-bits to enable easy handling of representation of these counters that are longer than 32-bits to
wraps. enable easy handling of wraps.
There is a difference in packet duplication reports between the There is a difference in packet duplication reports between the
packet loss counter that is defined in the Receiver Report Block packet loss counter that is defined in the Receiver Report Block
[RFC3550] and that defined here. To avoid holding state for what RTP [RFC3550] and that defined here. To avoid holding state for what RTP
sequence numbers have been received, [RFC3550] specifies that one can sequence numbers have been received, [RFC3550] specifies that one can
count packet loss by counting the number of received packets and count packet loss by counting the number of received packets and
comparing it to the number of packets expected. As a result a packet comparing it to the number of packets expected. As a result a packet
duplication can hide a packet loss. However, when populating the ECN duplication can hide a packet loss. However, when populating the ECN
Feedback report, a receiver needs to track the sequence numbers Feedback report, a receiver needs to track the sequence numbers
actually received and count duplicates and packet loss separately to actually received and count duplicates and packet loss separately to
skipping to change at page 20, line 11 skipping to change at page 20, line 11
Figure 4: RTCP XR ECN Summary Report Figure 4: RTCP XR ECN Summary Report
The RTCP XR ECN Summary Report contains the following fields: The RTCP XR ECN Summary Report contains the following fields:
BT: Block Type identifying the ECN summary report block. Value is BT: Block Type identifying the ECN summary report block. Value is
[TBA2]. [TBA2].
Reserved: All bits SHALL be set to 0 on transmission and ignored on Reserved: All bits SHALL be set to 0 on transmission and ignored on
reception. reception.
Block Length: The length of the report block. Used to indicate the Block Length: The length of this XR report block, including the
number of report data blocks present in the ECN summary report. header, in 32- bit words minus one. Used to indicate the number
This length will be 5*n, where n is the number of ECN summary of ECN summary report data blocks present in the ECN summary
report blocks, since blocks are a fixed size. The block length report. This length will be 5*n, where n is the number of ECN
MAY be zero if there is nothing to report. Receivers MUST discard summary report blocks, since blocks are a fixed size. The block
reports where the block length is not a multiple of five octets, length MAY be zero if there is nothing to report. Receivers MUST
discard reports where the block length is not a multiple of five,
since these cannot be valid. since these cannot be valid.
SSRC of Media Sender: The SSRC identifying the media sender this SSRC of Media Sender: The SSRC identifying the media sender this
report is for. report is for.
ECT(0) Counter: as in Section 5.1. ECT(0) Counter: as in Section 5.1.
ECT(1) Counter: as in Section 5.1. ECT(1) Counter: as in Section 5.1.
ECN-CE Counter: as in Section 5.1. ECN-CE Counter: as in Section 5.1.
skipping to change at page 28, line 44 skipping to change at page 28, line 44
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 very media dependent. For audio formats, if would make
payloads [I-D.ietf-avt-rtp-no-op], if supported, would be an sense for the sender to mark comfort noise packets or similar.
appropriate choice. For audio formats, if would make sense for For video formats, packets containing P- or B-frames (rather than
the sender to mark comfort noise packets or similar. For video I-frames) would be an appropriate choice. No matter which RTP
formats, packets containing P- or B-frames (rather than I-frames) packets are marked, those packets MUST NOT be sent in duplicate,
would be an appropriate choice. No matter which RTP packets are with and without ECT, since the RTP sequence number is used to
marked, those packets MUST NOT be sent in duplicate, with and identify packets that are received with ECN markings.
without ECT, since the RTP sequence number is used to identify
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
be generated on receipt of the first ECT or ECN-CE marked packet be generated on receipt of the first ECT or ECN-CE marked packet
from a sender that has not previously sent any ECT traffic. Each from a sender that has not previously sent any ECT traffic. Each
regular RTCP report MUST also contain an ECN summary report regular RTCP report MUST also contain an ECN summary report
(Section 5.2). Reception of subsequent ECN-CE marked packets MUST (Section 5.2). Reception of subsequent ECN-CE marked packets MUST
skipping to change at page 31, line 26 skipping to change at page 31, line 26
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 working connectivity rather than necessarily finding the that one has working connectivity rather than necessarily finding the
best ECN capable network path, this procedure is applied after having best ECN capable network path, this procedure is applied after having
performed a successful connectivity check for a candidate, which is performed a successful connectivity check for a candidate, which is
nominated for usage. At that point an additional connectivity check nominated for usage. At that point an additional connectivity check
is performed, sending the "ECN Check" attribute in a STUN packet that is performed, sending the "ECN Check" attribute in a STUN packet that
is ECT marked. On reception of the packet, a STUN server supporting is ECT marked. On reception of the packet, a STUN server supporting
this extension will note the received ECN field value, and send a this extension will note the received ECN field value, and send a
STUN/UDP/IP packet in reply with the ECN field set to not-ECT and STUN/UDP/IP packet in reply with the ECN field set to not-ECT and
including an ECN check attribute. A STUN server that doesn't including an ECN-CHECK attribute. A STUN server that doesn't
understand the extension, or is incapable of reading the ECN values understand the extension, or is incapable of reading the ECN 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 due to various other non ECN related reasons ECT marking, but also due to various other non ECN related reasons
causing 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
skipping to change at page 32, line 38 skipping to change at page 32, line 38
call in amount, to meet that goal for most media flows, setting the 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. 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. 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 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 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 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 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 packets being sent in parallel mode SHALL NOT be ECT marked prior to
verification of the path as ECT. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 20 skipping to change at page 33, line 20
the content is arbitrary. the content is arbitrary.
Reserved: Reserved bits (29 bits) SHALL be set to 0 on transmission, Reserved: Reserved bits (29 bits) SHALL be set to 0 on transmission,
and SHALL be ignored on reception. and SHALL be ignored on reception.
This attribute MAY be included in any STUN request to request the ECN This attribute MAY be included in any STUN request to request the ECN
field to be echoed back. In STUN requests the V bit SHALL be set to field to be echoed back. In STUN requests the V bit SHALL be set to
0. A compliant STUN server receiving a request with the ECN Check 0. A compliant STUN server receiving a request with the ECN Check
attribute SHALL read the ECN field value of the IP/UDP packet the attribute SHALL read the ECN field value of the IP/UDP packet the
request was received in. Upon forming the response the server SHALL request was received in. Upon forming the response the server SHALL
include the ECN Check attribute setting the V bit to valid and include the ECN-CHECK attribute setting the V bit to valid and
include the read value of the ECN field into the ECF field. If the include the read value of the ECN field into the ECF field. If the
STUN responder was unable to ascertain, due to temporary errors, the STUN responder was unable to ascertain, due to temporary errors, the
ECN value of the STUN request, it SHALL set the V bit in the response ECN value of the STUN request, it SHALL set the V bit in the response
to 0. The STUN client may retry immediately. to 0. The STUN client may retry immediately.
The ICE based initialization method does require some special The ICE based initialization method does require some special
consideration when used by a translator. This is especially for consideration when used by a translator. This is especially for
transport translators and translators that fragment or reassemble transport translators and translators that fragment or reassemble
packets, since they do not separate the ECN control loops between the packets, since they do not separate the ECN control loops between the
end-points and the translator. When using ICE-based initiation, such end-points and the translator. When using ICE-based initiation, such
skipping to change at page 33, line 44 skipping to change at page 33, line 44
Alternatively, it must correctly handle remarking of ECT RTP packets Alternatively, it must correctly handle remarking of ECT RTP packets
towards that participant. When a new participant joins the session, towards that participant. When a new participant joins the session,
the translator will perform a check towards the new participant. If the translator will perform a check towards the new participant. If
that is successfully completed the ECT properties of the session are that is successfully completed the ECT properties of the session are
maintained for the other senders in the session. If the check fails maintained for the other senders in the session. If the check fails
then the existing senders will now see a participant that fails to then the existing senders will now see a participant that fails to
receive ECT. Thus the failure detection in those senders will receive ECT. Thus the failure detection in those senders will
eventually detect this. However to avoid misusing the network on the eventually detect this. However to avoid misusing the network on the
path from the translator to the new participant, the translator SHALL path from the translator to the new participant, the translator SHALL
remark the traffic intended to be forwarded from ECT to non-ECT. Any remark the traffic intended to be forwarded from ECT to non-ECT. Any
packet intended to be forward that are ECN-CE marked SHALL be discard packet intended to be forward that are ECN-CE marked SHALL be
and not sent. In cases where the path from a new participant to the discarded and not sent. In cases where the path from a new
translator fails the ECT check then only that sender will not participant to the translator fails the ECT check then only that
contribute any ECT marked traffic towards the translator. sender will not contribute any ECT marked traffic towards the
translator.
7.2.3. Leap of Faith ECT initiation method 7.2.3. Leap of Faith ECT initiation method
This method for initiating ECN usage is a leap of faith that assumes This method for initiating ECN usage is a leap of faith that assumes
that ECN will work on the used path(s). The method is to go directly that ECN will work on the used path(s). The method is to go directly
to "ongoing use of ECN" as defined in Section 7.3. Thus all RTP to "ongoing use of ECN" as defined in Section 7.3. Thus all RTP
packets MAY be marked as ECT and the failure detection MUST be used packets MAY be marked as ECT and the failure detection MUST be used
to detect any case when the assumption that the path was ECT capable to detect any case when the assumption that the path was ECT capable
is wrong. This method is only recommended for controlled is wrong. This method is only recommended for controlled
environments where the whole path(s) between sender and receiver(s) environments where the whole path(s) between sender and receiver(s)
skipping to change at page 35, line 49 skipping to change at page 36, line 5
7.3.3. Response to Congestion Notifications 7.3.3. Response to Congestion Notifications
The reception of RTP packets with ECN-CE marks in the IP header is a The reception of RTP packets with ECN-CE marks in the IP header is a
notification that congestion is being experienced. The default notification that congestion is being experienced. The default
reaction on the reception of these ECN-CE marked packets MUST be to reaction on the reception of these ECN-CE marked packets MUST be to
provide the congestion control algorithm with a congestion provide the congestion control algorithm with a congestion
notification that triggers the algorithm to react as if packet loss notification that triggers the algorithm to react as if packet loss
had occurred. There should be no difference in congestion response had occurred. There should be no difference in congestion response
if ECN-CE marks or packet drops are detected. if ECN-CE marks or packet drops are detected.
We note that there MAY be other reactions to ECN-CE specified in the Other reactions to ECN-CE may be specified in the future, following
future. Such an alternative reaction MUST be specified and IETF review. Detailed designs of such alternative reactions MUST be
considered to be safe for deployment under any restrictions specified in a Standards Track RFC, and be reviewed to ensure the are
specified. A potential example for an alternative reaction could be safe for deployment under any restrictions specified. A potential
emergency communications (such as that generated by first responders, example for an alternative reaction could be emergency communications
as opposed to the general public) in networks where the user has been (such as that generated by first responders, as opposed to the
authorized. A more detailed description of these other reactions, as general public) in networks where the user has been authorized. A
well as the types of congestion control algorithms used by end-nodes, more detailed description of these other reactions, as well as the
is outside of the scope of this document. types of congestion control algorithms used by end-nodes, is outside
of the scope of this document.
Depending on the media format, type of session, and RTP topology Depending on the media format, type of session, and RTP topology
used, there are several different types of congestion control that used, there are several different types of congestion control that
can be used: can be used:
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
skipping to change at page 37, line 37 skipping to change at page 37, line 43
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). The ECN Nonce [RFC3540] is benefit over behaving flows (cheating). The ECN Nonce [RFC3540] is
an 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 that senders
senders acting on the behalf of the network may be reduced due to the act on behalf of the network may be false due to the nature of peer-
nature of peer-to-peer use of RTP. Still a significant portion of to-peer use of RTP. Still a significant portion of RTP senders are
RTP senders are infrastructure devices (for example, streaming media infrastructure devices (for example, streaming media servers) that do
servers) that do have an interest in protecting both service quality have an interest in protecting both service quality and the network.
and the network. Even though there may be cases where the nonce may Even though there may be cases where the nonce may be applicable for
be applicable for RTP, it is not included in this specification. RTP, it is not included in this specification. This is because a
This is because a receiver interested in cheating would simply claim receiver interested in cheating would simply claim to not support the
to not support the nonce, or even ECN itself. It is, however, worth nonce, or even ECN itself. It is, however, worth mentioning that, as
mentioning that, as real-time media is commonly sensitive to real-time media is commonly sensitive to increased delay and packet
increased delay and packet loss, it will be in both the media sender loss, it will be in both the media sender and receivers interest to
and receivers interest to minimise the number and duration of any minimise the number and duration of any congestion events as they
congestion events as they will adversely affect media quality. 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 an 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
skipping to change at page 39, line 5 skipping to change at page 39, line 11
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
mitigation. mitigation.
A sender that detects high packet loss rates for ECT-marked packets A sender that detects high packet loss rates for ECT-marked packets
SHOULD immediately switch to sending packets as not-ECT to determine SHOULD immediately switch to sending packets as not-ECT to determine
if the losses are potentially due to the ECT markings. If the losses if the losses are potentially due to the ECT markings. If the losses
disappear when the ECT-marking is discontinued, the RTP sender should disappear when the ECT-marking is discontinued, the RTP sender should
go back to initiation procedures to attempt to verify the apparent go back to initiation procedures to attempt to verify the apparent
loss of ECN capability of the used path. If a re-initiation fails loss of ECN capability of the used path. If a re-initiation fails
then the two possible actions exist: then two possible actions exist:
1. Periodically retry the ECN initiation to detect if a path change 1. Periodically retry the ECN initiation to detect if a path change
occurs to a path that is ECN capable. occurs to a path that is ECN capable.
2. Renegotiate the session to disable ECN support. This is a choice 2. Renegotiate the session to disable ECN support. This is a choice
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.
skipping to change at page 47, line 21 skipping to change at page 47, line 26
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 (0x8000-0xFFFF) 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 ECN-CHECK STUN attribute defined in Section 7.2.2. The STUN
can currently be found at: http://www.iana.org/assignments/ attribute registry can currently be found at: http://www.iana.org/
stun-parameters/stun-parameters.xhtml. assignments/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"
[RFC6336] 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
of two things: 1) Report a lot of packets as being Congestion of two things: 1) Report a lot of packets as being Congestion
Experience marked, thus forcing the sender into a congestion Experience marked, thus forcing the sender into a congestion
response; or 2) Ensure that the sender disable the usage of ECN by response; or 2) Ensure that the sender disables the usage of ECN
reporting failures to receive ECN by changing the counter fields. by reporting failures to receive ECN by changing the counter
This can also be accomplished by injecting false RTCP packets to fields. This can also be accomplished by injecting false RTCP
the media sender. Reporting a lot of ECN-CE marked traffic is packets to the media sender. Reporting a lot of ECN-CE marked
likely the more efficient denial of service tool as that may traffic is likely the more efficient denial of service tool as
likely force the application to use lowest possible bit-rates. that may likely force the application to use lowest possible bit-
The prevention against an external threat is to integrity protect rates. The prevention against an external threat is to integrity
the RTCP feedback information and authenticate the sender. protect the RTCP feedback information and authenticate the sender.
Information leakage: The ECN feedback mechanism exposes the Information leakage: The ECN feedback mechanism exposes the
receivers perceived packet loss, what packets it considers to be receivers perceived packet loss, what packets it considers to be
ECN-CE marked and its calculation of the ECN-none. This is mostly ECN-CE marked and its calculation of the ECN-none. This is mostly
not considered as sensitive information. If it is considered not considered as sensitive information. If it is considered
sensitive the RTCP feedback should be encrypted. sensitive the RTCP feedback should be encrypted.
Changing the ECN bits: An on-path attacker that sees the RTP packet Changing the ECN bits: An on-path attacker that sees the RTP packet
flow from sender to receiver and who has the capability to change flow from sender to receiver and who has the capability to change
the packets can rewrite ECT into ECN-CE thus forcing the sender or the packets can rewrite ECT into ECN-CE thus forcing the sender or
skipping to change at page 53, line 13 skipping to change at page 53, line 13
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,
November 2003. November 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, Traversal for Offer/Answer Protocols", RFC 5245,
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",
skipping to change at page 53, line 35 skipping to change at page 53, line 38
[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 [RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for
Interactive Connectivity Establishment (ICE) Options", Interactive Connectivity Establishment (ICE) Options",
RFC 6336, July 2011. RFC 6336, July 2011.
14.2. Informative References 14.2. Informative References
[I-D.ietf-avt-rtp-no-op]
Andreasen, F., "A No-Op Payload Format for RTP",
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 [RFC2762] Rosenberg, J. and H. Schulzrinne, "Sampling of the Group
Membership in RTP", RFC 2762, February 2000. 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,
skipping to change at page 54, line 30 skipping to change at page 54, line 28
[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.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
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,
July 2006. July 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
skipping to change at page 56, line 4 skipping to change at page 55, line 40
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
Ingemar Johansson Ingemar Johansson
Ericsson Ericsson
Laboratoriegrand 11 Laboratoriegrand 11
SE-971 28 Lulea SE-971 28 Lulea
SWEDEN SWEDEN
Phone: +46 73 0783289 Phone: +46 73 0783289
Email: ingemar.s.johansson@ericsson.com Email: ingemar.s.johansson@ericsson.com
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
School of Computing Science School of Computing Science
Glasgow G12 8QQ Glasgow G12 8QQ
United Kingdom United Kingdom
Email: csp@csperkins.org Email: csp@csperkins.org
Piers O'Hanlon Piers O'Hanlon
University College London University of Oxford
Computer Science Department Oxford Internet Institute
Gower Street 1 St Giles
London WC1E 6BT Oxford OX1 3JS
United Kingdom United Kingdom
Email: p.ohanlon@cs.ucl.ac.uk Email: piers.ohanlon@oii.ox.ac.uk
Ken Carlberg Ken Carlberg
G11 G11
1600 Clarendon Blvd 1600 Clarendon Blvd
Arlington VA Arlington VA
USA USA
Email: carlberg@g11.org.uk Email: carlberg@g11.org.uk
 End of changes. 29 change blocks. 
93 lines changed or deleted 90 lines changed or added

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