Internet DRAFT - draft-alexander-rtecn-use-cases
draft-alexander-rtecn-use-cases
Network Working Group C. Alexander, Ed.
Internet-Draft J. Babiarz
Expires: January 12, 2006 J. Matthews
Nortel
July 11, 2005
Real-time ECN Use Cases
draft-alexander-rtecn-use-cases-00.txt
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 January 12, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes use cases for the mechanisms described in
draft "Congestion Notification Process for Real-Time Traffic" and the
RTP payload format defined in draft "RTP Payload Format for ECN
Probing". Specifically, it describes admission control and
preemption use cases.
Alexander, et al. Expires January 12, 2006 [Page 1]
Internet-Draft Real-time ECN Use Cases July 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Admission Control . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Probing Mechanism . . . . . . . . . . . . . . . . . . . . 6
3.2 Delaying Session Establishment . . . . . . . . . . . . . . 6
3.3 Usage Examples . . . . . . . . . . . . . . . . . . . . . . 6
3.3.1 Unidirectional Probing without Cheater Detection . . . 7
3.3.2 Unidirectional Probing with Cheater Detection . . . . 9
3.3.3 Bidirectional Mechanisms . . . . . . . . . . . . . . . 11
4. Preemption . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1 Usage Example . . . . . . . . . . . . . . . . . . . . . . 12
4.2 Preemption Guidelines . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1 Normative References . . . . . . . . . . . . . . . . . . . 19
9.2 Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . 21
Alexander, et al. Expires January 12, 2006 [Page 2]
Internet-Draft Real-time ECN Use Cases July 2005
1. Introduction
Converged networks that are configured to provide multi-services
normally are engineered to provide the required quality of service
using Diffserv technologies. Real-time inelastic traffic (e.g.
voice) normally is configured to use Expedited Forwarding (EF) PHB to
provide very low delay, loss and jitter transport. To stay within
that engineered quality of service, and to ensure a quality of
service level for that traffic, some type of admission control
mechanism is necessary. Due to the sensitive nature of voice and
other telephony applications (video conferencing, multi-media
streaming), freely allowing these types of sessions onto a network
where resources are limited can quickly lead to degradation of
service that users may not tolerate. And in a packet based network,
the degradation is not limited to the offending flows, which the
provider may not tolerate.
The Real-Time ECN process offers two levels of congestion indication.
There is an intermediate congestion indication in addition to a
maximum congestion indication. This adds flexibility to admission
control decisions. The intermediate congestion indication
essentially warns endpoint applications that network congestion is
relatively high but that there is still some bandwidth available.
Using this information, applications can possibly decide to filter
out certain types of sessions for admission in favor of other types.
Applications demanding a large amount of bandwidth like video
conferencing might be denied, while less bandwidth-intensive voice
sessions could be admitted. Whatever the admission control basis,
Real-Time ECN enables some discernment in the decision making rather
than wholesale denial of sessions.
This document proposes an admission control solution based on
"Congestion Notification Process for Real-Time Traffic" [1] and "RTP
Payload Format for ECN Probing" [2]. The gist of the solution is
that nodes at selected points in the network, where congestion is
most likely to occur, measure traffic flow per service class and mark
the ECN bits in the IP header based on observed traffic level(s).
During session setup a probing mechanism is used between endpoints to
verify traffic level (or congestion) along the path. The probing
travels along the media path between the endpoints, where the
endpoints are on either side of one or more bandwidth constrained
links. At the links, ECN-capable nodes are provisioned with
congestion thresholds based on a traffic type's real-time service
class. The routers mark the ECN bits in the IP headers of the probe
packets according to the routers' experienced level of congestion for
the particular service class. As packets arrive, the ECN-capable
endpoints recognize any ECN markings and make an admission control
decision according to the indicated congestion level and session
Alexander, et al. Expires January 12, 2006 [Page 3]
Internet-Draft Real-time ECN Use Cases July 2005
precedence.
This document also proposes a preemption solution based on [1] and
[2]. This relies on endpoints monitoring the ECN value of incoming
media packets, specifically for the second level of congestion. When
present, the endpoint can initiate a preemption mechanism as dictated
by local policy.
Real-Time ECN does not introduce a significant amount of overhead to
the network. Not every node in the network needs to be ECN-capable.
Only those nodes located at congestion points need the capability.
At the nodes, ECN metering and marking is quick. There is
practically no real-time hit to the routing. An ECN node does not
maintain flow state and does not add delay with any intricate policy
decisions. Its impact on the network is very low.
The remainder of this memo provides two high-level examples depicting
unidirectional ECN-based probing for admission control, plus a
section describing how the same unidirectional probing can be used
twice to provide bidirectional probing. It also provides a single
high-level example depicting preemption. While the examples provided
are protocol-agnostic, general recommendations are provided as to how
the payload format defined in [2] should be used in the context of
admission control. No protocol-specific signaling is defined or
suggested herein to show how to use the payload while admitting a new
session.
This document replaces a prior draft, "Admission Control Use Case for
Real-time ECN" [5].
Alexander, et al. Expires January 12, 2006 [Page 4]
Internet-Draft Real-time ECN Use Cases July 2005
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [9] and
indicate requirement levels for compliant implementations.
Alexander, et al. Expires January 12, 2006 [Page 5]
Internet-Draft Real-time ECN Use Cases July 2005
3. Admission Control
Admission control can use a probing mechanism to determine whether
there is available bandwidth for a session. The endpoints of a
session perform this probing during session setup, having first
delayed session establishment. Depending upon the results of the
probing mechanism, the session will be either admitted or denied.
This decision can be made within an endpoint, or by a session server.
3.1 Probing Mechanism
The probing mechanism makes use of [1] and [2]. The mechanism is
unidirectional, but bidirectional probing is possible using two
unidirectional probes. In either case, probing is end-to-end.
3.2 Delaying Session Establishment
Session establishment should be delayed during the admission control
process, at a minimum to avoid indicating the new session to the
users prematurely, before an admission decision has been made. For
SIP, preconditions can accomplish this as described in "A Congestion
Status Precondition for the Session Initiation Protocol (SIP)" [3].
3.3 Usage Examples
Two usage examples are provided. These cover use of the RTP payload
format in [2] with unidirectional probing, both with and without
detection of Cheaters along the media path. A third section
describes how bidirectional probing is accomplished. The terminology
used is defined in [2].
All examples presume that probing starts at a point during session
setup when the Receiver endpoint addressing information is known by
the Sender, and the dynamic payload type used for the packets
carrying the payload has been determined. 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.
All examples list the relevant field contents where necessary. In a
real implementation, it is recommended that the payload be secured.
In order to ensure there is no confusion between different versions
of the referenced drafts, the following ECN bit definitions are used
in the four examples:
Alexander, et al. Expires January 12, 2006 [Page 6]
Internet-Draft Real-time ECN Use Cases July 2005
00 Not ECN-capable
10 ECN-capable, with no congestion experienced
11 ECN-capable, with congestion experienced at the first level
01 ECN-capable, with congestion experienced at the second level
3.3.1 Unidirectional Probing without Cheater Detection
A unidirectional probing mechanism without cheater detection is the
simplest possible use of the payload format defined in [2]. The
Version field MUST be set appropriately, i.e., for this memo, to
zero. The remaining fields SHOULD be set to zero. If the session
for which admission control is being performed is bidirectional, then
two of these unidirectional probes can be used, one in each
direction.
(1) (3)
+------+ +----------+ +------+
| | | | | |
| EP A | ----> | Router A | ----> + EP B | (5)
| | | | | |
+------+ +----------+ +------+
(2) (4)
Figure 1: Unidirectional Probing without Cheater Detection
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.
IP Header:
DSCP: <specific to application media>
ECN: 10
RTP Header:
Payload Type: <dynamically selected>
ECN Probe Payload:
Version: 0000
ECN: 00
IRSN: 0000 0000 0000 0000
Reserved: 00 0000 0000
Alexander, et al. Expires January 12, 2006 [Page 7]
Internet-Draft Real-time ECN Use Cases July 2005
2. Router A receives the Probe Packet, and applies to it the methods
described in [1] for real-time inelastic traffic.
3. Router A re-marks the ECN field in the IP header of the Probe
Packet as described in [1], then forwards the packet.
IP Header:
DSCP: <specific to application media>
ECN: <updated according to measured
bandwidth: ReqECN>
RTP Header:
Payload Type: <dynamically selected>
ECN Probe Payload:
Version: 0000
ECN: 00
IRSN: 0000 0000 0000 0000
Reserved: 00 0000 0000
4. EP B receives the Probe Packet. The ECN value, ReqECN, in the IP
header indicates the highest level of congestion on the path
towards EP B.
IP Header:
DSCP: <specific to application media>
ECN: <ReqECN: value indicating highest congestion
level on path towards EP B>
RTP Header:
Payload Type: <dynamically selected>
ECN Probe Payload:
Version: 0000
ECN: 00
IRSN: 0000 0000 0000 0000
Reserved: 00 0000 0000
5. EP B inspects the ECN value, ReqECN, in the IP header, then knows
the highest level of congestion on the path towards EP B. Based
on this, EP B can determine whether the session should be
admitted.
Alexander, et al. Expires January 12, 2006 [Page 8]
Internet-Draft Real-time ECN Use Cases July 2005
3.3.2 Unidirectional Probing with Cheater Detection
A unidirectional probing mechanism with cheater detection differs
from the first example in two respects. First, the ECN field in the
Probe Packet contains the ECN value set in the ECN field in the IP
header. Second, the IRSN field contains the initial RTP sequence
number selected randomly by EP A for the associated RTP media stream.
This may be used by the endpoints for cheater detection after the
real media exchange begins. Third, additional processing in EP B is
necessary to determine if there are Cheaters present on the path
towards EP B. In order to perform Cheater detection, more than one
Probe Packet must be sent, each with different ECN values in the IP
header, as described in [1]. As with the first example, if the
session for which admission control is being performed is
bidirectional, then two of these unidirectional probes can be used,
one in each direction.
(1) (3)
+------+ +----------+ +------+
| | | | | |
| EP A | ----> | Router A | ----> + EP B | (5)
| | | | | |
+------+ +----------+ +------+
(2) (4)
Figure 5: Unidirectional Probing without Cheater Detection
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. At least
three Probe Packets are sent. A random ordering of the three ECN
value 01, 10, and 11 is chosen, and these values are used in
sequential Probe Packets as the ECN value in the IP header and
the ECN field in the ECN Probe Payload. Refer to [1] for
additional details. At least three Probe Packets are needed so
that three sequential packets are received by the Receiver in
order to determine the actual marking from the routers along the
network path.
Alexander, et al. Expires January 12, 2006 [Page 9]
Internet-Draft Real-time ECN Use Cases July 2005
IP Header:
DSCP: <specific to application media>
ECN: <01, 10, or 11>
RTP Header:
Payload Type: <dynamically selected>
ECN Probe Payload:
Version: 0000
ECN: <ECN value used in IP header of original
Probe Packet>
IRSN: <Initial sequence number value randomly
selected by EP A>
Reserved: 00 0000 0000
2. Router A receives the Probe Packet, and applies to it the methods
described in [1] for real-time inelastic traffic.
3. Router A re-marks the ECN field in the IP header of the Probe
Packet as described in [1], then forwards the packet.
IP Header:
DSCP: <specific to application media>
ECN: <updated according to measured rate: ReqECN>
RTP Header:
Payload Type: <dynamically selected>
ECN Probe Payload:
Version: 0000
ECN: <ECN value used in IP header of original
Probe Packet>
IRSN: <Initial sequence number value randomly
selected by EP A>
Reserved: 00 0000 0000
4. EP B receives the Probe Packet. EP B tracks the ECN value,
ReqECN, from the IP header, and the ECN value from the ECN Probe
Payload until it receives at least three sequential Probe
Packets.
Alexander, et al. Expires January 12, 2006 [Page 10]
Internet-Draft Real-time ECN Use Cases July 2005
IP Header:
DSCP: <specific to application media>
ECN: <ReqECN: value indicating highest congestion
marking on path towards EP B>
RTP Header:
Payload Type: <dynamically selected>
ECN Probe Payload:
Version: 0000
ECN: <ECN value used in IP header of original
Probe Packet>
IRSN: <Initial sequence number value randomly
selected by EP A>
Reserved: 00 0000 0000
5. Once EP B has received three sequential Probe Packets, it can
follow the steps described in [1] to both detect if Cheaters are
present on the path towards EP B, and to filter out the highest
actual level of congestion on path towards EP B. The decision to
admit is made based on whether Cheaters are present and the level
of congestion indicated by the ECN markings.
3.3.3 Bidirectional Mechanisms
As described in each of the examples, bidirectional probing can be
accomplished by utilizing two unidirectional probes, one in each
direction. As it is simply a combination of two unidirectional, it
is not explicitly depicted here.
Alexander, et al. Expires January 12, 2006 [Page 11]
Internet-Draft Real-time ECN Use Cases July 2005
4. Preemption
The Real-time ECN mechanism defined in [1] can be used to provide
preemption capabilities. As with the unidirectional probe streams
described in the context of admission control earlier, endpoints can
similarly monitor the ECN value of RTP media packets and react
accordingly to provide preemption. If the first or second threshold
levels are exceeded, as indicated by the ECN value of the media
packets, local policy may dictate preemption as a required action to
keep bandwidth usage within engineered limits.
4.1 Usage Example
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 a local policy dictating that
preemption occurs when the second 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 9: 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 ECN 10. Refer to [1] for additional
details.
IP Header:
DSCP: <specific to application media>
ECN: 10
RTP Header:
Payload Type: <specific to application media>
2. Router A receives the RTP media packets, and applies to them the
methods described in [1] for real-time inelastic traffic.
Alexander, et al. Expires January 12, 2006 [Page 12]
Internet-Draft Real-time ECN Use Cases July 2005
3. Router A re-marks the ECN field in the IP header of the RTP media
packets as described in [1], then forwards the packet. For the
purposes of this example, it is presumed that bandwidth exists
such that Router A marks ECN 01 to indicate that the second level
of congestion has been exceeded.
IP Header:
DSCP: <specific to application media>
ECN: 01
RTP Header:
Payload Type: <specific to application media>
4. EP B receives the RTP media packets. EP B monitors the ECN value
of RTP media packets, and upon receiving packets marked with ECN
01 to indicate that the second level of congestion has been
exceeded somewhere along the path in the network, it follows
local policy to initiate preemption.
IP Header:
DSCP: <specific to application media>
ECN: 01
RTP Header:
Payload Type: <specific to application media>
5. The specific actions taken to carry out preemption may vary, but
some general guidelines will be specified below.
4.2 Preemption Guidelines
The specific actions taken to carry out preemption may vary, but some
general guidelines can be specified. Because the marking mechanism
described in [1] functions on all packets with the appropriate DSCP
code point, versus only on packets for an individual media flow,
there needs to be a mechanism in place that can control the rate and
number of sessions that are preempted. In other words, allowing
preemption to be performed immediately and directly within an
endpoint that detects a preempting congestion level in the network
would likely result in many more sessions being preempted than is
necessary to bring bandwidth levels back under the preempting
congestion level. This is due to the likelihood that more than one
endpoint will receive indication of the preemption congestion level
via ECN markings on their respective RTP media packets. It is
Alexander, et al. Expires January 12, 2006 [Page 13]
Internet-Draft Real-time ECN Use Cases July 2005
envisioned that when an endpoint detects this preempting congestion
level, it will send an indication to a preempting device which will
perform the actual preemption actions. In SIP, this indication would
take the form of an event package, and the preempting device would be
a back-to-back user agent (B2BUA).
Given this description, two things need to be considered. First, the
indications sent from the endpoints when the preempting congestion
level is detected need to be throttled among all the endpoints that
detect the preempting congtestion level. This will reduce the number
of indications sent at roughly the same time, and will allow the
preempting device to more easily manage their arrival. To accomplish
this, local policy could specify that endpoints would send these
indications only after a delay, selected randomly by the individual
endpoints from a range of a zero to ten seconds.
Second, to further ensure that no more preemptions occur than are
necessary, the preempting device needs to pace the preemption rate,
allowing a preemption and the resulting session termination time to
propagate through the network. This can be accomplished by limiting
the rate of preemption to no less than one preemption every 500
milliseconds.
Alexander, et al. Expires January 12, 2006 [Page 14]
Internet-Draft Real-time ECN Use Cases July 2005
5. Security Considerations
Refer to [1] and [2] for security-related considerations.
Alexander, et al. Expires January 12, 2006 [Page 15]
Internet-Draft Real-time ECN Use Cases July 2005
6. IANA Considerations
There are no IANA considerations.
Alexander, et al. Expires January 12, 2006 [Page 16]
Internet-Draft Real-time ECN Use Cases July 2005
7. IAB Considerations
There are no IAB considerations.
Alexander, et al. Expires January 12, 2006 [Page 17]
Internet-Draft Real-time ECN Use Cases July 2005
8. Acknowledgements
The authors acknowledge a great many inputs, including the following:
John Rutledge, Marvin Krym, Stephen Dudley, and Kwok-Ho Chan.
Alexander, et al. Expires January 12, 2006 [Page 18]
Internet-Draft Real-time ECN Use Cases July 2005
9. References
9.1 Normative References
[1] Babiarz, J., Chan, K., and V. Firoiu, "Congestion Notification
Process for Real-Time Traffic", Internet-Draft
draft-babiarz-tsvwg-rtecn-04.txt (Work in Progress), July 2005.
[2] Alexander, C., Ed. and J. Babiarz, "RTP Payload Format for ECN
Probing", Internet-Draft
draft-alexander-rtp-payload-for-ecn-probing-01.txt (Work in
Progress), July 2005.
[3] Alexander, C., Ed. and J. Rutledge, "A Congestion Status
Precondition for the Session Initiation Protocol (SIP)",
Internet-Draft
draft-alexander-congestion-status-preconditions-00.txt (Work in
Progress), July 2005.
9.2 Informative References
[4] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001.
[5] Alexander, C., Ed., Babiarz, J., and J. Matthews, "Admission
Control Use Case for Real-time ECN", Internet-Draft
draft-alexander-rtecn-admission-control-use-case-00.txt (Work in
Progress), February 2005.
Authors' Addresses
Corey W. Alexander (editor)
Nortel
MS 08704A30
2370 Performance Drive
Richardson, TX 75082
USA
Phone: +1 972 684-8320
Email: coreya@nortel.com
Alexander, et al. Expires January 12, 2006 [Page 19]
Internet-Draft Real-time ECN Use Cases July 2005
Jozef Z. Babiarz
Nortel
MS 04331C04
3500 Carling Avenue
Nepean, Ontario K2H 8E9
Canada
Phone: +1 613 763-6098
Email: babiarz@nortel.com
Jeremy P. Matthews
Nortel
MS 08704A30
2370 Performance Drive
Richardson, TX 75082
USA
Phone: +1 972 684-0336
Email: jeremym@nortel.com
Alexander, et al. Expires January 12, 2006 [Page 20]
Internet-Draft Real-time ECN Use Cases July 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.
Alexander, et al. Expires January 12, 2006 [Page 21]
