draft-ietf-avtcore-ecn-for-rtp-03.txt   draft-ietf-avtcore-ecn-for-rtp-04.txt 
skipping to change at page 1, line 15 skipping to change at page 1, line 15
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: January 12, 2012 C. Perkins Expires: January 12, 2012 C. Perkins
University of Glasgow University of Glasgow
P. O'Hanlon P. O'Hanlon
UCL UCL
K. Carlberg K. Carlberg
G11 G11
July 11, 2011 July 11, 2011
Explicit Congestion Notification (ECN) for RTP over UDP Explicit Congestion Notification (ECN) for RTP over UDP
draft-ietf-avtcore-ecn-for-rtp-03 draft-ietf-avtcore-ecn-for-rtp-04
Abstract Abstract
This memo specifies how Explicit Congestion Notification (ECN) can be This memo specifies how Explicit Congestion Notification (ECN) can be
used with the Real-time Transport Protocol (RTP) running over UDP, used with the Real-time Transport Protocol (RTP) running over UDP,
using RTP Control Protocol (RTCP) as a feedback mechanism. It using RTP Control Protocol (RTCP) as a feedback mechanism. It
defines a new RTCP Extended Report (XR) block for periodic ECN defines a new RTCP Extended Report (XR) block for periodic ECN
feedback, a new RTCP transport feedback message for timely reporting feedback, a new RTCP transport feedback message for timely reporting
of congestion events, and a Session Traversal Utilities for NAT of congestion events, and a Session Traversal Utilities for NAT
(STUN) extension used in the optional initilization method using (STUN) extension used in the optional initialization method using
Interactive Connectivity Establishment (ICE). Signalling and Interactive Connectivity Establishment (ICE). Signalling and
procedures for negotiation of capabilities and initilization methods procedures for negotiation of capabilities and initialization methods
are also defined. are also defined.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
skipping to change at page 4, line 36 skipping to change at page 4, line 36
implemented middleboxes, policy violations and so forth. implemented middleboxes, policy violations and so forth.
The introduction of ECN into the Internet requires changes to both The introduction of ECN into the Internet requires changes to both
the network and transport layers. At the network layer, IP the network and transport layers. At the network layer, IP
forwarding has to be updated to allow routers to mark packets, rather forwarding has to be updated to allow routers to mark packets, rather
than discarding them in times of congestion [RFC3168]. In addition, than discarding them in times of congestion [RFC3168]. In addition,
transport protocols have to be modified to inform the sender that ECN transport protocols have to be modified to inform the sender that ECN
marked packets are being received, so it can respond to the marked packets are being received, so it can respond to the
congestion. The Transmission Control Protocol (TCP) [RFC3168], congestion. The Transmission Control Protocol (TCP) [RFC3168],
Stream Control Transmission Protocol (SCTP) [RFC4960] and Datagram Stream Control Transmission Protocol (SCTP) [RFC4960] and Datagram
Congestion Control Protocl (DCCP) [RFC4340] have been updated to Congestion Control Protocol (DCCP) [RFC4340] have been updated to
support ECN, but to date there is no specification how UDP-based support ECN, but to date there is no specification how UDP-based
transports, such as RTP [RFC3550], can use ECN. This is due to the transports, such as RTP [RFC3550], can use ECN. This is due to the
lack of feedback mechanisms directly in UDP. Instead the signaling lack of feedback mechanisms directly in UDP. Instead the signaling
control protocol on top of UDP needs to provide that feedback. For control protocol on top of UDP needs to provide that feedback. For
RTP that feedback is provided by RTCP. RTP that feedback is provided by RTCP.
The remainder of this memo is structured as follows. We start by The remainder of this memo is structured as follows. We start by
describing the conventions, definitions and acronyms used in this describing the conventions, definitions and acronyms used in this
memo in Section 2, and the design rationale and applicability in memo in Section 2, and the design rationale and applicability in
Section 3. Section 4 gives an overview of how ECN is used with RTP Section 3. Section 4 gives an overview of how ECN is used with RTP
skipping to change at page 22, line 19 skipping to change at page 22, line 19
init-ext = token init-ext = token
parm-list = parm-value *(";" SP parm-value) parm-list = parm-value *(";" SP parm-value)
parm-value = mode / ect / parm-ext parm-value = mode / ect / parm-ext
mode = "mode=" ("setonly" / "setread" / "readonly") mode = "mode=" ("setonly" / "setread" / "readonly")
ect = "ect=" ("0" / "1" / "random") ect = "ect=" ("0" / "1" / "random")
parm-ext = parm-name "=" parm-value-ext parm-ext = parm-name "=" parm-value-ext
parm-name = token parm-name = token
parm-value-ext = token / quoted-string parm-value-ext = token / quoted-string
quoted-string = DQUOTE *qdtext DQUOTE quoted-string = DQUOTE *qdtext DQUOTE
qdtext = %x20-21 / %x23-7E / %x80-FF qdtext = %x20-21 / %x23-7E / %x80-FF
; any 8-bit ascii except <"> ; any 8-bit ASCII except <">
; external references: ; external references:
; token: from RFC 4566 ; token: from RFC 4566
; SP and DQUOTE from RFC 5234 ; SP and DQUOTE from RFC 5234
Figure 5: ABNF Grammar for the "a=ecn-capable-rtp" attribute Figure 5: ABNF Grammar for the "a=ecn-capable-rtp" attribute
6.1.1. Use of "a=ecn-capable-rtp:" with the Offer/Answer Model 6.1.1. Use of "a=ecn-capable-rtp:" with the Offer/Answer Model
When SDP is used with the offer/answer model [RFC3264], the party When SDP is used with the offer/answer model [RFC3264], the party
skipping to change at page 25, line 26 skipping to change at page 25, line 26
The offer/answer rules for this SDP feedback parameters are specified The offer/answer rules for this SDP feedback parameters are specified
in the RTP/AVPF profile [RFC4585]. in the RTP/AVPF profile [RFC4585].
6.3. XR Block ECN SDP Parameter 6.3. XR Block ECN SDP Parameter
A new unilateral RTCP XR block for ECN summary information is A new unilateral RTCP XR block for ECN summary information is
specified, thus the XR block SDP signalling also needs to be extended specified, thus the XR block SDP signalling also needs to be extended
with a parameter. This is done in the same way as for the other XR with a parameter. This is done in the same way as for the other XR
blocks. The XR block SDP attribute as defined in Section 5.1 of the blocks. The XR block SDP attribute as defined in Section 5.1 of the
RTCP XR specification [RFC3611] is defined to be extendible. As no RTCP XR specification [RFC3611] is defined to be extensible. As no
parameter values are needed for this ECN summary block, this parameter values are needed for this ECN summary block, this
parameter extension consists of a simple parameter name used to parameter extension consists of a simple parameter name used to
indicate support and intent to use the XR block. indicate support and intent to use the XR block.
xr-format = <See Section 5.1 of [RFC3611]> xr-format = <See Section 5.1 of [RFC3611]>
xr-format /= ecn-summary-par xr-format /= ecn-summary-par
ecn-summary-par = "ecn-sum" ecn-summary-par = "ecn-sum"
For SDP declarative and offer/answer usage, see the RTCP XR For SDP declarative and offer/answer usage, see the RTCP XR
specification [RFC3611] and its description of how to handle specification [RFC3611] and its description of how to handle
skipping to change at page 32, line 15 skipping to change at page 32, line 15
include the ECN Check attribute setting the V bit to valid and include the ECN Check attribute setting the V bit to valid and
include the read value of the ECN field into the ECF field. If the include the read value of the ECN field into the ECF field. If the
STUN responder was unable to ascertain, due to temporary errors, the STUN responder was unable to ascertain, due to temporary errors, the
ECN value of the STUN request, it SHALL set the V bit in the response ECN value of the STUN request, it SHALL set the V bit in the response
to 0. The STUN client may retry immediately. to 0. The STUN client may retry immediately.
The ICE based initialization method does require some special The ICE based initialization method does require some special
consideration when used by a translator. This is especially for consideration when used by a translator. This is especially for
transport translators and translators that fragment or reassemble transport translators and translators that fragment or reassemble
packets, since they do not separate the ECN control loops between the packets, since they do not separate the ECN control loops between the
end-points and the translator. Whe using ICE-based initiation, such end-points and the translator. When using ICE-based initiation, such
a translator must ensure that any participants joining an RTP session a translator must ensure that any participants joining an RTP session
for which ECN has been negotiated are successfully verified in the for which ECN has been negotiated are successfully verified in the
direction from the translator to the joining participant. direction from the translator to the joining participant.
Alternatively, it must correctly handle remarking of ECT RTP packets Alternatively, it must correctly handle remarking of ECT RTP packets
towards that participant. When a new participant joins the session, towards that participant. When a new participant joins the session,
the translator will perform a check towards the new participant. If the translator will perform a check towards the new participant. If
that is successfully completed the ECT properties of the session are that is successfully completed the ECT properties of the session are
maintained for the other senders in the session. If the check fails maintained for the other senders in the session. If the check fails
then the existing senders will now see a participant that fails to then the existing senders will now see a participant that fails to
receive ECT. Thus the failure detection in those senders will receive ECT. Thus the failure detection in those senders will
skipping to change at page 37, line 17 skipping to change at page 37, line 17
The RTCP XR ECN summary packet and the ECN feedback packet allow the The RTCP XR ECN summary packet and the ECN feedback packet allow the
sender to compare the number of ECT marked packets of different types sender to compare the number of ECT marked packets of different types
received with the number it actually sent. The number of ECT packets received with the number it actually sent. The number of ECT packets
received, plus the number of ECN-CE marked and lost packets, should received, plus the number of ECN-CE marked and lost packets, should
correspond to the number of sent ECT marked packets plus the number correspond to the number of sent ECT marked packets plus the number
of received duplicates. If these numbers doesn't agree there are two of received duplicates. If these numbers doesn't agree there are two
likely reasons, a translator changing the stream or not carrying the likely reasons, a translator changing the stream or not carrying the
ECN markings forward, or that some node re-marks the packets. In ECN markings forward, or that some node re-marks the packets. In
both cases the usage of ECN is broken on the path. By tracking all both cases the usage of ECN is broken on the path. By tracking all
the different possible ECN field values a sender can quickly detect the different possible ECN field values a sender can quickly detect
if some non-compliant behavior is happing on the path. if some non-compliant behavior is happening 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.
7.4.1. Fallback mechanisms 7.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.
 End of changes. 8 change blocks. 
8 lines changed or deleted 8 lines changed or added

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