TSVWG K. Carlberg
Internet-Draft G11
Intended Status: Informational P. O'Hanlon
Expires: August 25, 2013 UCL
Feb 25, 2013
Reactions to Signaling from ECN Support for RTP/RTCP
<draft-carlberg-tsvwg-ecn-reactions-04.txt>
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts. The list of current Internet-Drafts is at
http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
This Internet-Draft will expire on August 25, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Abstract
This document presents an examination of various responses to Congestion
Experience (CE) notifications by real time applications that have
negotiated end-to-end support of Explicit Congestion Notification (ECN).
This document is a follow-on effort of [rfc6679], which specifies the
signaling used to provide ECN support for RTP/RTCP flows.
Carlberg & O'Hanlon Expires August 25, 2013 [Page 1]
Internet Drafts Reactions to ECN for RTP/RTCP Feb 25, 2013
1. Introduction
This document presents an examination of various responses to Congestion
Experience (CE) notifications by real time applications that have
negotiated end-to-end support of Explicit Congestion Notification (ECN).
[rfc6679] defines the signaling for support of ECN by RTP based sessions
and also covers the case where a et of nodes do not respond to CE
notifications. A more detailed discussion about how back-off algorithms
can be achieved, as well as other potential reactions, is viewed as out
of scope of that document and may be addressed by a companion document.
1.1 Background
ECN is a mechanism used to explicitly signal the presence of congestion
without relying on packet loss. It was initially designed using a dual
layer signaling model; negotiation and feedback at the transport layer,
and downstream notification of congestion at the network layer. For IP,
a new two bit field was used to both indicate the successful negotiated
support for ECN signaling, as well as indicate the presence of
congestion via the CE flag. In the case of TCP [rfc3168], a new TCP
header flag was defined that provides upstream end-to-end indication of
congestion occurring somewhere along the downstream path.
There should be no difference in congestion response if ECN-CE marks or
packet drops are detected. However it is noted that there MAY be other
reactions to ECN-CE specified in the future. Such an alternative
reaction MUST be specified and considered to be safe for deployment
under any restrictions specified. We specify such an alternative in
this document.
With respect to ECN for TCP, [rfc3168] specifies an indication of
congestion, but it does so once per Round Trip Time (RTT). [rfc6679] is
an effort that proposes a finer grained notification reflecting a more
accurate indication of the number of ECN marked packets received within
one RTT. It should be noted that there is also other on going work to
provide more accurate ECN feedback information for TCP
[draft-tcpm-accecn-reqs].
1.2 Terminology and Abbreviations
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119].
2. Issues