Internet DRAFT - draft-babiarz-tsvwg-rtecn
draft-babiarz-tsvwg-rtecn
TSVWG J. Babiarz
Internet-Draft K. Chan
Expires: April 27, 2006 Nortel Networks
V. Firoiu
BAE Systems
October 24, 2005
Congestion Notification Process for Real-Time Traffic
draft-babiarz-tsvwg-rtecn-05
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 April 27, 2006.
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
networks. Defined in this document are, new ECN semantics that
Babiarz, et al. Expires April 27, 2006 [Page 1]
Internet-Draft Document October 2005
provide two levels of experienced congestion along the path for real-
time inelastic flows, the required ECN marking behavior in network
nodes, and state the required behavior of end-systems that support
this function with an explanation of how the two ECN schemes can co-
exist safely in the network.
Babiarz, et al. Expires April 27, 2006 [Page 2]
Internet-Draft Document October 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
1.2. Applicability and Operating Environment . . . . . . . . . 5
2. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Application Decisions based on Network Information . . . . 6
2.2. Network Information for Supporting Application
Decisions . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Operational Overview with SIP Applications . . . . . . . . 9
2.3.1. Session Admission Control . . . . . . . . . . . . . . 10
2.3.2. Session Preemption . . . . . . . . . . . . . . . . . . 11
2.3.3. Operational Overview Summary . . . . . . . . . . . . . 13
3. General Principles . . . . . . . . . . . . . . . . . . . . . . 13
4. Definition of Congestion for Real-Time Traffic . . . . . . . . 14
4.1. Avoiding Congestion for Real-Time Traffic . . . . . . . . 15
4.2. Congestion Detection for Real-Time Traffic . . . . . . . . 16
4.3. Behavior of Meter and Marker . . . . . . . . . . . . . . . 17
4.4. Marking for Congestion Notification . . . . . . . . . . . 17
4.4.1. ECN Marking of Real-Time Inelastic Flows . . . . . . . 18
4.4.2. ECN Semantics for Real-Time Traffic . . . . . . . . . 18
4.5. End-System Behavior . . . . . . . . . . . . . . . . . . . 19
5. Detection of Inappropriate Changes to the ECN Field . . . . . 20
5.1. During Session Setup . . . . . . . . . . . . . . . . . . . 20
5.2. After Session is Established . . . . . . . . . . . . . . . 23
6. Network with DiffServ and Real-Time ECN Support . . . . . . . 25
6.1. Workable Approach for Co-existence of RT-ECN . . . . . . . 26
7. Discussion on Different Marking Approaches . . . . . . . . . . 27
7.1. Alternate RT-ECN marking . . . . . . . . . . . . . . . . . 27
7.2. Implication of this Marking . . . . . . . . . . . . . . . 27
7.3. Reason for Not Using this RT-ECN Marking . . . . . . . . . 28
8. Example of ECN usage for Admission Control . . . . . . . . . . 28
9. Non-compliance . . . . . . . . . . . . . . . . . . . . . . . . 29
10. Changes from Previous Version . . . . . . . . . . . . . . . . 29
11. Security Considerations . . . . . . . . . . . . . . . . . . . 30
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
14. Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . 30
14.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 31
14.2. Meter Configuration . . . . . . . . . . . . . . . . . . . 31
14.3. Meter Behavior . . . . . . . . . . . . . . . . . . . . . . 32
14.4. Marking . . . . . . . . . . . . . . . . . . . . . . . . . 33
14.5. Summary of the Behavior . . . . . . . . . . . . . . . . . 33
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
15.1. Normative References . . . . . . . . . . . . . . . . . . . 33
15.2. Informative References . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 36
Babiarz, et al. Expires April 27, 2006 [Page 3]
Internet-Draft Document October 2005
1. Introduction
Proposed is an additional usage of Explicit Congestion Notification
(ECN) for real-time inelastic flows such as voice, video
conferencing, and multimedia streaming. RFC 3168 [7] 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 perform
admission control and session preemption.
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 byte two in IPv4 header) 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 or precedence of the
flow for a given level of congestion experienced. For example,
situation critical or life threatening VoIP flows within a service
class used for real-time traffic may need to get priority access to
the network resources over regular VoIP traffic. In the
specification of the required behavior for network nodes and end-
systems that are configured to provide ECN-capability for real-time
flows, we factor in the requirements specified in Specifying
Alternate Semantics for the Explicit Congestion Notification (ECN)
Field [17].
The operating environment is discussed first, then a framework is
provided, 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, (2) marking
of ECN bits in the IP header of real-time packets for a given DSCP-
marked service class and (3) actions that the end-systems needs to
take based on the ECN bits marking. Since real-time inelastic flows
like voice and video conferencing are very delay sensitive, a
different method than what is described in RFC 3168 for determining
levels of congestion needs to be used.
The proposal is to use ECN as a method to notify the end-systems 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 end-system needs to 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 detailed mechanism used in the
end-system to achieve the required behavior 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
Babiarz, et al. Expires April 27, 2006 [Page 4]
Internet-Draft Document October 2005
end-systems should perform the required actions to conform to ECN bit
marking 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, one such example is Real-time ECN Use Cases
[11] which defines admission control and preemption procedures for
VoIP flows. For illustration purposes, a high level example of
admission control is provided in this document.
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 [12] 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 [7] 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, or there may be a router in the path that
does not support DiffServ but performs ECN marking as defined in RFC
3168. 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 Allow mixing of traffic from Real-Time ECN capable and incapable
end-systems in the same service class and using ECN bits to
provide the differentiation.
o Allow traffic from both Real-Time ECN capable and RFC 3168
conformant end-systems as long as the traffic is marked with
different DSCP values (using different service classes).
Babiarz, et al. Expires April 27, 2006 [Page 5]
Internet-Draft Document October 2005
2. Framework
When the packet forwarding network is used to support Session Based
Real Time Application usage, the application behavior requires
different support from the network. For example, random packet drops
does not trigger application to lessen the offered load to the
network, it just degrade the session service the application needs.
The mechanism described by this document is used within a framework
where we try to achieve the following goals:
1. Allow the application control and signaling be separate from the
packet forwarding network control and signaling.
2. Keeping the packet forwarding network and its control simple.
3. Allow application features be controlled in the application
layer.
The above set of goals point us to an architecture where:
1. The network plays a role of providing current network information
concerning the availability of network resource to support the
application needs.
2. The application uses the information provided by the network to
make application level decisions.
In the context of Session Admission Control for Real Time traffic
with Voice Over IP as an example, we will discuss the framework in
the following sections.
2.1. Application Decisions based on Network Information
For this document the application decisions is for support of real
time traffic session admission control. This includes the decision
of:
1. should normal priority real time sessions be admitted.
2. should higher priority real time sessions be admitted.
3. should normal priority real time sessions be terminated.
4. should higher priority real time sessions be terminated.
Notice these are decisions local to the application and the actual
actions can be controlled by the use of local application level
policies.
Babiarz, et al. Expires April 27, 2006 [Page 6]
Internet-Draft Document October 2005
For normal priority real time session admission control, the goal is
to make sure the additional offered load by the new normal priority
real time session does not push the network resource utilization into
a state that will negatively affect the packet delay, delay
variation, loss requirements of the already admitted real time
sessions. Hence the application decision is to admit or not to admit
a new real time session based on a set of network information.
For higher priority real time session admission control, the goal is
to make sure the additional offered load by the new higher priority
real time session does not push the network resource utilization into
a state that will negatively affect the packet delay, delay
variation, loss requirements of the already admitted real time
sessions. Hence the application decision is to admit or not to admit
a new real time session based on a set of network information.
Notice by the nature of higher priority real time session, the
decision can be to admit higher priority session when not admitting
normal priority sessions while approaching fuller utilization of
network resources. With the notion of normal priority and higher
priority sessions being application level notions and the decisions
be application level decisions, possibly determined using local
application policies.
For normal priority real time session termination decision, the goal
is to have a method to decrease the offered load to the network when
the network resource utilization approaches the level of affecting
the packet delay, delay variation, loss requirements of the already
admitted real time sessions. This action is taken due to the fact
that for real time sessions like VoIP, the affect will be on all real
time sessions that shares the limiting network resource. This
decision is to sacrifice a single (or limited number of) real time
session on behave of all the other affected real time sessions.
For higher priority real time session termination decision, the goal
is to have a method to decrease the offered load to the network when
the network resource utilization approaches the level of affecting
the packet delay, delay variation, loss requirements of the already
admitted real time sessions. This action is taken due to the fact
that for real time sessions like VoIP, the affect will be on all real
time sessions that shares the limiting network resource. This
decision is to sacrifice a single (or limited number of) real time
session on behave of all the other affected real time sessions. By
the nature of higher priority, the normal priority sessions are
sacrificed/terminated before higher priority sessions. This can be
controlled using local application level policies.
Notice the action of the decisions are controlled by local
application policies, one example is to do nothing when higher
Babiarz, et al. Expires April 27, 2006 [Page 7]
Internet-Draft Document October 2005
priority real time session termination decision needs to be made,
hence not supporting the higher priority session termination
function.
We call this Session Admission Control at the application layer.
2.2. Network Information for Supporting Application Decisions
For Session Admission Control of Real Time traffic, due to the nature
of real time traffic like VoIP, the network information needs to
indicate will the offered load introduced by the to-be-admitted
session affect the existing admitted sessions. The application also
requires the network to indication when more aggressive action is
needed by the application to allow acceptable network service be
provided to the admitted sessions. Hence we propose the following
network information:
1. Network information for session admission control. This
information is used to assist the application to decide if a new
application session should be admitted to use the packet
forwarding network resource. For real time in-elastic session,
this information needs to indicate the on-set of additional
packet delay/delay-variation/loss that affects the real time in-
elastic sessions sharing the packet forwarding network resource.
For normal priority session admission control, we allow the
network device along the session's packet forwarding path to
indicate if a certain level of resource utilization is reached.
We call this Admission-Level, and uses bits per second as the
basic measurement unit at the network device. When the network
resource utilization at a network device exceeds Admission
-Level, the network device indicates this condition by using some
field in the packet (proposing the use of the ECN field) being
forwarded to the session end point. Please notice that the
setting of Admission -Level is a local network provisioning
policy for the network device. And it may depend on the link
speed being used, other traffic sharing the link resource, and
other local network device provisioning criterion. This approach
allows the network devices' local provisioning policy to control
the allocation of resources of the network device, allowing
network devices with different capabilities be used in the
session packet forwarding path, and providing the information to
the application to assist the making of session admission control
decision.
2. Network information for session termination. This information is
used to assist the application to decide if the network load
offered by the application should be lessened to allow existing
application sessions to receive acceptable service from the
Babiarz, et al. Expires April 27, 2006 [Page 8]
Internet-Draft Document October 2005
packet forwarding network. For real time in-elastic session,
this information needs to indicate a more severe on-set of
additional packet delay/delay-variation/loss that affects the
real time in-elastic sessions sharing the packet forwarding
network resource, as compared with session admission control
information. For normal priority session termination, we allow
the network device along the session's packet forwarding path to
indicate if a certain level of resource utilization is reached.
We call this Termination-Level, and uses bits per second as the
basic measurement unit at the network device. When the network
resource utilization at a network device exceeds Termination-
Level, the network device indicates this condition by using some
field in the packet (proposing the use of the ECN field) being
forwarded to the session end point. Please notice that the
setting of Termination-Level is a local network provisioning
policy for the network device. And it may depend on the link
speed being used, other traffic sharing the link resource, and
other local network device provisioning criterion. This approach
allows the network devices' local provisioning policy to control
the allocation of resources of the network device, allowing
network devices with different capabilities be used in the
session packet forwarding path, and providing the information to
the application to assist the making of session termination
decision. The Termination-Level indication can also be used for
higher priority sessions' admission control decision. For
example, when Termination-Level indication is received by the
application session decision point, higher priority sessions may
not be admitted but their session initiation request being
queued, depending on the application level higher priority session
admission control policy. There are also mechanisms for
smoothing out the session termination process and to provide
network information to allow multiple higher level session
termination. These will be discussed in the detail mechanism
sections of this document.
In the following section, we provide an operational overview using
SIP to show how the above information are used together. In later
sections we provide the details of the packet forwarding network
mechanism itself.
2.3. Operational Overview with SIP Applications
This operational overview section provides some high level indication
of how the goals and ideas of previous sections of the framework can
be used together in a SIP application environment. We separated the
overview into subsections, each describing session admission control
operation and session preemption operation.
Babiarz, et al. Expires April 27, 2006 [Page 9]
Internet-Draft Document October 2005
2.3.1. Session Admission Control
For session admission control application level decisions, the
application requires the knowledge of "will the offered load of the
new session push the network resource utilization along the
application media packet forwarding path (called media path for
short) beyond the network resource's ability to support the required
service".
The network provides this information by performing a measurement of
packet traffic along the media path and comparing the measurement
with a preset Admission-Level. Notice that this Admission-Level can
be setup using static or dynamic network device configuration. The
mechanism described by this document is independent from network
control, provisioning, signaling. Hence allowing network devices
freedom to setup Admission-Level based on its capability and local
network control/provisioning policy.
Since this measurement is performed prior to any application media
traffic can flow, we use a pre-media probing method to allow the
application to learn this information for session admission control
decision. For SIP environment this is described in "RTP Payload
Format for ECN Probing" [15]. We also use the SIP application level
signaling pre-condition mechanism to indicate the use of this method.
Please see A Congestion Status Precondition for the Session
Initiation Protocol (SIP) [18] for details.
We provided a simple high level operational walk through below, with
the presumption that probing starts at a point during session setup
when the Receiver endpoint addressing information is known by the
Sender. As the immediate application is admission control, the
endpoints involved SHOULD NOT begin alerting or otherwise notifying
the user of a new session until the admission control procedures
determine whether to admit the new session.
With an unidirectional probing mechanism, after the Sender knows
addressing information specific to the Receiver, it can begin
generating probe packets to the Receiver. When the probe packets are
received at the Receiver, an admission decision can be made based on
the congestion level indicated by the probe packets and the priority
associated with the session. The process of making this decision may
involve a unilateral decision made in the Receiver, or it may involve
communication either back to the Sender, or to another device
responsible for making the session admission decision.
Babiarz, et al. Expires April 27, 2006 [Page 10]
Internet-Draft Document October 2005
(1) (3)
+------+ +----------+ +------+
| | | | | |
| EP A | ----> | Router A | ----> + EP B | (5)
| | | | | |
+------+ +----------+ +------+
(2) (4)
Figure 1: Session Admission Control
1. Endpoint (EP) A starts the process. It creates a Probe Packet
and sends it to the address and port it has for EP B.
2. Router A receives the Probe Packet, and applies a metering and
marking mechanism for real-time inelastic traffic.
3. Router A re-marks the ECN field in the IP header of the Probe
Packet based on the metering and marking mechanism being used,
then forwards the packet.
4. EP B receives the Probe Packet. The ECN value received in the
Probe Packet in the IP header indicates exceeding the admission
control level of congestion on the path towards EP B.
5. EP B inspects the ECN value received in the IP header, and uses
it to begin the decision process on whether to admit the session.
In the context of admission control, application level session
admission policy may dictate that higher priority sessions may get
admitted when the Probe Packets indicate pre-congestion level that
prevent normal priority sessions from being admitted.
2.3.2. Session Preemption
For application level session preemption decisions, the application
requires the knowledge of "is the current offered load of network
traffic pushing the network resource utilization along the
application media packet forwarding path beyond the network
resource's ability to support the required service for the admitted
sessions?". This condition can occur even when session admission
control have been applied. For example, packet network routing
change can cause previously different session packet forwarding paths
to merge at some points in the network and pushed the network
Babiarz, et al. Expires April 27, 2006 [Page 11]
Internet-Draft Document October 2005
resource utilization at these points to beyond their ability to
support the required service. These packet network routing change
may be caused by router failures or other reasons, this framework
allows the packet forwarding network to use whatever method it
chooses to provide the best packet forwarding network service without
getting in its way. The application just need to know if it needs to
take action based on the resulting packet forwarding network
conditions.
The above knowledge can be provided to the application by the
network. As with the probe packets described in the context of
session admission control, endpoints can similarly monitor the ECN
value of RTP media packets and react accordingly, initiating
preemption mechanisms when necessary. If the preemption threshold
level is exceeded, as indicated by the ECN value of the media
packets, application level local policy may dictate session
preemption as a required action to keep bandwidth resource usage
within engineered limits.
The example provided here shows only a unidirectional media flow. A
bidirectional session would operate similarly, but with two
unidirectional flows in opposite directions.
The example provided here describes an application level local policy
dictating that preemption occurs when the preemption threshold level
has been exceeded, as indicated by the ECN value of the media
packets.
(1) (3)
+------+ +----------+ +------+
| | | | | |
| EP A | ----> | Router A | ----> + EP B | (5)
| | | | | |
+------+ +----------+ +------+
(2) (4)
Figure 2: Preemption
1. Endpoint (EP) A starts the process. It creates an RTP media
packet and sends it to the address and port it has for EP B. Each
media packet is marked with default ECN value to indicate no
congestion.
2. Router A receives the RTP media packets, and applies a metering
and marking mechanism for real-time inelastic traffic.
Babiarz, et al. Expires April 27, 2006 [Page 12]
Internet-Draft Document October 2005
3. Router A re-marks the ECN field in the IP header of the RTP media
packets based on the metering and marking mechanism being used,
then forwards the packet. For the purposes of this example, it
is presumed the network resource condition is such that Router A
marks the ECN bits to indicate that the preemption level of
congestion has been exceeded.
4. EP B receives the RTP media packets. EP B monitors the ECN value
of RTP media packets, and upon receiving packets marked with the
ECN value indicating that the preemption level of congestion has
been exceeded somewhere along the path in the network, it follows
local application level session preemption policy to initiate
session preemption.
5. The specific actions taken to carry out preemption may vary, as
they are local application level session preemption policy.
2.3.3. Operational Overview Summary
The simple high level walk through of operational overview for
session admission control and session preemption in previous sections
provided some overview of how we:
1. Keep the application features being controlled in the application
layer using application level session policies.
2. Keep the packet forwarding network and its control simple by just
adding simple network condition indication to the forwarded
packet with existing packet header field.
3. Allow the application control and signaling be separate from the
packet forwarding network control and signaling. And allowing
the packet forwarding network to do what it does best without
adding application level baggage to it. And allowing the
application layer to do what it does best on utilizing the packet
forwarding network resources.
3. 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
Babiarz, et al. Expires April 27, 2006 [Page 13]
Internet-Draft Document October 2005
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 for real-
time traffic. The assumption 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 marking
packets as ECN-Capable Transport (ECT).
o Flow measurement and marking of ECN bits as defined herein is
performed on flows from ECN-capable end-systems that is mapped to
a ECN-enabled service class, and may be performed 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 the
ECN field of the IP header.
o ECN procedure as defined in RFC 3168 [7] 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.
4. 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 elastic applications
that use a protocol such as TCP. One such requirement is that end-
to-end delay be bounded to a small value, and that packets should not
be dropped.
It is generally accepted that such performance requirements can be
Babiarz, et al. Expires April 27, 2006 [Page 14]
Internet-Draft Document October 2005
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
Expedited Forwarding (EF) PHB [8] treatment. This treatment can be
provided only when the real-time service class is not overloaded
(i.e., when the aggregate 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.
4.1. Avoiding Congestion for Real-Time Traffic
Congestion notification can be utilized in a flow admission control
scheme to ensure sufficient forwarding resources (bandwidth), hence
for Real-Time Traffic, ECN is used to prevent congestion. 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 4.4.2 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.
Babiarz, et al. Expires April 27, 2006 [Page 15]
Internet-Draft Document October 2005
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
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.
4.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 need only to perform flow measurement of packets marked
with specific DS codepoint and with ECN indication that the end-
system is ECN-capable. Another policy that may be used is where
network nodes perform flow measurement of packets marked with a
specific DS codepoint and if the rate is exceeded, only ECN mark
packets that indicate that they are ECN-capable. The application
monitors the ECN field, and takes an appropriate action based on the
marking.
Figure 3 below shows a block diagram of the traffic measurement and
ECN marking function.
+------------+
| Result |
| V
+-------+ +--------+
| | | ECN |
Packet Stream ===>| Meter |===>| Marker |===> Marked Packet Stream
| | | |
+-------+ +--------+
Figure 3: Block Diagram of Meter and Marker Function
The Meter meters each packet within the real-time service class and
passes the packet and the metering result to the ECN Marker.
The Marker sets the ECN congestion level for each packet that is
marked as ECN-capable within the real-time service class based on the
results of the Meter.
Babiarz, et al. Expires April 27, 2006 [Page 16]
Internet-Draft Document October 2005
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.
4.3. Behavior of Meter and Marker
When the measured rate exceeds the engineered traffic level for ECN-
capable marked packets, the Meter sets its result flag and passes it
to the Marker. The Marker, sets the appropriate ECN value for all
ECN-capable marked packets belonging to the service class that is
measured until the result flag from the Meter is cleared.
When the measured traffic rate is reduced below the engineered rate
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 (example size of the token bucket) of the
traffic measurement mechanism and should be configured to meet the
characteristics of the real-time inelastic traffic that is being
measured. See report, Simulation of RT-ECN based Admission Control
and Preemption [13] for results of the above metering and marking as
well analysis of different metering approaches in Discussion of
Congestion Marking with RT-ECN [14].
4.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 4: DS and ECN Fields in IP Header
Bits 6 and 7 in the IPv4 octet are designated as the ECN field. This
octet of the IPv4 header corresponds to the Traffic Class octet in
IPv6, and the ECN field is defined identically in both cases. The
Babiarz, et al. Expires April 27, 2006 [Page 17]
Internet-Draft Document October 2005
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 [6]. 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 [7]
standardizes the use of the ECN bits.
4.4.1. ECN Marking of Real-Time Inelastic Flows
Marking of ECN bits for real-time inelastic flows is defined so that
nodes in the path need only to perform an ECN set function when an
engineered rate is exceeded for packets that are marked as ECN-
capable. With this approach there is no need to perform a test to
determine the congestion level marking of the received packet before
a node performs ECN marking. Other approaches could be used, but for
simplicity we have chosen this one. In Section 7 we discuss the
different marking approaches that were studied.
Network nodes that are configured to support congestion notification
for real-time flows need to provide the following capability:
o Congestion detection of packets marked indicating that the end-
system is ECN-capable (ECT) SHOULD be performed using a real-time
measurement mechanism (e.g., flow metering).
o When the flow rate exceeds configured rate "A" (i.e., the first
level of congestion), ECN bit 7 of ECT marked packets is set to
'1'.
o When the flow rate exceeds configured rate "B" (i.e., the second
level of congestion), ECN bits 6 and 7 of ECT market packets are
set to '01'.
o Measured rate "B" SHOULD be greater than rate "A".
4.4.2. ECN Semantics for Real-Time Traffic
Some real-time applications or services need the indication of two
levels of congestion experienced, CE(1) and CE(2), 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 for real-time inelastic traffic.
Babiarz, et al. Expires April 27, 2006 [Page 18]
Internet-Draft Document October 2005
ECN Marking:
Bits 6 and 7 values
0 0 Not-ECT - End-system is Not ECN-Capable Transport
1 0 ECT(0) - End-system is ECN-Capable Transport
1 1 CE(1) - Congestion Experienced at 1st level
0 1 CE(2) - Congestion Experienced at 2nd level
Figure 5: ECN Semantics for Real-Time Flows
4.5. End-System Behavior
Listed below are reactions to ECN marking that needs to be supported
by end-systems that indicated that they are ECN-capable:
o Under normal (non emergency or situation critical) conditions
during new flow establishment, ECN-capable end-system that receive
packets marked indicating that congestion was experienced at 1st
level CE(1), SHOULD NOT proceed with the session setup. New flows
that indicate that they are "emergency or situation critical"
SHOULD be allowed admission at CE(1). The definition and
verification of what flow is classified as "emergency or situation
critical" is left up to the application.
o Once a flow has been admitted and the path experience 1st level of
congestion CE(1), ECN-capable end-systems that have ability to
dynamically react to ECN marking, SHOULD reduce their sending rate
as agreed to during session setup.
o During new flow establishment, ECN-capable end-systems that
receive packets marked indicating that congestion was experience
at 2nd level CE(2) SHOULD NOT proceed with session setup.
o Systems with established flows that experience the 2nd level of
congestion CE(2) SHOULD terminating sessions or reduce sending
rate in a controlled manner, and continue until the congestion
level drops below the 2nd level of congestion.
Generally, at 1st level of congestion, no additional traffic should
be added with the exception for flows that are identified as being
potentially life threatening i.e., E911 or situation critical. End-
systems that have the ability to reduce their sending rate should do
so. At 2nd level of congestion, no additional traffic is added to
the congested path plus selected flows on the congested path are
removed to reduce congestion below 2nd level.
Babiarz, et al. Expires April 27, 2006 [Page 19]
Internet-Draft Document October 2005
5. Detection of Inappropriate Changes to the ECN Field
This section discusses in detail some of the possible inappropriate
changes to the ECN field in the network, such as reducing level of
congestion, falsely reporting no congestion, or modifying ECN bits to
indicate that the path is or is not Real-Time ECN compliant.
Reducing the level of congestion or falsely reporting no congestion
will be referred to here as "cheating".
The Real-Time ECN mechanism provides two levels of congestion
indication. Therefore, the cheating detection mechanism as defined
in RFC 3168 [7] and RFC 3540 [10] that uses ECT(0) and ECT(1) states
can not be used. Instead, the procedure outlined in this memo SHOULD
be used to detect if inappropriate changes to the ECN bits have
occurred between originator and receiver. The outlined procedure is
executed under the control of the application prior to admission of a
new real-time flow. The testing for conformance is performed between
the two Real-Time ECN-capable and conformant applications running in
the end-systems. These two end-systems will be referred to as sender
and receiver.
In the implementation of a Real-Time ECN mechanism in the network,
the network administrator through the use of policies 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 applications running in end-systems that are capable and
conformant to this Real-Time ECN mechanism may use it. End-systems
that are not Real-Time ECN-capable or conformant MUST set ECN field
to '00' when sending packets.
5.1. During Session Setup
During the admission of a new real-time flow, application signaling
is used to exchange end-system capabilities, including whether the
end-systems are Real-Time ECN capable. The Real-Time ECN mechanism
defined in this memo can be used to provide admission control
capabilities to end-systems. In order to provide this capability,
the signaling used by the end-systems requires a means to both
trigger the Real-Time ECN probing process as described in "RTP
Payload Format for ECN Probing" [15] and "Real-time ECN Use Cases"
[11], as well as to delay session setup; - specifically user
indication of a new session, i.e., ringing until an admission control
decision has been made. In the context of SIP, preconditions can be
used to accomplish both of these requirements. For more details, see
A Congestion Status Precondition for the Session Initiation Protocol
(SIP) [18].
If signaling indicates that the destination end-system does not
Babiarz, et al. Expires April 27, 2006 [Page 20]
Internet-Draft Document October 2005
support the Real-Time ECN mechanism, the originating end-system MAY
reattempt the session without stipulating the use of the Real-Time
ECN mechanism. While such a session would not undergo the Real-Time
ECN admission control tests, this does allow session creation between
end-systems that support the Real-Time ECN mechanism and those that
do not.
Prior to admission of a new real-time flow, the following procedure
SHOULD be used to detect inappropriate changes to ECN field. Note
that this procedure can be independent of an actual admission control
procedure.
Under the control of the application, the sender generates and sends
a stream of RTP-probe packets. This stream of RTP-probe packets is
specified as follows:
1. A random sequence of the four possible ECN bit combinations is
selected, and this sequence of values is used as the ECN field
values on the initial four RTP-probe packets. The ECN field
marking is also copied into the RTP-probe payload [15] and the
payload should be secured. SRTP RFC 3711 [9] is one mechanism
that can provide the necessary security for the probe packets.
2. After the sequence of four RTP-probe packets is sent, the sender
sends RTP-probe packets with randomly generated ECN bit of '10',
'11' and '01' until probing is stopped. As before, the ECN field
marking is also copied into the RTP-probe payload and the payload
should be secured.
The probing sequence just described is one method that can be
implemented for probing to detect inappropriate changes to the ECN
field. Because the ECN field marking on probe packets is always
copied into the RTP-probe payload, the receiving end-system is always
able to compare the received ECN value in the IP header with that in
the secured RTP-probe payload. Therefore the ability to detect
inappropriate changes to the ECN Field via probing is independent of
the ECN bit sequence used.
Upon reception of the RTP-probe packet, the receiver compares the
received ECN marking in the IP header to ECN marking in RTP-probe
payload.
A packet sent with ECN field '10' and received as indicated below
have the meanings as indicated:
o Received as '10': path is valid, no congestion.
Babiarz, et al. Expires April 27, 2006 [Page 21]
Internet-Draft Document October 2005
o Received as '11': path is valid, congestion experienced at 1st
level.
o Received as '01': path is valid, congestion experienced at 2nd
level.
o Received as '00': path is not valid, device in path zeroed ECN
field.
Packet sent with ECN field '01' and received as indicated below have
the meanings as indicated:
o Received as '01': path is valid.
o Received as '11': path is not valid, device in path reduced
congestion experienced to 1st level, this could also mean that the
path is through a congested router that used RFC 3168 for ECN
marking of this flow.
o Received as '10': path is not valid, device in path cleared
indication of congestion experienced.
o Received as '00': path is not valid, device in path zeroed ECN
field.
Packet sent with ECN field '11' and received as indicated below have
the meanings as indicated:
o Received as '11': path is valid.
o Received as '01': path is valid, congestion experienced at 2nd
level.
o Received as '10': path is not valid, device in path cleared
indication of congestion experienced.
o Received as '00': path is not valid, device in path zeroed ECN
field.
Packet sent with ECN field '00' and received as indicated below have
the meanings as indicated:
o Received as '00': path is valid.
o Received other than '00':, path is not conformant.
The above mechanism will detect when a device in the path tries to
cheat by changing the ECN field to indicate no congestion, or reduce
Babiarz, et al. Expires April 27, 2006 [Page 22]
Internet-Draft Document October 2005
the level of congestion, or incorrectly indicate a path is or is not
ECN capable. Due to the nature of the Real-time ECN process
described in this memo, it is not possible to detect the presence of
devices which raise the level of congestion in the ECN marking.
The detection of presence of devices that lower ECN marking is only
possible if there are no other Real-Time ECN capable routers down
stream from the cheating device along the network path legitimately
marking the ECN bits, masking out the cheating condition. However,
this is not a problem if the down steam router marks ECN back to the
appropriate congestion level, as the end-system will take the correct
action for that flow.
The outlined procedure for detection of inappropriate changes to the
ECN field is also applied to RTP-probe flow in the direction from
call originator to the far-end as outlined in Real-time ECN Use Cases
[11].
During session setup phase, if it is determined that the path is
invalid, non-conformant or congested, the setup of the session SHOULD
be terminated with cause information provided to the user.
5.2. After Session is Established
Once a new real-time flow has been admitted, the following procedure
SHOULD be used to detect cheaters and routers that use ECN procedure
defined in RFC 3168:
o For real-time flow, the media packets are sent with an ECN value
of '10' set in the IP header. At random intervals, a single media
packet will be sent with '01' in order to detect the cheaters and
congested RFC 3168-capable routers. The receiver must be aware of
which packets the sender marked with '01', so that it does not
misinterpret such packets as indicating congestion.
o In order that both the sender and receiver are synchronized as to
which packets are marked '01', they will use a common function to
determine which packets are marked. The Mersenne Twister MT 19937
[16] random number generator, seeded with the initial RTP Sequence
Number used by the sender, is utilized in this synchronization
process.
o During the initial RTP-probe sequence [15] that was used to verify
conformance of path during session setup, the initial Sequence
Number used by the sender is sent to the receiver in the payload
of the probe packets. This value is used as a seed in a Mersenne
Twister MT 19937 random number generator in both the sender and
receiver. The sender begins sending media packets marked with ECN
Babiarz, et al. Expires April 27, 2006 [Page 23]
Internet-Draft Document October 2005
'10'. The sender and receiver each use the MT 19937 function to
select the next pseudorandom number in the sequence, modulus 4, to
determine the next packet to mark with ECN '01'. The use of
modulus 4 is to keep the interval between packets used for
detection of cheaters, etc., bounded.
In the sender, the following steps describe this process:
1. During probing, send the Initial RTP Sequence Number (IRSN), in
the payload of the probe packet.
2. Seed the MT 19937 function with the initial sequence number:
MT19937.seed(IRSN).
3. Calculate N, the number of media packets to be marked with ECN
'10', before marking a single media packet with ECN '01', as
follows: N = (MT19937.next)(MOD 4) + 1.
4. Once the real-time flow begins, mark N packets with ECN '10'.
5. Send the next packet with ECN '01'.
6. Repeat starting with Step 3, until the real-time flow is
terminated.
In the receiver, the following steps describe this process:
1. During probing, pull the Initial RTP Sequence Number (IRSN) from
the payload of a received probe packet[15]. Initialize NSN
(described in Step 4 below): NSN = IRSN.
2. Seed the MT19937 function with the initial sequence number:
MT19937.seed(IRSN).
3. Calculate N, the number of media packets to be marked with ECN
'10', before marking a single media packet with ECN '01', as
follows: N = (MT19937.next)(MOD 4) + 1.
4. Calculate NSN, the sequence number of the next packet expected to
be marked with ECN '01': NSN = NSN + N.
5. Receive media packets, watching for a packet with a sequence
number equal to or greater than NSN, until the real-time flow is
terminated:
A. Packets with a sequence number less than NSN are used for
congestion detection. Repeat Step 5.
Babiarz, et al. Expires April 27, 2006 [Page 24]
Internet-Draft Document October 2005
B. Packets with a sequence number equal to NSN are used for
detection of cheaters and congested RFC 3168-enabled routers.
If the ECN value of this packet is not '01', a cheater or
congested RFC 3168-enabled router is present along the
network path. Jump to Step 3 and repeat.
C. Packets with a sequence number greater than NSN should result
in calculation of a new NSN value. Jump to Step 3 and
repeat.
The previous algorithm is one that should be used. Other methods can
be used as long as both the sender and receiver agree to it.
Upon receipt of an RTP packet the receiver expects to be marked '01',
the end-system compares the received ECN field with the expected
value of '01', or CE(2). If a cheater is present, and is not being
overridden by marking of one or more Real-Time ECN capable routers
along the path through the network, the end-system detects the
presence of a cheater if the received ECN value is '10' or '11' or
'00', (ECT(0) or CE(1) or Not-ECT). Also, this procedure can be used
to detect the presence of congested routers that use RFC 3168 as its
ECN marking. A congested router that uses the ECN marking procedure
as defined in RFC 3168 will interpret ECN value '01' as ECT(1) and
change the marking to '11' (CE).
If after a session has been admitted it is detected that there is a
cheater or congested router that uses RFC 3168 for ECN marking of
real-time flows, the established session SHOULD be terminated with
cause information provided to the user.
6. 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
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.
Babiarz, et al. Expires April 27, 2006 [Page 25]
Internet-Draft Document October 2005
This approach allows for incremental deployment of DiffServ and Real-
Time ECN. Specific network nodes where congestion is not likely to
occur may delay its use of DiffServ and ECN.
6.1. Workable Approach for Co-existence of RT-ECN
Routers need a method to understand which ECN mechanism should be
applied based on the traffic being forwarded. We believe DiffServ
architecture can provide this capability. The normal practice is to
segregate elastic and real-time inelastic flows into different
service classes that use different PHBs with the DS codepoint being
used as the indicator for selection of the PHB. Router can implement
both ECN procedures and use DS codepoint for indicating which ECN
mechanism applies to each packet.
The approach that we selected allows for two different ECN
mechanisms, one for elastic flows and the other for real-time
inelastic flows with the following rules for deployment:
1. ECN as per RFC 3168 applies to the Default Forwarding [4] PHB
'000000'.
2. In DiffServ enable networks, DS codepoints is used to indicate
the ECN mechanisms that may be supported.
A. ECN as per RFC 3168 should be used with the AF [5] PHBs.
B. RT-ECN should be used with EF [8] PHB.
C. Class Selector PHBs may use RFC 3168 or RT-ECN and should be
based on traffic characteristic assigned to the PHB. See
Configuration Guidelines for DiffServ Service Classes [12]
for guidance.
3. As RFC 3168 defines the default behavior, all other mechanisms
that are defined should not cause harm to the default ECN
behavior or network if the alternate ECN mechanism encounters RFC
3168 marking.
As stated in Specifying Alternate Semantics for the Explicit
Congestion Notification (ECN) Field [17] "that the default ECN
semantics defined in RFC 3168 are the current default semantics for
the ECN field, regardless of the contents of any other fields in the
IP header. In particular, the default ECN semantics apply for more
than best-effort traffic with a codepoint of '000000' for the
diffserv field - the default ECN semantics currently apply regardless
of the contents of the diffserv field." We propose that an amendment
to RFC 3168 be considered that would allow non default DS codepoints
Babiarz, et al. Expires April 27, 2006 [Page 26]
Internet-Draft Document October 2005
to be used for indicating alternate ECN semantics with guidance as
stated above.
7. Discussion on Different Marking Approaches
In our analysis of ECN marking to address the needs of real-time
flows like voice and video conferencing, we look at different marking
schemes so that the ECN bit definition and meanings be closely
aligned with what is defined in RFC 3168. Below is one example worth
noting that was considered but rejected even if it uses the same ECN
semantics as what is defined in RFC 3168.
7.1. Alternate RT-ECN marking
During session setup (flow admission), end-system marks its' packets
with ECT(0) ECN='10' and once the flow is admitted the end-system
marks its' packets with ECT(1) ECN='01'.
With the following metering and marking policy in router, packets
that are marked as ECN-capable (ECN= 10, 11 or 01) are meter by both
meters:
o If traffic exceeds 1st threshold level, mark ECN-capable ECT(0)
'10' packets to indicate that congestion was experienced CE '11'.
o If traffic exceeds 2nd threshold level, mark ECN-capable ECT(1)
'01'packets to indicate that congestion was experienced CE '11'.
ECN Marking (identical to RFC 3168):
Bits 6 and 7 values
0 0 Not-ECT - End-system is Not ECN-capable
0 1 ECT(1) - End-system is ECT, once flow is admitted
1 0 ECT(0) - End-system is ECT, during flow admission
1 1 CE - Congestion Experienced
Figure 6: Alternate ECN Semantics for Real-Time Flows
7.2. Implication of this Marking
During session setup (admission control) end-systems send their
packets marked with ECT(0) '10' and once the flow is admitted, end-
systems mark their packets with ECT(1) '01'. Routers have a policy
that meters all ECN-capable traffic, packets marked with ECT(0) are
measured to the 1st threshold level and packets marked with ECT(1)
are measured against the 2nd threshold level. The receiving end-
system must be informed (some how) if the packet is ECT(0) or ECT(1),
Babiarz, et al. Expires April 27, 2006 [Page 27]
Internet-Draft Document October 2005
during RTP-probing as well after, and there are methods to achieve
this.
7.3. Reason for Not Using this RT-ECN Marking
The concern that the authors of this draft had with the use of the
same ECN semantics for two different congestion control mechanism is
that there is no simple method for detection of the wrong ECN
behavior being applied by router in the path. As stated in
Specifying Alternate Semantics for the Explicit Congestion
Notification (ECN) Field [17] a method is needed for end-systems to
verify that routers are applying the compliant marking for safe co-
existence of alternate ECN behavior. For the proposed ECN semantics
(see Section 4.4.2), and Section 5 of this document defines a method
that can be used to detect the presence of congested routers that use
RFC 3168 for its ECN marking. As well, we would like to note that
the procedure outlined in RFC 3540 can be used to detect presence of
congested routers that use RT-ECN marking.
8. 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 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
Babiarz, et al. Expires April 27, 2006 [Page 28]
Internet-Draft Document October 2005
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",
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.
9. 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 [7] Section 22.
10. Changes from Previous Version
NOTE TO RFC EDITOR: Please remove this section during the publication
process.
Babiarz, et al. Expires April 27, 2006 [Page 29]
Internet-Draft Document October 2005
This version of the draft was rework to address the requirements
stated in Specifying Alternate Semantics for the Explicit Congestion
Notification (ECN) Field [17], updated section that define "Detection
of Inappropriate Changes to the ECN Field" and changes to Appendix A.
11. 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.
12. IANA Considerations
To be completed.
13. 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, Stephen
Dudley, Bob Briscoe, David Black, and Ralph Carsten.
14. Appendix A
Babiarz, et al. Expires April 27, 2006 [Page 30]
Internet-Draft Document October 2005
Below is a description of a Single Rate Meters and ECN Marker. For
scenarios that require two traffic levels within a service class to
be measured for congestion indication, two instances of the single
rate meter can be used, one for configured rate "A" and the other for
configured rate "B", with a single ECN marker. The meter parameters
should be selected to meet the characteristics and performance
requirements of traffic being measured.
14.1. Introduction
The Single Rate Meters and ECN Marker is configured by assigning
values to four parameters: Committed Information Rate (CIR), Token
Bucket Size (TBS), ECN set threshold 'm' as a percentage of TBS and
ECN clear threshold 'n' as a percentage of TBS. The meter has an
internal state "result flag" which when set indicates a condition
where the measured traffic has exceeded the CIR and token in the
token bucket where exhausted below 'm' threshold. When the rate
decreases below CIR, token bucket is filled above 'n' threshold and
the internal "result flag" is cleared.
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 7: 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.
14.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), and values 'm' and 'n' representing
percentage fullness of Token Bucket. 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. 'm' and 'n' are percentages that
change size of TBS depending on the state of the result flag.
Normally, variable rate traffic will need larger token bucket than
Babiarz, et al. Expires April 27, 2006 [Page 31]
Internet-Draft Document October 2005
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
measurement duration.
14.3. Meter Behavior
The behavior of the Meter is specified in terms of its Committed
Information Rate (CIR), Token Bucket Size (TBS) and its ECN set and
clear thresholds 'm' and 'n'.
Initially (at time 0), token bucket (TBS) is full, i.e., the token
count is represented by Tp.
Where Tp(0) = TBS
As well, the internal meter result flag (1st_result_flag) is
cleared.
When a packet of size B arrives at time t, the following happens:
Tp = Tp(t) + (CIR x delta_t) //tokens added at CIR
Tp = Min (Tp(t), TBS) //keep Tp from growing pass full
Tp = Tp(t) - B //decrement Tp by B bytes
Tp = Max (0,Tp(t)) //keep Tp from going negative
if (1st_result_flag = = 0) //internal result_flag not set?
if (Tp < TBS x m) //has traffic exceeded CIR?
1st_result_flag = 1 //set internal result_flag
Tp = 0 //set token bucket to zero
else //if internal result_flag is set
if (Tp > TBS x n) //is traffic below CIR?
1st_result_flag = 0 //clear internal result_flag
Tp = TBS //set Tp to TBS
return
Where m and n is 1-99%
Notes:
- delta_t is the elapsed time from the previous received packets.
- m controls token bucket threshold for setting the result flag.
- n controls token bucket threshold for clearing the result flag.
A second instance of this single rate meter can be configured for
measurement of rate "B" (the second rate).
The actual implementation of a Meter doesn't need to be modeled
according to the above formal specification.
Babiarz, et al. Expires April 27, 2006 [Page 32]
Internet-Draft Document October 2005
14.4. Marking
The ECN Marker reflects the result flag setting received from the
Meters. If 1st_result_flag is set, all packets indicating that the
end-system is ECN-capable, have their ECN bit 7 set to '1'. If the
2nd_result-flag is set, all packets indicating that the end-system is
ECN-capable have their ECN bits 6 and 7 set to '01'. The ECN Marker
sets the ECN bit of ECN-capable marked packets as long as the result
flag(s) from the meters is set.
14.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(s) of all ECN-capable marked packets
marked with a specific DS codepoint 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". The
clearing of the result flag output from the meter, stops marking of
ECN bit by the Marker.
15. References
15.1. 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] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured
Forwarding PHB Group", RFC 2597, June 1999.
[6] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers", BCP 37,
RFC 2780, March 2000.
[7] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168,
Babiarz, et al. Expires April 27, 2006 [Page 33]
Internet-Draft Document October 2005
September 2001.
[8] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, J.,
Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An
Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246,
March 2002.
[9] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
15.2. Informative References
[10] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces", RFC 3540,
June 2003.
[11] Alexander, C., "Real-time ECN Use Cases",
draft-alexander-rtecn-use-cases-00 , July 2005.
[12] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines
for DiffServ Service Classes",
draft-ietf-tsvwg-diffserv-service-classes-01 , July 2005.
[13] Dudley, S., "Simulation of RT-ECN based Admission Control and
Preemption", draft-dudley-tsvwg-rtecn-simulation-00 , July
2005.
[14] Babiarz, J., Dudley, S., and K. Chan, "Discussion of Congestion
Marking with RT-ECN", draft-babiarz-rtecn-marking-00 .
[15] Alexander, C. and J. Babiarz, "RTP Payload Format for ECN
Probing", draft-alexander-rtp-payload-for-ecn-probing-01 ,
July 2005.
[16] Matsumoto, M. and T. Nishimura, "Mersenne Twister MT 19937",
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html
http://en.wikipedia.org/wiki/Mersenne_twister, March 2004.
[17] Floyd, S., "Specifying Alternate Semantics for the Explicit
Congestion Notification (ECN) Field",
draft-floyd-ecn-alternates-01 , July 2005.
[18] Alexander, C. and J. Rutledge, "A Congestion Status
Precondition for the Session Initiation Protocol (SIP)",
draft-alexander-congestion-status-preconditions-00 , July 2005.
Babiarz, et al. Expires April 27, 2006 [Page 34]
Internet-Draft Document October 2005
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
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@nortel.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 April 27, 2006 [Page 35]
Internet-Draft Document October 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 April 27, 2006 [Page 36]
