TSVWG J. Babiarz
Internet-Draft K. Chan
Expires: August 5, 2004 Nortel Networks
February 5, 2004
Congestion Notification Process for Real-Time Traffic
draft-babiarz-tsvwg-rtecn-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 5, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This memo specifies the incorporation of Explicit Congestion
Notifications (ECN) for real-time flows that use UDP such as voice,
video conferencing and multimedia streaming. Defined is the marking
of the two ECN bits in the IP header and the requirements put on
routers that are configured to provide the ECN marking capability for
real-time UDP flows. Also, an example is provided showing how ECN for
real-time UDP flows can be used for admission control of VoIP flows.
Babiarz & Chan Expires August 5, 2004 [Page 1]
Internet-Draft Document February 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
2. Assumptions and General Principles . . . . . . . . . . . . . . 3
3. Congestion Detection for Real-Time Traffic . . . . . . . . . . 4
4. Explicit Congestion Notification for Real-Time Traffic . . . . 5
5. Example of ECN usage for Admission Control . . . . . . . . . . 6
6. Non-compliance . . . . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
Normative References . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 10
Babiarz & Chan Expires August 5, 2004 [Page 2]
Internet-Draft Document February 2004
1. Introduction
This paper summarizes the recommended method for providing end-to-end
Explicit Congestion Notifications (ECN) for real-time flows such as
voice, video conferencing and multimedia streaming. RFC 3168 [6]
specifies the incorporation of ECN for TCP flows using IP, including
ECN's use of two bits in the IP header. In this document we take the
same concepts but apply them to real-time UDP flows. Since real-time
flows like voice and video conferencing are very delay sensitive, a
different method then what is specified in RFC 3168 for determining
level of congestion needs to be used. Furthermore, we redefine the
usage of Bit 6 and 7 of DS Field of IP header as compared to what is
defined in RFC 3168.
The proposal is to use ECN as a method to notify end applications
that there is a bandwidth constraint or congestion along the path.
Based on this information, the applications may take action to reduce
their sending rate in what ever means is appropriate, stop sending
packets or not admit any new flows if the path is congested.
This document defines the functions that need to be performed in the
network for real-time flows, specifically congestion detection
through the use of flow metering and marking of ECN bits in the IP
header of real-time packets. This document establishes how the ECN
bits must be marked for this purpose. The reaction or decision taken
by the application to the ECN markings is not specified in this
document as it will depend on the application. However, we provided
an example of a procedure that may be used for admission of VoIP
flows based on measured congestion level in the network. In this
admission control example, ECN bit marking is used to convey the
congestion status for that VoIP flow being attempted to be setup.
1.1 Requirements Notation
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 RFC 2119 [3].
2. Assumptions and General Principles
In this section, we describe some of the important design principles
and assumptions that guided choices in this proposal.
o Because ECN for real-time flows is likely to be adopted gradually
and selectively in routers, accommodating migration and selective
deployment is essential. Some routers may not be able to detect
congestion (flow meter) and mark the ECN bits of the IP packets.
Also there maybe parts of the network that congestion is very
Babiarz & Chan Expires August 5, 2004 [Page 3]
Internet-Draft Document February 2004
unlikely and therefore there is no need for ECN function. The most
viable strategy is one that accommodates selective or incremental
deployment without having to resort to "islands" of ECN-capable
and non-ECN-capable environments.
o Asymmetric routing is likely to be a normal occurrence in the
Internet. The path (sequence of links and routers) taken by
forward and reverse packet flow may be different.
o Many routers process the "regular" headers in IP packets more
efficiently than they process the header information in IP
options. This suggests keeping congestion experienced information
in the regular headers of an IP packet.
o A specific DiffServ service class would be implemented exclusively
for Real-time traffic flows from ECN-capable end points. The
assumption is that signaling protocol (SIP, H.323, MGCP, H.248,
RSVP, etc.) will be used to determine if end points are capable of
understanding ECN bit marking and are willing to cooperate in
congestion control.
o Metering and marking of ECN bits as defined herein is performed on
flows that are mapped in to this service class and is performed
only on selected router links in the network where congestion is
likely to occur. Other traffic flows are not affected by this
function. Routers that do not support this function, forward
packets without modifying bit 6 and 7 in DS Field of IP header.
3. Congestion Detection for Real-Time Traffic
Real-time traffic generated by applications such as voice, video
conferencing, multimedia streaming have different performance
requirements and traffic characteristics when compared with so called
data applications that use TCP, hence in this section we describe a
different method for detecting congestion for real-time traffic.
Real-time traffic is generally non-bursty and inelastic and have
end-to-end performance requirements that require the network to give
it the lowest possible delay and variation in delay (jitter). Where
as data applications that use TCP are elastic and generally uses some
form of Active Queue Management (AQM) for detecting that congestion
level has been reached when queue length exceeds a threshold of
certain size (many packets queued). Because of the characteristic of
real-time traffic, ideally, the service class (or queue) that is used
for forwarding real-time traffic should be engineered so that less
than one packet is queued on average. Hence AQM can not be used for
real-time traffic congestion detection. For real-time traffic, we
propose that flow metering be used to measure the aggregate flow rate
Babiarz & Chan Expires August 5, 2004 [Page 4]
Internet-Draft Document February 2004
and generate a policy that when the flow rate exceeds a configured
rate, one of the ECN bits in the DS field of the IP header is set.
This policy is similar to policing currently being performed at
network edges, however the difference here is that instead of
dropping packets when configured rate is exceeded, we set one of the
ECN bits.
4. Explicit Congestion Notification for Real-Time Traffic
This document specifies that the Internet provide a congestion
indication for incipient congestion and where the notification is
through marking packets rather than dropping them. This uses an ECN
field in the IP header with two bits, making four ECN codepoints,
'00' to '11'. Figure 1 defines the use and meaning of the ECN
codepoints as it applies to real-time flows defined in this document.
It should be noted that the definition and naming of ECN codepoints
as defined in RFC 3168 does not apply when used for controlling
real-time UDP based flows as RFC 3168 specifically only address ECN
usage of elastic TCP flows. However, both methods RFC 3168 for TCP
traffic and as document herein for real-time traffic can co-exist in
the network. The premise is that these traffic types will be
separated using Differentiated Services into two or more service
classes with different polices for each traffic type. The mapping of
ECN bits in figure 1 is defined so that routers in the path only need
to set one of the ECN bits if the metering criteria has been
exceeded. Other approaches could be used, but for simplicity we have
chosen this one.
<----------- DS FIELD ---------------->
0 1 2 3 4 5 6 7
----+----+----+----+----+----+----+----
| DSCP FIELD |ECN FIELD|
----+----+----+----+----+----+----+----
DSCP: Differentiated Services Codepoint
ECN: Explicit Congestion Notification
* Bits 6 and 7 set to 0; represents not congested
* Bit 7 set to 1; represents 1st level of congestion detected
* Bit 6 set to 1; represents 2nd level of congestion detected
Figure 1: DSCP and ECN Fields in IP Header
Nodes that are configured to support congestion notification for
real-time flows need to provide the following capability:
o Congestion detection MUST be performed using a real-time
measurement method (e.g., flow metering).
Babiarz & Chan Expires August 5, 2004 [Page 5]
Internet-Draft Document February 2004
o As a minimum, one flow congestion detection mechanisms is REQUIRED
to be associated with a link where measurement is performed.
o Bit 7 of the DS Field in the IP header MUST be set to 1, when the
flow rate exceeds the configured rate "A" (i.e., the first level
of congestion).
o Bit 6 of the DS Field in the IP header MUST be set to 1, when the
flow rate exceeds the configured rate "B" (i.e., the second level
of congestion).
o Metering rate "B" SHOULD be greater than rate "A".
Bits 6 and 7 in the IPv4 TOS octet are designated as the ECN field.
The IPv4 TOS octet corresponds to the Traffic Class octet in IPv6,
and the ECN field is defined identically in both cases. The
definitions for the IPv4 TOS octet RFC 791 [1] and the IPv6 Traffic
Class octet have been superseded by the six-bit DS (Differentiated
Services) Field RFC 2474 [4], RFC 2780 [5]. Bits 6 and 7 are listed
in RFC 2474 as Currently Unused, and are specified in RFC 2780 as
approved for experimental use for ECN. Finally, RFC 3168 standardizes
the use of the ECN bits.
Selected router in the network are configured to meter real-time
traffic that is classified and marked via a DS codepoint as requiring
congestion control, i.e., EF DSCP. The EF marked packet flows are
segregate into a network defined service class where metering and
marking of ECN bits may be performed on selected nodes in the
network.
5. Example of ECN usage for Admission Control
Normally real-time VoIP bearer traffic is marked with EF DSCP and is
mapped into a DiffServ service class that produces very low latency,
jitter and packet loss when traffic load is within the specified
parameters. Currently there is no method defined that can limit
(without dropping packets) the amount of traffic that can be
aggregated on to a link, therefore controlling loads to within the
engineered limits is difficult. We propose that for real-time flows
we use the metering and ECN marking method to address this issue.
Here we describe how ECN can be used in real-time VoIP solution to
provide end-to-end admission of new media flows. This is only a
simple example of how admission control may be implemented using rate
metering and ECN bit marking in the network. Different applications
may use modified approaches to verify if there is sufficient
bandwidth before admitting a new flow.
Babiarz & Chan Expires August 5, 2004 [Page 6]
Internet-Draft Document February 2004
Lets assume that the network is configured to mark real-time VoIP
payload packet with EF DSCP and map this traffic into a DiffServ
service class referred to as Telephony service class herein. Further
we state that only EF marked traffic are mapped into the Telephony
service class in this example. Mapping of real-time traffic marked
with other DSCP is possible but to keep this example simple we will
only talk about EF marked packets.
For example, before a session (i.e., a call) is established between
two clients, the two endpoints involved in the call will execute a
request/response transaction where the called party (Client B) sends
a Probe Request packet to the calling party (Client A) and the
calling party correspondingly sends back a Probe Response packet to
the called party. Probe packets are marked with EF DSCP and are
mapped into the same service class as real-time (ECN-capable) traffic
flows.
DiffServ style traffic conditioner, meter and ECN marker are used on
selected routers in the network along the path to measure the
aggregated (real-time media and probe packets) flow rate of EF marked
packets. If flow rate of EF marked packets as measured by the meter
is greater than rate "A" bit 7 in DS Field of IP header is set to 1
and the packet is forwarded as usual. The metering and marking of ECN
bit need only to be performed on selected routers where bandwidth
constraints exist and where congestion is likely to occur.
Upon receipt of Request Probe packet, the calling party generates and
sends a Response Probe packet to the called party echoing the status
of the received ECN bits in the Response Probe packet. Again,
DiffServ style traffic conditioner, meter and ECN marker are used on
selected routers in the network along the reverse path to measure the
aggregated flow rate of EF marked packets. If flow rate of EF marked
packets as measured by the meter is greater than rate "A" bit 7 in DS
Field of IP header is set to 1 and the packet is forwarded as usual.
On receipt of Response Probe packet, the called party could sends a
notification with the ECN Status to relay the ECN bit status results
for the media path to a server in the network where call admission
control is performed. Based on the received congestion status
(bandwidth usage) for that path, admission control function will make
a decision as to whether or not to continue with call setup and admit
the new real-time flow.
6. Non-compliance
Because of the unstable history of the TOS octet, the use of the ECN
field as specified in this document cannot be guaranteed to be
backwards compatible with those past uses of these two bits that
pre-date ECN. The potential dangers of this lack of backwards
Babiarz & Chan Expires August 5, 2004 [Page 7]
Internet-Draft Document February 2004
compatibility are discussed in RFC 3168 Section 22.
7. Security Considerations
This document discusses detection of congestion for real-time traffic
and describes a common policy configuration, for the use of a ECN bit
marking and application of. If implemented as described, it should
require the network to do nothing that the network has not already
allowed. If that is the case, no new security issues should arise
from the use of such a policy.
It is possible for the policy to be applied incorrectly, or for a
wrong policy to be applied in the network for the defined congestion
detection point. In that case, a policy issue exists that the network
must detect, assess, and deal with. This is a known security issue in
any network dependent on policy directed behavior.
A well known flaw appears when bandwidth is reserved or enabled for a
service (for example, voice transport) and another service or an
attacking traffic stream uses it. This possibility is inherent in
DiffServ technology, which depends on appropriate packet markings.
When bandwidth reservation or a priority queuing system is used in a
vulnerable network, the use of authentication and flow admission is
recommended. To the author's knowledge, there is no known technical
way to respond to an unauthenticated data stream using service that
it is not intended to use, and such is the nature of the Internet.
8. IANA Considerations
To be completed.
9. Acknowledgements
The authors acknowledge a great many inputs, most notably from John
Rutledge, Francois Audet, Tony MacDonald, Mary Barnes and Victor
Firoiu.
Normative References
[1] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[2] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of
Babiarz & Chan Expires August 5, 2004 [Page 8]
Internet-Draft Document February 2004
the Differentiated Services Field (DS Field) in the IPv4 and
IPv6 Headers", RFC 2474, December 1998.
[5] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers", BCP 37,
RFC 2780, March 2000.
[6] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001.
Authors' Addresses
Jozef Z. Babiarz
Nortel Networks
3500 Carling Avenue
Ottawa, Ont. K2H 8E9
Canada
Phone: +1-613-763-6098
Fax: +1-613-768-2231
EMail: babiarz@nortelnetworks.com
Kwok Ho chan
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821
US
Phone: +1-978-288-8175
Fax: +1-978-288-4690
EMail: khchan@nortelnetworks.com
Babiarz & Chan Expires August 5, 2004 [Page 9]
Internet-Draft Document February 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Babiarz & Chan Expires August 5, 2004 [Page 10]
Internet-Draft Document February 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Babiarz & Chan Expires August 5, 2004 [Page 11]