One document matched: draft-babiarz-pcn-explicit-marking-00.txt
Network Working Group J. Babiarz
Internet-Draft X-G. Liu
Intended status: Informational K. Chan
Expires: August 27, 2007 Nortel
February 23, 2007
Explicit PCN Marking
draft-babiarz-pcn-explicit-marking-00
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 August 27, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
In this document, we propose to the PCN WG for review, discussion and
evaluation of a method for marking real-time packets to indicate that
removal (preemption) of excess real-time traffic from the network is
needed. First, we define the marking behavior in the interior node
followed with a brief description of how this marking would work in
the edge-to-edge and application-control deployment models with
simulations results for different conditions and traffic mixes.
Babiarz, et al. Expires August 27, 2007 [Page 1]
Internet-Draft Explicit PCN Marking February 2007
Then, we discuss the simulation results for voice, both constant rate
and variable rate with silence suppression, and variable rate MPEG-4
like video traffic with large and small number of flows at the
congestion point.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
1.1.1. Terminology used in this Document . . . . . . . . . . 3
2. Explicit Flow Termination Marking . . . . . . . . . . . . . . 4
2.1. Operation in Edge-to-Edge Solution . . . . . . . . . . . . 6
2.2. Operation in Application Controlled Solution . . . . . . . 6
2.3. Differences of this Approach . . . . . . . . . . . . . . . 7
2.4. Characteristics of Proposed Marking . . . . . . . . . . . 8
3. Simulation Results . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Simulation Setup for Voice Traffic . . . . . . . . . . . . 10
3.2. Large Number of Voice Flows . . . . . . . . . . . . . . . 11
3.3. Small Number of Voice Flows . . . . . . . . . . . . . . . 12
3.4. Large Number of Voice Flows with Packet Loss . . . . . . . 13
3.5. Small Number of Voice Flows with Packet Loss . . . . . . . 14
3.6. Corner Voice Cases Studied . . . . . . . . . . . . . . . . 15
3.7. Simulation Setup for Video Traffic . . . . . . . . . . . . 16
3.8. Excess Load Marking Algorithm Used in Simulation . . . . . 18
4. Security Considerations . . . . . . . . . . . . . . . . . . . 19
5. Informative References . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Babiarz, et al. Expires August 27, 2007 [Page 2]
Internet-Draft Explicit PCN Marking February 2007
1. Introduction
Pre-Congestion Notification (PCN) builds on the concepts of
[RFC3168], "The addition of Explicit Congestion Notification (ECN) to
IP". Pre-Congestion Notification is applied to real-time flows (such
as voice, video and multimedia streaming) in DiffServ-enabled
networks. The reader is referred to
[I-D.briscoe-tsvwg-cl-architecture] and [I-D.babiarz-pcn-sip-cap] for
description of how PCN enables "pre" congestion control through two
procedures, flow admission control and flow termination (preemption).
Flow admission control determines whether a new flow can be added
into the network, whereas flow termination reduces the current
traffic load by terminating selected flows.
Note this document focuses on defining a marking behavior that
explicitly indicates what *flows* (not packets or measured traffic
rate) need to be removed from the congested path.
This document provides an alternative for excess load (preemption)
marking to what is documented in [I-D.briscoe-tsvwg-cl-phb]. The
approach defined in this document explicitly marks a packet belonging
to a flow that is in excess of the configured supportable service
rate. The explicit marking of a packet is an indication that the
flow is passing through a node where congestion has been encountered.
We first discuss the metering and excess load (preemption) marking
that is performed by the PCN capable router, followed with a brief
description of action that needs to be taken in the edge nodes
(boundary or hosts) to complete the excess load reduction action.
Then we identify differences between the two approaches and explain
the benefits of this marking approach. Finally we provide simulation
results with explanation for the explicit excess load marking
approach.
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 [RFC2119].
1.1.1. Terminology used in this Document
Here we provide a brief definition of the terminology used in this
document as it applies to the PCN work.
o PCN - Pre-Congestion Notification is a method for detecting the
onset of congestion (before any packets are significantly queued
or lost) and signalling to the edge nodes or endpoints via packet
marking of the IP header. This method is applicable to real-time
Babiarz, et al. Expires August 27, 2007 [Page 3]
Internet-Draft Explicit PCN Marking February 2007
inelastic traffic, e.g., voice. The marking of bits in the IP
header will need to be standardized.
o ECN Field - Refers to the use of the standardized two bit field in
the IP header that is used for signalling Explicit Congestion
Notification [RFC3168]. In the PCN framework the ECN field maybe
reused to signal two levels of Pre-Congestion Notification Marking
[I-D.briscoe-tsvwg-cl-phb].
o Admissible Rate - A bandwidth or resource threshold configured in
network elements that when crossed marking of packets occurs to
indicate that additional flow/session should not be admitted on to
that path. In Pre-Congestion Notification Marking
[I-D.briscoe-tsvwg-cl-phb] this is called the "configured-
admission-rate".
o Supportable Rate - A bandwidth or resource threshold configured in
network elements that when crossed marking of packets occurs to
indicate that on-path traffic has exceeded the configured service
level. Normally, this would be before any significant queuing or
packet loss occurs for traffic being forwarded by this service
class. In Pre-Congestion Notification Marking
[I-D.briscoe-tsvwg-cl-phb] this is called the "configured-
preemption-rate".
o Service class - By service class we mean a grouping of packets
belonging to one or more applications or services that generated
traffic with similar characteristics and requiring similar QoS
treatment. See [RFC4594] for details.
o Endpoint - Application controlled media device such as a phone, a
media gateway or a multi media terminal or host.
o Admission Control - It is the action of blocking the adding of new
flows or sessions in to the network in the attempt to prevent
overload condition.
o Preemption - During an overload condition, it is the action of
removing excess traffic by randomly terminating flows or sessions.
Some solution may have additional policies where termination of
flows or sessions is performed in some controlled hierarchical
fashion.
2. Explicit Flow Termination Marking
We propose a simple excess load (preemption) marking approach for the
PCN mechanism that explicitly identifies the real-time flow that is
Babiarz, et al. Expires August 27, 2007 [Page 4]
Internet-Draft Explicit PCN Marking February 2007
passing through an interior node (router) experiencing congestion.
The metering and marking procedure for excess load (preemption) is
described using token bucket approach, with octets being the unit of
the token bucket size and its operations. The defined behavior can
also be realized using virtual queue approach.
o PCN capable routers perform metering of real-time packets that are
identified as being PCN capable and mark packets when token bucket
runs out of tokens.
o Tokens are added to the token bucket at "Supportable Rate" (also
called configured-preemption-rate), which is below the link rate
and the relevant service class scheduling rate.
o Tokens are removed when a real-time packet arrives; the amount
removed is the same as the number of octets in the packet.
o When the token bucket becomes empty or goes negative, the packet
is marked and "x" tokens are added to the token bucket. The
general guideline is that "x" should be several times larger than
the octet size of packets being serviced. The amount of tokens
added, "x", controls the aggressiveness of marking. The lager the
value of "x", the amount of tokens added to the token bucket each
time a packet is marked, the longer before the next packet is
marked assuming that current traffic load is greater than
Supportable Rate. When traffic level drops below Supportable Rate
no packets are marked.
In summary, a packet is marked every "x" octets of traffic that
exceeds the Supportable Rate. In Figure 1 below the metering and
marking procedure is visualized.
+-----------------------------+ Yes
Packet ------>| Are there sufficient tokens |-------> Forward
arrives | in the token bucket? | packet
+-----------------------------+
|
| No
|
\/
+---------------------------+
| Mark packet and add "x" |
| tokens to token bucket |-------> Forward
+---------------------------+ packet
Figure 1: Router Processing to Support Excess Flow Marking
Babiarz, et al. Expires August 27, 2007 [Page 5]
Internet-Draft Explicit PCN Marking February 2007
If traffic is sustained at a level greater than the Supportable Rate,
then a packet is excess load (preemption) marked every "x" octets of
traffic exceeding the Supportable Rate. However, a short burst of
traffic that is greater than the Supportable Rate (measured over the
burst) may not trigger any excess load (preemption) marking if the
burst is sufficiently short that the token bucket doesn't run out of
tokens.
2.1. Operation in Edge-to-Edge Solution
The explicit excess load (preemption) marking approach can be used in
the edge-to-edge framework described in
[I-D.briscoe-tsvwg-cl-architecture], in the following way. First, as
real-time packets travel across the edge-to-edge CL- region, PCN
capable routers that encounter onset of congestion mark packets, as
per algorithm described earlier. When the egress gateway of the
region receives a excess load (preemption) marked packet, it sends a
message to the ingress gateway indicating the IP source/destination
address and port number of the market packet. The ingress gateway
invokes the defined excess load (preemption) process for the
identified flow. Under extreme overload conditions (link failures)
where large number of flows may require termination, the egress
gateway may collect IP source/destination address and port number of
excess load (preemption) marked packet over a period of time and then
sent all the information to the ingress gateway in one message. This
approach reduces the number of messages sent between the egress and
ingress gateways.
Also if needed, the egress gateway of the region may count excess
load (preemption) marked packet that it receives per ingress-egress
aggregate, and calculate the amount of traffic that needs to be
removed for each ingress-egress aggregate (number of excess load
(preemption) marked packet received multiplied by "x" octets used in
routers for excess load marking). The egress gateway signals to
ingress gateway indicating the amount of traffic that needs to be
removed over the measurement time interval.
The excess load reduction process repeats until all the excess
traffic flowing through the congestion point is removed.
2.2. Operation in Application Controlled Solution
The explicit excess load (preemption) marking approach can also be
used in the application-control framework described in
[I-D.babiarz-pcn-sip-cap] in the following way. As real-time packets
travel across the network, PCN capable routers that encounter onset
of congestion mark packets, as per algorithm described earlier.
Babiarz, et al. Expires August 27, 2007 [Page 6]
Internet-Draft Explicit PCN Marking February 2007
When the endpoint (egress host) receives an excess load (preemption)
marked packet, it invokes the defined excess load reduction
(preemption) policy for that flow. Normally the endpoint verifies
that the excess load (preemption) marked packet belongs to a flow
that can be terminated. If the policy allows the flow to be
terminated, the egress host initiates the flow termination procedure
by signalling via application control signalling e.g., SIP to the
ingress host (flow origination) to terminate the flow or stop sending
packets.
2.3. Differences of this Approach
The differences between explicit marking approach described by this
document versus what is in [I-D.briscoe-tsvwg-cl-phb] the "marking
draft" for excess load (preemption) are:
In the "marking draft" any packet that exceeds the supportable rate
is marked, where with the explicit marking approach only a packet
every "x" octets of excess traffic is marked. The marking approach
that is proposed in this draft is similar to what is used in
[RFC3168], where a packet is marked based on average queue length
exceeding a configured threshold, except that our approach does not
use average queue length.
The packet marking in [RFC3168] indicates for TCP application that
source needs to halve its effective rate whereas with PCN, the
feedback indicates excess load reduction through reducing the sending
rate or through termination of that real-time flow. With PCN, flow
termination action is more aggressive against the selected flows but
the gain is that it enables the full QoS of the remaining flows to be
preserved.
Currently with the "marking draft" approach, when the egress gateway
of the region detects a Pre-emption Marked packet, it measures the
rate of real-time traffic *excluding* any packets that are Pre-
emption Marked. Hence it measures the amount of traffic that the
network can actually support safely (which is term Sustainable-
Aggregate-Rate). The measurement is made for traffic from a
particular ingress gateway, and then reported to that ingress
gateway. When it receives this message, the ingress gateway measures
the ingress-aggregate-rate of real-time traffic that is being sent
towards the particular egress gateway. If this measured ingress-
aggregate-rate exceeds the Sustainable-Aggregate-Rate, then the
ingress gateway pre-empts sufficient number of real-time flow(s) to
bring down the ingress-aggregate-rate to (approximately) the
Sustainable-Aggregate-Rate.
It should be pointed out that a deployment solution wishing to
Babiarz, et al. Expires August 27, 2007 [Page 7]
Internet-Draft Explicit PCN Marking February 2007
compute the excess rate using the explicit excess load marked where a
marked packet represents "x" bytes of excess traffic, can do so if
"x" is known.
2.4. Characteristics of Proposed Marking
Here we highlight some of the characteristics and benefits that
explicit excess load marking approach has:
1. Works with Equal Cost Multipath (ECMP) routing in the network
(without additional complexity in the gateways). With the
explicit excess load marking approach, a marked packet belongs
to a flow that was routed through congested router.
2. Works reasonable well in presence of low and high packet loss.
(See simulation results details). Packet loss only intrudes
small delta delay for excess load reduction to be completed. If
a marked packet is lost and the overload is still presented, the
congested router will mark another packet.
3. This approach works well with small and large number of flows,
constant bit rate, variable rate (on-off voice) and variable
rate MPEG-4 like traffic. To date simulation results [SIM-07]
indicate that this marking approach is not that sensitive to
different flow counts and traffic characteristics.
4. Works reasonably well in presence of multiple congestion points
in the path. The explicit excess load marking approach has an
exponential decay marking property, therefore marking frequency
decreases as the traffic load is decreases and it approaches the
supportable rate. In other words, flow termination slows down
as the excess load approaches that supportable rate traffic
level.
5. With mixed traffic of different rates and packet sizes, the
explicit excess load marking approach marks high BW flows more
aggressively. Therefore after link failure condition the result
is that more flows as total can be supported with the aggregate
traffic being below the supportable rate.
6. Another benefit of explicit excess load marking approach and its
exponential decay property is that it works well with
bidirectional flows. When a bidirectional flows is terminated,
excess load is removed from the congested router(s), therefore
reducing the frequency of marking. This marking approach works
with unidirectional and bidirectional flows (without additional
complexity in the gateways).
Babiarz, et al. Expires August 27, 2007 [Page 8]
Internet-Draft Explicit PCN Marking February 2007
7. Works well over a wide range of round-trip times (RTTs) that are
reasonable for real-time traffic. See [SIM-07] simulation
results with different RTTs. The "x" value should be configured
so that it is greater than the number of octets transmitted by a
flow in RTT. For aggregation of voice flows that have various
rates, using the mean rate should produce reasonable results.
More work is required before any guidelines for "x" can be
stated.
8. Stable behavior under most operating conditions. Simulations
show very good accuracy both for constant rate and variable rate
traffic with small and large number of overload conditions.
9. This approach works well in gateway-to-gateway and host-to-host
deployment models.
10. The explicit excess load marking behavior is friendly to
behavior in [RFC3168] and should PCN flow encounter a router
that performs [RFC3168] marking, it would provide some
protection against congestion. A packet belonging to a PCN flow
that is CE marked would invoke the excess load reduction
procedure for that flow.
11. If the egress edge node (gateway) reports which flows that need
to be removed (preempted) versus bandwidth, than any reasonable
value for "x" can be used. The value for "x" and the algorithm
do not need to be standardized, but only the metering and
marking behavior. Different algorithms may be used to obtain
the described metering and marking behavior.
3. Simulation Results
In this section we will provide explanation of our simulation setup
and results. Detailed explanations and graphed results from the
simulations can be viewed in [SIM-07]
(http://standards.nortel.com/pcn/Simulation_EPCN.pdf). In
Section 3.1 we provide a brief explanation of the simulations setup
that was used to test flow termination of constant and variable rate
(silence superseded) voice traffic, Section 3.2 to Section 3.6
discusses results of the voice-related simulation, and Section 3.7
briefly discusses the preliminary video-related simulation results.
All the simulations were performed using the token bucket algorithm
documented in Section 3.8.
Note: Since the terminology for this work is evolving, we provide a
brief explanation of terms used in the simulation results.
Babiarz, et al. Expires August 27, 2007 [Page 9]
Internet-Draft Explicit PCN Marking February 2007
Preemption = flow termination
Preemption Threshold = Supportable Rate
Preemption Level = traffic above this rate is marked as excess.
Same as Supportable Rate.
PM flag = explicit marking of packet to indicated excess load. In
the simulation, the router sets both ECN bits to "11" in the IP
header.
Preemption Time = RTT + processing time of termination of a flow.
This is how long it takes before a marked flow stops sending
packets.
pcn_px = represents marking a packet every "x" bytes of excess
rate.
3.1. Simulation Setup for Voice Traffic
Our simulations were done using OPNET see simulation results at
[SIM-07] (http://standards.nortel.com/pcn/Simulation_EPCN.pdf).
Pages 2 through 6 [SIM-07] provide details of the simulation setup:
o Pages 2 and 3 [SIM-07] describe simulation setup. The source
traffic generator (SRC) block produces flows and each flow has a
flow ID, with each flow sending packets at its codec configured
rate. Start time of packets between flows is asynchronous,
representing different sources. Codec mix and number of flows
enabled is programmable.
o Pages 4 and 5 [SIM-07] describe characteristics of the 4 voice
codecs used in the simulations and explanation of two methods used
to simulate fail in the network to cause flow termination
(preemption) to be invoked. During a failure, 100% of additional
traffic is introduced on to the path (router that is performing
metering and marking of packets). The additional load was
introduced using two models. The first failure emulates a fast
reroute, were all traffic is switched instantaneously. The second
failure on the graph represents a condition where reroutes takes
some time. We configured the simulation so that 80% of new
traffic is added within 1 second and the remaining 20% within
additional 5 seconds. Our simulations generated a traffic mix
ratio of up to 15 to 1 for voice. The highest sending rate is 15
times the smallest.
Babiarz, et al. Expires August 27, 2007 [Page 10]
Internet-Draft Explicit PCN Marking February 2007
3.2. Large Number of Voice Flows
First we provide simulation results when there are many flows at the
congestion point (internal router), 500 to 4,250 flows depending on
codec mix used. The violet trace on the graphs shows the number of
flows that are sending packets.
o The preemption marking threshold is set to 40Mbps, so when traffic
exceeds this rate packets are marked every "x" bytes of excess
rate.
o The forwarding rate is configures such that there is no packet
loss in these simulations. See Section 3.4 for results with
packet loss.
o We simulated with pcn_px = 2,064, 4,064 and 8,064 bytes sizes as
well with preemption time set to 50ms, 200ms and 800ms to see the
impact these parameters had on rate and behavior of flow
termination (preemption). See page 7 [SIM-07]
(http://standards.nortel.com/pcn/Simulation_EPCN.pdf) for more
details.
Pages 8 through 20 [SIM-07] show the simulation results. The left
side of graph shows aggregate bandwidth. The bottom of the graph
indicates time scale in 0.05 seconds resolution or 3 seconds between
vertical dashed lines. The right side of the graph shows number of
active flows (flows that are sending packets). The violet trace
shows number of active flows. The orange trace shows aggregated
transmitted rate that egresses the congested router. The blue trace
shows aggregated transmitted rate that is flowing into the router.
Note: The blue trace is only visible when there is packet loss. In
simulations where there is no packet loss the orange trace over-
writes the blue.
Observations for large (500 - 4,250) number of flows with no packet
loss:
o The shorter the preemption time, the faster overload condition is
restored back to supportable rate.
o The smaller the pcn_px value (packet marked every "x" bytes of
excess traffic), the faster the overload condition is restored
back to supportable rate.
o Packets where marked and flows where terminated when ever excess
rate exceeded by pcn_px bytes the supportable rate.
Babiarz, et al. Expires August 27, 2007 [Page 11]
Internet-Draft Explicit PCN Marking February 2007
o The marking and flow termination (preemption) produced exponential
decay behavior. When excess rate was high meaning many flows
needed to be terminated, the marking was frequent but as excess
load decreased so did the marking and flow termination frequency.
Produce a stable behavior for both constant rate and silence
supersede voice traffic.
o Flow termination (preemption) of traffic generated by constant bit
rate codecs is faster than when silence suppression was used since
the model that we used to generate VBR voice had an exponential
distribution that generated mean on period of 1 second and mean
off period of 1.59 seconds (40 on / 60 off).
o With VBR voice, during reroute condition some active flows were in
silence mode (not sending any packets during off period that had
exponential distribution) as can be observed by rounded peak for
active flows during link failure. Therefore the total load was
not presented instantaneously.
o The defined token bucket measurement method, marked higher rate
flows more aggressively then lower rate flows. See page 15
[SIM-07] for details. This can also be observed that with mixed
codec the number of flows that can be supported after link fail is
higher then before.
3.3. Small Number of Voice Flows
Here we provide simulation results when there are small numbers of
flows at the congestion point (internal router), 10 to 80 depending
on codec mix used. The violet trace on the graphs shows the number
of flows that are sending packets.
o The preemption marking threshold is set to 800Kbps, so when
traffic exceeds this rate packets are marked every "x" bytes of
excess rate.
o The forwarding rate is configures such that there is no packet
loss in these simulations. See Section 3.5 for results with
packet loss.
o We simulated with pcn_px = 2,064 and 8,064 bytes sizes as well
with preemption time set to 50ms, 200ms and 800ms to see the
impact these parameters had on rate and behavior of flow
termination (preemption). See page 21 [SIM-07] for more details.
Pages 22 through 28 [SIM-07] show the simulation results when there
are a low number of flows at the congested router.
Babiarz, et al. Expires August 27, 2007 [Page 12]
Internet-Draft Explicit PCN Marking February 2007
Observations for small (10 - 80) number of flows with no packet loss:
o The shorter the preemption time, the faster overload condition is
restored back to supportable rate.
o The smaller pcn_px value (packet marked every "x" bytes of excess
traffic), the faster the overload condition is restored back to
supportable rate.
o Packets where marked and flows where terminated when ever excess
rate exceeded by pcn_px bytes the supportable rate.
o When excess rate was high meaning many flows needed to be
terminated, the marking was frequent but as excess load decreased
so did the marking and flow termination frequency. Produce a
stable behavior for both constant rate and silence supersede voice
traffic.
o Flow termination (preemption) of traffic generated by constant bit
rate codecs is faster than when silence suppression was used since
the model that we used to generate VBR voice had an exponential
distribution that generated "mean on period" of 1 second and "mean
off period" of 1.59 seconds (40 on / 60 off).
o With VBR voice, during reroute condition some active flows were in
silence mode (not sending any packets during off period that had
exponential distribution) as can be observed by rounded peak for
active flows during link failure. Therefore the total load was
not presented instantaneously.
o The defined token bucket measurement method, marked higher rate
flows more aggressively then lower rate flows. See [SIM-07] page
28 for details. This can also be observed that with mixed codec
the number of flows that can be supported after link fail is
higher then before.
The explicit marking behavior produced similar results when the
number of constant rate and variable rate (silence suppressed) voice
flows was small or high. These simulation results would indicated
that for voice traffic this marking approach works independently of
number of flows at the congestion point.
3.4. Large Number of Voice Flows with Packet Loss
Now we analyze the impact of packet loss has on the explicate marking
approach when there are many flows at the congestion point (internal
router), 500 to 4,250 depending on codec mix used. The violet trace
on the graphs shows the number of flows that are sending packets.
Babiarz, et al. Expires August 27, 2007 [Page 13]
Internet-Draft Explicit PCN Marking February 2007
o The preemption marking threshold is set to 40Mbps, so when traffic
exceeds this rate packets are marked every "x" bytes of excess
rate.
o The forwarding rate is configures to 48Mbps (introducing up to 40%
packet loss) or 40Mbps (introducing up to 50% packet loss). 50%
packet loss occurs when forwarding rate of service class =
supportable rate (or preemption level), current traffic level is
at supportable rate and 100% of additional traffic is added to
simulate traffic being switch or rerouted due to failure in the
network.
o We simulated with pcn_px = 8,064 bytes sizes as well with
preemption time set to 200ms and 800ms to see the impact these
parameters had on rate and behavior of flow termination
(preemption). See page 29 [SIM-07] for more details.
Pages 30 through 38 [SIM-07] show the simulation results.
Observations for large (500 - 4,250) number of flows with up to 40%
and 50% packet loss:
o As can be observed the flow termination behaved is similar to when
there was no packet loss, except that when there is packet loss
the time it takes to terminate sufficient number of flows to the
supportable rate (preemption threshold) takes longer.
o We also observed that over preemption can occur see page 31
[SIM-07] for CBR (G.711 at 20ms) only traffic when pcn_px value of
8.064 bytes is used with preemption time of 800ms. Increasing
pcn_px or decreasing preemption time will remove the over
preemption condition for this traffic mix..
o This packet marking and flow termination approach works well even
under high packet loss conditions.
3.5. Small Number of Voice Flows with Packet Loss
Now we analyze the impact of packet loss has on the explicate marking
approach when there are a small number of flows at the congestion
point (internal router), 10 to 80 depending on codec mix used. The
violet trace on the graphs shows the number of flows that are sending
packets.
o The preemption marking threshold is set to 800Kbps, so when
traffic exceeds this rate packets are marked every "x" bytes of
excess rate.
Babiarz, et al. Expires August 27, 2007 [Page 14]
Internet-Draft Explicit PCN Marking February 2007
o The forwarding rate is configures 960Kbps (introducing up to 40%
packet loss) and 800Kbps (introducing up to 50% packet loss). 50%
packet loss occurs when forwarding rate of service class =
supportable rate (or preemption level), current traffic level is
at supportable rate and 100% of additional traffic is added to
simulate traffic being switch or rerouted due to failure in the
network.
o We simulated with pcn_px = 8,064 bytes sizes and preemption time
set to 800ms to see the impact these parameters had on rate and
behavior of flow termination (preemption). See page 39 [SIM-07]
for more details.
Pages 40 through 43 [SIM-07] show the simulation results when there
are a low number of flows with up to 40% and 50% packet loss at the
congested router.
Observations for small (10 - 80) number of flows with up to 40% and
50% packet loss:
o As can be observed the flow termination behaved is similar to when
there was no packet loss, except that when there is packet loss
the time it takes to terminate sufficient number of flows to the
supportable rate (preemption threshold) takes longer.
o We also observed that over preemption can occur see page 40
[SIM-07] for CBR (G.711 at 20ms) only traffic when pcn_px value of
8.064 bytes is used with preemption time of 800ms. Increasing
pcn_px or decreasing preemption time will remove the over
preemption condition for this traffic mix..
o This packet marking and flow termination approach works well even
under high packet loss conditions.
3.6. Corner Voice Cases Studied
Now we want to look at some corner cases where this method starts to
breakdown. We looked at the configuration of parameters that caused
the following conditions:
o Over termination (preemption) of flows. This condition occurs
when pcn_px parameter is too small for the time that it takes to
terminate a flow (total preemption time). This condition is
noticeable when there is CBR only traffic flowing through the
router. Increasing pcn_px therefore slowing down flow termination
can eliminate any possibility of over terminating flows. This is
a parameter that can be configured by the network administrator.
See simulation results [SIM-07], pages 45-48 of examples of this
Babiarz, et al. Expires August 27, 2007 [Page 15]
Internet-Draft Explicit PCN Marking February 2007
condition.
o Synchronization of packet marking. This conditional occurs for
CBR fixed packet size traffic at metering point and when pcn_px is
an even multiple of payload packet size, e.g., packet size = 200
bytes and pcn_px = 2,000 bytes. Page 49 [SIM-07] shows that
synchronization of marking condition. However, this undesirable
behavior does not break the mechanism, but it takes longer to
terminate flows.
o Preemption takes to long. This condition can be created if pcn_px
is configured to me x times larger than need. Page 50 [SIM-07]
shows the impact of setting pcn_px to 2x bigger then needed.
3.7. Simulation Setup for Video Traffic
In this section, we briefly discuss the preliminary video-related
simulation results; for details, see pages 51-65 [SIM-07]
(http://standards.nortel.com/pcn/Simulation_EPCN.pdf).
The video simulation is based on the same token bucket algorithm as
the voice simulation discussed in the previous sections. The main
differences between our video simulation and voice simulation are the
traffic source model and the selection of the pcn_tb and pcn_px
values.
In the video simulation, the traffic source model is based on the
video model proposed by [Maglaris-88], which has the following
properties:
o a constant frame rate of F frames per sec (a fixed time interval
between frames),
o a constant number of P pixels per frame,
o a random number of bits per frame calculated using the number of
compressed bits per pixel in the n-th frame modeled by a first-
order autoregressive Markov process.
In our simulation, the packetization of the bits is modeled as
follows,
o the MTU of the video packet is 1356 bytes, including 40 bytes of
the IP header;
o only the positive bits calculated from the above video model can
generate packets;
Babiarz, et al. Expires August 27, 2007 [Page 16]
Internet-Draft Explicit PCN Marking February 2007
o the first 1316*8 bits of the total bits of a frame is packed into
the first MTU-sized packet; the second 1316*8 bits is packed into
the second MTU-sized packet; this is done until all the bits are
packed; the last packet likely smaller than MTU contains all the
remainder bits plus the 40-byte IP header;
o the packets generated from a frame are sent to the network one by
one at the end of the time interval of 1/F seconds with a per-
packet serialization time of (packet size / link speed);
o when a source starts, the first frame is generated at a random
time point in the 1/F-sec time interval.
In our current video simulation, only a single type of video source
is used for generating video flows, which has an expected average
data rate of 400Kbps. The following flow settings are considered,
similarly to those voice settings, where T is relative to the end of
the simulation warm-up period,
o Small sources with preemption threshold BW = 4Mpbs: start with 8
flows, add 10 flows at T = 3 sec; add another 10 flows at T = 24
sec;
o Medium sources with preemption threshold BW = 40Mpbs: start with
80 flows, add 100 flows at T = 3 sec; add another 100 flows at T =
24 sec;
o Large sources with preemption threshold BW = 200Mpbs: start with
400 flows, add 500 flows at T = 3 sec; add another 500 flows at T
= 24.
The simulation was run with these flow settings for three RTT (flow
termination) times of 50, 200, and 800ms and four token bucket-
marking interval combinations,
o (pcn_tb = 400KB; pcn_px = 200KB);
o (pcn_tb = 200KB; pcn_px = 100KB);
o (pcn_tb = 300KB; pcn_px = 200KB);
o (pcn_tb = 250KB; pcn_px = 50KB).
In all the simulation runs, the forwarding rate of the router is set
as two times the preemption threshold BW, and the buffer has
unlimited space (i.e., there is no packet loss).
We have the following observations from the simulations,
Babiarz, et al. Expires August 27, 2007 [Page 17]
Internet-Draft Explicit PCN Marking February 2007
o video flow preemption is achievable and behaves similarly to what
is observed in the voice simulations;
o the tested token bucket-marking interval combinations are
similarly effective across the flow settings and RTT cases with
combination (pcn_tb = 400 KB; pcn_px = 200 KB) seemingly the most
stable;
o It is difficult to measure the over-/under-preemption error, as
offered traffic is constantly changing. However, we believe that
(pcn_tb = 400 KB; pcn_px = 200 KB) provide more consistent results
then (pcn_tb = 250 KB; pcn_px = 50 KB) parameter settings.
3.8. Excess Load Marking Algorithm Used in Simulation
Below is the pseudo code of a token bucket algorithm that was used in
our simulations for metering and marking for flow termination
(preemption) of flows. This is an example of an metering and
preemption marking function that would reside in PCN capable routers.
Configuration parameters are per DSCP:
pcn_pt = traffic rate at preemption threshold in bits per second
pcn_tb = the size of token bucket in bytes for detection that
preemption threshold is exceeded
pcn_px = the measurement of excess rate, (sets ECN=11 every "x"
bytes of excess traffic)
Definition of terms used in the algorithm:
delta_t is the time since the processing of the previous packet
for this token bucket
pktLen is the length of the packet being processed in unit of
bytes
Initialization of local variables:
tokenCountP = pcn_tb //initialize token bucket to max.
pcn_pt_B = pcn_pt / 8 //change preemption rate to bytes per second
Babiarz, et al. Expires August 27, 2007 [Page 18]
Internet-Draft Explicit PCN Marking February 2007
Preempt_Level_Metering_Marking routine, with length of current packet
as input:
Preempt_Meter ( pktLen)
{
tokenCountP = tokenCountP + (delta_t * pcn_pt_B)
//this adds tokens to token bucket
tokenCountP = Min (tokenCountP, pcn_tb)
//keeps tb from growing pass full
tokenCountP = tokenCountP - pktLen //subtracts tx bytes from bucket
if (tokenCountP < = 0) //when tb becomes empty or negative
{
Set ECN = 11 //preemption mark packet, (Set ECN bits = 11)
tokenCountP = tokenCountP + pcn_px
//add "x" tokens to token bucket
}
return
} // End of Preempt_Meter().
Figure 2
4. Security Considerations
Not applicable for this draft.
5. Informative References
[I-D.babiarz-pcn-sip-cap]
Babiarz, J., "SIP Controlled Admission and Preemption",
draft-babiarz-pcn-sip-cap-00 (work in progress),
October 2006.
[I-D.briscoe-tsvwg-cl-architecture]
Briscoe, B., "An edge-to-edge Deployment Model for Pre-
Congestion Notification: Admission Control over a
DiffServ Region", draft-briscoe-tsvwg-cl-architecture-04
(work in progress), October 2006.
[I-D.briscoe-tsvwg-cl-phb]
Briscoe, B., "Pre-Congestion Notification marking",
draft-briscoe-tsvwg-cl-phb-03 (work in progress),
October 2006.
[Maglaris-88]
Maglaris et al, "Performance Models of Statistical
Babiarz, et al. Expires August 27, 2007 [Page 19]
Internet-Draft Explicit PCN Marking February 2007
Multiplexing in Packet Video Communications, IEEE
Transactions on Communications 36, pp. 834-844", July
1988.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594,
August 2006.
[SIM-07] Liu, X-G. and J. Babiarz, "Simulation Results for Explicit
PCN Marking and Flow Termination
(http://standards.nortel.com/pcn/Simulation_EPCN.pdf)",
February 2007.
Authors' Addresses
Jozef Z. Babiarz
Nortel
3500 Carling Avenue
Ottawa, Ont. K2H 8E9
Canada
Phone: +1-613-763-6098
Email: babiarz@nortel.com
Xiao-Gao Liu
Nortel
3500 Carling Avenue
Ottawa, Ont. K2H 8E9
Canada
Phone: +1-613-763-7516
Email: xgliu@nortel.com
Babiarz, et al. Expires August 27, 2007 [Page 20]
Internet-Draft Explicit PCN Marking February 2007
Kwok Ho Chan
Nortel
600 Technology Park Drive
Billerica, MA 01821
USA
Phone: +1-978-288-8175
Email: khchan@nortel.com
Babiarz, et al. Expires August 27, 2007 [Page 21]
Internet-Draft Explicit PCN Marking February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Babiarz, et al. Expires August 27, 2007 [Page 22]
| PAFTECH AB 2003-2026 | 2026-04-23 03:37:55 |