draft-ietf-avtcore-ecn-for-rtp-07.txt   draft-ietf-avtcore-ecn-for-rtp-08.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: October 1, 2012 C. Perkins Expires: November 15, 2012 C. Perkins
University of Glasgow University of Glasgow
P. O'Hanlon P. O'Hanlon
University of Oxford University of Oxford
K. Carlberg K. Carlberg
G11 G11
March 30, 2012 May 14, 2012
Explicit Congestion Notification (ECN) for RTP over UDP Explicit Congestion Notification (ECN) for RTP over UDP
draft-ietf-avtcore-ecn-for-rtp-07 draft-ietf-avtcore-ecn-for-rtp-08
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 October 1, 2012. This Internet-Draft will expire on November 15, 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 36 skipping to change at page 3, line 36
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 . . . . . . . 42 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 . . . . . . . . . . . . . . . . . . . . . 46 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 . . . . . . . . . . . . . . . 47
10.4. RTCP XR Report blocks . . . . . . . . . . . . . . . . . . 47 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 . . . . . . . . . . . . . . . . 52
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53
14.1. Normative References . . . . . . . . . . . . . . . . . . . 52 14.1. Normative References . . . . . . . . . . . . . . . . . . . 53
14.2. Informative References . . . . . . . . . . . . . . . . . . 53 14.2. Informative References . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
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
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 can be used to minimise the impact of congestion on real-time ECN can be used to minimise the impact of congestion on real-time
multimedia traffic. The use of ECN provides a way for the network to multimedia traffic. The use of ECN provides a way for the network to
send a congestion control signal to a media transport without having send congestion control signals to the media transport without having
to impair the media. Unlike packet loss, ECN signals unambiguously to impair the media. Unlike packet loss, ECN signals unambiguously
indicate congestion to the transport as quickly as feedback delays indicate congestion to the transport as quickly as feedback delays
allow, and without confusing congestion with losses that might have allow, and without confusing congestion with losses that might have
occurred for other reasons such as transmission errors, packet-size occurred for other reasons such as transmission errors, packet-size
errors, routing errors, badly implemented middleboxes, policy errors, routing errors, badly 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
skipping to change at page 5, line 39 skipping to change at page 5, line 39
[RFC3168] for the definition of the ECT(0) and ECT(1) marks. [RFC3168] for the definition of the ECT(0) and ECT(1) marks.
ECN-CE: ECN Congestion Experienced mark (see [RFC3168]). ECN-CE: ECN Congestion Experienced mark (see [RFC3168]).
ECN Capable Packets: Packets with ECN mark set to either ECT(0), ECN Capable Packets: Packets with ECN mark set to either ECT(0),
ECT(1) or ECN-CE. ECT(1) or ECN-CE.
Not-ECT packets: Packets that are not sent by an ECN capable Not-ECT packets: Packets that are not sent by an ECN capable
transport, and are not ECN-CE marked. transport, and are not ECN-CE marked.
ECN Oblivious Relay: A router or middlebox that treats ECN Capable
Packets no differently from Not-ECT packets.
ECN Capable Queue: A queue that supports ECN-CE marking of ECN- ECN Capable Queue: A queue that supports ECN-CE marking of ECN-
Capable Packets to indicate congestion. Capable Packets to indicate congestion.
ECN Blocking Middlebox: A middlebox that discards ECN-Capable ECN Blocking Middlebox: A middlebox that discards ECN-Capable
Packets. Packets.
ECN Reverting Middlebox: A middlebox that changes ECN-Capable ECN Reverting Middlebox: A middlebox that changes ECN-Capable
Packets to Not-ECT packets by removing the ECN mark. Packets to Not-ECT packets by removing the ECN mark.
Note that RTP mixers or translators that operate in such a manner Note that RTP mixers or translators that operate in such a manner
skipping to change at page 7, line 19 skipping to change at page 7, line 13
feedback [RFC5760]). feedback [RFC5760]).
Application Awareness: When ECN support is provided within the Application Awareness: When ECN support is provided within the
transport protocol, the ability of the application to react to transport protocol, the ability of the application to react to
congestion is limited, since it has little visibility into the congestion is limited, since it has little visibility into the
transport layer. By adding support of ECN to RTP using RTCP transport layer. By adding support of ECN to RTP using RTCP
feedback, the application is made aware of congestion, allowing a feedback, the application is made aware of congestion, allowing a
wider range of reactions in response to that loss. wider range of reactions in response to that loss.
Counting vs Detecting Congestion: TCP, and the protocols derived Counting vs Detecting Congestion: TCP, and the protocols derived
from, it are mainly designed to respond in the same way whether from it, are mainly designed to respond in the same way whether
they experience a burst of congestion indications within one RTT, they experience a burst of congestion indications within one RTT,
or just a single congestion indication. Whereas real-time or just a single congestion indication. Whereas real-time
applications may be concerned with the amount of congestion applications may be concerned with the amount of congestion
experienced, whether it is distributed smoothly or in bursts. experienced, whether it is distributed smoothly or in bursts.
When feedback of ECN was added to TCP [RFC3168], the receiver was When feedback of ECN was added to TCP [RFC3168], the receiver was
designed to flip the echo congestion experienced (ECE) flag to 1 designed to flip the echo congestion experienced (ECE) flag to 1
for a whole RTT then flop it back to zero. Whereas ECN feedback for a whole RTT then flop it back to zero. Whereas ECN feedback
in RTCP will need to report a count of how much congestion has in RTCP will need to report a count of how much congestion has
been experienced within an RTCP reporting period, irrespective of been experienced within an RTCP reporting period, irrespective of
round trip times. round trip times.
These differences will significantly alter the shape of ECN support These differences significantly alter the shape of ECN support in
in RTP-over-UDP compared to ECN support in TCP, SCTP, and DCCP, but RTP-over-UDP compared to ECN support in TCP, SCTP, and DCCP, but do
do not invalidate the need for ECN support. not invalidate the need for ECN support.
ECN support is more important for RTP sessions than, for instance, is ECN support is more important for RTP sessions than, for instance, is
the case for TCP. This is because the impact of packet loss in real- the case for many applications over TCP. This is because the impact
time audio-visual media flows is highly visible to users. Effective of packet loss in real-time audio-visual media flows is highly
ECN support for RTP flows running over UDP will allow real-time visible to users. For TCP-based applications, however, TCP will
audio-visual applications to respond to the onset of congestion retransmit lost packets, and while extra delay is incurred by having
packets dropped rather than ECN-CE marked, the loss is repaired.
Effective ECN support for RTP flows running over UDP will allow real-
time audio-visual applications to respond to the onset of congestion
before routers are forced to drop packets, allowing those before routers are forced to drop packets, allowing those
applications to control how they reduce their transmission rate, and applications to control how they reduce their transmission rate, and
hence media quality, rather than responding to, and trying to conceal hence media quality, rather than responding to, and trying to conceal
the effects of unpredictable packet loss. Furthermore, widespread the effects of unpredictable packet loss. Furthermore, widespread
deployment for ECN and active queue management in routers, should it deployment for ECN and active queue management in routers, should it
occur, can potentially reduce unnecessary queueing delays in routers, occur, can potentially reduce unnecessary queueing delays in routers,
lowering the round-trip time and benefiting interactive applications lowering the round-trip time and benefiting interactive applications
of RTP, such as voice telephony. of RTP, such as voice telephony.
3.1. Requirements 3.1. Requirements
Considering ECN, transport protocols supporting ECN, and RTP based Considering ECN, transport protocols supporting ECN, and RTP based
applications one can create a set of requirements that must be applications one can create a set of requirements that must be
satisfied to at least some degree if ECN is to used by RTP over UDP. satisfied to at least some degree if ECN is to be used by RTP over
UDP.
o REQ 1: A mechanism MUST exist to negotiate and initiate the use of o REQ 1: A mechanism must exist to negotiate and initiate the use of
ECN for RTP/UDP/IP sessions so that an RTP sender will not send ECN for RTP/UDP/IP sessions so that an RTP sender will not send
packets with ECT in the IP header unless it knows that all packets with ECT in the IP header unless it knows that all
potential receivers will understand any ECN-CE indications they potential receivers will understand any ECN-CE indications they
might receive. might receive.
o REQ 2: A mechanism MUST exist to feed back the reception of any o REQ 2: A mechanism must exist to feed back the reception of any
packets that are ECN-CE marked to the packet sender. packets that are ECN-CE marked to the packet sender.
o REQ 3: The provided mechanism SHOULD minimise the possibility of o REQ 3: The provided mechanism should minimise the possibility of
cheating (either by the sender or receiver). cheating (either by the sender or receiver).
o REQ 4: Some detection and fallback mechanism SHOULD exist to avoid o REQ 4: Some detection and fallback mechanism should exist to avoid
loss of communication due to the attempted usage of ECN in case an loss of communication due to the attempted usage of ECN in case an
intermediate node clears ECT or drops packets that are ECT marked. intermediate node clears ECT or drops packets that are ECT marked.
o REQ 5: Negotiation of ECN SHOULD NOT significantly increase the o REQ 5: Negotiation of ECN should not significantly increase the
time taken to negotiate and set-up the RTP session (an extra RTT time taken to negotiate and set-up the RTP session (an extra RTT
before the media can flow is unlikely to be acceptable for some before the media can flow is unlikely to be acceptable for some
use cases). use cases).
o REQ 6: Negotiation of ECN SHOULD NOT cause media clipping at the o REQ 6: Negotiation of ECN should not cause media clipping at the
start of a session. start of a session.
The following sections describes how these requirements can be met The following sections describes how these requirements can be met
for RTP over UDP. for RTP over UDP.
3.2. Applicability 3.2. Applicability
The use of ECN with RTP over UDP is dependent on negotiation of ECN The use of ECN with RTP over UDP is dependent on negotiation of ECN
capability between the sender and receiver(s), and validation of ECN capability between the sender and receiver(s), and validation of ECN
support in all elements of the network path(s) traversed. RTP is support in all elements on the network path(s) traversed. RTP is
used in a heterogeneous range of network environments and topologies, used in a heterogeneous range of network environments and topologies,
with various different signalling protocols. The mechanisms defined with various different signalling protocols. The mechanisms defined
here make it possible to verify support for ECN in each of these here make it possible to verify support for ECN in each of these
environments, and irrespective of the topology. environments, and irrespective of the topology.
Due to the need for each RTP sender that intends to use ECN with RTP Due to the need for each RTP sender that intends to use ECN with RTP
to track all participants in the RTP session, the sub-sampling of the to track all participants in the RTP session, the sub-sampling of the
group membership as specified by "Sampling of the Group Membership in group membership as specified by "Sampling of the Group Membership in
RTP" [RFC2762] MUST NOT be used. RTP" [RFC2762] MUST NOT be used.
skipping to change at page 12, line 27 skipping to change at page 12, line 27
To ensure timely feedback of ECN-CE marked packets when needed, this To ensure timely feedback of ECN-CE marked packets when needed, this
mechanism requires support for the RTP/AVPF profile [RFC4585] or any mechanism requires support for the RTP/AVPF profile [RFC4585] or any
of its derivatives, such as RTP/SAVPF [RFC5124]. The standard RTP/ of its derivatives, such as RTP/SAVPF [RFC5124]. The standard RTP/
AVP profile [RFC3551] does not allow any early or immediate AVP profile [RFC3551] does not allow any early or immediate
transmission of RTCP feedback, and has a minimal RTCP interval whose transmission of RTCP feedback, and has a minimal RTCP interval whose
default value (5 seconds) is many times the normal RTT between sender default value (5 seconds) is many times the normal RTT between sender
and receiver. and receiver.
3.3. Interoperability 3.3. Interoperability
The interoperability requirements for this specification are that To ensure interoperability for this specification there is need for
there is at least one common interoperability point for all at least one common initilization method for all implementations.
implementations. Since initialization using RTP and RTCP Since initialization using RTP and RTCP (Section 7.2.1) is the one
(Section 7.2.1) is the one method that works in all cases, although method that works in all cases, although is not optimal for all uses,
is not optimal for all uses, it is selected as mandatory to implement it is selected as mandatory to implement this initialisation method.
this initialisation method. This method requires both the RTCP XR This method requires both the RTCP XR extension and the ECN feedback
extension and the ECN feedback format, which require the RTP/AVPF format, which require the RTP/AVPF profile to ensure timely feedback.
profile to ensure timely feedback.
When one considers all the uses of ECN for RTP it is clear that there When one considers all the uses of ECN for RTP it is clear that there
exist congestion control mechanisms that are receiver driven only exist congestion control mechanisms that are receiver driven only
(Section 7.3.3). These congestion control mechanism do not require (Section 7.3.3). These congestion control mechanisms do not require
timely feedback of congestion events to the sender. If such a timely feedback of congestion events to the sender. If such a
congestion control mechanism is combined with an initialization congestion control mechanism is combined with an initialization
method that also doesn't require timely feedback using RTCP, like the method that also doesn't require timely feedback using RTCP, like the
leap of faith or the ICE based method then neither the ECN feedback leap of faith (Section 7.2.3) or the ICE based method (Section 7.2.2)
format nor the RTP/AVPF profile would appear to be needed. However, then neither the ECN feedback format nor the RTP/AVPF profile would
fault detection can be greatly improved by using receiver side appear to be needed. However, fault detection can be greatly
detection (Section 7.4.1) and early reporting of such cases using the improved by using receiver side detection (Section 7.4.1) and early
ECN feedback mechanism. reporting of such cases using the ECN feedback mechanism.
For interoperability we mandate the implementation of the RTP/AVPF For interoperability we mandate the implementation of the RTP/AVPF
profile, with both RTCP extensions and the necessary signalling to profile, with both RTCP extensions and the necessary signalling to
support a common operations mode. This specification recommends the support a common operations mode. This specification recommends the
use of RTP/AVPF in all cases as negotiation of the common use of RTP/AVPF in all cases as negotiation of the common
interoperability point requires RTP/AVPF, mixed negotiation of RTP/ interoperability point requires RTP/AVPF, mixed negotiation of RTP/
AVP and RTP/AVPF depending on other SDP attributes in the same media AVP and RTP/AVPF depending on other SDP attributes in the same media
block is difficult, and the fact that fault detection can be improved block is difficult, and the fact that fault detection can be improved
when using RTP/AVPF. when using RTP/AVPF.
skipping to change at page 13, line 47 skipping to change at page 13, line 46
must be agreed is the capability of a participant to support ECN. must be agreed is the capability of a participant to support ECN.
Note that all participants having the capability of supporting ECN Note that all participants having the capability of supporting ECN
does not necessarily imply that ECN is usable in an RTP session, does not necessarily imply that ECN is usable in an RTP session,
since there may be middleboxes on the path between the participants since there may be middleboxes on the path between the participants
which don't pass ECN-marked packets (for example, a firewall that which don't pass ECN-marked packets (for example, a firewall that
blocks traffic with the ECN bits set). This document defines the blocks traffic with the ECN bits set). This document defines the
information that needs to be negotiated, and provides a mapping to information that needs to be negotiated, and provides a mapping to
SDP for use in both declarative and offer/answer contexts. SDP for use in both declarative and offer/answer contexts.
When a sender joins a session for which all participants claim to When a sender joins a session for which all participants claim to
support ECN, it must verify if that support is usable. There are support ECN, it needs to verify that the ECN support is usable.
three ways in which this verification can be done: There are 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 of the IP header set to ECT(0) or ECT(1). Each with the ECN field of the IP header set to ECT(0) or ECT(1). Each
receiver will then send an RTCP feedback packet indicating the receiver will then send an RTCP feedback packet indicating the
reception of the ECT marked RTP packets. Upon reception of this reception of the ECT marked RTP packets. Upon reception of this
feedback from each receiver it knows of, the sender can consider feedback from each receiver it knows of, the sender can consider
ECN functional for its traffic. Each sender does this ECN functional for its traffic. Each sender does this
verification independently. When a new receiver joins an existing verification independently. When a new receiver joins an existing
RTP session, it will send RTCP reports in the usual manner. If RTP session, it will send RTCP reports in the usual manner. If
those RTCP reports include ECN information, verification will have those RTCP reports include ECN information, verification will have
skipping to change at page 22, line 36 skipping to change at page 22, line 36
init-list = init-value *("," init-value) init-list = init-value *("," init-value)
init-value = "rtp" / "ice" / "leap" / init-ext init-value = "rtp" / "ice" / "leap" / init-ext
init-ext = token init-ext = token
parm-list = parm-value *(";" SP parm-value) parm-list = parm-value *(";" SP parm-value)
parm-value = mode / ect / parm-ext parm-value = mode / ect / parm-ext
mode = "mode=" ("setonly" / "setread" / "readonly") mode = "mode=" ("setonly" / "setread" / "readonly")
ect = "ect=" ("0" / "1" / "random") ect = "ect=" ("0" / "1" / "random")
parm-ext = parm-name "=" parm-value-ext parm-ext = parm-name "=" parm-value-ext
parm-name = token parm-name = token
parm-value-ext = token / quoted-string parm-value-ext = token / quoted-string
quoted-string = DQUOTE *qdtext DQUOTE quoted-string = ( DQUOTE *qdtext DQUOTE )
qdtext = %x20-21 / %x23-7E / %x80-FF qdtext = %x20-21 / %x23-5B / %x5D-7E / quoted-pair / UTF8-NONASCII
; any 8-bit ASCII except <"> ; No DQUOTE and no "\"
quoted-pair = "\\" / ( "\" DQUOTE )
UTF8-NONASCII = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4
; external references: ; external references:
; token: from RFC 4566 ; token: from RFC 4566
; SP and DQUOTE from RFC 5234 ; SP and DQUOTE from RFC 5234
; UTF8-1, UTF8-2, UTF8-3, and UTF8-4 from RFC 3629
Figure 5: ABNF Grammar for the "a=ecn-capable-rtp" attribute Figure 5: ABNF Grammar for the "a=ecn-capable-rtp" attribute
Note the above quoted string construct has an escaping mechanism for
strings containing ". This uses \ (back slash) as escaping
mechanism, i.e. in a string that contains a " it is replaced by \"
(backslash double quote) and any \ (backslash) is replaced by \\
(backslash backslash) when put into the double quotes as defined by
the above syntax. The string in a quoted string is UTF-8 [RFC3629].
6.1.1. Use of "a=ecn-capable-rtp:" with the Offer/Answer Model 6.1.1. Use of "a=ecn-capable-rtp:" with the Offer/Answer Model
When SDP is used with the offer/answer model [RFC3264], the party When SDP is used with the offer/answer model [RFC3264], the party
generating the SDP offer MUST insert an "a=ecn-capable-rtp" attribute generating the SDP offer MUST insert an "a=ecn-capable-rtp" attribute
into the media section of the SDP offer of each RTP session for which into the media section of the SDP offer of each RTP session for which
it wishes to use ECN. The attribute includes one or more ECN it wishes to use ECN. The attribute includes one or more ECN
initiation methods in a comma separated list in decreasing order of initiation methods in a comma separated list in decreasing order of
preference, with any number of optional parameters following. The preference, with any number of optional parameters following. The
answering party compares the list of initiation methods in the offer answering party compares the list of initiation methods in the offer
with those it supports in order of preference. If there is a match, with those it supports in order of preference. If there is a match,
skipping to change at page 36, line 7 skipping to change at page 36, line 18
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.
Other reactions to ECN-CE may be specified in the future, following Other reactions to ECN-CE may be specified in the future, following
IETF review. Detailed designs of such alternative reactions MUST be IETF review. Detailed designs of such alternative reactions MUST be
specified in a Standards Track RFC, and be reviewed to ensure the are specified in a Standards Track RFC, and be reviewed to ensure they
safe for deployment under any restrictions specified. A potential are safe for deployment under any restrictions specified. A
example for an alternative reaction could be emergency communications potential example for an alternative reaction could be emergency
(such as that generated by first responders, as opposed to the communications (such as that generated by first responders, as
general public) in networks where the user has been authorized. A opposed to the general public) in networks where the user has been
more detailed description of these other reactions, as well as the authorized. A more detailed description of these other reactions, as
types of congestion control algorithms used by end-nodes, is outside well as the types of congestion control algorithms used by end-nodes,
of the scope of this document. 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 46, line 13 skipping to change at page 46, line 18
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.
10.1. SDP Attribute Registration 10.1. SDP Attribute Registration
Following the guidelines in [RFC4566], the IANA is requested to Following the guidelines in [RFC4566], the IANA is requested to
register one new SDP attribute: register one new media-level SDP attribute:
o Contact name, email address and telephone number: Authors of o Contact name, email address and telephone number: Authors of
RFCXXXX RFCXXXX
o Attribute-name: ecn-capable-rtp o Attribute-name: ecn-capable-rtp
o Type of attribute: media-level o Type of attribute: media-level
o Subject to charset: no o Subject to charset: no
This attribute defines the ability to negotiate the use of ECT (ECN This attribute defines the ability to negotiate the use of ECT (ECN
capable transport) for RTP flows running over UDP/IP. This attribute capable transport) for RTP flows running over UDP/IP. This attribute
should be put in the SDP offer if the offering party wishes to is put in the SDP offer if the offering party wishes to receive an
receive an ECT flow. The answering party should include the ECT flow. The answering party then include the attribute in the
attribute in the answer if it wish to receive an ECT flow. If the answer if it wishes to receive an ECT flow. If the answerer does not
answerer does not include the attribute then ECT MUST be disabled in include the attribute then ECT MUST be disabled in both directions.
both directions.
10.2. RTP/AVPF Transport Layer Feedback Message 10.2. RTP/AVPF Transport Layer Feedback Message
The IANA is requested to register one new RTP/AVPF Transport Layer The IANA is requested to register one new RTP/AVPF Transport Layer
Feedback Message in the table of FMT values for RTPFB Payload Types Feedback Message in the table of FMT values for RTPFB Payload Types
[RFC4585] as defined in Section 5.1: [RFC4585] as defined in Section 5.1:
Name: RTCP-ECN-FB Name: RTCP-ECN-FB
Long name: RTCP ECN Feedback Long name: RTCP ECN Feedback
Value: TBA1 Value: TBA1
skipping to change at page 49, line 34 skipping to change at page 49, line 43
other traffic out of the way without being affected too other traffic out of the way without being affected too
negatively. However, we do note that a media sender still needs negatively. However, we do note that a media sender still needs
to implement congestion control functions to prevent the media to implement congestion control functions to prevent the media
from being badly affected by congestion events. Thus the from being badly affected by congestion events. Thus the
misbehaving sender is getting a unfair share. This can only be misbehaving sender is getting a unfair share. This can only be
detected and potentially prevented by network monitoring and detected and potentially prevented by network monitoring and
administrative entities. See Section 7 of [RFC3168] for more administrative entities. See Section 7 of [RFC3168] for more
discussion of this issue. discussion of this issue.
We note that the end-point security functions needed to prevent an We note that the end-point security functions needed to prevent an
external attacker from inferring with the signalling are source external attacker from interfering with the signalling are source
authentication and integrity protection. To prevent information authentication and integrity protection. To prevent information
leakage from the feedback packets encryption of the RTCP is also leakage from the feedback packets encryption of the RTCP is also
needed. For RTP there exist multiple solutions possible depending on needed. For RTP there exist multiple solutions possible depending on
the application context. Secure RTP (SRTP) [RFC3711] does satisfy the application context. Secure RTP (SRTP) [RFC3711] does satisfy
the requirement to protect this mechanism despite only providing the requirement to protect this mechanism. Note, however, that when
authentication if a entity is within the security context or not. using SRTP in group communication scenarios, different parties might
IPsec [RFC4301] and DTLS [RFC6347] can also provide the necessary share the same security context; in this case, the authentication
security functions. mechanism only shows that one of those parties is involved, not
necessarily which one. IPsec [RFC4301] and DTLS [RFC6347] can also
provide the necessary security functions.
The signalling protocols used to initiate an RTP session also need to The signalling protocols used to initiate an RTP session also need to
be source authenticated and integrity protected to prevent an be source authenticated and integrity protected to prevent an
external attacker from modifying any signalling. Here an appropriate external attacker from modifying any signalling. Here an appropriate
mechanism to protect the used signalling needs to be used. For SIP/ mechanism to protect the used signalling needs to be used. For SIP/
SDP ideally S/MIME [RFC5751] would be used. However, with the SDP ideally S/MIME [RFC5751] would be used. However, with the
limited deployment a minimal mitigation strategy is to require use of limited deployment a minimal mitigation strategy is to require use of
SIPS (SIP over TLS) [RFC3261] [RFC5630] to at least accomplish hop- SIPS (SIP over TLS) [RFC3261] [RFC5630] to at least accomplish hop-
by-hop protection. by-hop protection.
skipping to change at page 53, line 13 skipping to change at page 54, 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.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[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.
 End of changes. 32 change blocks. 
69 lines changed or deleted 83 lines changed or added

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