TSVWG J. Babiarz
Internet-Draft K. Chan
Expires: July 2, 2005 Nortel Networks
V. Firoiu
BAE Systems
January 2005
Congestion Notification Process for Real-Time Traffic
draft-babiarz-tsvwg-rtecn-02
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 July 2, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document specifies the usage of Explicit Congestion Notification
(ECN) markings for real-time inelastic flows such as voice, video
conferencing, and multimedia streaming. We build on the principles
of RFC 3168, "The Addition of Explicit Congestion Notification to
IP", and apply them to real-time inelastic traffic in DiffServ
Babiarz, et al. Expires July 2, 2005 [Page 1]
Internet-Draft Document January 2005
networks. The method specified in this document has the requirement
that these real-time inelastic flows can be distinguished from other
flows and may receive separate treatment from the network.
We introduce new ECN semantics that provide information for two
levels of experienced congestion along the path for real-time
inelastic flows. This document describes how network nodes perform
ECN marking for real-time inelastic flows 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
purposes, 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 . . . . . . . . . . . . . . . . . . 4
1.2 Applicability and Operating Environment . . . . . . . . . 4
1.3 Network with DiffServ and Real-Time ECN Support . . . . . 4
2. General Principles . . . . . . . . . . . . . . . . . . . . . . 5
3. Definition of Congestion for Real-Time Traffic . . . . . . . . 6
3.1 Avoiding Congestion for Real-Time Traffic . . . . . . . . 7
3.2 Congestion Detection for Real-Time Traffic . . . . . . . . 8
3.3 Behavior of Meter and Marker . . . . . . . . . . . . . . . 9
3.4 Marking for Congestion Notification . . . . . . . . . . . 9
3.4.1 Congestion Notification for Real-Time Traffic . . . . 9
3.4.2 ECN Marking of Real-Time Inelastic Flows . . . . . . . 10
3.4.3 Definition of Congestion for Real-Time Traffic . . . . 11
4. Possible Inappropriate Changes to the ECN Field . . . . . . . 12
5. Example of ECN usage for Admission Control . . . . . . . . . . 13
6. Non-compliance . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Issues List . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
A. Meter Example . . . . . . . . . . . . . . . . . . . . . . . . 17
A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 17
A.2 Meter Configuration . . . . . . . . . . . . . . . . . . . 18
A.3 Meter Behavior . . . . . . . . . . . . . . . . . . . . . . 19
A.4 Marking . . . . . . . . . . . . . . . . . . . . . . . . . 19
A.5 Summary of the Behavior . . . . . . . . . . . . . . . . . 20
11. Normative References . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 22
Babiarz, et al. Expires July 2, 2005 [Page 2]
Internet-Draft Document January 2005
1. Introduction
This document summarizes the recommended method for providing
end-to-end Explicit Congestion Notification (ECN) for real-time
inelastic flows such as voice, video conferencing, and multimedia
streaming. RFC 3168 [6] specifies the incorporation of ECN for IP,
including ECN's use of two bits in the IP header. This document
builds on the concepts of RFC 3168, "The Addition of Explicit
Congestion Notification to IP", and applies them to real-time
inelastic flows in DiffServ enabled networks.
To address a wider usage of this mechanism, it is necessary to
introduce new semantics for the ECN field of the IP header (bits 6
and 7 of the TOS byte) that can provide two levels of congestion
indication for real-time inelastic flows. There are applications and
services that need to provide different treatment at the application
level based on the importance of the flow for a given level of
congestion experienced. For example, higher importance flows within
a service class used for real-time traffic may need to get priority
access to the network resources over regular traffic. This document
specifies the required behavior of network nodes that are configured
to provide ECN-capability for real-time flows.
The operating environment is discussed first, and then functions are
defined that need to be performed in the network for real-time flows.
Specifically, this includes (1) congestion detection through the use
of flow measurement and (2) marking of ECN bits in the IP header of
real-time packets for a given DSCP-marked service class. Since
real-time inelastic flows like voice and video conferencing are very
delay sensitive, a different method than what is specified in RFC
3168 for determining levels of congestion needs to be used.
The proposal is to use ECN as a method to notify the application that
packets flowing on this path are above the engineered capacity of the
service class that is used for real-time traffic in the network.
Based on this information, the application may take action to reduce
its sending rate by whatever means is appropriate; for example stop
sending packets, or reduce its rate, or not admit new flows while the
path remains congested. The reaction or decision taken by the
application to the ECN marking is not specified in this document as
it will depend on the application. It is left up to 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 documents will be produced to explain the
application's usage of this real-time ECN mechanism. For
illustration purposes, a high level example of a procedure that may
be used for admission of VoIP flows based on ECN marking within a
service class in the network is provided.
Babiarz, et al. Expires July 2, 2005 [Page 3]
Internet-Draft Document January 2005
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].
1.2 Applicability and Operating Environment
Networks that need to support real-time inelastic services may need
to provide a controlled environment that allows for a high level of
guarantees on the quality of service to be honored. We suggest the
use of DiffServ service classes to separate the real-time inelastic
traffic from the other traffic for such a controlled environment, and
applying the Real-Time ECN process discussed in this document.
This document addresses the use of the ECN markings in a DiffServ
controlled environment, with both marking as defined herein and in
RFC 3168 [6] co-existing in the same network but in different service
classes. As well, there may be network segments that do not deploy
any ECN processing at all. These operating environments are explored
and discussed herein. But in all cases, DiffServ separation of the
real-time inelastic traffic from the other traffic should be
supported. With the basic rules of:
o no mixing of Real-Time ECN and RFC 3168 ECN marking in the same
service class
o no mixing of traffic from Real-Time ECN capable end-systems and
from Real-Time ECN un-capable end-systems into the same service
class
o allowed mixing of traffic from ECN and non ECN capable end-systems
at points where congestion is not possible
1.3 Network with DiffServ and Real-Time ECN Support
The real-time ECN process requires that the real-time inelastic
traffic is separated from the other traffic. Within a DiffServ
network, it is perfectly fine to deploy RFC 3168 ECN marking for
service classes that are used for elastic TCP traffic and to deploy
Real-Time ECN marking as defined herein for service classes that are
used for inelastic real-time traffic. DiffServ is used to separate
the real-time traffic from the other traffic flows, and Real-Time ECN
processing is applied to this separated traffic to provide control
within the service class. Under this condition, the most optimal
deployment is to have all network segments support DiffServ, with
Real-Time ECN marking capability on selected nodes where congestion
Babiarz, et al. Expires July 2, 2005 [Page 4]
Internet-Draft Document January 2005
within the real-time service class is likely. Over time, as traffic
levels within the real-time service class become complex and/or the
network topology becomes more complex, it may be preferable that
Real-Time ECN capability is extended to all or most network nodes.
This notion of traffic separation into different service classes also
applies to end-systems supporting Real-Time ECN processing. Traffic
from end-systems that do not support Real-Time ECN processing
(reaction to ECN marking) should not be placed into the same DiffServ
service class as traffic that does. If it were, the end-systems that
do not support the Real-Time ECN processing would not "back off" on
onset of congestion conditions and would impact flows from
end-systems that support Real-Time ECN processing.
This approach allows for specific network nodes where congestion is
very unlikely to occur not to require DiffServ or Real-Time ECN
processing to be deployed.
2. General Principles
In this section, some of the important design principles and
assumptions guiding the development of this proposal are described.
o Because ECN for real-time flows is likely to be adopted gradually
and selectively in nodes, accommodating migration and selective
deployment is essential. Some nodes 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 nodes.
o Asymmetric routing is likely to be a normal occurrence within IP
networks. That is, the path (the sequence of links and nodes)
taken by forward and reverse packet flows may be different.
o Many nodes 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-systems. A
different DiffServ service class is used to identify real-time
flows that are not ECN-capable. Hence, the ECT(0) or ECT(1)
indicators defined in RFC 3168 [6] are not needed. The assumption
Babiarz, et al. Expires July 2, 2005 [Page 5]
Internet-Draft Document January 2005
is that a signaling protocol (SIP, H.323, MGCP, H.248, etc.) will
be used to determine if the end-systems are capable of
understanding ECN bit marking and thus, are willing to participate
in congestion control prior to usage of the specific ECN-enabled
service class.
o Furthermore, it is desirable that real-time traffic flows from
ECN-capable and non-ECN-capable end-systems 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
real-time ECN capable traffic, the ECT(0) and ECT(1) states
defined in RFC 3168 [6] are not used in the network. This is
reasonable as the proposed mechanism is meant for managed IP
networks.
o Flow measurement and marking of ECN bits is defined herein to be
performed on flows that are mapped to a set pf ECM-enable service
classes, and is performed only on selected node links in the
network where congestion is likely to occur. Other traffic flows
are not affected by this function. Nodes that do not support this
function forward packets without modifying bit 6 and 7 in the ECN
field of the IP header.
o ECN procedure as defined in RFC 3168 [6] may also be applied to
DiffServ service classes in the IP network. Both methods may
co-exist in the network, but in different DiffServ service
classes.
3. Definition of Congestion for Real-Time Traffic
Real-time traffic generated by applications such as voice, video
conferencing, and multimedia streaming have different performance
requirements when compared with non-real-time applications that use a
protocol such as 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 nodes 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 not overloaded (i.e., when the aggregate
Babiarz, et al. Expires July 2, 2005 [Page 6]
Internet-Draft Document January 2005
of input traffic never exceeds the class' capacity, and thus no
congestion condition occurs). It should also be noted that when the
overloaded condition occurs, all real-time traffic flows within the
real-time service class at the congestion point will be affected, not
just the offending traffic flow. Hence, it is desirable to avoid the
overloaded condition as much as possible.
With the above performance requirements for real-time inelastic
traffic in mind, "congestion of real-time inelastic traffic" is
defined to be the network condition when aggregated packet flows
within the service class exceed an engineered traffic level. The
engineering of the network is such that traffic exceeding this
engineered traffic level by a defined and limited amount does not
generally cause an increase in packet queuing or packet dropping
(service class overload) in the network. Instead, the ECN field is
used to provide an indication that traffic is above the engineered
traffic level. This can be viewed as explicit notification to
prevent congestion. However, uncontrolled or prolonged increase in
traffic above the defined amount may result in an increase in packet
queuing and/or packet dropping, and therefore may cause overload of
the real-time service class.
3.1 Avoiding Congestion for Real-Time Traffic
Congestion (ECN) notification can be utilized in a flow admission
control scheme to ensure sufficient forwarding resources (bandwidth).
In this scheme, a continuous process at selected link(s)/node(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 3.4.3 is then used by the
application to select the action that will be taken by the
application controlling the service. The action could be to admit or
not to admit a new flow into that real-time service class in the
network, or have the sending rate of ECN marked flows reduced or
stopped, or terminate a flow. All with the effect of reducing level
of offered traffic. Based on the performance requirements of
real-time traffic, it is desirable that the measurement process
indicate congestion of real-time traffic before any significant
packet accumulates in the queue occurs. This is such that no
significant queuing delay is added to existing real-time flows'
end-to-end delay.
An alternative method to avoid the overloaded 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
Babiarz, et al. Expires July 2, 2005 [Page 7]
Internet-Draft Document January 2005
resources on the links in its path so that the overloaded condition
is avoided. 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.
3.2 Congestion Detection for Real-Time Traffic
One of the goals is to keep the amount of processing that is
performed in the network to be very small and not require any other
computations or state information to be kept in network nodes. One
way to achieve this is through monitoring the aggregate rate of
traffic in the specified real-time service class and to indicate
congestion when a certain traffic threshold is exceeded. Hence the
network nodes only need to perform flow measurement of packets marked
with the defined DSCP value(s) and set the ECN bit(s) when that
traffic rate exceeds the defined level. The application monitors the
ECN field, and takes an appropriate action based on the marking.
Figure 1 below shows a block diagram of the traffic measurement and
ECN marking function.
The Meter meters each packet within the real-time service class and
passes the packet and the metering result to the ECN Marker:
+------------+
| Result |
| V
+-------+ +--------+
| | | ECN |
Packet Stream ===>| Meter |===>| Marker |===> Marked Packet Stream
| | | |
+-------+ +--------+
Figure 1: Block Diagram of Meter and Marker Function
The Marker sets the ECN bit values for each packet within the
real-time service class based on the results of the Meter.
The traffic rate of the specified service class may be measured with
a simple token bucket meter, an exponentially weighted moving average
meter, or other methods. The goals of a rate measuring method are
simplicity and minimum or no added delay to traffic forwarding.
The specification of the traffic measurement mechanism is outside the
scope of this document. The intention is that an existing traffic
measurement mechanisms may be used. In Appendix A, an example of a
simple token bucket method for measurement and marking is provided.
Babiarz, et al. Expires July 2, 2005 [Page 8]
Internet-Draft Document January 2005
3.3 Behavior of Meter and Marker
When the measured rate exceeds the engineered traffic level (i.e.,
when token bucket runs out of tokens), the Meter sets its result flag
and passes it to the Marker. The Marker, sets the appropriate ECN
value for all packets belonging to the service class that is measured
until the result flag from the Meter is cleared.
When the measured traffic rate is, or is reduced below the engineered
rate (the token bucket becomes full) the Meter clears the result flag
if set. The clearing of the result flag output from the Meter stops
marking ECN bits by the Marker. The metering function has built-in
hysteresis for setting and clearing the result flag. The amount of
hysteresis is controlled by the configuration parameters of the
traffic measurement mechanism and should be configured to meet the
characteristics of the real-time inelastic traffic that is being
measured.
3.4 Marking for Congestion Notification
Marking for Explicit Congestion Notifications is done through the use
of the two ECN bits in the IP header.
0 1 2 3 4 5 6 7
----+----+----+----+----+----+----+----
| DS FIELD, DSCP |ECN FIELD|
----+----+----+----+----+----+----+----
DSCP: Differentiated Services Codepoint
ECN: Explicit Congestion Notification
Figure 2: DS 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 [4] 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.
3.4.1 Congestion Notification for Real-Time Traffic
Proposed is an additional usage of the ECN bits for indicating two
levels of congestion for real-time inelastic packet flows in DiffServ
capable networks. The selected nodes in the network are configured
to measure real-time traffic that is classified and marked via a DS
Babiarz, et al. Expires July 2, 2005 [Page 9]
Internet-Draft Document January 2005
codepoint as requiring congestion control, i.e., EF DSCP.
We would like to keep the amount of processing that is performed in
the network elements to be minimal and not require any flow state
information to be kept in network nodes. The network nodes only need
to perform flow measurement of packets marked with the defined DSCP
value(s) and set the ECN bit when that traffic rate exceeds the
defined level. Whereas, the application running in the end-system
may care about the semantics of the total ECN field as a whole.
Figure 3 defines the new ECN semantics as they apply to real-time
inelastic flows. It should be noted that the definition and naming
of ECN codepoints for real-time flows is different than what is
defined in RFC 3168. RFC 3168 addressed ECN marking for a single
level of congestion. 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-system's transport are
ECN-Capable are not used for applications that use real-time
inelastic flows, as only the real-time ECN capable traffic will be
placed in the specific service class to receive the real-time ECN
treatment in the network. The targeted applications have a
requirement that the network provide real-time transport with very
low packet loss and delay. Mixing flows from ECN-capable and
non-ECN-capable end-systems into the same service class and using ECT
for providing treatment differentiation (dropping or ECN marking) in
nodes may result in non-ECN-capable end-systems continuing to offer
traffic at the current level or possibly even increase the offered
rate, therefore causing queue buildup (delay) and eventually
introducing packet loss to flows from both ECN-capable and
non-ECN-capable end-systems.
We prefer to take a gradual or incremental approach for deployment of
ECN-capable nodes in the network and use the DiffServ architecture
for flow differentiation. Therefore, this new functionality needs
only to be deployed in selected nodes, where congestion is likely to
occur. 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 and as documented herein for real-time
inelastic traffic can co-exist in the network, using independent
DiffServ service classes.
3.4.2 ECN Marking of Real-Time Inelastic Flows
Marking of ECN bits for real-time inelastic flows is defined so that
nodes in the path only need to set one of the ECN bits when an
engineered rate is exceeded. Other approaches could be used, but for
simplicity we have chosen this one.
Babiarz, et al. Expires July 2, 2005 [Page 10]
Internet-Draft Document January 2005
Nodes that are configured to support congestion notification for
real-time flows need to provide the following capability:
o Congestion detection SHOULD be performed using a real-time
measurement mechanism (e.g., flow metering).
o At a minimum, one flow congestion detection mechanism is REQUIRED
to be associated to a link where congestion measurement is
performed.
o Bit 7 of the ECN 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 ECN 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" SHOULD be greater than rate "A".
Nodes in the IP network MAY be configured to support one or two
congestion detection levels.
3.4.3 Definition of Congestion for Real-Time Traffic
Some real-time applications or services need the indication of two
levels of congestion experienced, CE(0) and CE(1), for first and
second level respectively. Other applications may only need a single
indication. To address a wide range of usage, we have selected the
following ECN semantics as interpreted by applications for real-time
inelastic 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 3: ECN Semantics for Real-Time Flows
Specific applications may take different action(s) in response to
congestion being experienced in the network. Depending on the
application, one possible outcome may be for the application to stop
initiating new real-time inelastic flows at the 1st level of
congestion, and if the offered load in the selected service class
reaches the 2nd level of congestion, the application in the
end-system stops sending packets. Most likely, different
Babiarz, et al. Expires July 2, 2005 [Page 11]
Internet-Draft Document January 2005
applications will take various independent actions. The various
independent actions taken by the applications are out of scope of
this document.
4. Possible Inappropriate Changes to the ECN Field
This section discusses in detail possible inappropriate changes to
the ECN field in the network, such as falsely reporting no
congestion, by erasing the ECN congestion indication.
In the implementation of a Real-Time ECN mechanism in the network,
the network administrator through the use of polices or through the
use of signaling/control protocols such as SIP can verify the
capabilities and conformance of the end-systems. As stated earlier,
only end-systems that are capable and conformant to Real-Time ECN
mechanism may use it. End-systems that are not Real-Time ECN capable
or conformant are mapped into a different service class (a service
class that is configured not to use Real-Time ECN) or are not allowed
access to the network through a deployment of a filter policy at the
network edge.
The Real-Time ECN mechanism provides two levels of congestion
indication; therefore, the cheating mechanism as defined in RFC 3168
that uses ECT(0) and ECT(1) state can not be used. Instead, the
following procedure may be used to catch cheaters, network nodes,
software drivers or plug-ins that are not part of the certified
application in the end-system, altering ECN bit marking. The
outlined procedure may be executed under the control of the
application prior to admission of a new real-time flow or
periodically to verify the conformance of ECN marking. The testing
for conformance is between the two ECN capable and conformant
applications running in the end-systems referred to as sender and
responder.
o Under the control of the application, the sender sends four test
packets referred to as Request probe packets. The packets' ECN
field are distinctly marked with values in the range of "00 - 11".
The order of the marking can be random ("00, 11, 01, and 10" or
"10, 00, 11, and 01", etc).
o Upon reception of the Request probe packet, the responder echoes
the received Request probe packets back to the sender as Response
probe packets including the value of ECN field in the IP header
o The sender compares the received ECN marking of the Response probe
packets to Request probe packets originally sent
For example, if the following ECN field markings sequence 11, 10, 00,
Babiarz, et al. Expires July 2, 2005 [Page 12]
Internet-Draft Document January 2005
01 is sent by the sender, the following list of received Response
probe packets are possible for paths that are not cheating in both
directions:
o 11, 10, 00, 01; meaning ECN = 00 Not-CE
o 11, 11, 01, 01; meaning ECN = 01 CE(0)
o 11, 11, 11, 11; meaning ECN = 11 CE(2)
o 11, 10, 10, 11; meaning ECN = 10 CE(1)
The following list of ECN field markings of received Response probe
packets for the above sent sequence would indicate that the path is
not conformant, meaning that one or more nodes in one or the other
direction is miss-marking ECN bits (remarking ECN bit(s) to zero):
o 00, 00, 00, 00; one or more nodes is setting ECN bit 6 and/or 7 to
zero
o 10, 10, 00, 00; one or more nodes is setting ECN bit 7 to zero
o 01, 00, 00, 01; one or more nodes is setting ECN bit 6 to zero
The following list of ECN field markings of received Response probe
packets for the above sent sequence would indicate that one or more
nodes is selectively remarking (setting ECN bit(s) to zero in only
one packet (cheating):
o 10, 10, 00, 01; indicates that ECN state 11 was remarked to 10
o 01, 10, 00, 01; indicates that ECN state 11 was remarked to 01
o 11, 00, 00, 01; indicates that ECN state 10 was remarked to 00
o 11, 10, 00, 00; indicates that ECN state 01 was remarked to 00
This method requires the sending of four test packets to determine
conformance (no cheating) of network nodes that are in the data path
in both directions. The defined method only detects network nodes
clearing congestion indication by setting ECN bit(s) to zero. To
detect the opposite cheating condition, the setting of ECN bits high
to indicate the presence of congestion falsely, traffic load levels
in the network needs to be known.
5. Example of ECN usage for Admission Control
Normally real-time VoIP bearer traffic is marked with EF DSCP and is
Babiarz, et al. Expires July 2, 2005 [Page 13]
Internet-Draft Document January 2005
mapped into a DiffServ service class that produces very low latency,
jitter and packet loss when the 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 onto a link. As a result, controlling loads to within
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 document.
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 packets with EF DSCP, and only this traffic is mapped into a
DiffServ service class referred to as Telephony service class.
Mapping of real-time traffic marked with other DSCP values 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 Request probe packet to the calling party (Client A) and the
calling party correspondingly sends back a Response probe packet to
the called party. Probe packets are marked with EF DSCP and are
mapped into the Telephony service class.
A DiffServ style traffic conditioner, meter and ECN marker are used
on selected nodes in the network along the path to measure the
aggregated (real-time media and probe packets) flow rate of EF marked
packets. If the flow rate of the EF marked packets as measured by
the meter is greater than rate "A", bit 7 in the ECN field of IP
header is set to 1 and the packet is forwarded as usual. The
metering and marking of ECN bit only needs to be performed on
selected nodes where bandwidth constraints exist and where congestion
is likely to occur.
Upon receipt of the 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,
a DiffServ style traffic conditioner, meter and ECN marker are used
on selected nodes in the network along the reverse path to measure
the aggregated flow rate of EF marked packets. If the flow rate of
EF marked packets as measured by the meter is greater than rate "A",
Babiarz, et al. Expires July 2, 2005 [Page 14]
Internet-Draft Document January 2005
bit 7 in ECN field of IP header is set to 1 and the packet is
forwarded as usual. On receipt of the 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 [6] Section 22.
7. Issues List
NOTE TO RFC EDITOR: Please remove this section during the publication
process.
Babiarz, et al. Expires July 2, 2005 [Page 15]
Internet-Draft Document January 2005
The following issues list are based on comments received.
Issues from Sally during our discussion at San Diego IETF 8/1-6/2004
on -01 version of the draft.
1. Need to resolve Receiver Cheating situations.
Section on cheating was added to draft.
2. Need to indicate why we are not concerned with ECT usage.
Explanation was added. However, we are still investigating
scenarios where ECT may be useful.
3. Clarify to indicate using specific DiffServ Code Point.
Added clarification in "Abstract" section and added
"Applicability and Operating Environment" section.
4. Need Applicability Statement up front.
Added clarification in "Abstract" section and added
"Applicability and Operating Environment" section.
5. Change the draft to indicate RFC 3168 applies to UDP as well as
TCP (all IP traffic).
Removed mentioning of RFC3168 focusing on TCP in "Introduction"
and bottom of "Assumptions and General Principles" sections.
6. Provide an explanation on situation where there is a node in
the middle that does not understand DiffServ but can do ECN.
Added "Applicability and Operating Environment" section.
7. Sally preferred to have the ECN bits to have: 00=Not-CE,
01=CE(0), 10=CE(1), 11=Not-DiffServ-CE.
Open: Keeping current marking as is for this version of draft.
Investigate alternate marking approach pros and cons for two
level of congestion.
Figure 4
8. 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.
Babiarz, et al. Expires July 2, 2005 [Page 16]
Internet-Draft Document January 2005
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.
9. IANA Considerations
To be completed.
10. Acknowledgements
The authors acknowledge a great many inputs, most notably from Sally
Floyd, Nabil Bitar, Hadriel Kaplan, David McDysan, Mike Pierce, Alia
Atlas, John Rutledge, Francois Audet, Tony MacDonald, Mary Barnes,
Greg Thor, Corey Alexander, Jeremy Matthews, Marvin Krym, and Stephen
Dudley.
Appendix A. Meter Example
The below is a description of a Single Rate Meter and ECN Marker.
For scenarios that require two traffic levels within a service class
to be measured for congestion indications, two instances of the
single rate meter and ECN marker can be used, one for configured rate
"A" and one for configured rate "B". The meter parameters should be
selected to meet the characteristics and performance requirements of
traffic being measured as well meters' behavior for each level.
Appendix A.1 Introduction
The Single Rate Meter and ECN Marker is configured by assigning
values to four parameters: Committed Information Rate (CIR), Token
Bucket Size (TBS), upper threshold m (in percentage of TBS) and lower
threshold n (in percentage of TBS). The Token Bucket Update duration
(TBU) is an implementation parameter that may not be configurable.
We also consider the Token Bucket Drain duration (TBD) resulting from
the first two configurable parameters, TBD=TBS/CIR. The meter also
has an internal state "flag" which when set indicates a condition
Babiarz, et al. Expires July 2, 2005 [Page 17]
Internet-Draft Document January 2005
where the measured traffic has exceeded the CIR and token in the
token bucket where exhausted below n threshold, as described below.
CIR is measured in bytes of IP packets per second, i.e., it includes
the IP header, but not link specific headers.
The Meter meters each packet within the real-time service class and
passes the packet and the metering result to the Marker:
+------------+
| Result |
| V
+-------+ +--------+
| | | |
Packet Stream ===>| Meter |===>| Marker |===> Marked Packet Stream
| | | |
+-------+ +--------+
Figure 5: Block Diagram of Meter and Marker Function
The Marker sets the ECN bit values for each packet within the
real-time service class based on the results of the Meter.
Appendix A.2 Meter Configuration
The Single Rate Meter and ECN Marker is configured by assigning
values to four traffic parameters: Committed Information Rate (CIR),
Token Bucket Size (TBS), Token Bucket Drain duration (TBD)
TBD=TBS/CIR and Token Bucket Update duration (TBU). CIR is measured
in bytes of IP packets per second, i.e., it includes the IP header,
but not link specific headers.
TBS is measured in bytes, and represents the variants of the rate
being measured. Normally, variable rate traffic will need larger
token bucket than constant rate traffic, and the size will depend on
the characteristics of traffic being measured. TBS should be
configured such that traffic variation within the specified rate as
measured at the node should not use up all the available tokens
during a single TBD duration.
TBD and TBU are measured in seconds and TBD should be configured to
be at least 2 times greater than TBU. For real-time inelastic
traffic, it is recommended that TBD be configured to be greater than
the expected inter-packet emission time at sender for the measured
packet stream. For best accuracy, TBU should be a small value, as
small as implementation practical.
Babiarz, et al. Expires July 2, 2005 [Page 18]
Internet-Draft Document January 2005
Appendix A.3 Meter Behavior
The behavior of the Meter is specified in terms of its Token Bucket
Size (TBS) with its rates CIR and Token Bucket Update duration (TBU).
Where TBD = TBS/CIR and
Where TBD > 2 x TBU
The token bucket (TBS) initially (at time 0) is full, i.e., the token
count is represented by Tp.
Where Tp(0) = TBS
Thereafter, tokens (Tp) are added to the token bucket at rate of (CIR
x TBU) per TBU.
Every TBU; Tp = Tp(t)+(TBU x CIR)
If Tp(t) > TBS, Set Tp = TBS
If result flag is set and Tp(t) + (TBU x CIR) > m x TBS, clear
result flag, and set Tp = TBS
Where m = 1-100% of TBS
When a packet of size B bytes arrives at time t, the following
happens:
If result flag is not set and Tp(t)-B < n x TBS, set result flag,
and set Tp to zero. (TBS empty)
Where n = 0-99% of TBS
else
Decrement Tp by B.
Where m > n; both m and n are a percentage of TBS.
The actual implementation of a Meter doesn't need to be modeled
according to the above formal specification.
Appendix A.4 Marking
The ECN Marker reflects the result flag setting received from the
meter. If result flag is set, all packets serviced by the real-time
inelastic service class have their ECN bit set. The ECN Marker sets
Babiarz, et al. Expires July 2, 2005 [Page 19]
Internet-Draft Document January 2005
the ECN bit as long as the result flag from the meter is set.
Appendix A.5 Summary of the Behavior
When the measured rate is exceeded (token bucket runs out of tokens)
the meter sets the "result flag" and passes it to the ECN Marker.
The ECN Marker, sets the ECN bit of all packets belonging to the
service classes flowing through the interface being measured until
the traffic rate is reduced below the measuring threshold; thereby
the token bucket becomes full. When the token bucket becomes full,
the meter clears the "result flag" if set. The clearing of the
result flag output from the meter, stops marking of ECN bit by the
Marker.
11 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@nortel.com
Babiarz, et al. Expires July 2, 2005 [Page 20]
Internet-Draft Document January 2005
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
BAE Systems
6 New England Executive Park
Burlington, MA 01803
US
Phone:
Fax:
EMail: victor.firoiu@baesystems.com
Babiarz, et al. Expires July 2, 2005 [Page 21]
Internet-Draft Document January 2005
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 (2005). 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 July 2, 2005 [Page 22]