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/ |