TSVWG J. Babiarz
Internet-Draft K. Chan
Expires: January 16, 2005 V. Firoiu
Nortel Networks
July 18, 2004
Congestion Notification Process for Real-Time Traffic
draft-babiarz-tsvwg-rtecn-01
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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 January 16, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This memo specifies the usage of Explicit Congestion Notifications
(ECN) markings for real-time flows that use UDP, such as voice, video
conferencing and multimedia streaming. This memo tries to reuse as
much of RFC 3168, "The Addition of Explicit Congestion Notification
to IP", as possible. However, we found it necessary to introduce new
ECN semantics for real-time UDP flows. For real-time UDP flows, this
Babiarz, et al. Expires January 16, 2005 [Page 1]
Internet-Draft Document July 2004
memo describes how the network performs ECN marking when congestion
is experienced, but it is left up to the application designers to
define how end systems should react to ECN bit marking. For
illustration purpose, an example is provided showing how ECN for
real-time UDP flows can be used for admission control of VoIP flows.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. Assumptions and General Principles . . . . . . . . . . . . . . 4
3. Congestion Detection for Real-Time Traffic . . . . . . . . . . 5
4. Explicit Congestion Notification for Real-Time Traffic . . . . 6
5. Example of ECN usage for Admission Control . . . . . . . . . . 9
6. Non-compliance . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
10. Normative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 13
Babiarz, et al. Expires January 16, 2005 [Page 2]
Internet-Draft Document July 2004
1. Introduction
This memo 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 IP, focusing on TCP flows,
including ECN's use of two bits in the IP header. This memo tries to
reuse as much of RFC 3168, "The Addition of Explicit Congestion
Notification to IP", as possible. We take the same concepts but
apply them to real-time UDP flows. However, we found it necessary to
introduce a new ECN semantics that can provide two levels of
congestion experienced indication for real-time inelastic UDP flows.
There are applications or services that need to provide different
treatment at application level based on importance of the session for
given level of congestion experienced. As an example, higher
importance flows may need to get access to network over regular
traffic. In addition this memo specify the requirements for network
nodes that are configured to provide ECN-capability.
Defined in this memo are the functions that need to be performed in
the network for real-time flows, specifically congestion detection
through the use of flow measurement and marking of ECN bits in the IP
header of real-time packets. Since real-time flows like voice and
video conferencing are very delay sensitive, a different method than
what is specified in RFC 3168 for determining level of congestion
needs to be used. Furthermore, we redefine a new ECN semantics for
bit 6 and 7 in the DS Field of the IP header to be used for real-time
UDP flows compared to what is defined in RFC 3168 for TCP flows.
The proposal is to use ECN as a method to notify to the application
that there is a bandwidth constraint or congestion along the path in
the network. Based on this information, the application may take
action to reduce its sending rate in what ever means is appropriate,
stop sending packets, or reduce its rate or not admit any new flows
if the path is congested. The reaction or decision taken by the
application to the ECN marking is not specified in this memo as it
will depend on the application. It is left up to the application
designers to define how applications in end systems should react to
ECN bit marking that is performed in the network. It is expected
that application specific memos will be produced to explain the
detailed usage of real-time ECN mechanism. For illustration purpose,
a high level example of a procedure that may be used for admission of
VoIP flows based on measured congestion level in the network is
provided.
1.1 Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
Babiarz, et al. Expires January 16, 2005 [Page 3]
Internet-Draft Document July 2004
"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 the development of 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 or mark the ECN bits within IP packet headers. Also
there may be parts of the network where congestion is very
unlikely and therefore, there is no need for an ECN function. The
most viable strategy is one that accommodates selective or
incremental deployment in a network with both ECN-capable and
non-ECN-capable routers.
o Asymmetric routing is likely to be a normal occurrence within IP
networks. That is the path (sequence of links and routers) taken
by forward and reverse packet flows may be different.
o Many routers process the "regular" header in IP packets more
efficiently than they process the header information in IP
options. This suggests that the ideal approach is to keep
"congestion experienced" information in the regular header of an
IP packet.
o A specific DiffServ service class would be implemented exclusively
for real-time traffic flows from ECN-capable end points.
Different DiffServ service class is used to identify real-time
flows that are ECN-capable and hence the ECT(0) or ECT(1) states
defined in RFC 3168 [6] are not needed. The assumption is that a
signaling protocol (SIP, H.323, MGCP, H.248, etc.) will be used to
determine if the end points are capable of understanding ECN bit
marking and thus, are willing to participate in congestion
control.
o Further, it is desirable that traffic flows from ECN-capable and
non-ECN-capable end points are not aggregated into the same
DiffServ service class. Aggregating the two may cause the flows
that are non-ECN-capable to generate congestion and to introduce
delay and/or packet drop to both ECN-capable and non-ECN-capable
flows.
o The proposed real-time ECN mechanism assumes end-to-end usage of
DiffServ in order to allow differentiation of real-time ECN
capable traffic from all other traffic on the network. For the
Babiarz, et al. Expires January 16, 2005 [Page 4]
Internet-Draft Document July 2004
real-time ECN capable traffic, the ECT(0) and ECT(1) states
defined inRFC 3168 [6] are not used in the network. This is
reasonable as the proposed mechanism is meant for an engineered
network that is DiffServ capable as compared to the best-effort
nature of the Internet at-large.
o Flow measurement 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 the IP header.
o ECN procedure as defined in RFC 3168 [6] may be applied to
DiffServ service class(es) in the IP network that are intended for
applications that use TCP. Both methods may co-exist in the
network, but in different DiffServ service classes.
3. Congestion Detection for Real-Time Traffic
Real-time traffic generated by applications such as voice, video
conferencing, multimedia streaming have different performance
requirements when compared with non-real-time applications that use
TCP. One such requirement is that end-to-end delay be bounded by a
small value, and that packets should not be dropped.
It is generally accepted that such performance requirements can be
achieved when the real-time flows are serviced by the routers in
their path through a real-time service class such as one based on the
EF PHB treatment. This treatment can be provided only when the
real-time service class is under-loaded (i.e., when the aggregate of
input traffic never exceeds the class' capacity, and thus no
congestion condition occurs).
One way to ensure the under-loaded condition of a service class is
through resource reservation and admission control: a (centralized or
distributed) database maintains a record of available resources
(bandwidth) for the real-time service class on each link in the
network and a new flow is admitted only if there are enough resources
on the links in its path so that the under-loaded condition is
maintained. Checking for available resources can be done with a
reservation protocol or through a policy based protocol. An
important issue is that the maintenance and per-flow querying of the
resource database in conjunction with the routing database is an
important overhead that is undesirable in many implementations.
Babiarz, et al. Expires January 16, 2005 [Page 5]
Internet-Draft Document July 2004
An alternative method for ensuring sufficient forwarding resources
(bandwidth) is through flow admission control based on local traffic
measurement. In this scheme, a continuous process at selected
link(s) measures the traffic going through a specified real-time
service class and indicates a level of congestion (such as "not
congested", "mildly congested" or "severely congested"). This
congestion indication as described in Section 4 is then used by the
application to select the action that will be taken by the
application that controls the service. The action could be to admit
or not admit a new flow into that real-time service class in the
network, or have the sending rate of ECN marked flows reduced,
stopped or terminated a flow thereby reducing level of congestion.
It is desirable that the measurement process indicate congestion
before any significant packet accumulates in the queue such that no
significant queuing delay is added to the flows' end-to-end delay.
One way to achieve this is through monitoring the aggregate rate of
the specified real-time service class and to indicate congestion when
a certain threshold is exceeded.
4. Explicit Congestion Notification for Real-Time Traffic
This memo specifies a method for an IP network to provide congestion
indication for incipient of congestion and where notification is
accomplished through marking packets rather than dropping them. The
marking is done through the use of the two ECN bits in the IP header.
<----------- DS FIELD ---------------->
0 1 2 3 4 5 6 7
----+----+----+----+----+----+----+----
| DSCP FIELD |ECN FIELD|
----+----+----+----+----+----+----+----
DSCP: Differentiated Services Codepoint
ECN: Explicit Congestion Notification
Figure 1: DSCP and ECN Fields in IP Header
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 Differentiated
Services (DS) 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 [6]
standardizes the use of the ECN bits.
With this memo, we propose an additional usage of the ECN bits for
indicating congestion for real-time inelastic UDP packet flows in
Babiarz, et al. Expires January 16, 2005 [Page 6]
Internet-Draft Document July 2004
DiffServ capable networks. The selected routers in the network are
configured to measure real-time traffic that is classified and marked
via a DS codepoint as requiring congestion control, i.e., EF DSCP.
These flows are segregated into a network defined service class where
flow metering and marking of ECN bits may be performed on selected
nodes in the network.
We would like to keep network element processing to be simple,
without keeping states. Hence the network only perform the ECN bit
markings without any state maintenance. Whereas the application may
care about the semantics of the total ECN field as a whole. Figure 2
defines the new ECN semantics as they apply to real-time inelastic
UDP flows. It should be noted that the definition and naming of ECN
codepoints for real-time UDP flows is different than what is defined
in RFC 3168. RFC 3168 only addressed ECN usage for elastic TCP
flows. The ECN-Capable Transport (ECT) codepoints '10' (ECT(0)) and
'01' (ECT(1)) defined in RFC 3168 that are set by the data sender to
indicate that the end points of the transport are ECN-Capable are not
used for real-time UDP applications, as only the real-time ECN
capable traffic will be placed in a specific service class to receive
the real-time ECN treatment in the network. The targeted real-time
UDP applications have a requirement that the network provide
transport with very low packet loss. Mixing flows from ECN-capable
and non-ECN-capable end points into the same service class and using
ECT codepoint for providing treatment differentiation in routers
would require that every router in the network to be ECN-capable. We
prefer to take a gradual or incremental approach for deployment of
ECN-capable routers in the network and use DiffServ architecture for
flow differentiation. Therefore, this new functionality needs only
to be deployed in selected nodes. The premise is that different
traffic types are separated using Differentiated Services into two or
more service classes with different polices for each traffic type.
However, both methods as described in RFC 3168 for TCP traffic and as
documented herein for real-time UDP traffic can co-exist in the
network, using independent DiffServ service classes.
The mapping of ECN bits for real-time UDP flows is defined so that
routers in the path only need to set one of the ECN bits if the flow
measurement criteria has been exceeded. Other approaches could be
used, but for simplicity we have chosen this one.
Action Performed in Router:
o Bit 7 set to 1 to indicate 1st level of congestion detected
o Bit 6 set to 1 to indicate 2nd level of congestion detected
Nodes that are configured to support congestion notification for
Babiarz, et al. Expires January 16, 2005 [Page 7]
Internet-Draft Document July 2004
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).
o As a minimum, one flow congestion detection mechanism is REQUIRED
to be associated with a link where congestion 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 Measured rate "B" MUST be greater than rate "A".
Routers in the IP network MAY be configured to support one or two
congestion detection levels.
Some real-time applications or services need the indication of two
levels of congestion experienced, CE(0) and CE(1), for first level
and second level congestion experienced respectively. Therefore we
have selected the following ECN semantics as interpreted by
applications for real-time UDP traffic.
ECN States as Interpreted by Application:
Bits 6 and 7 values
0 0 Not-CE - Congestion Not Experienced
0 1 CE(0) - Congestion Experienced only at 1st level
1 0 CE(1) - Congestion Experienced only at 2nd level
1 1 CE(2) - Congestion Experienced at 1st and 2nd level
Figure 2: ECN Semantics for Real-Time UDP Flows
Specific applications may take different action(s) in response to
congestion being experienced in the network. Depending on the
application, one possible outcome maybe for the application to stop
initiating new real-time UDP flows at the 1st level of congestion and
if the offered load in the selected service class where this
real-time ECN marking is performed reaches 2nd level of congestion
the application selectively stops sending packets on some flows.
Most likely, different applications will take various independent
actions. The various independent actions taken by the applications
are out of scope of this memo.
Babiarz, et al. Expires January 16, 2005 [Page 8]
Internet-Draft Document July 2004
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. To address this issue, we propose
that for real-time flows we use the metering and ECN marking method
defined in this memo.
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.
Let us 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 flows 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,
Babiarz, et al. Expires January 16, 2005 [Page 9]
Internet-Draft Document July 2004
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 send 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, the admission control function will
make a decision as to whether or not to continue with call setup and
admit this new real-time flow. Should bandwidth usage parameters as
indicated by ECN bit marking be exceeded, then this new real-time
flow will not be admitted.
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 any past uses of these two bits that
pre-date ECN. The potential dangers of this lack of backwards
compatibility are discussed in RFC 3168 Section 22.
7. Security Considerations
This document discusses detection of congestion for real-time traffic
flows and also describes a common policy configuration, for the use
and application of ECN bit marking. 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 or act upon a data stream that has been admitted
for service but that it is not intended for authenticated use.
Babiarz, et al. Expires January 16, 2005 [Page 10]
Internet-Draft Document July 2004
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, Greg Thor,
Nabil Bitar, and Hadriel Kaplan.
10 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
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
Babiarz, et al. Expires January 16, 2005 [Page 11]
Internet-Draft Document July 2004
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
Victor Firoiu
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821
US
Phone: +1-978-288-4354
Fax: +1-978-288-4690
EMail: vfiroiu@nortelnetworks.com
Babiarz, et al. Expires January 16, 2005 [Page 12]
Internet-Draft Document July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Babiarz, et al. Expires January 16, 2005 [Page 13]