draft-westerlund-avt-ecn-for-rtp-01.txt   draft-westerlund-avt-ecn-for-rtp-02.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: April 5, 2010 C. Perkins Expires: April 29, 2010 C. Perkins
University of Glasgow University of Glasgow
P. O'Hanlon P. O'Hanlon
UCL UCL
K. Carlberg K. Carlberg
G11 G11
October 2, 2009 October 26, 2009
Explicit Congestion Notification (ECN) for RTP over UDP Explicit Congestion Notification (ECN) for RTP over UDP
draft-westerlund-avt-ecn-for-rtp-01 draft-westerlund-avt-ecn-for-rtp-02
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 5, 2010. This Internet-Draft will expire on April 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 3 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 3
3. Discussion, Requirements, and Design Rationale . . . . . . . . 4 3. Discussion, Requirements, and Design Rationale . . . . . . . . 4
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 6
4. Use of ECN with RTP/UDP/IP . . . . . . . . . . . . . . . . . . 9 4. Use of ECN with RTP/UDP/IP . . . . . . . . . . . . . . . . . . 9
4.1. Negotiation of ECN Capability . . . . . . . . . . . . . . 12 4.1. Negotiation of ECN Capability . . . . . . . . . . . . . . 12
4.2. Initiation of ECN Use in an RTP Session . . . . . . . . . 17 4.2. Initiation of ECN Use in an RTP Session . . . . . . . . . 16
4.3. Ongoing Use of ECN Within an RTP Session . . . . . . . . . 22 4.3. Ongoing Use of ECN Within an RTP Session . . . . . . . . . 22
4.4. Detecting Failures and Receiver Misbehaviour . . . . . . . 26 4.4. Detecting Failures and Receiver Misbehaviour . . . . . . . 25
5. RTCP Extensions for ECN feedback . . . . . . . . . . . . . . . 29 5. RTCP Extensions for ECN feedback . . . . . . . . . . . . . . . 29
5.1. ECN Feedback packet . . . . . . . . . . . . . . . . . . . 29 5.1. ECN Feedback packet . . . . . . . . . . . . . . . . . . . 29
5.2. RTCP XR Report block for ECN summary information . . . . . 32 5.2. RTCP XR Report block for ECN summary information . . . . . 32
5.3. RTCP XR Report Block for ECN Nonce . . . . . . . . . . . . 34 5.3. RTCP XR Report Block for ECN Nonce . . . . . . . . . . . . 33
6. Processing RTCP ECN Feedback in RTP Translators and Mixers . . 37 6. Processing RTCP ECN Feedback in RTP Translators and Mixers . . 36
6.1. Fragmentation and Reassembly in Translators . . . . . . . 37 6.1. Fragmentation and Reassembly in Translators . . . . . . . 36
6.2. Generating RTCP ECN Feedback in Translators . . . . . . . 37 6.2. Generating RTCP ECN Feedback in Translators . . . . . . . 36
6.3. Generating RTCP ECN Feedback in Mixers . . . . . . . . . . 38 6.3. Generating RTCP ECN Feedback in Mixers . . . . . . . . . . 36
7. Implementation considerations . . . . . . . . . . . . . . . . 38 7. Implementation considerations . . . . . . . . . . . . . . . . 37
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
8.1. SDP Attribute Registration . . . . . . . . . . . . . . . . 38 8.1. SDP Attribute Registration . . . . . . . . . . . . . . . . 37
8.2. AVPF Transport Feedback Message . . . . . . . . . . . . . 39 8.2. AVPF Transport Feedback Message . . . . . . . . . . . . . 37
8.3. RTCP XR Report blocks . . . . . . . . . . . . . . . . . . 39 8.3. RTCP XR Report blocks . . . . . . . . . . . . . . . . . . 38
8.4. STUN attribute . . . . . . . . . . . . . . . . . . . . . . 39 8.4. STUN attribute . . . . . . . . . . . . . . . . . . . . . . 38
8.5. ICE Option . . . . . . . . . . . . . . . . . . . . . . . . 39 8.5. ICE Option . . . . . . . . . . . . . . . . . . . . . . . . 38
9. Security Considerations . . . . . . . . . . . . . . . . . . . 39 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38
10. Examples of SDP Signalling . . . . . . . . . . . . . . . . . . 42 10. Examples of SDP Signalling . . . . . . . . . . . . . . . . . . 41
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 42 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 41
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
12.1. Normative References . . . . . . . . . . . . . . . . . . . 42 12.1. Normative References . . . . . . . . . . . . . . . . . . . 41
12.2. Informative References . . . . . . . . . . . . . . . . . . 43 12.2. Informative References . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
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 RTP [RFC3550] flows running over UDP/IP
which use RTCP as feedback mechanism. The solution consists of which use RTCP as feedback mechanism. The solution consists of
feedback of ECN congestion experienced markings to sender using RTCP, feedback of ECN congestion experienced markings to sender using RTCP,
verification of ECN functionality end-to-end, and how to initiate ECN verification of ECN functionality end-to-end, and how to initiate ECN
usage. The initiation process will have some dependencies on the usage. The initiation process will have some dependencies on the
signalling mechanism used to establish the RTP session, a signalling mechanism used to establish the RTP session, a
skipping to change at page 7, line 21 skipping to change at page 7, line 21
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
the changes it makes to the RTP data packets. A legacy, ECN- the changes it makes to the RTP data packets. A legacy, ECN-
unaware, RTP translator is expected to ignore the ECN bits on unaware, RTP translator is expected to ignore the ECN bits on
received packets, and zero out the ECN bits when sending packets, received packets, and to set the ECN bits to not-ECT when sending
so causing ECN negotiation on the path containing the translator packets, so causing ECN negotiation on the path containing the
to fail (any new RTP translator that does not wish to support ECN translator to fail (any new RTP translator that does not wish to
may do similarly). An ECN aware RTP translator may act in one of support ECN may do similarly). An ECN aware RTP translator may
three ways: act in one of three ways:
* If the translator does not modify the media stream, it should * If the translator does not modify the media stream, it should
copy the ECN bits unchanged from the incoming to the outgoing copy the ECN bits unchanged from the incoming to the outgoing
datagrams, unless it is overloaded and experiencing congestion, datagrams, unless it is overloaded and experiencing congestion,
in which case it may mark the outgoing datagrams with an ECN-CE in which case it may mark the outgoing datagrams with an ECN-CE
mark. Such a translator passes RTCP feedback unchanged. mark. Such a translator passes RTCP feedback unchanged.
* If the translator modifies the media stream to combine or split * If the translator modifies the media stream to combine or split
RTP packets, but does not otherwise transcode the media, it RTP packets, but does not otherwise transcode the media, it
must manage the ECN bits in a way analogous to that described must manage the ECN bits in a way analogous to that described
skipping to change at page 8, line 13 skipping to change at page 8, line 13
into the ECN negotiation process, effectively splitting the into the ECN negotiation process, effectively splitting the
connection into two parts with their own negotiation. Once connection into two parts with their own negotiation. Once
negotiation has been completed, the translator must generate negotiation has been completed, the translator must generate
RTCP ECN feedback back to the source based on its own RTCP ECN feedback back to the source based on its own
reception, and must respond to RTCP ECN feedback received from reception, and must respond to RTCP ECN feedback received from
the receiver(s) (see Section 6.2). the receiver(s) (see Section 6.2).
It is recognised that ECN and RTCP processing in an RTP translator It is recognised that ECN and RTCP processing in an RTP translator
that modifies the media stream is non-trivial. that modifies the media stream is non-trivial.
Topo-Mixer: This is an RTP-level middlebox that aggregates multiple Topo-Mixer: A mixer is an RTP-level middlebox that aggregates
RTP streams, mixing them together to generate a new RTP stream. multiple RTP streams, mixing them together to generate a new RTP
The mixer is visible to the other participants in the RTP session. stream. The mixer is visible to the other participants in the RTP
The RTP flows on each side of the mixer are treated independently session, and is also usually visible in the associated signalling
for ECN purposes, with the mixer generating its own RTCP ECN session. The RTP flows on each side of the mixer are treated
feedback, and responding to ECN feedback for data it sends. Since independently for ECN purposes, with the mixer generating its own
connections are treated independently, it would seem reasonable to RTCP ECN feedback, and responding to ECN feedback for data it
allow the transport on one side of the mixer to use ECN, while the sends. Since connections are treated independently, it would seem
transport on the other side of the mixer is not ECN capable, if reasonable to allow the transport on one side of the mixer to use
this is desired. ECN, while the transport on the other side of the mixer is not ECN
capable, if this is desired.
Topo-Video-switch-MCU: A video switching MCU receives several RTP Topo-Video-switch-MCU: A video switching MCU receives several RTP
flows, but forwards only one of those flows onwards to the other flows, but forwards only one of those flows onwards to the other
participants at a time. The flow that is forwarded changes during participants at a time. The flow that is forwarded changes during
the session, often based on voice activity. Since only a subset the session, often based on voice activity. Since only a subset
of the RTP packets generated by a sender are forwarded to the of the RTP packets generated by a sender are forwarded to the
receivers, a video switching MCU can break ECN negotiation (the receivers, a video switching MCU can break ECN negotiation (the
success of the ECN negotiation may depend on the voice activity of success of the ECN negotiation may depend on the voice activity of
the participant at the instant the negotiation takes place - shout the participant at the instant the negotiation takes place - shout
if you want ECN). It also breaks congestion feedback and if you want ECN). It also breaks congestion feedback and
skipping to change at page 9, line 7 skipping to change at page 9, line 9
translator in the other. To quote RFC 5117 "This topology is so translator in the other. To quote RFC 5117 "This topology is so
problematic and it is so easy to get the RTCP processing wrong, problematic and it is so easy to get the RTCP processing wrong,
that it is NOT RECOMMENDED to implement this topology." that it is NOT RECOMMENDED to implement this topology."
These topologies may be combined within a single RTP session. These topologies may be combined within a single RTP session.
The ECN mechanism defined in this memo is applicable to both sender The ECN mechanism defined in this memo is applicable to both sender
and receiver controlled congestion algorithms. The mechanism ensures and receiver controlled congestion algorithms. The mechanism ensures
that both senders and receivers will know about ECN-CE markings and that both senders and receivers will know about ECN-CE markings and
any packet losses. Thus the actual decision point for the congestion any packet losses. Thus the actual decision point for the congestion
control is not relevant. This is a great benefit as RTP session can control is not relevant. This is a great benefit as the rate of an
be adapted in a number of ways, such as media sender using TFRC RTP session can be varied in a number of ways, for example a unicast
[RFC5348] or other algorithms, or for multicast sessions either a media sender might use TFRC [RFC5348] or some other algorithm, while
sender based scheme with lowest common rate, or receiver driven a multicast session could use a sender based scheme adapting to the
mechanism based on layers to support more heterogeneous paths. lowest common supported rate, or a receiver driven mechanism using
layered coding to support more heterogeneous paths.
To ensure timely feedback of CE marked packets, this mechanism To ensure timely feedback of CE marked packets, this mechanism
requires support for the RTP/AVPF profile [RFC4585] or any of its requires support for the RTP/AVPF profile [RFC4585] or any of its
derivatives, such as RTP/SAVPF [RFC5124]. The standard RTP/AVP derivatives, such as RTP/SAVPF [RFC5124]. The standard RTP/AVP
profile [RFC3551] does not allow any early or immediate transmission profile [RFC3551] does not allow any early or immediate transmission
of RTCP feedback, and has a minimal RTCP interval whose default value of RTCP feedback, and has a minimal RTCP interval whose default value
(5 seconds) is many times the normal RTT between sender and receiver. (5 seconds) is many times the normal RTT between sender and receiver.
The control of which RTP data packets are marked as ECT, and whether The control of which RTP data packets are marked as ECT, and whether
ECT(0) or ECT(1) is used, is due to the sender. RTCP packets must ECT(0) or ECT(1) is used, is due to the sender. RTCP packets must
not be ECT marked, whether generated by sender or receivers. not be ECT marked, whether generated by sender or receivers.
4. Use of ECN with RTP/UDP/IP 4. Use of ECN with RTP/UDP/IP
The solution for using ECN with RTP over UDP/IP consists of four The solution for using ECN with RTP over UDP/IP consists of four
different pieces that together makes the solution work: different pieces that together make the solution work:
1. Negotiation of the capability to use ECN with RTP/UDP 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. Failure detection, verification and fallback 4. Failure detection, 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 session parameters to discover the other participants and negotiate session parameters
(see Section 4.1). One of the parameters that can be negotiated is (see Section 4.1). One of the parameters that can be negotiated is
the capability of a participant to support ECN functionality, or the capability of a participant to support ECN functionality, or
otherwise. Note that all participants having the capability of otherwise. Note that all participants having the capability of
supporting ECN does not necessarily imply that ECN is usable in an supporting ECN does not necessarily imply that ECN is usable in an
RTP session, since there may be middleboxes on the path between the RTP session, since there may be middleboxes on the path between the
participants which don't support ECN (for example, a firewall that participants which don't pass ECN-marked packets (for example, a
blocks traffic with the ECN bits set). This document defines the firewall that blocks traffic with the ECN bits set). This document
information that needs to be negotiated, and provides a mapping to defines the information that needs to be negotiated, and provides a
SDP for use in both declarative and offer/answer contexts. mapping to SDP for use in both declarative and offer/answer contexts.
When a sender joins a session for which all participants claim ECN When a sender joins a session for which all participants claim ECN
capability, it must verify if that capability is usable. There are capability, it must verify if that capability is usable. There are
three ways in which this verification phase may be done three ways in which this verification may be done (Section 4.2):
(Section 4.2):
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
its traffic. Each sender does this verification independently of its traffic. Each sender does this verification independently of
each other. If a new receiver joins an existing session it also each other. If a new receiver joins an existing session it also
needs to verify ECN support. If verification fails the sender needs to verify ECN support. If verification fails the sender
needs to stop using ECN. As the sender will not know of the needs to stop using ECN. As the sender will not know of the
receiver prior to it sending RTP or RTCP packets, the sender will receiver prior to it sending RTP or RTCP packets, the sender will
wait for the first RTCP packet from the new receiver to determine wait for the first RTCP packet from the new receiver to determine
if that contains ECN feedback or not. if that contains ECN feedback or not.
o Alternatively, ECN support can be verified during an initial end- o Alternatively, ECN support can be verified during an initial end-
to-end STUN exchange (for example, as part of ICE connection to-end STUN exchange (for example, as part of ICE connection
establishment). After having verified connectivity without ECN establishment). After having verified connectivity without ECN
capability an extra STUN exchange, this time with the ECN field capability an extra STUN exchange, this time with the ECN field
set to ECT(0) or ECT(1), is performed. If successful the path's set to ECT(0) or ECT(1), is performed. If successful the path's
capability to convey ECN marked packets is verified. A new STUN capability to convey ECN marked packets is verified. A new STUN
attribute is defined to convey feedback that the ECT marked attribute is defined to convey feedback that the ECT marked STUN
request was received. request was received (see Section 8.4), along with an ICE
signalling option (Section 8.5).
o Thirdly, make a leap of faith that it will work. This is only o Thirdly, the sender may make a leap of faith that ECN will work.
recommended in applications that know they run in controlled This is only recommended for applications that know they are
environments where ECN functionality through other means have been running in controlled environments where ECN functionality has
verified. In this mode one assumes ECN to work and then reacts to been verified through other means. In this mode it is assumed
failure indicators if the assumption proved wrong. The usage of that ECN works, and the system reacts to failure indicators if the
this method relies on a high confidence in successful ECN function assumption proved wrong. The use of this method relies on a high
or an application where failure are not serious. However, also confidence that ECN operation will be successful, or an
the impact on the network and other users must be considered. application where failure are not serious. The impact on the
Thus there are limitation to when this method is allowed. network and other users must be considered when making a leap of
faith, so there are limitations on when this method is allowed.
The first mechanism, using RTP with RTCP feedback, has the advantage The first mechanism, using RTP with RTCP feedback, has the advantage
of working for all RTP sessions, but the disadvantages of potential of working for all RTP sessions, but the disadvantages of potential
clipping if ECN marked RTP packets are discarded by middleboxes, and clipping if ECN marked RTP packets are discarded by middleboxes, and
slow verification of ECN support. The STUN-based mechanism is faster slow verification of ECN support. The STUN-based mechanism is faster
to verify ECN support, but only works in those scenarios supported by to verify ECN support, but only works in those scenarios supported by
end-to-end STUN, such as within an ICE exchange. The third one, end-to-end STUN, such as within an ICE exchange. The third one,
leap-of-faith, has the advantage of avoiding additional tests or leap-of-faith, has the advantage of avoiding additional tests or
complexities and enabling ECN usage from the first media packet. The complexities and enabling ECN usage from the first media packet. The
downside is that if the end-to-end path contains middleboxes that do downside is that if the end-to-end path contains middleboxes that do
skipping to change at page 11, line 11 skipping to change at page 11, line 14
worst case, all media could be lost if a middlebox that discards ECN worst case, all media could be lost if a middlebox that discards ECN
marked packets is present. A less severe effect, but still requiring marked packets is present. A less severe effect, but still requiring
reaction, is the presence of a middlebox that remarks ECT marked reaction, is the presence of a middlebox that remarks ECT marked
packets to non-ECT, possibly marking packets with a CE mark as non- packets to non-ECT, possibly marking packets with a CE mark as non-
ECT. This can force the network into heavy congestion due to non- ECT. This can force the network into heavy congestion due to non-
responsiveness, and seriously impact media quality. responsiveness, and seriously impact media quality.
Once ECN support has been verified (or assumed) to work for all Once ECN support has been verified (or assumed) to work for all
receivers, a sender marks all its RTP packets as ECT packets, while receivers, a sender marks all its RTP packets as ECT packets, while
receivers rapidly feedback any CE marks to the sender using RTCP in receivers rapidly feedback any CE marks to the sender using RTCP in
RTP/AVPF immediate or early feedback mode (see Section 4.3). An RTCP RTP/AVPF immediate or early feedback mode. An RTCP feedback report
feedback report is sent as soon as possible by the transmission rules is sent as soon as possible by the transmission rules for feedback
for feedback that are in place. This feedback report indicates new that are in place. This feedback report indicates new CE marks since
CE marks since last ECN feedback packet and also the number of new CE last ECN feedback packet and also the number of new CE marks through
marks through a accumulative sum. This is the mechanism to provide a accumulative sum. This is the mechanism to provide the fastest
the fastest possible feedback to senders about CE marks. On receipt possible feedback to senders about CE marks. On receipt of a CE
of a CE marked packet, the system must react to congestion as-if marked packet, the system must react to congestion as-if packet loss
packet loss has been reported. has been reported. Section Section 4.3 describes the ongoing use of
ECN with an RTP session.
This rapid feedback is not optimised for reliability, therefore an This rapid feedback is not optimised for reliability, therefore an
additional procedure is used to ensure more reliable, but less additional procedure is used to ensure more reliable, but less
timely, reporting of the ECN information. An ECN summary report timely, reporting of the ECN information. An ECN summary report
should also be sent in regular RTCP reports. The ECN summary report should also be sent in regular RTCP reports. The ECN summary report
contains the same information as the ECN feedback format, only packed contains the same information as the ECN feedback format, only packed
differently for better efficiency with large reports. By using differently for better efficiency with large reports. By using
accumulative counters for seen CE, ECT, not-ECT or packet loss the accumulative counters for seen CE, ECT, not-ECT or packet loss the
sender can determine what events has happened since the last report, sender can determine what events has happened since the last report,
independently of any RTCP packets having been lost. independently of any RTCP packets having been lost.
skipping to change at page 11, line 44 skipping to change at page 11, line 48
received in cases when ECT marked traffic is not getting through. received in cases when ECT marked traffic is not getting through.
There are numerous reasons why the path the RTP packets take from the There are numerous reasons why the path the RTP packets take from the
sender to the receiver may change, e.g. mobility, link failure sender to the receiver may change, e.g. mobility, link failure
followed by re-routing around it. Such an event may result in the followed by re-routing around it. Such an event may result in the
packet being sent through a node that is ECN non-compliant, thus packet being sent through a node that is ECN non-compliant, thus
remarking or dropping packets with ECT set. To prevent this from remarking or dropping packets with ECT set. To prevent this from
impacting the application for longer than necessary, the operation of impacting the application for longer than necessary, the operation of
ECN is constantly monitored by all senders. Both the RTCP ECN ECN is constantly monitored by all senders. Both the RTCP ECN
summary reports and the ECN feedback packets allow the sender to summary reports and the ECN feedback packets allow the sender to
compare the number of ECT(0), ECT(1), and non-ECT marked packet with compare the number of ECT(0), ECT(1), and non-ECT marked packets with
those that were sent, while also reporting CE marked and lost those that were sent, while also reporting CE marked and lost
packets. If these numbers do not agree with what was sent, it can be packets. If these numbers do not agree with what was sent, it can be
inferred that the path does not reliably pass ECN-marked packets. inferred that the path does not reliably pass ECN-marked packets
More detailed discussions are presented in Section 4.4 and (Section 4.4.2 discusses how to interpret the different cases). A
Section 4.4.2 on how to interpret different cases. A sender sender detecting a possible ECN non-compliance issue should then stop
detecting a possible ECN non-compliance issue should then stop sending ECT marked packets to determine if that allows the packets to
sending ECT marked packets to determine if that allows the packet to
be correctly delivered. If the issues can be connected to ECN, then be correctly delivered. If the issues can be connected to ECN, then
ECN usage is suspended and possibly also re-negotiated. ECN usage is suspended and possibly also re-negotiated.
This specification offers an option of computing and reporting an ECN This specification offers an option of computing and reporting an ECN
nonce over all received packets that where not ECN-CE marked or nonce over all received packets that where not ECN-CE marked or
reported explicitly lost. Thus, the sender will have an additional reported explicitly lost. This provides an additional means to
tool to detect if any remarking happens. It can also based on detect any packet remarking that happens in the network, and can also
statistics detect receivers that suppress reporting of CE marked be used by a sender to detect receivers that lie about reception of
packets, i.e. detect cheating. The incentive for a real-time CE-marked packets (it is to be noted that the incentive for receivers
application to cheat in its ECN reporting is less than for TCP, as to lie in their ECN reports is low for RTP/UDP/IP sessions, since
increased congestion levels are likely to cause packet losses that increased congestion levels are likely to cause unpredictable packet
decrease the media quality. While for TCP lying allows for keeping a losses that decrease the media quality more than would reducing the
larger congestion window than compliant receivers and any packet data rate). To enable the sender to verify the ECN nonce, the sender
losses will be corrected by TCP's retransmission. The ECN nonce must learn the sequence number of all packets that was either CE
mechanism also requires more data to function correctly. To enable marked or lost, otherwise it can't correctly exclude these packet
the sender to verify the ECN nonce, the sender must learn the from the ECN nonce sum. This is done using a new RTCP XR report
sequence number of all packets that was either CE marked or lost. type, the Nonce Report, that contains the nonce sums and indicating
Otherwise it can't correctly exclude these packet from the ECN nonce the lost or ECN-CE marked packets using a run length encoded bit-
sum. This is done using a RTCP XR Nonce report, containing the nonce vector. Due to the size of ECN Nonce Reports, and as most RTP-based
sums and indicating the lost or ECN-CE marked packets using a run applications have little incentive to lie about ECN marks, the use of
length encoded bit-vector. Thus ECN nonce has a higher demand for the ECN none is OPTIONAL.
RTCP bandwidth. Combined with the reduced incentive to cheat, this
mechanism is optional and is only recommended for applications where
the incentive might be higher, such as streaming with
retransmissions.
In the detailed specification of the behaviour below, the different In the detailed specification of the behaviour below, the different
functions the general case will first be discussed. In cases special functions the general case will first be discussed. In cases special
considerations are needed for middleboxes, multicast usage etc, those considerations are needed for middleboxes, multicast usage etc, those
will be specially discussed in related subsections. will be specially discussed in related subsections.
4.1. Negotiation of ECN Capability 4.1. Negotiation of ECN Capability
The first stage of ECN negotiation for RTP-over-UDP is to signal the The first stage of ECN negotiation for RTP-over-UDP is to signal the
capability to use ECN. This includes negotiating if ECN is to be capability to use ECN. This includes negotiating if ECN is to be
used symmetrically, the method for initial ECT verification, and used symmetrically, the method for initial ECT verification, and
whether the ECN nonce is to be used. This memo defines the mappings whether the ECN nonce is to be used. This memo defines the mappings
of this information onto SDP both for declarative and offer/answer of this information onto SDP for both declarative and offer/answer
usage. There are one SDP extension to indicate if ECN support should usage. There is one SDP extension to indicate if ECN support should
be used and the method for initiation. In addition there are an ICE be used, and the method for initiation. In addition an ICE parameter
parameter to indicate that ECN initiation using STUN as part of an is defined to indicate that ECN initiation using STUN is supported as
ICE exchange is supported. part of an ICE exchange.
An RTP system that supports ECN and uses SDP in the signalling MUST An RTP system that supports ECN and uses SDP in the signalling MUST
implement the SDP extension to signal ECN capability as described in implement the SDP extension to signal ECN capability as described in
Section 4.1.1. It MAY also implement alternative ECN capability Section 4.1.1. It MAY also implement alternative ECN capability
negotiation schemes, such as the ICE extension described in negotiation schemes, such as the ICE extension described in
Section 4.1.2. Section 4.1.2.
4.1.1. Signalling ECN Capability using SDP 4.1.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
skipping to change at page 14, line 6 skipping to change at page 14, line 6
case when both the offerer and answerer set the "mode=" parameter case when both the offerer and answerer set the "mode=" parameter
to "setonly" or "readonly", or when an RTP sender entity considers to "setonly" or "readonly", or when an RTP sender entity considers
offering "readonly". offering "readonly".
o The "nonce" parameter may be used to signal whether the ECN nonce o The "nonce" parameter may be used to signal whether the ECN nonce
is to be used in the session. This parameter takes two values; is to be used in the session. This parameter takes two values;
"nonce=1" for nonce proposed or shall be used, and "nonce=0" for "nonce=1" for nonce proposed or shall be used, and "nonce=0" for
no nonce. no nonce.
o The "ect" parameter makes it possible to express the preferred ECT o The "ect" parameter makes it possible to express the preferred ECT
marking. This is either random (default), ECT(0) or ECT(1). If marking. This is either random (default), 0, or 1. If the ECN
the ECN nonce is used then this parameter MUST be ignored, and nonce is used then this parameter MUST be ignored, and random ECT
random ECT is implied. The "ect" parameter describes a receiver is implied. The "ect" parameter describes a receiver preference,
preference, and is useful in the case where the receiver knows it and is useful in the case where the receiver knows it is behind a
is behind a link using IP header compression, the efficiency of link using IP header compression, the efficiency of which would be
which would be seriously disrupted if it were to receive packets seriously disrupted if it were to receive packets with randomly
with randomly chosen ECT marks. chosen ECT marks.
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" init-list parameter-list ecn-attribute = "a=ecn-capable-rtp:" init-list *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
parameter-list = *(SP ";" par-value) parm-list = parm-value *(";" SP parm-value)
par-value = nonce / mode / ect / (parameter "=" value) parm-value = nonce / mode / ect
mode = "mode=" ("setonly" / "setread" / "readonly") mode = "mode=" ("setonly" / "setread" / "readonly")
nonce = "nonce=" ("0" / "1") nonce = "nonce=" ("0" / "1")
ect = "ect=" ("random" / "0" / "1") ect = "ect=" ("random" / "0" / "1")
parameter = token
value = token / quoted-string ; external references:
token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 / ; token: from RFC 4566
%x41-5A / %x5E-7A / %x7C / %x7E)
quoted-string = ( DQ *qdtext DQ )
qdtext = %x20-21 / %x23-7E / %x80-FF
DQ = %x22 ; US-ASCII double-quote mark (34)
When SDP is used with the offer/answer model [RFC3264], the party When SDP is used with the offer/answer model [RFC3264], the party
generating the SDP offer MUST insert an "a=ecn-capable-rtp" attribute generating the SDP offer MUST insert an "a=ecn-capable-rtp" attribute
into the media section of the SDP offer of each RTP flow for which it into the media section of the SDP offer of each RTP flow for which it
wishes to use ECN. The attribute includes one or more ECN initiation wishes to use ECN. The attribute includes one or more ECN initiation
methods in a comma separated list in decreasing order of preference, methods in a comma separated list in decreasing order of preference,
with some number of optional parameters following. The answering with some number of optional parameters following. The answering
party compares the list of initiation methods in the offer with those party compares the list of initiation methods in the offer with those
it supports in order of preference. If there is a match, and if the it supports in order of preference. If there is a match, and if the
receiver wishes to attempt to use ECN in the session, it includes an receiver wishes to attempt to use ECN in the session, it includes an
"a=ecn-capable-rtp" attribute containing its single preferred choice "a=ecn-capable-rtp" attribute containing its single preferred choice
of initiation method in the media sections of the answer. If there of initiation method in the media sections of the answer. If there
is no matching initiation method capability, or if the receiver does is no matching initiation method capability, or if the receiver does
not wish to attempt to use ECN in the session, it does not include an not wish to attempt to use ECN in the session, it does not include an
"a=ecn-capable-rtp" attribute in its answer. If the attribute is "a=ecn-capable-rtp" attribute in its answer. If the attribute is
removed then ECN MUST NOT be used in any direction for that media removed in the answer then ECN MUST NOT be used in any direction for
flow. The answer may also include optional parameters, as discussed that media flow. The answer may also include optional parameters, as
below. discussed below.
If the "mode=setonly" parameter is present in the "a=ecn-capable-rtp" If the "mode=setonly" parameter is present in the "a=ecn-capable-rtp"
attribute of the offer and the answering party is also attribute of the offer and the answering party is also
"mode=setonly", then there is no common ECN capability, and the "mode=setonly", then there is no common ECN capability, and the
answer MUST NOT include the "a=ecn-capable-rtp" attribute. answer MUST NOT include the "a=ecn-capable-rtp" attribute.
Otherwise, if the offer is "mode=setonly" then ECN may only be Otherwise, if the offer is "mode=setonly" then ECN may only be
initiated in the direction from the offering party to the answering initiated in the direction from the offering party to the answering
party. party.
If the "mode=readonly" parameter is present in the "a=ecn-capable- If the "mode=readonly" parameter is present in the "a=ecn-capable-
skipping to change at page 15, line 27 skipping to change at page 15, line 23
party. party.
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. absence of a "mode=" parameter in the offer or the answer.
If the "nonce=1" parameter is present in the "a=ecn-capable-rtp" If the "nonce=1" parameter is present in the "a=ecn-capable-rtp"
attribute of the offer, the answer MUST explicitly include the attribute of the offer, the answer MUST explicitly include the
"nonce=" parameter in the "a=ecn-capable-rtp" attribute of the answer "nonce=" parameter in the "a=ecn-capable-rtp" attribute of the answer
to indicate if it supports the ECN nonce. If the answer indicates to indicate if it supports the ECN nonce. If the answer indicates
support ("nonce=1") then ECN nonce SHALL be used in the session; if support ("nonce=1") then ECN nonce SHALL be used in the session; if
the answer does not include the "nonce=" parameter, or includes the answer does not include the "nonce=" parameter, or includes
"nonce=0", then the ECN nonce SHALL NOT be used. The answer MAY "nonce=0", then the ECN nonce SHALL NOT be used. The answer MAY
include a "nonce=0" parameter in an answer even if not included in include a "nonce=0" parameter in an answer even if not included in
the offer. This indicates that the answerer supports and is the offer. This indicates that the answerer supports and is
skipping to change at page 16, line 30 skipping to change at page 16, line 26
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 4.3.3, RTP sessions using ECN require rapid As described in Section 4.3.3, RTP sessions using ECN require rapid
RTCP ECN feedback, in order that the sender can react to ECN-CE RTCP ECN feedback, in order that the sender can react to ECN-CE
marked packets. Thus, the use of the Extended RTP Profile for RTCP- marked packets. Thus, the use of the Extended RTP Profile for RTCP-
Based Feedback (RTP/AVPF) [RFC4585] MUST be signalled. Based Feedback (RTP/AVPF) [RFC4585] MUST be signalled.
When using ECN nonce, the RTCP XR signalling indicating the ECN Nonce When using ECN nonce, the RTCP XR signalling indicating the ECN Nonce
report MUST also be included in the SDP following [RFC3611]. report MUST also be included in the SDP [RFC3611].
4.1.2. ICE Parameter to Signal ECN Capability 4.1.2. ICE Parameter to Signal ECN Capability
One new ICE [I-D.ietf-mmusic-ice] option, "rtp+ecn", is defined. One new ICE [I-D.ietf-mmusic-ice] option, "rtp+ecn", is defined.
This is used with the SDP session level "a=ice-options" attribute in This is used with the SDP session level "a=ice-options" attribute in
an SDP offer to indicate that the initiator of the ICE exchange has an SDP offer to indicate that the initiator of the ICE exchange has
the capability to support ECN for RTP-over-UDP flows (via "a=ice- the capability to support ECN for RTP-over-UDP flows (via "a=ice-
options: rtp+ecn"). The answering party includes this same attribute options: rtp+ecn"). The answering party includes this same attribute
at the session level in the SDP answer if it also has the capability, at the session level 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 and removes the attribute if it does not wish to use ECN, or doesn't
skipping to change at page 17, line 11 skipping to change at page 17, line 5
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.
4.2. Initiation of ECN Use in an RTP Session 4.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 its destination(s). There is some risk of ECT or ECN-CE will reach their destination(s). There is some risk
that the usage 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 receiver 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.
The RTP senders and receivers SHALL NOT ECT mark their RTCP traffic The RTP senders and receivers SHALL NOT ECT mark their RTCP traffic
during both the initiation and full usage of ECN with RTP. This is at any time. This is to ensure that packet loss due to ECN marking
to ensure that packet loss due to ECN marking will not effect the will not effect the RTCP traffic and the necessary feedback
RTCP traffic and the necessary feedback information. 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 RTP and RTCP described in Section 4.2.1. It MAY also implement using in-band RTP and RTCP described in Section 4.2.1. It MAY also
other mechanisms to initiate ECN support, for example the STUN-based implement other mechanisms to initiate ECN support, for example the
mechanism described in Section 4.2.2 or use the leap of faith option STUN-based mechanism described in Section 4.2.2 or use the leap of
if the session supports the limitations provided in Section 4.2.3. faith option if the session supports the limitations provided in
If support for both mechanisms is signalled, the sender should try Section 4.2.3. If support for both in-band and out-of-band
ECN negotiation using STUN with ICE first, and if it fails, fallback mechanisms is signalled, the sender should try ECN negotiation using
to negotiation using RTP and RTCP ECN feedback. STUN with ICE first, and if it fails, fallback to negotiation using
RTP and RTCP ECN feedback.
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 receivers, to support monitor the ability of the network, and all its receivers, to support
ECN, following the mechanisms described in Section 4.4. This is ECN, following the mechanisms described in Section 4.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 network to support ECN. may invalidate the ability of the network to support ECN.
4.2.1. Detection of ECT using RTP and RTCP 4.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
path supports ECN comprises three stages. Firstly, the RTP sender path supports ECN comprises three stages. Firstly, the RTP sender
generates some fraction of its traffic with ECT marks to act a probe generates some small fraction of its traffic with ECT marks to act a
for ECN support. Then, on receipt of these ECT-marked packets, the probe for ECN support. Then, on receipt of these ECT-marked packets,
receivers send RTCP ECN feedback packets and RTCP ECN summary reports the receivers send RTCP ECN feedback packets and RTCP ECN summary
to inform the sender that their path supports ECN. Finally, the RTP reports to inform the sender that their path supports ECN. Finally,
sender makes the decision to use ECN or not, based on whether the the RTP sender makes the decision to use ECN or not, based on whether
paths to all RTP receivers have been verified to support ECN. the paths to all RTP receivers have been verified to support ECN.
Generating ECN Probe Packets: During the ECN initiation phase, an Generating ECN Probe Packets: During the ECN initiation phase, an
RTP sender SHALL mark a small fraction of its RTP traffic as ECT, RTP sender SHALL mark a small fraction of its RTP traffic as ECT,
while leaving the reminder of the packets unmarked. The main while leaving the reminder of the packets unmarked. The main
reason for only marking some packets is to maintain usable media reason for only marking some packets is to maintain usable media
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
skipping to change at page 18, line 36 skipping to change at page 18, line 28
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 duplicated in transmission, marked, those packets MUST NOT be duplicated in transmission,
since their RTP sequence number is used to identify packets that since their RTP sequence number is used to identify packets that
are received with ECN markings. 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 participants 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) to mark their receipt. An immediate or early packets (Section 5.1) to mark their receipt. An immediate or
(depending on the RTP/AVPF mode) ECN feedback packet SHOULD be early (depending on the RTP/AVPF mode) ECN feedback packet SHOULD
generated on receipt of the first ECT or ECN-CE marked packet from be generated on receipt of the first ECT or ECN-CE marked packet
a sender that has not previously sent any ECT traffic. Each from a sender that has not previously sent any ECT traffic. Each
regular RTCP report MUST contain an ECN summary report regular RTCP report MUST also contain an ECN summary report
(Section 5.2). Reception of any ECN-CE marked packets SHOULD also (Section 5.2). Reception of subsequent ECN-CE marked packets
result in additional early or immediate feedback packet with the SHOULD result in additional early or immediate ECN feedback
ECN feedback packet. packets being sent.
Determination of ECN Support: RTP is a group communication protocol, Determination of ECN Support: RTP is a group communication protocol,
where members can join and leave the group at any time. This where members can join and leave the group at any time. This
complicates the ECN initiation phase, since the sender must wait complicates the ECN initiation phase, since the sender must wait
until it believes the group membership has stabilised before it until it believes the group membership has stabilised before it
can determine if the paths to all receivers support ECN (group can determine if the paths to all receivers support ECN (group
membership changes after the ECN initiation phase has completed membership changes after the ECN initiation phase has completed
are discussed in Section 4.3). are discussed in Section 4.3).
An RTP sender shall consider the group membership to be stable An RTP sender shall consider the group membership to be stable
after it has been in the session and sending ECT-marked probe after it has been in the session and sending ECT-marked probe
packets for at least three RTCP reporting intervals (i.e. after packets for at least three RTCP reporting intervals (i.e. after
sending its third regularly scheduled RTCP packet), and when a sending its third regularly scheduled RTCP packet), and when a
complete RTCP reporting interval has passed without changes to the complete RTCP reporting interval has passed without changes to the
group membership. ECN initiation is considered successful when group membership. ECN initiation is considered successful when
the group membership becomes stable, provided all known the group membership is stable, and all known participants have
participants have sent one or more RTCP ECN feedback packets sent one or more RTCP ECN feedback packets indicating correct
indicating correct receipt of the ECT-marked RTP packets generated receipt of the ECT-marked RTP packets generated by the sender.
by the sender.
As an optimisation, if an RTP sender is initiating ECN usage As an optimisation, if an RTP sender is initiating ECN usage
towards a unicast address, then it MAY treat the ECN initiation as towards a unicast address, then it MAY treat the ECN initiation as
provisionally successful if it receives a single RTCP ECN feedback provisionally successful if it receives a single RTCP ECN feedback
report indicating successful receipt of the ECT-marked packets, report indicating successful receipt of the ECT-marked packets,
with no negative indications, from a single RTP receiver. After with no negative indications, from a single RTP receiver. After
declaring provisional success, the sender MAY generate ECT-marked declaring provisional success, the sender MAY generate ECT-marked
packets as described in Section 4.3, provided it continues to packets as described in Section 4.3, provided it continues to
monitor the RTCP reports for a period of three RTCP reporting monitor the RTCP reports for a period of three RTCP reporting
intervals from the time the ECN initiation started, to check if intervals from the time the ECN initiation started, to check if
skipping to change at page 20, line 5 skipping to change at page 19, line 45
ECN initiation is considered to have failed at the instant when ECN initiation is considered to have failed at the instant when
any RTP session participant sends an RTCP packet that doesn't any RTP session participant sends an RTCP packet that doesn't
contain an RTCP ECN feedback report or ECN summary report, but has contain an RTCP ECN feedback report or ECN summary report, but has
an RTCP RR with an extended RTP sequence number field that an RTCP RR with an extended RTP sequence number field that
indicates that it should have received multiple (>3) ECT marked indicates that it should have received multiple (>3) ECT marked
RTP packets. This can be due to failure to support the ECN RTP packets. This can be due to failure to support the ECN
feedback format by the receiver or some middlebox, or the loss of feedback format by the receiver or some middlebox, or the loss of
all ECT marked packets. Both indicate a lack of ECN support. all ECT marked packets. Both indicate a lack of ECN support.
The reception of RTCP ECN feedback packets that indicate greatly If the ECN negotiation succeeds, this indicates that the path can
increased packet loss rates for ECT marked packets, compared to pass some ECN-marked traffic, and that the receivers support ECN
non-ECT marked packets, is a strong indication of problems with feedback. This does not necessarily imply that the path can robustly
ECN support on the network path. Senders MAY consider such convey ECN feedback; Section Section 4.3 describes the ongoing
reports as indications that they should not use ECN on the path, monitoring that must be performed to ensure the path continues to
even though some ECT-marked packets do reach all receivers. robustly support ECN.
The sender must also watch for cases where ECT packets has been
remarked, for example to not-ECT, either explicitly reported in an
ECN feedback packet, or implicit due to a receiver not including
the ECN feedback format in its regular report.
4.2.2. Detection of ECT using STUN with ICE 4.2.2. Detection of ECT using STUN with ICE
This section describes an OPTIONAL method that can be used to avoid This section describes an OPTIONAL method that can be used to avoid
media impact and also ensure ECN capable path prior to media media impact and also ensure an ECN capable path prior to media
transmission. This method is considered in the context where the transmission. This method is considered in the context where the
session participants are using ICE [I-D.ietf-mmusic-ice] to find session participants are using ICE [I-D.ietf-mmusic-ice] to find
working connectivity. We need to use ICE rather than STUN only, as working connectivity. We need to use ICE rather than STUN only, as
the verification needs to happen from the media sender to the address the verification needs to happen from the media sender to the address
and port on which the receiver is listening. and port on which the receiver is listening.
To minimise the impact of set-up delay, and to prioritise the fact To minimise the impact of set-up delay, and to prioritise the fact
that one has a working connectivity rather than necessarily finding that one has a working connectivity rather than necessarily finding
the best ECN capable network path, this procedure is applied after the best ECN capable network path, this procedure is applied after
having performed a successful connectivity check for a candidate, having performed a successful connectivity check for a candidate,
which is nominated for usage. At that point, and provided the chosen which is nominated for usage. At that point, and provided the chosen
candidate is not a relayed address, one performs an additional candidate is not a relayed address, one performs an additional
connectivity check including the here defined STUN attribute "ECT connectivity check including the here defined STUN attribute "ECT
Check" and in an IP/UDP packet that are ECT marked. The STUN server Check" and in an UDP/IP packet that are ECT marked. The STUN server
will upon reception of the packet note the received ECN field value will upon reception of the packet note the received ECN field value
and in its response send an IP/UDP/STUN Packet with ECN field set to and in its response send an STUN/UDP/IP Packet with ECN field set to
not-ECT and also include the ECN check STUN attribute. not-ECT and also include the ECN check STUN attribute.
The STUN ECN check STUN attribute contains one field and a flag. The The STUN ECN check STUN attribute contains one field and a flag. The
flag indicate if the echo field contains a valid value or not. The flag indicate if the echo field contains a valid value or not. The
field is the ECN echo field, and when valid contains the two ECN bits field is the ECN echo field, and when valid contains the two ECN bits
from the packet it echoes back. The ECN check STUN attribute is an from the packet it echoes back. The ECN check STUN attribute is a
comprehension optional attribute. 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 1: ECN Check Stun Attribute Figure 1: ECN Check Stun Attribute
V: Valid (1 bit) ECN Echo value field is valid when set to 1, and V: Valid (1 bit) ECN Echo value field is valid when set to 1, and
invalid when set 0. invalid when set 0.
ECF: ECN Echo value field (2 bits) contains the ECN filed value of ECF: ECN Echo value field (2 bits) contains the ECN filed value of
the STUN packet it echoes back when field is valid. If invalid the STUN packet it echoes back when field is valid. If invalid
the content is arbitrary. the content is arbitrary.
Reserved: Reserved bits (29 bits) SHALL be set to 0 and SHALL be Reserved: Reserved bits (29 bits) SHOULD be set to 0 on
ignored on reception. transmission, and SHALL be ignored on reception.
This attribute MAY be included in any STUN request to request the ECN This attribute MAY be included in any STUN request to request the ECN
field to be echoed back. In STUN requests the V bit SHALL be set to field to be echoed back. In STUN requests the V bit SHALL be set to
0. A STUN server receiving a request with the ECN Check attribute 0. A STUN server receiving a request with the ECN Check attribute
which understand it SHALL read the ECN field value of the IP/UDP which understand it SHALL read the ECN field value of the IP/UDP
packet the request was received in. Upon forming the response the packet the request was received in. Upon forming the response the
server SHALL include the ECN Check attribute setting the V bit to server SHALL include the ECN Check attribute setting the V bit to
valid and include the read value of the ECN field into the ECF field. valid and include the read value of the ECN field into the ECF field.
4.2.3. Leap of Faith ECT initiation method 4.2.3. Leap of Faith ECT initiation method
This method for initiating ECN usage is a leap of faith that assumes This method for initiating ECN usage is a leap of faith that assumes
that ECN will work on the used path(s). It is not generally that ECN will work on the used path(s). It is not generally
recommended as the impact on both the application and the network may recommended as the impact on both the application and the network may
be substantial. Applications may experience high packet loss rates, be substantial if the path is not ECN capable. Applications may
this is both from dropped ECT marked packets, and the result of experience high packet loss rates, this is both from dropped ECT
driving the network into higher degrees of congestion by not being marked packets, and as a result of driving the network into higher
responsive to ECN marks. The network may experience higher degrees degrees of congestion by not being responsive to ECN marks. The
of congestion due to the unresponsiveness of the sender due to lost network may experience higher degrees of congestion due to the
ECN-CE marks from non-compliant remarking. unresponsiveness of the sender due to lost ECN-CE marks from non-
compliant remarking.
The method is to go directly to "ongoing use of ECN" as defined in The method is to go directly to "ongoing use of ECN" as defined in
Section 4.3. Thus all RTP packets MAY be marked as ECT and the Section 4.3. Thus all RTP packets MAY be marked as ECT and the
failure detection MUST be used to detect any case when the assumption failure detection MUST be used to detect any case when the assumption
that the path was ECT capable is wrong. that the path was ECT capable is wrong.
Not sending any RTP packets as not-ECT in the case of non-compliant If the sender marks all packets as ECT while transmitting on a path
node dropping ECT marked traffic the RTP receiver will not get any that contains a middlebox that drops all ECT-marked packets, then a
baseline packets to ensure that it treat this SSRC as an active receiver downstream of that middlebox will not receive any RTP data
sender. Thus the failure to include the sender in its RTCP sender or packets from that sender, and hence will not consider it to be an
receiver packets report block becomes the indicator for this case. active RTP SSRC. The sender can detect this, since SR/RR packets
This is blunter than a receiver report block that indicates from such receivers will either not include a report for the sender's
explicitly how many packets actually has been lost. The sender SSRC, or will include a report claiming that no packets have been
should be aware that in unicast or under AVPF transmission rules the received. The sender should be aware that a receiver may generate
first RTCP packet may come immediately upon joining or already after its first RTCP packet immediately on joining a unicast session, or
500 ms. Thus, triggering on reports without any report blocks, very shortly after joining a RTP/AVPF session, before it has had
cannot be done reliably on the first RTCP report received from a new chance to receive any data packets. A sender that receives RTCP
SSRC. Thus delaying detection of lack of functionality substantially SR/RR packet indicating lack of reception by a receiver may therefore
until a second report comes in. have to wait for a second RTCP report from that receiver to be sure
that the lack of reception is due to ECT-marking.
This method is only recommended for controlled environments where the This method is only recommended for controlled environments where the
whole path(s) between sender and receiver(s) has been built and whole path(s) between sender and receiver(s) has been built and
verified to be ECT. verified to be ECT. It is NOT RECOMMENDED that the leap-of-faith ECT
initiation method is used on unmanaged public Internet paths.
4.2.4. ECN Nonce during initiation 4.2.4. ECN Nonce during initiation
ECN Nonce if enabled SHALL be used during initiation the same way as If the ECN Nonce was enabled in the signalling, it SHALL be used
ECN nonce is used under ongoing use of ECN as described in during the initiation phase as described in Section 4.3.2.1.
Section 4.3.2.1.
4.3. Ongoing Use of ECN Within an RTP Session 4.3. Ongoing Use of ECN Within an RTP Session
Once ECN usage has been successfully initiated for an RTP sender, Once ECN usage has been successfully initiated for an RTP sender,
that sender begins sending all RTP data packets as ECT-marked, and that sender begins sending all RTP data packets as ECT-marked, and
its receivers continue sending ECN feedback information via RTCP its receivers continue sending ECN feedback information via RTCP
packets. This section describes procedures for sending ECT-marked packets. This section describes procedures for sending ECT-marked
data, providing ECN feedback information via RTCP, responding to ECN data, providing ECN feedback information via RTCP, responding to ECN
feedback information, and detecting failures and misbehaving feedback information, and detecting failures and misbehaving
receivers. receivers.
4.3.1. Transmission of ECT-marked RTP Packets 4.3.1. Transmission of ECT-marked RTP Packets
After a sender has successfully initiated ECN usage, it SHOULD mark After a sender has successfully initiated ECN usage, it SHOULD mark
all the RTP data packets it sends as ECT. The choice between ECT(0) all the RTP data packets it sends as ECT. The choice between ECT(0)
and ECT(1) is determined by the sender having considered the and ECT(1) is determined by the sender having considered the receiver
preferencies expressed by the "ect" parameter in the "a=ecn-capable- preferencies expressed by the "ect" parameter in the "a=ecn-capable-
rtp" attribute. If the sender selects a random choice of ECT rtp" attribute. If the sender selects a random choice of ECT
marking, the sender MUST record the statistics for the different ECN marking, the sender MUST record the statistics for the different ECN
values sent. If ECN nonce is activated the sender must record the values sent. If ECN nonce is activated the sender must record the
value and calculate the ECN-nonce sum for outgoing packets [RFC3540] value and calculate the ECN-nonce sum for outgoing packets [RFC3540]
to allow the use of the ECN-nonce to detect receiver misbehaviour to allow the use of the ECN-nonce to detect receiver misbehaviour
(see Section 4.4). Guidelines on the random choice of ECT values are (see Section 4.4). Guidelines on the random choice of ECT values are
provided in Section 8 of [RFC3540]. provided in Section 8 of [RFC3540].
The sender SHALL NOT include ECT marks on outgoing RTCP packets, and The sender SHALL NOT include ECT marks on outgoing RTCP packets, and
SHOULD NOT include ECT marks on any outgoing control messages (e.g. SHOULD NOT include ECT marks on any other outgoing control messages
STUN [RFC5389] packets, DTLS [RFC4347] handshake packets, or ZRTP (e.g. STUN [RFC5389] packets, DTLS [RFC4347] handshake packets, or
[I-D.zimmermann-avt-zrtp] control packets, that are multiplexed on ZRTP [I-D.zimmermann-avt-zrtp] control packets) that are multiplexed
the same UDP port). on the same UDP port.
4.3.2. Reporting ECN Feedback via RTCP 4.3.2. Reporting ECN Feedback via RTCP
An RTP receiver that receives a packet with an ECN-CE mark, or that An RTP receiver that receives a packet with an ECN-CE mark, or that
detects a packet loss, MUST schedule the transmission of an RTCP ECN detects a packet loss, MUST schedule the transmission of an RTCP ECN
feedback packet as soon as possible to report this back to the feedback packet as soon as possible to report this back to the
sender. The feedback RTCP packet sent SHALL consist at least one ECN sender. The feedback RTCP packet sent SHALL consist at least one ECN
feedback packet (Section 5) reporting on the packets received since feedback packet (Section 5) reporting on the packets received since
the last ECN feedback packet, and SHOULD contain an RTCP SR or RR the last ECN feedback packet, and SHOULD contain an RTCP SR or RR
packet. The RTP/AVPF profile in early or immediate feedback mode packet. The RTP/AVPF profile in early or immediate feedback mode
skipping to change at page 23, line 30 skipping to change at page 23, line 14
set-up signalling before they can be used. ECN Nonce information set-up signalling before they can be used. ECN Nonce information
SHOULD NOT be included in early or immediate reports, only when SHOULD NOT be included in early or immediate reports, only when
regular reports are sent. regular reports are sent.
Every time a regular compound RTCP packet is to be transmitted, the Every time a regular compound RTCP packet is to be transmitted, the
RTP receiver MUST include an RTCP XR ECN summary report Section 5.2 RTP receiver MUST include an RTCP XR ECN summary report Section 5.2
as part of the compound packet. If ECN-nonce is enabled the receiver as part of the compound packet. If ECN-nonce is enabled the receiver
MUST also include an RTCP XR Nonce report packet Section 5.3. It is MUST also include an RTCP XR Nonce report packet Section 5.3. It is
important to configure the RTCP bandwidth (e.g. using an SDP "b=" important to configure the RTCP bandwidth (e.g. using an SDP "b="
line) such that the bit-rate is sufficient for a usage that includes line) such that the bit-rate is sufficient for a usage that includes
ECN-CE events. these regular summary and none reports, and feedback on ECN-CE
events.
The multicast feedback implosion problem, that occurs when many The multicast feedback implosion problem, that occurs when many
receivers simultaneously send feedback to a single sender, must also receivers simultaneously send feedback to a single sender, must also
be considered. The RTP/AVPF transmission rules will limit the amount be considered. The RTP/AVPF transmission rules will limit the amount
of feedback that can be sent, avoiding the implosion problem but also of feedback that can be sent, avoiding the implosion problem but also
delaying feedback by varying degrees from nothing up to a full RTCP delaying feedback by varying degrees from nothing up to a full RTCP
reporting interval. As a result, the full extent of a congestion reporting interval. As a result, the full extent of a congestion
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 reasonably timely, allowing the sender to feedback should arrive in a reasonably timely manner , allowing the
react on a single or a few reports. sender to react on a single or a few reports.
An open issue is whether we should employ some form of feedback An open issue is whether we should employ some form of feedback
suppression on ECN-CE feedback for groups? If one can make an suppression on ECN-CE feedback for groups? If one can make an
assumption that a sender will react on a few ECN-CE marks then assumption that a sender will react on a few ECN-CE marks then
suppression could be employed successfully and reduce the RTCP suppression could be employed successfully and reduce the RTCP
bandwidth usage. bandwidth usage.
In case a receiver driven congestion control algorithm is to be used In case a receiver driven congestion control algorithm is to be used
and has through signalling been agreed upon, the algorithm MAY and has been agreed upon through signalling, the algorithm MAY
specify that the immediate scheduling (and later transmission) of specify that the immediate scheduling (and later transmission) of
ECN-CE feedback of any received ECN-CE mark is not required and shall ECN-CE feedback of any received ECN-CE mark is not required and shall
not be done. In that case ECN feedback is only sent using regular not be done (since it is not necessary for congestion control
RTCP reports for verification purpose and in response to the purposes in such cases). In that case ECN feedback is only sent
initiation process ("rtp") of any new media senders as specified in using regular RTCP reports for verification purpose and in response
Section 4.2.1. to the initiation process ("rtp") of any new media senders as
specified in Section 4.2.1.
4.3.2.1. ECN Nonce Reporting 4.3.2.1. ECN Nonce Reporting
ECN Nonce reporting requires both the ECN nonce sum and the sequence When ECN Nonce reporting is used, it requires both the ECN nonce sum
numbers for packets where the ECN marking has been lost. This and the sequence numbers for packets where the ECN marking has been
information is variable size as it depends on both the total number lost to be reported. This information is variable size as it depends
of packet sent per reporting interval and the CE and Packet loss on both the total number of packet sent per reporting interval and
pattern how many bits are required for reporting. the CE and Packet loss pattern how many bits are required for
reporting.
The RTCP packets may be lost, and to avoid the possibility for The RTCP packets may be lost, and to avoid the possibility for
cheating by "losing" the Nonce information for where one is cheating cheating by "losing" the Nonce information for where one is cheating
the nonce coverage needs to be basically complete. Thus the Nonce the nonce coverage needs to be basically complete. Thus the Nonce
reporting SHOULD cover at least the 3 regular reporting intervals. reporting SHOULD cover at least the 3 regular reporting intervals.
The only exception allowed is if the reporting information becomes to The only exception allowed is if the reporting information becomes to
heavy and makes the RTCP report packet become larger than the MTU. heavy and makes the RTCP report packet become larger than the MTU.
In that case a receiver MAY reduced to coverage for the ECN nonce to In that case a receiver MAY reduced to coverage for the ECN nonce to
only the last or two last reporting intervals. A sender should only the last or two last reporting intervals. A sender should
consider the received size report for cases where the coverage is not consider the received size report for cases where the coverage is not
skipping to change at page 25, line 6 skipping to change at page 24, line 42
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.
Receiver-Driven Congestion Control: If receiver driven congestion Receiver-Driven Congestion Control: If a receiver driven congestion
control mechanism is used, the receiver can react to the ECN-CE control mechanism is used, the receiver can react to the ECN-CE
marks without contacting the sender. This may allow faster marks without contacting the sender. This may allow faster
response than sender-driven congestion control in some response than sender-driven congestion control in some
circumstances. Receiver-driven congestion control is usually circumstances. Receiver-driven congestion control is usually
implemented by providing the content in a layered way, with each implemented by providing the content in a layered way, with each
layer providing improved media quality but also increased layer providing improved media quality but also increased
bandwidth usage. The receiver locally monitors the ECN-CE marks bandwidth usage. The receiver locally monitors the ECN-CE marks
on received packet to check if it experiences congestion at the on received packet to check if it experiences congestion at the
current number of layers. If congestion is experienced, the current number of layers. If congestion is experienced, the
receiver drops one layer, so reducing the resource consumption on receiver drops one layer, so reducing the resource consumption on
skipping to change at page 25, line 32 skipping to change at page 25, line 19
can determine if ECN is supported on the network path. The can determine if ECN is supported on the network path. The
timeliness of RTCP feedback is less of a concern with receiver timeliness of RTCP feedback is less of a concern with receiver
driven congestion control, and regular RTCP reporting of ECN driven congestion control, and regular RTCP reporting of ECN
feedback is sufficient (without using RTP/AVPF immediate or early feedback is sufficient (without using RTP/AVPF immediate or early
feedback). feedback).
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
problem is diverse paths, i.e. when different receivers don't see the problem is diverse paths, i.e. when different receivers don't see the
same path, and thus have different bottlenecks, so the receivers may same path, and thus have different bottlenecks, so the receivers may
get ECN-CE marked packets due to congestion in different points in get ECN-CE marked packets due to congestion at different points in
the network. This is problematic for sender driven congestion the network. This is problematic for sender driven congestion
control, since when receivers are heterogeneous in regards to control, since when receivers are heterogeneous in regards to
capacity the sender is limited to transmitting at the rate the capacity the sender is limited to transmitting at the rate the
slowest receiver can support. This often becomes a significant slowest receiver can support. This often becomes a significant
limitation as group size grows. Also, as group size increases the limitation as group size grows. Also, as group size increases the
frequency of reports from each receiver decreases, which further frequency of reports from each receiver decreases, which further
reduces the responsiveness of the mechanism. Receiver-driven reduces the responsiveness of the mechanism. Receiver-driven
congestion control has the advantage that each receiver can choose congestion control has the advantage that each receiver can choose
the appropriate rate for its network path, rather than all having to the appropriate rate for its network path, rather than all having to
settle for the lowest common rate. settle for the lowest common rate.
skipping to change at page 26, line 18 skipping to change at page 26, line 6
is in the best interest of an application to respond to ECN is in the best interest of an application to respond to ECN
congestion feedback promptly, to avoid packet loss. congestion feedback promptly, to avoid packet loss.
4.4. Detecting Failures and Receiver Misbehaviour 4.4. Detecting Failures and Receiver Misbehaviour
ECN-nonce is defined in RFC3540 as a means to ensure that a TCP ECN-nonce is defined in RFC3540 as a means to ensure that a TCP
clients does not mask ECN-CE marks, this assumes that the sending clients does not mask ECN-CE marks, this assumes that the sending
endpoint (server) acts on behalf of the network. endpoint (server) acts on behalf of the network.
The assumption about the senders acting on the behalf of the network The assumption about the senders acting on the behalf of the network
may be reduced due to the nature of peer-to-peer usage. Still a may be reduced due to the nature of peer-to-peer use of RTP. Still a
large part of RTP senders are infrastructure devices that do have an significant portion of RTP senders are infrastructure devices (for
interest in protecting both service quality and the network. In example, streaming media servers) that do have an interest in
addition as real-time media commonly is more sensitive to increased protecting both service quality and the network. In addition as
delay and packet loss it will be in both media sender and receivers real-time media is commonly sensitive to increased delay and packet
interest to minimise the number and duration of any congestion events loss it will be in both media sender and receivers interest to
as it will affect media quality. minimise the number and duration of any congestion events as they
will affect media quality.
In addition ECN with RTP can suffer from path changes resulting in RTP sessions can also suffer from path changes resulting in a non-ECN
that a non ECN compliant node becomes part of the path. That node compliant node becoming part of the path. That node may perform
may perform either of two actions that has effect on the ECN and either of two actions that has effect on the ECN and application
application functionality. The gravest is if the node drops packets functionality. The gravest is if the node drops packets with any ECN
with any ECN field values other than 00b. This can be detected by field values other than 00b. This can be detected by the receiver
the receiver when it receives a RTCP SR packet indicating that a when it receives a RTCP SR packet indicating that a sender has sent a
number of packets has not been received. The sender may also detect a number of packets has not been received. The sender may also
it based on the receivers RTCP RR packet where the extended sequence detect it based on the receivers RTCP RR packet where the extended
number is not advanced due to the failure to receive packets. If the sequence number is not advanced due to the failure to receive
packet loss is less than 100% then packet loss reporting in either packets. If the packet loss is less than 100% then packet loss
the ECN feedback information or RTCP RR will indicate the situation. reporting in either the ECN feedback information or RTCP RR will
The other action is to remark a packet from ECT to not-ECT. That has indicate the situation. The other action is to remark a packet from
less dire results, however, it should be detected so that ECN usage ECT to not-ECT. That has less dire results, however, it should be
can be suspended to prevent misusing the network. detected so that 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. If this number doesn't agree there are two likely marked packets. If this number doesn't agree there are two likely
reasons, a translator changing the stream or not carrying the ECN reasons, a translator changing the stream or not carrying the ECN
markings forward or that some node remarks the packets. In both markings forward, or that some node remarks the packets. In both
cases the usage of ECN is broken on the path. By tracking all the cases the usage of ECN is broken on the path. By tracking all the
different possible ECN field values a sender can quickly detect if different possible ECN field values a sender can quickly detect if
some non-compliant behavior is happing on the path. some non-compliant behavior is 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.
4.4.1. Fallback mechanisms 4.4.1. Fallback mechanisms
Upon the detection of a potential failure both the sender and the Upon the detection of a potential failure both the sender and the
receiver can react to mitigate the situation. receiver can react to mitigate the situation.
A Receiver that detects a packet loss burst MAY schedule an early A receiver that detects a packet loss burst MAY schedule an early
feedback packet to report this to the sender that includes at least feedback packet to report this to the sender that includes at least
the RTCP RR and the ECN feedback message. Thus speeding up the the RTCP RR and the ECN feedback message. Thus speeding up the
detection at the sender of the losses and thus triggering sender side detection at the sender of the losses and thus triggering sender side
mitigation. mitigation.
A Sender that detects high packet loss rates for its RTP packet flow A sender that detects high packet loss rates for ECT-marked packets
while sending them marked as ECT, SHOULD immediately remark them as SHOULD immediately switch to sender packets as not-ECT to determine
not-ECT to determine if the losses potentially are due to the ECT if the losses potentially are due to the ECT markings. If the losses
markings. If the losses disappear with the remarking, the RTP sender disappear when the ECT-marking is discontinued, the RTP sender should
should go back to initiation procedures to attempt to verify the go back to initiation procedures to attempt to verify the apparent
apparent loss of ECN capability of the used path. If a re-initiation loss of ECN capability of the used path. If a re-initiation fails
fails then the two possible actions exist: then the two possible actions exist:
1. Periodically retry the ECN initiation to detect if a path change 1. Periodically retry the ECN initiation to detect if a path change
occurs to a path that are ECN capable. occurs to a path that are ECN capable.
2. Renegotiating the session to disable ECN support. A choice that 2. Renegotiating the session to disable ECN support. This is a
is suitable if the impact of ECT probing on the media quality are choice that is suitable if the impact of ECT probing on the media
noticeable. If multiple initiations has been successful but the quality are noticeable. If multiple initiations has been
following full usage of ECN has resulted in the fallback successful but the following full usage of ECN has resulted in
procedures then disabling of the ECN support is RECOMMENDED. the fallback procedures then disabling of the ECN support is
RECOMMENDED.
We foresee the possibility of flapping ECN capability due to several We foresee the possibility of flapping ECN capability due to several
reasons: reasons: video switching MCU or similar middleboxes that selects to
deliver media from the sender only intermittently; Load balancing
o Video switching MCU or similar middleboxes that selects to deliver devices may in worst case result in that some packets take a
media from the sender only intermittently. different network path then the others; mobility solutions that
switches underlying network path in a transparent way for the sender
o Load balancing devices may in worst case result in that some or receiver; and membership changes in a multicast group.
packets take a different network path then the others.
o Mobility solutions that switches underlying network path in a
transparent way for the sender or receiver.
o Membership changes in a multicast group.
4.4.2. Interpretation of ECN Summary information 4.4.2. Interpretation of ECN Summary information
This section contains discussion on how you can use the ECN summary This section contains discussion on how you can use the ECN summary
report information in detecting various types of ECN path issues. report information in detecting various types of ECN path issues.
Lets start to review the information the reports provide on a per Lets start to review the information the reports provide on a per
source (SSRC) basis: source (SSRC) basis:
CE Counter: The number of RTP packets received so far in the session CE Counter: The number of RTP packets received so far in the session
with an ECN field set to CE (11b). with an ECN field set to CE (11b).
ECT (0/1) Counters: The number of RTP packets received so far in the ECT (0/1) Counters: The number of RTP packets received so far in the
session with an ECN field set to ECT (0) and ECT (1) respectively session with an ECN field set to ECT (0) and ECT (1) respectively
(10b / 01b). (10b / 01b).
not-ECT Counter: The number of RTP packets received so far in the not-ECT Counter: The number of RTP packets received so far in the
session with an ECN field set to not-ECT (00b) session with an ECN field set to not-ECT (00b)
Lost Packets counter: The number of RTP packets that are expected
Packet loss counter: The number of RTP packets that are expected
minus the number received. minus the number received.
Extended Highest Sequence number: The highest sequence number seen Extended Highest Sequence number: The highest sequence number seen
when sending this report, but with additional bits, to handle when sending this report, but with additional bits, to handle
disambiguation when wrapping the RTP sequence number field. disambiguation when wrapping the RTP sequence number field.
The counters will be initiated to zero they provide value for the RTP The counters will be initiated to zero to provide value for the RTP
stream sender from the very first report. After the first report the stream sender from the very first report. After the first report the
changes between the latest received and the previous one is changes between the latest received and the previous one is
determined by simply taking the values of the latest minus the determined by simply taking the values of the latest minus the
previous one, taking field wrapping into account. This definition is previous one, taking field wrapping into account. This definition is
also robust to packet losses, as if one report is missing, the period also robust to packet losses, since if one report is missing, the
for which the information is covering becomes longer, but otherwise reporting interval becomes longer, but is otherwise equally valid.
equally valid.
In a perfect world the number of not-ECT received should be equal to In a perfect world the number of not-ECT packets received should be
the number sent minus some fraction of the lost packets, and the sum equal to the number sent minus the lost packets counter, and the sum
of the ECT, CE should be equal to the number ECT marked sent minus a of the ECT(0), ECT(1), and CE counters should be equal to the number
fraction of the lost packets. There are however two sources of of ECT marked packet sent. Two issues may cause a mismatch in these
uncertainty in this, number of packet losses, and packet duplication. statistics: severe network congestion or unresponsive congestion
Packet loss and packet duplication can change the distribution control might cause some ECT-marked packets to be lost, and packet
between ECT(0), ECT(1) and not-ECT. This by having for example a ECT duplication might result in some packets being received, and counted
(0) packet being lost, and then a ECT(1) packet being duplicated and in the statistics, multiple times (potentially with a different ECN-
counted as two, thus making the ECT(1) counter become one bigger and mark on each copy of the duplicate).
the ECT(0) one less than expected. To avoid these issues it is
recommended that suppression of duplicate packets are performed
before gathering this statistics.
The level of packet duplication included in the report can be The level of packet duplication included in the report can be
estimated from the sum over all of fields counting received packets. estimated from the sum over all of fields counting received packets
compared to the number of packets sent. A high level of packet
A high level of packet duplication increases the insecurity in the duplication increases the insecurity in the statistics and firm
statistics and firm conclusions becomes more difficult and requires conclusions becomes more difficult and requires clearer statics.
clearer statics.
Detecting clearing of ECN field: If the ratio between ECT and not- Detecting clearing of ECN field: If the ratio between ECT and not-ECT
ECT transmitted in the reports has become all not-ECT or transmitted in the reports has become all not-ECT or substantially
substantially changed towards not-ECT then this is clearly changed towards not-ECT then this is clearly indication that the path
indication that the path results in clearing of the ECT field. results in clearing of the ECT field.
Dropping of ECT packets To determine if the packet drop ratio is Dropping of ECT packets: To determine if the packet drop ratio is
different between not-ECT and ECT marked transmission requires a different between not-ECT and ECT marked transmission requires a mix
mix of transmitted traffic. The sender should compare if the of transmitted traffic. The sender should compare if the delivery
delivery percentage (delivered / transmitted) between ECT and not- percentage (delivered / transmitted) between ECT and not-ECT is
ECT is significantly different. Care must be taken if the number significantly different. Care must be taken if the number of packets
of packets are low in either of the categories. are low in either of the categories.
4.4.3. Using ECN-nonce 4.4.3. Using ECN-nonce
This document offers ECN Nonce as a method of strengthening both the This document offers ECN Nonce as a method of strengthening the
detection of failures and enable senders to verify the receiver detection of failures, and to allow senders to verify the receiver
behavior. We note that it appears quite counter productive for a behavior. We note that it appears counter-productive for a receiver
receiver to attempt to cheat as it most likely will have negative to attempt to cheat as it most likely will have negative impact on
impact on its media quality. However, certain usages of RTP may its media quality. However, certain usages of RTP may result in a
result in a situation that is more similar to TCP, i.e. where packet situation that is more similar to TCP, i.e. where packet losses are
losses are repaired and a higher bit-rate is desirable. Thus RTP repaired and a higher bit-rate is desirable. Thus RTP sessions that
sessions that use repair mechanisms as FEC or retransmission may use repair mechanisms as FEC or retransmission may consider the usage
consider the usage of the ECN nonce to prevent cheating. of the ECN nonce to prevent cheating.
5. RTCP Extensions for ECN feedback 5. RTCP Extensions for ECN feedback
This documents defines three different RTCP extensions. One AVPF This documents defines three different RTCP extensions: one AVPF NACK
NACK Transport feedback format for urgent ECN information. One RTCP Transport feedback format for urgent ECN information; one RTCP XR ECN
XR ECN summary report block type for regular reporting of the ECN summary report block type for regular reporting of the ECN marking
marking information. And one additional RTCP XR report block type information; and one additional RTCP XR report block type for ECN
for ECN nonce. nonce.
5.1. ECN Feedback packet 5.1. ECN Feedback packet
This AVPF NACK feedback format is intended for usage in AVPF early or This AVPF NACK feedback format is intended for usage in AVPF early or
immediate feedback modes when information needs to urgently reach the immediate feedback modes when information needs to urgently reach the
sender. Thus its main usage is upon reception of a ECN-CE marked RTP sender. Thus its main use is to report on reception of an ECN-CE
packet, or during the initiation procedures to speed that up. The marked RTP packet so that the sender may perform congestion control,
feedback format is also defined with reduced size RTCP [RFC5506] in or to speed up the initiation procedures by rapidly reporting that
mind. In reduced size RTCP feedback packets may be sent without the path can support ECN-marked traffic. The feedback format is also
accompanying Sender or Receiver Reports that would contain the defined with reduced size RTCP [RFC5506] in mind, where RTCP feedback
Extended Highest Sequence number and the accumulated number of packet packets may be sent without accompanying Sender or Receiver Reports
losses. Both are important for the ECN functionality to verify that would contain the Extended Highest Sequence number and the
functionality and keep track of when CE marking does occur. accumulated number of packet losses. Both are important for the ECN
functionality to verify functionality and keep track of when CE
marking does occur.
The RTCP packet starts with the common header defined by AVPF The RTCP AVPF NACK packet starts with the common header defined by
[RFC4585] which is reproduced here for the readers information: the RTP/AVPF profile [RFC4585] which is reproduced here for the
reader's information:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | length | |V=2|P| FMT | PT | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender | | SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source | | SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) : : Feedback Control Information (FCI) :
skipping to change at page 31, line 5 skipping to change at page 30, line 29
Figure 3: ECN Feedback Format Figure 3: ECN Feedback Format
The FCI information for the ECN Feedback format (Figure 3) are the The FCI information for the ECN Feedback format (Figure 3) are the
following: following:
Extended Highest Sequence Number: The least significant 20-bit from Extended Highest Sequence Number: The least significant 20-bit from
an Extended highest sequence number received value as defined by an Extended highest sequence number received value as defined by
[RFC3550]. Used to indicate for which packet this report is valid [RFC3550]. Used to indicate for which packet this report is valid
upto. upto.
Lost Packets Counter: The total number of RTP packets from this SSRC Lost Packets Counter: The cumulative number of RTP packets that the
the receiver that it expected minus the number of received, see receiver expected to receive from this SSRC, minus the number of
Section 6.4.1 of [RFC3550] for the normative definition. This packets it actually received. This is the same as the cumulative
representation is done using 12-bit signed representation, number of packets lost defined in Section 6.4.1 of [RFC3550]
compared to 24-bit in RTCP SR or RR packets. It is important to except represented in 12-bit signed format, compared to 24-bit in
ensure that the wrapping is handled correctly. RTCP SR or RR packets. As with the equivalent value in RTCP SR or
RR packets, note that packets that arrive late are not counted as
lost, and the loss may be negative if there are duplicates.
CE Counter: The total number of RTP packets from this SSRC the CE Counter: The cumulative number of RTP packets received from this
receiver has received since the receiver joined the RTP session SSRC since the receiver joined the RTP session that were ECN-CE
that had an ECN field value of CE. The receiver should keep track marked. The receiver should keep track of this value using a
of this value using a local representation that is longer than 16- local representation that is longer than 16-bits, and only include
bits, and only include the 16-bits with least significance. In the 16-bits with least significance. In other words, the field
other words, the field will wrap to 0 if more than 65535 packets will wrap to 0 if more than 65535 packets has been received.
has been received.
ECT (0) Counter: The total number of RTP packets from this SSRC the ECT(0) Counter: The cumulative number of RTP packets received from
receiver has received since the receiver joined the RTP session this SSRC since the receiver joined the RTP session that had an
that had an ECN field value of ECT (0). The receiver should keep ECN field value of ECT(0). The receiver should keep track of this
track of this value using a local representation that is longer value using a local representation that is longer than 16-bits,
than 16-bits, and only include the 16-bits with least and only include the 16-bits with least significance. In other
significance. In other words, the field will wrap if more than words, the field will wrap if more than 65535 packets have been
65535 packets has been received. received.
ECT (1) Counter: The total number of RTP packets from this SSRC the ECT(1) Counter: The cumulative number of RTP packets received from
receiver has received since the receiver joined the RTP session this SSRC since the receiver joined the RTP session that had an
that had an ECN field value of ECT (1). The receiver should keep ECN field value of ECT(1). The receiver should keep track of this
track of this value using a local representation that is longer value using a local representation that is longer than 16-bits,
than 16-bits, and only include the 16-bits with least and only include the 16-bits with least significance. In other
significance. In other words, the field will wrap if more than words, the field will wrap if more than 65535 packets have been
65535 packets has been received. received.
not-ECT Counter: The total number of RTP packets from this SSRC the not-ECT Counter: The cumulative number of RTP packets received from
receiver has received since the receiver joined the RTP session this SSRC since the receiver joined the RTP session that had an
that had an ECN field value of not-ECT. The receiver should keep ECN field value of not-ECT. The receiver should keep track of
track of this value using a local representation that is longer this value using a local representation that is longer than 16-
than 16-bits, and only include the 16-bits with least bits, and only include the 16-bits with least significance. In
significance. In other words, the field will wrap if more than other words, the field will wrap if more than 65535 packets have
65535 packets has been received. been received.
Each FCI reports on a single source. Multiple sources can be Each FCI block reports on a single source (SSRC). Multiple sources
reported by including multiple RTCP feedback messages in an compound can be reported by including multiple RTCP feedback messages in an
RTCP packet. The AVPF common header indicates both the sender of the compound RTCP packet. The AVPF common header indicates both the
feedback message and on which stream it relates to. sender of the feedback message and on which stream it relates to.
The Counters SHALL be initiated to 0 for a new receiver. This to The Counters SHALL be initiated to 0 for a new receiver. This to
enable detection of CE or Packet loss already on the initial report enable detection of CE or Packet loss already on the initial report
from a specific participant. from a specific participant.
The Extended Highest sequence number and packet loss fields are both The Extended Highest sequence number and packet loss fields are both
truncated in comparison to the RTCP SR or RR versions. This is to truncated in comparison to the RTCP SR or RR versions. This is to
save bits as the representation is redundant unless reduced size RTCP save bits as the representation is redundant unless reduced size RTCP
is used in such a way that only feedback packets are transmitted, is used in such a way that only feedback packets are transmitted,
with no SR or RR in the compound RTCP packet. Due to that regular with no SR or RR in the compound RTCP packet. Due to that regular
skipping to change at page 33, line 21 skipping to change at page 32, line 45
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (0) Counter | ECT (1) Counter | | ECT (0) Counter | ECT (1) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BT: Block Type identifying the ECN summary report block. Value is BT: Block Type identifying the ECN summary report block. Value is
[TBA2]. [TBA2].
Reserved: All bits SHALL be set to 0 on transmission and ignored on Reserved: All bits SHALL be set to 0 on transmission and ignored on
reception. reception.
Block Lenght: The length of the report block. Used to indicate the Block Length: The length of the report block. Used to indicate the
number of report data blocks present in the ECN summary report. number of report data blocks present in the ECN summary report.
This length will 3*n, where n is the number of data blocks, i.e. 3 This length will always equal 3, since blocks are a fixed size.
for one data block, 6 for two, etc.
SSRC of Media Sender: The SSRC identifying the media sender this SSRC of Media Sender: The SSRC identifying the media sender this
report is for. report is for.
CE Counter: The total number of RTP packets from this SSRC the CE Counter: as in Section 5.1.
receiver has received since the receiver joined the RTP session
that had an ECN field value of CE. The receiver should keep track
of this value using a local representation that is longer than 16-
bits, and only include the 16-bits with least significance. In
other words, the field will wrap if more than 65535 packets has
been received.
not-ECT Counter: The total number of RTP packets from this SSRC the ECT(0) Counter: as in Section 5.1.
receiver has received since the receiver joined the RTP session
that had an ECN field value of not-ECT. The receiver should keep
track of this value using a local representation that is longer
than 16-bits, and only include the 16-bits with least
significance. In other words, the field will wrap if more than
65535 packets has been received.
ECT (0) Counter: The total number of RTP packets from this SSRC the ECT(1) Counter: as in Section 5.1.
receiver has received since the receiver joined the RTP session
that had an ECN field value of ECT (0). The receiver should keep
track of this value using a local representation that is longer
than 16-bits, and only include the 16-bits with least
significance. In other words, the field will wrap if more than
65535 packets has been received.
ECT (1) Counter: The total number of RTP packets from this SSRC the not-ECT Counter: as in Section 5.1.
receiver has received since the receiver joined the RTP session
that had an ECN field value of ECT (1). The receiver should keep
track of this value using a local representation that is longer
than 16-bits, and only include the 16-bits with least
significance. In other words, the field will wrap if more than
65535 packets has been received.
The Extended Highest Sequence number and the packet loss counter for The Extended Highest Sequence number and the packet loss counter for
each SSRC is not present in RTCP XR report, in contrast to the each SSRC is not present in RTCP XR report, in contrast to the
feedback version. The reason is that this summary report will always feedback version. The reason is that this summary report will always
be sent in a RTCP compound packet where the Extended Highest Sequence be sent in a RTCP compound packet where the Extended Highest Sequence
number and the accumulated number of packet losses are present in the number and the accumulated number of packet losses are present in the
RTCP Sender Report or Receiver Report packet's report block. RTCP Sender Report or Receiver Report packet's report block.
5.3. RTCP XR Report Block for ECN Nonce 5.3. RTCP XR Report Block for ECN Nonce
This RTCP XR block is for ECN Nonce reporting. It consists of an This RTCP XR block is for ECN Nonce reporting. It consists of an
initial part that contains the ECN nonce XOR sum followed by an Run initial part that contains the ECN nonce XOR sum, followed by a
length encoded (RLE) bitvector that indicate which RTP sequence series of bit-vector chunks that indicate which RTP sequence numbers
numbers that wasn't included in the ECN nonce sum due to having been were lost or CE-marked, and so weren't included in the ECN nonce sum.
lost or ECN CE marked. The bit-vector uses 1 to indicate that the The bit-vector uses 1 to indicate that the packet wasn't included in
packet wasn't included in the ECN nonce sum and 0 for packets that the ECN nonce sum and 0 for packets that where.
where.
The bit-vector is expressed using either Run-Length Encoding or 15- The bit-vector is expressed using either Run-Length Encoding or 15-
bit explicit bit-vectors. The whole vector is encoded using the 16- bit explicit bit-vectors. The whole vector is encoded using the 16-
bit chunks as defined by Section 4.1.1, 4.1.2, and 4.1.3 in bit chunks as defined by Section 4.1.1, 4.1.2, and 4.1.3 in
[RFC3611]. The Terminating Null Chunk MUST be used as padding in [RFC3611]. The Terminating Null Chunk MUST be used as padding in
cases the total number of chunks would otherwise be odd and thus the cases the total number of chunks would otherwise be odd and thus the
report block wouldn't reach a 32-bit boundary. report block wouldn't reach a 32-bit boundary.
The ECN Nonce report block structure is the following: The ECN Nonce report block structure is the following:
skipping to change at page 36, line 22 skipping to change at page 35, line 5
Nonce sum MUST perform suppression of packet duplicates. The nonce Nonce sum MUST perform suppression of packet duplicates. The nonce
sum will become incorrect if any duplicates are included in the sum. sum will become incorrect if any duplicates are included in the sum.
All packets not received or received as ECN-CE marked when All packets not received or received as ECN-CE marked when
constructing the ECN Nonce report MUST be explicitly marked in the constructing the ECN Nonce report MUST be explicitly marked in the
bitvector. bitvector.
The Nonce reporting interval is RECOMMENDED to cover all the RTP The Nonce reporting interval is RECOMMENDED to cover all the RTP
packets received during the three last regular reporting intervals. packets received during the three last regular reporting intervals.
This is to ensure that the sender will receive a report over all RTP This is to ensure that the sender will receive a report over all RTP
packets. Failure to deliver reports that cover all the packets may packets. Failure to deliver reports that cover all the packets may
be interpreted as an attempt to cheat. Two additional considerations be interpreted as an attempt to cheat.
must be made when selecting the reporting interval. First, are the
MTU considerations. The packet vector and its encoding into chunks Two additional considerations must be made when selecting the
results in a variable sized report. The size depends on two main reporting interval. First, are the MTU considerations. The packet
factors, the number of packets to report on and the frequency of bit- vector and its encoding into chunks results in a variable sized
value changes in the vector. The reporting interval may need to be report. The size depends on two main factors, the number of packets
shortened to two or even one reporting interval if the resulting ECN to report on and the frequency of bit-value changes in the vector.
nonce report becomes too big to fit into the RTCP packet. The reporting interval may need to be shortened to two or even one
reporting interval if the resulting ECN nonce report becomes too big
to fit into the RTCP packet.
Secondly, the RTP sequence number can easily wrap and that needs to Secondly, the RTP sequence number can easily wrap and that needs to
be considered when they are handed. The report SHALL NOT report on be considered when they are handed. The report SHALL NOT report on
more than 32768 consecutive packets. The last sequence number is the more than 32768 consecutive packets. The last sequence number is the
extended sequence number that is equal too or smaller (less than extended sequence number that is equal too or smaller (less than
65535 packets) than the value present in the Receiver Reports 65535 packets) than the value present in the Receiver Reports
"extended highest sequence number received" field. The "first "extended highest sequence number received" field. The "first
sequence number" value is thus an extended sequence number which is sequence number" value is thus an extended sequence number which is
smaller than the "last sequence number". If there is a wrap between smaller than the "last sequence number". If there is a wrap between
the first sequence number and the last, i.e. First sequence number > the first sequence number and the last, i.e. if the first sequence
Last sequence number (seen as 16-bit unsigned integers), then the number is greater than the last sequence number (when seen as 16-bit
wrap needs to included in the calculation. If an application is unsigned integers), this needs to included in the calculation. If an
having these issues, the frequency of regular RTCP reporting should application is having these issues, the frequency of regular RTCP
be modified by ensuring that the application chooses appropriate reporting should be modified by ensuring that the application chooses
settings for the minimum RTCP reporting interval parameters. appropriate settings for the minimum RTCP reporting interval
parameters.
Both the ECN-CE and packet loss information is structured as bit Both the ECN-CE and packet loss information is structured as bit
vectors where the first bit represents the RTP packet with the vectors where the first bit represents the RTP packet with the
sequence number equal to the First Sequence number. The bit-vector sequence number equal to the First Sequence number. The bit-vector
will contain values representing all packets up to and including the will contain values representing all packets up to and including the
one in the "end_seq" field. The chunk mechanism used to represent one in the "end_seq" field. The chunk mechanism used to represent
the bit-vector in an efficient way may appear longer upon reception the bit-vector in an efficient way may appear longer upon reception
if an explicit bit-vector is used as the last chunk. Bit-values if an explicit bit-vector is used as the last chunk. Bit-values
representing packets with higher sequence number (modulo 16) than representing packets with higher sequence number (modulo 16) than
"end_seq" are not valid and SHALL be ignored. "end_seq" are not valid and SHALL be ignored.
 End of changes. 89 change blocks. 
413 lines changed or deleted 380 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/