draft-ietf-avtcore-ecn-for-rtp-00.txt   draft-ietf-avtcore-ecn-for-rtp-01.txt 
Network Working Group M. Westerlund Network Working Group M. Westerlund
Internet-Draft I. Johansson Internet-Draft I. Johansson
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: August 1, 2011 C. Perkins Expires: September 15, 2011 C. Perkins
University of Glasgow University of Glasgow
P. O'Hanlon P. O'Hanlon
UCL UCL
K. Carlberg K. Carlberg
G11 G11
January 28, 2011 March 14, 2011
Explicit Congestion Notification (ECN) for RTP over UDP Explicit Congestion Notification (ECN) for RTP over UDP
draft-ietf-avtcore-ecn-for-rtp-00 draft-ietf-avtcore-ecn-for-rtp-01
Abstract Abstract
This document specifies how explicit congestion notification (ECN) This document specifies how explicit congestion notification (ECN)
can be used with RTP/UDP flows that use RTCP as feedback mechanism. can be used with Real-time Transport Protocol (RTP) over UDP flows
It defines one RTCP XR extension for ECN summary, a RTCP transport that use RTP Control Protocol (RTCP) as feedback mechanism. It
feedback format for timely reporting of congestion events, and an defines one RTP Control Protocol Extended Reports (RTCP XR) extension
STUN extension used in the optional initilization method using ICE. for ECN summary, a RTCP transport feedback format for timely
Signalling and procedures for negotiation of capabilities and reporting of congestion events, and an Session Traversal Utilities
initilization methods are also defined. for NAT (STUN) extension used in the optional initilization method
using Interactive Connectivity Establishment (ICE). Signalling and
procedures for negotiation of capabilities and initilization methods
are also defined.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 1, 2011. This Internet-Draft will expire on September 15, 2011.
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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
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 . . . . . . . . 5 3. Discussion, Requirements, and Design Rationale . . . . . . . . 6
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Interoperability . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . 20
6.1. Signalling ECN Capability using SDP . . . . . . . . . . . 20 6.1. Signalling ECN Capability using SDP . . . . . . . . . . . 20
6.2. RTCP Feedback SDP Parameter . . . . . . . . . . . . . . . 24 6.2. RTCP Feedback SDP Parameter . . . . . . . . . . . . . . . 24
6.3. XR Block SDP Parameter . . . . . . . . . . . . . . . . . . 24 6.3. XR Block SDP Parameter . . . . . . . . . . . . . . . . . . 25
6.4. ICE Parameter to Signal ECN Capability . . . . . . . . . . 24 6.4. ICE Parameter to Signal ECN Capability . . . . . . . . . . 25
7. Use of ECN with RTP/UDP/IP . . . . . . . . . . . . . . . . . . 25 7. Use of ECN with RTP/UDP/IP . . . . . . . . . . . . . . . . . . 25
7.1. Negotiation of ECN Capability . . . . . . . . . . . . . . 25 7.1. Negotiation of ECN Capability . . . . . . . . . . . . . . 26
7.2. Initiation of ECN Use in an RTP Session . . . . . . . . . 25 7.2. Initiation of ECN Use in an RTP Session . . . . . . . . . 26
7.3. Ongoing Use of ECN Within an RTP Session . . . . . . . . . 31 7.3. Ongoing Use of ECN Within an RTP Session . . . . . . . . . 32
7.4. Detecting Failures . . . . . . . . . . . . . . . . . . . . 34 7.4. Detecting Failures . . . . . . . . . . . . . . . . . . . . 35
8. Processing RTCP ECN Feedback in RTP Translators and Mixers . . 37 8. Processing RTCP ECN Feedback in RTP Translators and Mixers . . 38
8.1. Fragmentation and Reassembly in Translators . . . . . . . 37 8.1. Fragmentation and Reassembly in Translators . . . . . . . 38
8.2. Generating RTCP ECN Feedback in Media Transcoders . . . . 39 8.2. Generating RTCP ECN Feedback in Media Transcoders . . . . 40
8.3. Generating RTCP ECN Feedback in Mixers . . . . . . . . . . 40 8.3. Generating RTCP ECN Feedback in Mixers . . . . . . . . . . 41
9. Implementation considerations . . . . . . . . . . . . . . . . 41 9. Implementation considerations . . . . . . . . . . . . . . . . 42
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
10.1. SDP Attribute Registration . . . . . . . . . . . . . . . . 41 10.1. SDP Attribute Registration . . . . . . . . . . . . . . . . 42
10.2. RTP/AVPF Transport Layer Feedback Message . . . . . . . . 41 10.2. RTP/AVPF Transport Layer Feedback Message . . . . . . . . 42
10.3. RTCP Feedback SDP Parameter . . . . . . . . . . . . . . . 42 10.3. RTCP Feedback SDP Parameter . . . . . . . . . . . . . . . 43
10.4. RTCP XR Report blocks . . . . . . . . . . . . . . . . . . 42 10.4. RTCP XR Report blocks . . . . . . . . . . . . . . . . . . 43
10.5. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 42 10.5. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 43
10.6. STUN attribute . . . . . . . . . . . . . . . . . . . . . . 42 10.6. STUN attribute . . . . . . . . . . . . . . . . . . . . . . 43
10.7. ICE Option . . . . . . . . . . . . . . . . . . . . . . . . 42 10.7. ICE Option . . . . . . . . . . . . . . . . . . . . . . . . 43
11. Security Considerations . . . . . . . . . . . . . . . . . . . 42 11. Security Considerations . . . . . . . . . . . . . . . . . . . 43
12. Examples of SDP Signalling . . . . . . . . . . . . . . . . . . 45 12. Examples of SDP Signalling . . . . . . . . . . . . . . . . . . 46
12.1. Basic SDP Offer/Answer . . . . . . . . . . . . . . . . . . 45 12.1. Basic SDP Offer/Answer . . . . . . . . . . . . . . . . . . 46
12.2. Declarative Multicast SDP . . . . . . . . . . . . . . . . 47 12.2. Declarative Multicast SDP . . . . . . . . . . . . . . . . 48
13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 48 13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 49
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50
14.1. Normative References . . . . . . . . . . . . . . . . . . . 49 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50
14.2. Informative References . . . . . . . . . . . . . . . . . . 50 15.1. Normative References . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 15.2. Informative References . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
1. Introduction 1. Introduction
This document outlines how Explicit Congestion Notification (ECN) This document outlines how Explicit Congestion Notification (ECN)
[RFC3168] can be used for RTP [RFC3550] flows running over UDP/IP [RFC3168] can be used for Real-time Transport Protocol (RTP)
which use RTCP as a feedback mechanism. The solution consists of [RFC3550] flows running over UDP/IP which use RTP Control Protocol
feedback of ECN congestion experienced markings to the sender using (RTCP) as a feedback mechanism. The solution consists of feedback of
RTCP, verification of ECN functionality end-to-end, and how to ECN congestion experienced markings to the sender using RTCP,
initiate ECN usage. The initiation process will have some verification of ECN functionality end-to-end, and how to initiate ECN
dependencies on the signalling mechanism used to establish the RTP usage. The initiation process will have some dependencies on the
session, a specification for signalling mechanisms using SDP is signalling mechanism used to establish the RTP session, a
included. specification for signalling mechanisms using Session Description
Protocol (SDP) [RFC4566] is included.
ECN is getting attention as a method to minimise the impact of ECN is getting attention as a method to minimise the impact of
congestion on real-time multimedia traffic. When ECN is used, the congestion on real-time multimedia traffic. When ECN is used, the
network can signal to applications that congestion is occurring, network can signal to applications that congestion is occurring,
whether that congestion is due to queuing at a congested link, whether that congestion is due to queuing at a congested link,
limited resources and coverage on a radio link, or other reasons. limited resources and coverage on a radio link, or other reasons.
ECN provides a way for networks to send congestion control signals to ECN provides a way for networks to send congestion control signals to
a media transport without having to impair the media. Unlike losses, a media transport without having to impair the media. Unlike losses,
the signals unambiguously indicate congestion to the transport as the signals unambiguously indicate congestion to the transport as
skipping to change at page 5, line 4 skipping to change at page 5, line 5
The remainder of this memo is structured as follows. We start by The remainder of this memo is structured as follows. We start by
describing the conventions, definitions and acronyms used in this describing the conventions, definitions and acronyms used in this
memo in Section 2, and the design rationale and applicability in memo in Section 2, and the design rationale and applicability in
Section 3. Section 4 provides an overview of how ECN is used with Section 3. Section 4 provides an overview of how ECN is used with
RTP over UDP. Then the definition of the RTCP extensions for ECN RTP over UDP. Then the definition of the RTCP extensions for ECN
feedback in Section 5. Then the SDP signalling extensions required feedback in Section 5. Then the SDP signalling extensions required
are specified Section 6.Then the full details of how ECN is used with are specified Section 6.Then the full details of how ECN is used with
RTP over UDP is defined in Section 7. In Section 8 we discuss how RTP over UDP is defined in Section 7. In Section 8 we discuss how
RTCP ECN feedback is handled in RTP translators and mixers. RTCP ECN feedback is handled in RTP translators and mixers.
Section 9 discusses some implementation considerations, Section 10 Section 9 discusses some implementation considerations, Section 10
lists IANA considerations, and Section 11 discusses the security lists IANA considerations, and Section 11 discusses the security
considerations. considerations.
2. Conventions, Definitions and Acronyms 2. Conventions, Definitions and Acronyms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119].
Abbreviations Abbreviations
o ECN: Explicit Congestion Notification o ECN: Explicit Congestion Notification
o ECT: ECN Capable Transport o ECT: ECN Capable Transport
o ECN-CE: ECN Congestion Experienced o ECN-CE: ECN Congestion Experienced
o not-ECT: Not ECN Capable Transport o not-ECT: Not ECN Capable Transport
This document uses the terms sender and receiver according to the
following definition:
Sender: Sender of RTP packets carrying an encoded media stream. The
sender has the possibility to effect how this transmission is
performed. It is one end-point of the ECN control loop.
Receiver: A receiver of RTP packets with the intention to consume
the media stream in some form. It sends RTCP feedback on the
received stream. It is the other end-point of the ECN control
loop.
Note: RTP mixers or translators that operate in such a manner that
they terminate or split the ECN control loop will take on the role of
receivers or senders. This is further discussed in Section 3.2.
The meaning of the term ECN support depends on which entity between The meaning of the term ECN support depends on which entity between
the sender and receiver (inclusive) that is considered. We the sender and receiver (inclusive) that is considered. We
distinguish between: distinguish between:
o ECN-Capable Host: Sender or receiver of media. o ECN-Capable Host: Sender or receiver of media.
o ECN-Capable Transport: ECT = all ends are ECN capable hosts. o ECN-Capable Transport: ECT = all ends are ECN capable hosts.
o ECN-Capable Packets: Packets are either ECT or CE. o ECN-Capable Packets: Packets are either ECT or CE.
skipping to change at page 8, line 28 skipping to change at page 8, line 46
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 of 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, all of which need to be with various different signalling protocols, all of which need to be
verified to support ECN before it can be used. verified to support ECN before it can be used.
Due to the need for each RTP sender that intended to use ECN with RTP
to track all participants in the RTP session the sub-sampling of the
group membership as specified by "Sampling of the Group Membership in
RTP" [RFC2762] MUST NOT be used.
The usage of ECN is further dependent on a capability of the RTP The usage of ECN is further dependent on a capability of the RTP
media flow to react to congestion signalled by ECN marked packets. media 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 is a standard unicast flow. ECN may be
used with RTP in this topology in an analogous manner to its use used with RTP in this topology in an analogous manner to its use
skipping to change at page 9, line 7 skipping to change at page 9, line 30
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 sender and unicast RTCP feedback from
receivers. RTCP is designed to scale to large group sizes while receivers. RTCP is designed to scale to large group sizes while
avoiding feedback implosion (see Section 6.2 of [RFC3550], avoiding feedback implosion (see Section 6.2 of [RFC3550],
[RFC4585], and [RFC5760]), and can be used by a sender to [RFC4585], and [RFC5760]), and can be used by a sender to
determine if all its receivers, and the network paths to those 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 known receivers support ECN, and
and irrespective of whether the paths from other senders to their irrespective of whether the paths from other senders to their
receivers support ECN. Note that group membership may change receivers support ECN. "all its known receivers" are all the SSRCs
during the lifetime of a multicast RTP session, potentially that the RTP sender has received RTP or RTCP from the last five
introducing new receivers that are not ECN capable or have a path reporting intervals, i.e. they are not timed out. Note that group
that doesn't support ECN. Senders must use the mechanisms membership may change during the lifetime of a multicast RTP
described in Section 7.4 to monitor that all receivers continue to session, potentially introducing new receivers that are not ECN
support ECN, and they need to fallback to non-ECN use if any capable or have a path that doesn't support ECN. Senders must use
senders do not. the mechanisms described in Section 7.4 to monitor that all
receivers continue to support ECN, and they need to fallback to
non-ECN use if any senders do not.
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 do not modify the There are two types of RTP translator: those do not modify the
media stream, and are concerned with transport parameters, for media stream, and are concerned with transport parameters, for
example a multicast to unicast gateway; and those that do modify example a multicast to unicast gateway; and those that do modify
the media stream, for example transcoding between different media the media stream, for example transcoding between different media
codecs. A single RTP session traverses the translator, and the codecs. A single RTP session traverses the translator, and the
translator must rewrite RTCP messages passing through it to match translator must rewrite RTCP messages passing through it to match
skipping to change at page 18, line 27 skipping to change at page 19, line 8
The CE counter is actually more robust for packet duplication. The CE counter is actually more robust for packet duplication.
Adding each received CE marked packet to the counter is not an issue. Adding each received CE marked packet to the counter is not an issue.
If one of the clones was CE marked that is still a indication of If one of the clones was CE marked that is still a indication of
congestion. Packet duplication has potential impact on the ECN congestion. Packet duplication has potential impact on the ECN
verification. Thus the sum of packets reported may be higher than verification. Thus the sum of packets reported may be higher than
the number sent. However, most detections are still applicable. the number sent. However, most detections are still applicable.
5.2. RTCP XR Report block for ECN summary information 5.2. RTCP XR Report block for ECN summary information
This report block combined with RTCP SR or RR report blocks carries This unilateral XR report block combined with RTCP SR or RR report
the same information as the ECN Feedback Packet and shall be based on blocks carries the same information as the ECN Feedback Packet and
the same underlying information. However, there is a difference in shall be based on the same underlying information. However, there is
semantics between the feedback format and this XR version. Where the a difference in semantics between the feedback format and this XR
feedback format is intended to report on a CE mark as soon as version. Where the feedback format is intended to report on a CE
possible, this extended report is for the regular RTCP report and mark as soon as possible, this extended report is for the regular
continuous verification of the ECN functionality end-to-end. RTCP report and continuous verification of the ECN functionality end-
to-end.
The ECN Summary report block consists of one report block header: The ECN Summary report block consists of one report block header:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT | Reserved | Block Length | | BT | Reserved | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
and then followed of one or more of the following report data blocks: and then followed of one or more of the following report data blocks:
skipping to change at page 20, line 18 skipping to change at page 20, line 42
the negotiation of the ECN for RTP support when using SDP. This the negotiation of the ECN for RTP support when using SDP. This
include one SDP attribute "ecn-capable-rtp" that negotiates the include one SDP attribute "ecn-capable-rtp" that negotiates the
actual operation of ECN for RTP. Two SDP signalling parameters are actual operation of ECN for RTP. Two SDP signalling parameters are
defined to indicate the usage of the RTCP XR ECN summary block and defined to indicate the usage of the RTCP XR ECN summary block and
the AVPF feedback format for ECN. One ICE option SDP reprensenation the AVPF feedback format for ECN. One ICE option SDP reprensenation
is also defined. is also defined.
6.1. Signalling ECN Capability using SDP 6.1. Signalling ECN Capability using SDP
One new SDP attribute, "a=ecn-capable-rtp", is defined. This is a One new SDP attribute, "a=ecn-capable-rtp", is defined. This is a
media level attribute, which MUST NOT be used at the session level. media level attribute, thus it is normally included as part of the
It is not subject to the character set chosen. The aim of this media description, but if present at session level the same
signalling is to indicate the capability of the sender and receivers configuration applies to all media descriptions. It is not subject
to support ECN, and to negotiate the method of ECN initiation to be to the character set chosen. The aim of this signalling is to
used in the session. The attribute takes a list of initiation indicate the capability of the sender and receivers to support ECN,
methods, ordered in decreasing preference. The defined values for and to negotiate the method of ECN initiation to be used in the
the initiation method are: session. The attribute takes a list of initiation methods, ordered
in decreasing preference. The defined values for the initiation
method are:
rtp: Using RTP and RTCP as defined in Section 7.2.1. rtp: Using RTP and RTCP as defined in Section 7.2.1.
ice: Using STUN within ICE as defined in Section 7.2.2. ice: Using STUN within ICE as defined in Section 7.2.2.
leap: Using the leap of faith method as defined in Section 7.2.3. leap: Using the leap of faith method as defined in Section 7.2.3.
Further methods may be specified in the future, so unknown methods Further methods may be specified in the future, so unknown methods
MUST be ignored upon reception. MUST be ignored upon reception.
skipping to change at page 21, line 31 skipping to change at page 22, line 12
The ABNF [RFC5234] grammar for the "a=ecn-capable-rtp" attribute is The ABNF [RFC5234] grammar for the "a=ecn-capable-rtp" attribute is
as follows: as follows:
ecn-attribute = "a=ecn-capable-rtp:" SP init-list [SP parm-list] ecn-attribute = "a=ecn-capable-rtp:" SP init-list [SP parm-list]
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") 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-7E / %x80-FF
; any 8-bit ascii except <"> ; any 8-bit ascii except <">
; external references: ; external references:
; token: from RFC 4566 ; token: from RFC 4566
; SP and DQUOTE from RFC 5234 ; SP and DQUOTE from RFC 5234
skipping to change at page 22, line 41 skipping to change at page 23, line 21
If the "mode=setread" parameter is present in the "a=ecn-capable-rtp" If the "mode=setread" parameter is present in the "a=ecn-capable-rtp"
attribute of the offer and the answering party is "setonly", then ECN attribute of the offer and the answering party is "setonly", then ECN
may only be initiated in the direction from the answering party to may only be initiated in the direction from the answering party to
the offering party. If the offering party is "mode=setread" but the the offering party. If the offering party is "mode=setread" but the
answering party is "mode=readonly", then ECN may only be initiated in answering party is "mode=readonly", then ECN may only be initiated in
the direction from the offering party to the answering party. If the direction from the offering party to the answering party. If
both offer and answer are "mode=setread", then ECN may be initiated both offer and answer are "mode=setread", then ECN may be initiated
in both directions. Note that "mode=setread" is implied by the in both directions. Note that "mode=setread" is implied by the
absence of a "mode=" parameter in the offer or the answer. absence of a "mode=" parameter in the offer or the answer.
If an RTP session using multicast is negotiated using offer/answer In an RTP session using multicast all participants intending to send
all participants intending to send RTP packets SHALL support setting RTP packets needs support setting ECT in the RTP packets, and all
of ECN packet, and all participants receiving SHALL have the participants receiving needs to have the capability to read ECN
capability to read ECN values on incoming packets. If the values on incoming packets. Especially the later is important,
participant lack the functionality they SHALL refuse the media otherwise no sender in the multicast session will be able to enable
streams using multicast. ECN. If a session is negotiated using offer/answer it is preferable
that intended session participant would be aware of the signalling
attributes and if not capable but ECN for RTP aware SHOULD refuse to
join the session. For intended session participants that are not
aware of the ECN for RTP signalling and simple ignore the signalling
attribute the other party in the offer/answer exchange SHOULD
terminate the SIP dialog so that the participant leaves the session.
The "ect=" parameter in the "a=ecn-capable-rtp" attribute is set The "ect=" parameter in the "a=ecn-capable-rtp" attribute is set
independently in the offer and the answer. Its value in the offer independently in the offer and the answer. Its value in the offer
indicates a preference for the sending behaviour of the answering indicates a preference for the sending behaviour of the answering
party, and its value in the answer indicates a sending preference for party, and its value in the answer indicates a sending preference for
the behaviour of the offering party. It will be the senders choice the behaviour of the offering party. It will be the senders choice
to honour the receivers preference for what to receive or not. In to honour the receivers preference for what to receive or not. In
multicast sessions, any sender SHOULD send using the value declared multicast sessions, any sender SHOULD send using the value declared
in the ect parameter. in the ect parameter.
skipping to change at page 23, line 32 skipping to change at page 24, line 18
and can generate RTCP ECN feedback (note that having the capability and can generate RTCP ECN feedback (note that having the capability
to use ECN doesn't necessarily imply that the underlying network path to use ECN doesn't necessarily imply that the underlying network path
between sender and receiver supports ECN). The mode parameter MAY be between sender and receiver supports ECN). The mode parameter MAY be
included also in declarative usage, to indicate the minimal included also in declarative usage, to indicate the minimal
capability is required by the consumer of the SDP. So for example in capability is required by the consumer of the SDP. So for example in
a SSM session the participants configured with a particular SDP will a SSM session the participants configured with a particular SDP will
all be in a media receive only mode, thus mode=readonly will work as all be in a media receive only mode, thus mode=readonly will work as
the capability of reporting on the ECN markings in the received is the capability of reporting on the ECN markings in the received is
what is required. However, using "mode=readonly" also in ASM what is required. However, using "mode=readonly" also in ASM
sessions is reasonable, unless all senders are required to attempt to sessions is reasonable, unless all senders are required to attempt to
use ECN for there outgoing sessions, in which case the mode needs to use ECN for their outgoing RTP data traffic, in which case the mode
be set to "setread". needs to be set to "setread".
The "a=ecn-capable-rtp" attribute MAY be used with RTP media sessions The "a=ecn-capable-rtp" attribute MAY be used with RTP media sessions
using UDP/IP transport. It MUST NOT be used for RTP sessions using using UDP/IP transport. It MUST NOT be used for RTP sessions using
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 AVPF's signalling (RTP/AVPF) [RFC4585] or other profile that inherits AVPF's signalling
rules, MUST be signalled unless timely feedback is not required in rules, MUST be signalled unless timely feedback is not required. If
case it is RECOMMENDED to be used. The signalling of an AVPF based timely feedback is not required it is still RECOMMENDED to used AVPF.
profile is likely to be required even if the preferred method of The signalling of an AVPF based profile is likely to be required even
initialization and the congestion control does not require timely if the preferred method of initialization and the congestion control
feedback, as the common interoperable method is likely to be does not require timely feedback, as the common interoperable method
signalled or the improved fault reaction is desired. is likely to be signalled or the improved fault reaction is desired.
6.2. RTCP Feedback SDP Parameter 6.2. RTCP 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:
rtcp-fb-nack-param = <See section 4.2 of RFC 4585> rtcp-fb-nack-param = <See section 4.2 of RFC 4585>
rtcp-fb-nack-param /= ecn-fb-par rtcp-fb-nack-param /= ecn-fb-par
ecn-fb-par = SP "ecn" ecn-fb-par = SP "ecn"
The offer/answer rules for this SDP feedback parameters are specified The offer/answer rules for this SDP feedback parameters are specified
in AVPF [RFC4585]. in AVPF [RFC4585].
6.3. XR Block SDP Parameter 6.3. XR Block SDP Parameter
A new RTCP XR block for ECN summary information is specified, thus A new unilateral RTCP XR block for ECN summary information is
the XR block SDP signalling also needs to be extended with a specified, thus the XR block SDP signalling also needs to be extended
parameter. This is done in the same way as for the other XR blocks. with a parameter. This is done in the same way as for the other XR
The XR block SDP attribute as defined in Section 5.1 of the RTCP XR blocks. The XR block SDP attribute as defined in Section 5.1 of the
specification [RFC3611] is defined to be extendible. As no parameter RTCP XR specification [RFC3611] is defined to be extendible. As no
values are needed for this ECN summary block, this parameter parameter values are needed for this ECN summary block, this
extension consistis of a simple parameter name used to indicate parameter extension consistis of a simple parameter name used to
support and intent to use the XR block. indicate support and intent to use the XR block.
xr-format = <See Section 5.1 of [RFC3611]> xr-format = <See Section 5.1 of [RFC3611]>
xr-format /= ecn-summary-par xr-format /= ecn-summary-par
ecn-summary-par = "ecn-sum" ecn-summary-par = "ecn-sum"
For SDP declarative and offer/answer usage, see the RTCP XR For SDP declarative and offer/answer usage, see the RTCP XR
specification[RFC3611]. specification[RFC3611] and its specifciation of how to handle
unilateral parameters.
6.4. ICE Parameter to Signal ECN Capability 6.4. ICE Parameter to Signal ECN Capability
One new ICE [RFC5245] option, "rtp+ecn", is defined. This is used One new ICE [RFC5245] option, "rtp+ecn", is defined. This is used
with the SDP session level "a=ice-options" attribute in an SDP offer with the SDP session level "a=ice-options" attribute in an SDP offer
to indicate that the initiator of the ICE exchange has the capability to indicate that the initiator of the ICE exchange has the capability
to support ECN for RTP-over-UDP flows (via "a=ice-options: rtp+ecn"). to support ECN for RTP-over-UDP flows (via "a=ice-options: rtp+ecn").
The answering party includes this same attribute at the session level The answering party includes this same attribute at the session level
in the SDP answer if it also has the capability, and removes the in the SDP answer if it also has the capability, and removes the
attribute if it does not wish to use ECN, or doesn't have the attribute if it does not wish to use ECN, or doesn't have the
capability to use ECN. If this initiation method (Section 7.2.2) capability to use ECN. If the ICE initiation method (Section 7.2.2)
actually is going to be used, it is explicitly negotiated using the actually is going to be used, it is also needs to be explicitly
"a=ecn-capable-rtp" attribute. negotiated using the "a=ecn-capable-rtp" attribute. This ICE option
SHALL be included when the ICE initiation method is offered or
declared in the SDP.
Note: This signalling mechanism is not strictly needed as long as Note: This signalling mechanism is not strictly needed as long as
the STUN ECN testing capability is used within the context of this the STUN ECN testing capability is used within the context of this
document. It may however be useful if the ECN verification document. It may however be useful if the ECN verification
capability is used in additional contexts. capability is used in additional contexts.
7. Use of ECN with RTP/UDP/IP 7. Use of ECN with RTP/UDP/IP
In the detailed specification of the behaviour below, the different In the detailed specification of the behaviour below, the different
functions in the general case will first be discussed. In case functions in the general case will first be discussed. In case
skipping to change at page 25, line 40 skipping to change at page 26, line 33
capability negotiation schemes, such as the ICE extension described capability negotiation schemes, such as the ICE extension described
in Section 6.4. in Section 6.4.
The "ecn-capable-rtp" SDP attribute MUST always be used when The "ecn-capable-rtp" SDP attribute MUST always be used when
employing ECN for RTP according to this specification. As the XR ECN employing ECN for RTP according to this specification. As the XR ECN
summary report is required independently of the initialization summary report is required independently of the initialization
method, or congestion control scheme the "rtcp-xr" attribute with the method, or congestion control scheme the "rtcp-xr" attribute with the
"ecn-sum" parameter MUST also be used. The "rtcp-fb" attribute with "ecn-sum" parameter MUST also be used. The "rtcp-fb" attribute with
the "nack" parameter "ecn" MUST be used whenever the initialization the "nack" parameter "ecn" MUST be used whenever the initialization
method or a congestion control algorithm requiring timely sender side method or a congestion control algorithm requiring timely sender side
knowledge of received CE markings. knowledge of received CE markings. If the congestion control scheme
uses additional signalling they should be indicated as appropriate
for those signalling methods.
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. ECN use.
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
skipping to change at page 32, line 33 skipping to change at page 33, line 23
situation may take some time to reach the sender, although some situation may take some time to reach the sender, although some
feedback should arrive in a reasonably timely manner, allowing the feedback should arrive in a reasonably timely manner, allowing the
sender to react on a single or a few reports. sender to react on a single or a few reports.
A possible future optimisation might be to define some form of A possible future optimisation might be to define some form of
feedback suppression mechanism to reduce the RTCP reporting feedback suppression mechanism to reduce the RTCP reporting
overhead for group communication using ECN. overhead for group communication using ECN.
7.3.3. Response to Congestion Notifications 7.3.3. Response to Congestion Notifications
When RTP packets are received with ECN-CE marks, the sender and/or The reception of RTP packets with ECN-CE marks in the IP header are a
receivers MUST react with congestion control as-if those packets had notification that congestion is being experience. The default
been lost. Depending on the media format, type of session, and RTP reaction on the reception of these ECN-CE marked packets MUST be to
topology used, there are several different types of congestion provide the congestion control algorithm with notification and that
control that can be used. it is treated as a packet loss would when it comes to indicating
congestion.
We note that there MAY be other reactions to ECN-CE specified in the
future. Such an alternative reaction MUST be specified and
considered to be safe for deployment under any restrictions
specified. A potential example for an alternative reaction could be
emergency communications (such as that generated by first responders,
as opposed to the general public) in networks where the user has been
authorized. A more detailed description of these other reactions, as
well as the types of congestion control algorithms used by end-nodes,
is outside of the scope of this document.
Depending on the media format, type of session, and RTP topology
used, there are several different types of congestion control that
can be used.
Sender-Driven Congestion Control: The sender may be responsible for Sender-Driven Congestion Control: The sender may be 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 on it as if it was adaptation mechanism so that it can react on it as if it was
packet losses that was reported. The congestion control algorithm packet losses that was reported. The congestion control algorithm
to be used is not specified here, although TFRC [RFC5348] is one to be used is not specified here, although TFRC [RFC5348] is one
example that might be used. example that might be used.
skipping to change at page 34, line 45 skipping to change at page 35, line 49
packet loss is less than 100% then packet loss reporting in either packet loss is less than 100% then packet loss reporting in either
the ECN feedback information or RTCP RR will indicate the situation. the ECN feedback information or RTCP RR will indicate the situation.
The other action is to re-mark a packet from ECT or CE to not-ECT. The other action is to re-mark a packet from ECT or CE to not-ECT.
That has less dire results, however, it should be detected so that That has less dire results, however, it should be detected so that
ECN usage can be suspended to prevent misusing the network. ECN usage can be suspended to prevent misusing the network.
The ECN feedback packet allows the sender to compare the number of The ECN feedback packet allows the sender to compare the number of
ECT marked packets of different type with the number it actually ECT marked packets of different type with the number it actually
sent. The number of ECT packets received plus the number of CE sent. The number of ECT packets received plus the number of CE
marked and lost packets should correspond to the number of sent ECT marked and lost packets should correspond to the number of sent ECT
marked packets unless their is duplication in the network. If this marked packets unless there is duplication in the network. If this
number doesn't agree there are two likely reasons, a translator number doesn't agree there are two likely reasons, a translator
changing the stream or not carrying the ECN markings forward, or that changing the stream or not carrying the ECN markings forward, or that
some node re-marks the packets. In both cases the usage of ECN is some node re-marks the packets. In both cases the usage of ECN is
broken on the path. By tracking all the different possible ECN field broken on the path. By tracking all the different possible ECN field
values a sender can quickly detect if some non-compliant behavior is values a sender can quickly detect if some non-compliant behavior is
happing on the path. happing on the path.
Thus packet losses and non-matching ECN field value statistics are Thus packet losses and non-matching ECN field value statistics are
possible indication of issues with using ECN over the path. The next possible indication of issues with using ECN over the path. The next
section defines both sender and receiver reactions to these cases. section defines both sender and receiver reactions to these cases.
skipping to change at page 46, line 14 skipping to change at page 47, line 14
v=0 v=0
o=jdoe 3502844782 3502844782 IN IP4 10.0.1.4 o=jdoe 3502844782 3502844782 IN IP4 10.0.1.4
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
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
a=ice-ufrag:9uB6 a=ice-ufrag:9uB6
a=ice-options:rtp+ecn
t=0 0 t=0 0
m=audio 45664 RTP/AVPF 97 98 99 m=audio 45664 RTP/AVPF 97 98 99
c=IN IP4 192.0.2.3 c=IN IP4 192.0.2.3
a=rtpmap:97 G719/48000/1 a=rtpmap:97 G719/48000/1
a=fmtp:97 maxred=160 a=fmtp:97 maxred=160
a=rtpmap:98 AMR-WB/16000/1 a=rtpmap:98 AMR-WB/16000/1
a=fmtp:98 octet-align=1; mode-change-capability=2 a=fmtp:98 octet-align=1; mode-change-capability=2
a=rtpmap:99 PCMA/8000/1 a=rtpmap:99 PCMA/8000/1
a=maxptime:160 a=maxptime:160
a=ptime:20 a=ptime:20
a=ecn-capable-rtp: ice rtp ect=0 mode=setread a=ecn-capable-rtp: ice rtp ect=0 mode=setread
a=rtcp-fb:* nack ecn a=rtcp-fb:* nack ecn
a=rtcp-fb:* trr-int 1000 a=rtcp-fb:* trr-int 1000
a=rtcp-xr:ecn-sum a=rtcp-xr:ecn-sum
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.1 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
initilziation as being prefered over the RTP/RTCP one. Leap of faith initilziation as being prefered over the RTP/RTCP one. Leap of faith
is not suggested to be used. The offerer is capable of both setting is not suggested to be used. The offerer is capable of both setting
and reading the ECN bits. In addition the RTCP ECN feedback packet and reading the ECN bits. In addition the RTCP ECN feedback packet
is configured and the RTCP XR ECN summary report. ICE is also is configured and the RTCP XR ECN summary report. ICE is also
proposed with two candidates. proposed with two candidates.
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
a=ice-pwd:asd88fgpdd777uzjYhagZg a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY a=ice-ufrag:8hhY
a=ice-options:rtp+ecn
t=0 0 t=0 0
m=audio 53879 RTP/AVPF 97 99 m=audio 53879 RTP/AVPF 97 99
c=IN IP4 198.51.100.235 c=IN IP4 198.51.100.235
a=rtpmap:97 G719/48000/1 a=rtpmap:97 G719/48000/1
a=fmtp:97 maxred=160 a=fmtp:97 maxred=160
a=rtpmap:99 PCMA/8000/1 a=rtpmap:99 PCMA/8000/1
a=maxptime:160 a=maxptime:160
a=ptime:20 a=ptime:20
a=ecn-capable-rtp: ice ect=0 mode=readonly a=ecn-capable-rtp: ice ect=0 mode=readonly
a=rtcp-fb:* nack ecn a=rtcp-fb:* nack ecn
skipping to change at page 48, line 12 skipping to change at page 49, line 12
The below session describes an any source multicast using session The below session describes an any source multicast using session
with a single media stream. with a single media stream.
v=0 v=0
o=jdoe 3502844782 3502844782 IN IP4 198.51.100.235 o=jdoe 3502844782 3502844782 IN IP4 198.51.100.235
s=Multicast SDP session using ECN for RTP s=Multicast SDP session using ECN for RTP
i=Multicasted audio chat using ECN for RTP i=Multicasted audio chat using ECN for RTP
b=AS:128 b=AS:128
t=3502892703 3502910700 t=3502892703 3502910700
m=audio 56144 RTP/AVPF 97 m=audio 56144 RTP/AVPF 97
c=IN IP4 224.2.1.3/127 c=IN IP4 233.252.0.212/127
a=rtpmap:97 g719/48000/1 a=rtpmap:97 g719/48000/1
a=fmtp:97 maxred=160 a=fmtp:97 maxred=160
a=maxptime:160 a=maxptime:160
a=ptime:20 a=ptime:20
a=ecn-capable-rtp: rtp mode=readonly; ect=0 a=ecn-capable-rtp: rtp mode=readonly; ect=0
a=rtcp-fb:* nack ecn a=rtcp-fb:* nack ecn
a=rtcp-fb:* trr-int 1500 a=rtcp-fb:* trr-int 1500
a=rtcp-xr:ecn-sum a=rtcp-xr:ecn-sum
In the above example, as this is declarative we need to require In the above example, as this is declarative we need to require
skipping to change at page 49, line 10 skipping to change at page 50, line 10
does this in terms of packets, but there may be an argument that does this in terms of packets, but there may be an argument that
we want to report bytes for ECN. we want to report bytes for ECN.
draft-ietf-tsvwg-byte-pkt-congest is extremely unclear on what is draft-ietf-tsvwg-byte-pkt-congest is extremely unclear on what is
the right approach. the right approach.
4. We have a saturation problem with the packet loss counters. They 4. We have a saturation problem with the packet loss counters. They
do need to continue working even if saturation happens due to do need to continue working even if saturation happens due to
long sessions where more lost packets than the counters can long sessions where more lost packets than the counters can
handle. handle.
14. References 14. Acknowledgments
14.1. Normative References The authors wish to thank the following persons for their reviews and
comments: Thomas Belling, Bob Briscoe, Roni Even, Thomas Frankkila,
Christian Groves, Cullen Jennings Tom Van Caenegem, Simo
Veikkolainen, Lei Zhu, Christer Holmgren.
15. References
15.1. Normative References
[I-D.ietf-mmusic-ice-options-registry] [I-D.ietf-mmusic-ice-options-registry]
Westerlund, M. and C. Perkins, "IANA Registry for Westerlund, M. and C. Perkins, "IANA Registry for
Interactive Connectivity Establishment (ICE) Options", Interactive Connectivity Establishment (ICE) Options",
draft-ietf-mmusic-ice-options-registry-00 (work in draft-ietf-mmusic-ice-options-registry-00 (work in
progress), January 2011. progress), January 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 50, line 5 skipping to change at page 51, line 14
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.
14.2. Informative References 15.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.
[I-D.zimmermann-avt-zrtp] [I-D.zimmermann-avt-zrtp]
Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media
Path Key Agreement for Unicast Secure RTP", Path Key Agreement for Unicast Secure RTP",
draft-zimmermann-avt-zrtp-22 (work in progress), draft-zimmermann-avt-zrtp-22 (work in progress),
June 2010. June 2010.
 End of changes. 37 change blocks. 
116 lines changed or deleted 186 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/