[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                         J. Babiarz
Internet-Draft                                                  X-G. Liu
Intended status: Informational                                    Nortel
Expires: January 9, 2008                                    July 8, 2007


                      Simulations Results for 3sM
                 draft-babiarz-pcn-explicit-marking-01

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 9, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document describes the simulation setups and results for testing
   the Three State PCN Marking approach.  Simulations done to date,
   demonstrate that the three state PCN marking approach has certain
   ability to support admission control and flow termination of real-
   time application flows at the congestion point of the PCN-enabled
   network.  The real-time traffic used in the simulation covers voice
   and video traffic with large and small number of flows.




Babiarz & Liu            Expires January 9, 2008                [Page 1]


Internet-Draft         Simulations Results for 3sM             July 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology used in this Document  . . . . . . . . . . . .  4
     1.2.  Overview of Three State PCN Marking Approach . . . . . . .  5
   2.  General Description of the Simulation Setup  . . . . . . . . .  5
     2.1.  Traffic Sources  . . . . . . . . . . . . . . . . . . . . .  6
     2.2.  Multiple PCN Nodes . . . . . . . . . . . . . . . . . . . .  7
     2.3.  Traffic Control  . . . . . . . . . . . . . . . . . . . . .  8
   3.  Performance of 3sM . . . . . . . . . . . . . . . . . . . . . .  8
     3.1.  Performance of Flow Termination  . . . . . . . . . . . . .  8
       3.1.1.  Large Number of Flows in a Single Domain . . . . . . .  9
       3.1.2.  Small Number of Flows in a Single Domain . . . . . . . 11
       3.1.3.  Large Number of Flows in a Multi Domain  . . . . . . . 12
       3.1.4.  Discussion of Parameter Settings . . . . . . . . . . . 13
     3.2.  Performance of Admission Control . . . . . . . . . . . . . 14
       3.2.1.  Simulation Results for Admission Control . . . . . . . 16
   4.  Simulation Results Prior to 68th IETF  . . . . . . . . . . . . 18
     4.1.  Simulation Setup for Voice Traffic . . . . . . . . . . . . 19
     4.2.  Large Number of Voice Flows  . . . . . . . . . . . . . . . 20
     4.3.  Small Number of Voice Flows  . . . . . . . . . . . . . . . 21
     4.4.  Large Number of Voice Flows with Packet Loss . . . . . . . 23
     4.5.  Small Number of Voice Flows with Packet Loss . . . . . . . 24
     4.6.  Corner Voice Cases Studied . . . . . . . . . . . . . . . . 25
     4.7.  Simulation Setup for Video Traffic . . . . . . . . . . . . 25
     4.8.  Excess Load Marking Algorithm Used in Simulation . . . . . 27
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 28
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
   7.  Informative References . . . . . . . . . . . . . . . . . . . . 29
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
   Intellectual Property and Copyright Statements . . . . . . . . . . 31




















Babiarz & Liu            Expires January 9, 2008                [Page 2]


Internet-Draft         Simulations Results for 3sM             July 2007


1.  Introduction

   In a PCN-enabled network, each link is configured with an admissible
   rate (AR).  When the PCN traffic rate on a link exceeds its AR, the
   corresponding PCN node re-marks all PCN packets on this link with an
   "admission-stop" (AS) codepoint.  The PCN egress nodes analyze the
   packet markings, and if sufficiently many packets are AS-marked
   within an ingress-egress aggregate, signal "admission-stop" for this
   aggregate to the appropriate admission control entity to stop
   admitting flows belonging to this aggregate so as to avoid the PCN
   traffic rate to exceed AR.  When the PCN egress nodes stop receiving
   AS-marked packets, they signal "admission-continue" after some time
   to allow admitting flows from the blocked aggregate.

   Similarly, a supportable rate (SR) is configured for each link in a
   PCN-enabled network.  When the current PCN traffic rate on a link
   exceeds its SR, the corresponding PCN node re-marks some of the PCN
   packets on this link with an "excess-traffic" (ET) codepoint.  The
   PCN egress nodes pass the marking information to the appropriate flow
   termination entity (e.g. at the respective PCN ingress nodes) to
   terminate flows in order to reduce the PCN traffic rate of the SR-
   overloaded link below its SR.  The reader is referred to
   [I-D.eardley-pcn-architecture] for details.

   The purpose of this document is to evaluate the performance of the
   proposed three state PCN marking (3sM) [I-D.babiarz-pcn-3sm]
   approach.  We provide an overview of the simulations setup and the
   results of testing that were carried out.  Simulation demonstrate
   that the three state PCN marking (3sM) approach has certain ability
   to support admission control and flow termination of real-time
   application flows at the congestion point of the PCN-enabled network.
   The simulation is based on modeling the real-time traffic of voice,
   both constant bit rate and variable bit rate with silence
   suppression, and variable rate MPEG-4 like video with large and small
   number of flows.  The preliminary key findings of the simulation are:

   o  Both the AR- and SR-meters are able to be adjusted to provide the
      desired traffic control to a certain degree, i.e., limiting the
      traffic in the network within some tolerance level for the test
      cases.

   o  The setting of the two meters are usually not sensitive or can be
      set proportional to the traffic load (BW and number of flows) in
      the test cases.

   o  The effectiveness of the AR-meter and AS-marker is similar for a
      single bottleneck node and a number of bottleneck nodes. (the SR-
      meter and ET-marking has not been tested for this scenario, it is



Babiarz & Liu            Expires January 9, 2008                [Page 3]


Internet-Draft         Simulations Results for 3sM             July 2007


      on the to do list.)

   o  The precise control of mixed VBR traffic for admission control is
      difficult with small number of flows, as expected additional
      mechanism may be needed.

   o  Flow termination using the proposed SR-metering and ET-marking:

      *  Is independent of the number of flows at the congestion point
         or in an ingress-egress aggregate, works equality well on small
         and large links.

      *  Works over a large range of network RTTs.

      *  Works well with packet loss.

      *  The desired setting for "s" marking slow-down parameter can be
         determined based on a given formula.

      *  ET-marking identifies flows that are routed on overloaded
         paths, therefore when multiple paths exist in a network the
         edge nodes or explicitly informed which flows should be
         terminated.

      *  ET-marking is proportional to the level of overload, the higher
         the overload the more packets are marked.

      *  ET-marking has an exponential decay property.

1.1.  Terminology used in this Document

   Since the terminology for this work is evolving, we provide a brief
   explanation of terms used in this document and the referenced
   simulation results.

      Preemption = flow termination

      SR = Supportable Rate = Preemption Threshold

      Preemption Level = traffic above this rate is marked as excess.
      Same as Supportable Rate.

      ET-marking = 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 = round-trip-time (RTT) in the network +
      processing time of termination of a flow.  This is how long it



Babiarz & Liu            Expires January 9, 2008                [Page 4]


Internet-Draft         Simulations Results for 3sM             July 2007


      takes before a marked flow to stops sending packets.

      "s" slow-down marking factor = pcn_px = represents marking a
      packet every "x" bytes of excess rate.

      AR = Admissible Rate

      AS-marking = Admission Stop-marking = marking to indicated that
      additional new flows should be blocked.

1.2.  Overview of Three State PCN Marking Approach

   For AR metering, the proposed approach defines an AR-meter and AS-
   marker based on a token bucket (TB) with threshold marking.  The TB
   has a bucket of size TB.size which is continuously filled with tokens
   at rate TB.rate.  The AR-meter and AS-marker consider only packets
   that are not ET-marked.  When a non-ET-marked PCN packet arrives, it
   is re-marked to "AS" if the fill state of the bucket (TB.fill) in
   tokens is smaller than its size (packet.size) in bytes; otherwise,
   the fill state is reduced by packet.size tokens and if the fill state
   is then smaller than the marking threshold (TB.threshold), the packet
   is also re-marked to "AS" while if the fill state is then larger than
   or equal to the marking threshold, the packet is not re-marked.

   For SR metering, the proposed approach defines an SR-meter and ET-
   marker based on a token bucket with tail marking and marking
   frequency reduction (see Appendix A for explanation).  The TB has a
   bucket of size TB.size which is continuously filled with tokens at
   rate TB.rate.  When a non-ET-labelled PCN packet arrives, it is re-
   marked with "ET" if the fill state of the bucket (TB.fill) in tokens
   is smaller than its size (packet.size) in bytes and "s" additional
   tokens are added to the bucket; otherwise, the fill state is reduced
   by packet.size tokens.  The slow-down parameter "s" reduces the
   marking frequency of the mechanism.  If an ET-marked packet arrives,
   the TB's fill state is also incremented by "s".


2.  General Description of the Simulation Setup

   The simulation model used in our experiments consists of the traffic
   sources, the PCN-enabled network nodes, and the traffic control loop
   (admission control and flow termination entities) Figure 1.









Babiarz & Liu            Expires January 9, 2008                [Page 5]


Internet-Draft         Simulations Results for 3sM             July 2007


          +-------------------------------------+
          |   Block/start admission or flow     |
          |  termination signal with time lag   |
          V                                     |
    +-----------+     +---------------+    +---------+
    |           |     |               |    |         |
    |  Traffic  |     | PCN Node      |    | Traffic |
    |  Sources  | ===>| with          |===>| Control |
    |           |     | AR/SR Meter & |    |         |
    +-----------+     | Marker        |    +---------+
                      |               |
                      +---------------+

                  Figure 1: PCN Marking Simulation Model

2.1.  Traffic Sources

   The traffic source model can generate voice or video flows (calls)
   according to the Poisson arrival process with a given arrival rate.
   A Poisson arrival can contain one or more flows.  The arrival batch
   size is a random variable with a given mean batch size.  To model the
   reroute events in the network, the traffic source model can also
   generate flows at scheduled time points and/or within scheduled short
   time intervals.  The model also allows some flows to start together,
   e.g., a voice flow plus a video flow.

   Each flow has a random life-span (holding time) with a given mean
   holding time.

   During its life time, a flow periodically generates packets based on
   a given codec and packetization scheme such as G.711 for voice over
   IP.  Depending on the type of application and codec used in
   simulation, the packets from a flow can have fixed or variable sizes,
   and the inter-arrival time between the packets can be fixed or
   variable.  To model the applications such as G.711 with silence
   suppression, the packet generation of a flow can be described by an
   ON-OFF process with given mean ON and OFF periods.  With an ON-OFF
   flow, the packet can only be generated in the ON-period of the flow.
   An ON-OFF flow may start in either the ON or OFF state.

   When a flow starts, it can delay the generation of its first packet
   for some random time up to a given time limit, say 10 seconds.  This
   delay is used for modeling the media delay of the call setup process
   for telephony application.  To avoid unrealistic synchronization
   effects in the network, in any case, the start of the first packet
   from a flow is always randomized within a given small time interval
   after the flow start time, which is independent of the media delay.




Babiarz & Liu            Expires January 9, 2008                [Page 6]


Internet-Draft         Simulations Results for 3sM             July 2007


   The generation of packets for different flows are independent of each
   other.

   There can be mixed types of flows in the network.  Each flow belongs
   to a given traffic aggregate with a fixed route crossing the network.
   Different types of flows can be in the same traffic aggregate.

   When modeling flow admission control, after a flow starts, the
   traffic source model will check if the traffic aggregate is blocked
   for admission.  If the aggregate is blocked, any new flows will
   immediately be turned off (blocked) without generating any packet.
   The blocking of a traffic aggregate for admission will not affect the
   existing flows of the aggregate.

   When modeling flow termination, the traffic source model may receive
   signals for terminating particular flows.  Upon receiving the flow
   termination signal, the affected flow will immediately be turned off,
   stopping generating of packets.

2.2.  Multiple PCN Nodes

   For multiple PCN nodes simulations, we use a "parking lot" model with
   n nodes in tandem.  A traffic aggregate uses a given segment of the
   n-node tandem to cross the network, i.e., its traffic will enter the
   network at node i and exit the network at node j (1<=i<=j<=n), where
   all the nodes in the segment are consecutively numbered.

   The node is configured with queue size and a given service rate or
   link bandwidth.  The queue can be configured to have finite or
   unlimited buffer size.  When a PCN packet arrives at a node, before
   entering the queue, the packet is metered by the AR-meter and/or SR-
   meter and re-marked if needed.  The AR-meter and SR-meter are modeled
   using the example pseudo codes provided in [I-D.babiarz-pcn-3sm].

   After AR- and/or SR-metering, the packet enters the queue to be
   forwarded or is discarded if the queue is full.  After forwarding,
   the packet will proceed to the next node or exit the network,
   depending on the definition of its traffic aggregate.  The packet
   travel between nodes is instant.

   Upon exiting the network, the packet will be checked by the traffic
   control for its PCN marking and then destroyed.  Based on the PCN
   marking of the packet, the traffic control will decide if it needs to
   signal the traffic model for a given type of traffic control: block
   new flow, restart admission of a particular traffic aggregate and/or
   terminate a particular flow.  The signal to the traffic source model
   will experience certain delay or round-trip-time (RTT).  The RTT can
   be modeled as a fixed time for all the flows or different RTT per



Babiarz & Liu            Expires January 9, 2008                [Page 7]


Internet-Draft         Simulations Results for 3sM             July 2007


   each flow.  (Term RTT signifies the delay between generating a packet
   and receiving the corresponding traffic control feedback at the
   traffic source.  But, in our model, RTT does not include any queueing
   delay experienced by the packet.)

2.3.  Traffic Control

   In the simulation for admission control, the "block admission signal"
   will be sent whenever the traffic control sees an "AS" marking in the
   packet.  The receiver (ingress) of the signal controls admission of
   all new flows within the aggregate and the same route.  If the
   traffic aggregate is currently not blocked, the receiving of the
   block admission signal will trigger a "stop blocking timer" with a
   preset timeout.  At timeout, the traffic control will check if there
   is one more block admission signal sent for the traffic aggregate
   during the timeout period, and if so, it will restart the timer.
   This process will repeat until there is no block admission signal
   sent for the traffic aggregate in the past timeout period.  At this
   time, the traffic control will send the start admission signal for
   the traffic aggregate to allow it to admit flows into the network
   from now on.

   In the simulation for flow termination, a flow termination signal
   will be sent to the traffic source model for each ET-marked packet.
   Since SR is by definition greater than AR, a flow termination signal
   will also generate a block admission signal to the related traffic
   aggregate if admission control is being modeled at the same time.

   For more details of the simulation setup, see the case description
   sections in this document.


3.  Performance of 3sM

   In this section we discuss the simulations results that where
   performed in time for 69th IETF meeting.  Graphical results of the
   simulations can be viewed at
   http://standards.nortel.com/pcn/3sM-Simulation-1.pdf [SIM1-07].  See
   also Section 4 for simulations results that where done prior to 68th
   IETF meeting.

3.1.  Performance of Flow Termination

   The following simulations were performed to measure how long it takes
   for the defined mechanism in 3sM to reduce the aggregate traffic
   after condition where significant overload of PCN traffic occurred on
   a link (like after fast reroute of traffic due to link failure).




Babiarz & Liu            Expires January 9, 2008                [Page 8]


Internet-Draft         Simulations Results for 3sM             July 2007


   The simulation setup emulates a condition where all PCN traffic is
   rerouted instantaneously from the failed link on to a good link that
   was at 50% or 100% of supportable rate (SR).  The rerouted PCN
   traffic from the failed link is equivalent to SR of the remaining
   link, so that after reroute the load on the link is 150% and 200% of
   SR.

   Simulations were done with CBR and variable rate silence suppressed
   voice traffic sources.  Our traffic generation model produces many
   individual flows that represented one of the codecs.  Results are
   recorded for the following codec mix:

   o  G.711CBR = G.711 with 20ms packetization time CBR, (200 bytes
      packets sent every 20ms)

   o  3VBR+CBR = 4 different code mix. 3 codecs running silence
      suppression per ITU-T P.56, G.711 at 20ms (200 byte packets),
      G.711 at 10ms (120 byte packets) and G.729 at 20ms (60 byte
      packets).  And one dual-rate codec that sends packets at constant
      rate, 360 byte packets every 20ms.  Each of the codec types
      generates approximate 20% of SR traffic measured as a rate.  Note,
      that there is significantly more number of G.729VBR flows than
      flows generated by the dual-rate codec.  The traffic mix for 3VBR+
      CBR produces a 15 to 1 bandwidth ratio; the highest flow rate is
      15 times bigger than the lowest rate within the mix for this
      simulation.

3.1.1.  Large Number of Flows in a Single Domain

   For these simulations, it was assumed that the RTT within a single
   domain would be less than 50ms, therefore we simulated with 50ms as
   the RTT.  However, normally RTT between different ingress-egress
   nodes will very, therefore typical results would produce shorter
   delays than the corner case that we simulated using 50ms for delay
   after marking for flow termination.  Large number of flows, equates
   approximately 500 to 4,250 flows depending on the codec mix used to
   generate SR of 40 Mbps.

   Parameter setting:

   o  Token bucket of the meter was configured to be 50,000 bytes in
      size

   o  Supportable Rate = 40.0 Mbps

   o  FT-marking reduction factor "s" was set to 1064 bytes.

   The table in Figure 2 summarizes the results of how long it took to



Babiarz & Liu            Expires January 9, 2008                [Page 9]


Internet-Draft         Simulations Results for 3sM             July 2007


   terminate the excess traffic form 200% of SR to SR.  Also we provide
   the measured traffic rate and variation after flow termination was
   completed.  The rate of remaining traffic was measured over 12 second
   period and results are recorded in table below as average, maximum,
   minimum and the variances.

    ------------------------------------------------------------------
   |          | % Overload, time in sec.  |     Bandwidth in Mbps     |
   |----------+---------------------------+---------------------------|
   |  Traffic | 150% | 125% | 110% | 100% |  AVG |  Max |  Min |  Var |
   |----------+------+------+------+------+------+------+------+------|
   | G.711CBR | 0.15 | 0.20 | 0.25 | 0.50 | 40.0 | 40.0 | 40.0 |  0   |
   |----------+------+------+------+------+------+------+------+------|
   | 3VBR+CVR | 0.15 | 0.20 | 0.30 |  ~2  | 38.9 | 41.7 | 36.7 | 5.00 |
    ------------------------------------------------------------------

        Figure 2: Overload at 200% of SR with "s" set to 1064 bytes

   The table in Figure 3 summarizes the results with FT-marking
   reduction factor "s" set to 2064 bytes.

   ------------------------------------------------------------------
   |          | % Overload, time in sec.  |     Bandwidth in Mbps     |
   |----------+---------------------------+---------------------------|
   |  Traffic | 150% | 125% | 110% | 100% |  AVG |  Max |  Min |  Var |
   |----------+------+------+------+------+------+------+------+------|
   | G.711CBR | 0.15 | 0.30 | 0.45 | 1.20 | 40.0 | 40.0 | 40.0 |  0   |
   |----------+------+------+------+------+------+------+------+------|
   | 3VBR+CVR | 0.20 | 0.35 | 0.85 |  ~3  | 38.9 | 41.8 | 36.3 | 5.52 |
    ------------------------------------------------------------------

        Figure 3: Overload at 200% of SR with "s" set to 2064 bytes

   The table in Figure 4 summarizes the results of how long it took to
   terminate the excess traffic form 150% of SR to SR with "s" set to
   2064 bytes.

   ------------------------------------------------------------------
   |          | % Overload, time in sec.  |     Bandwidth in Mbps     |
   |----------+---------------------------+---------------------------|
   |  Traffic | 150% | 125% | 110% | 100% |  AVG |  Max |  Min |  Var |
   |----------+------+------+------+------+------+------+------+------|
   | G.711CBR |  -   | 0.20 | 0.35 | 1.05 | 40.0 | 40.0 | 40.0 |  0   |
   |----------+------+------+------+------+------+------+------+------|
   | 3VBR+CVR |  -   | 0.20 | 0.40 |  ~2  | 38.7 | 41.6 | 35.4 | 6.30 |
    ------------------------------------------------------------------

        Figure 4: Overload at 150% of SR with "s" set to 2064 bytes



Babiarz & Liu            Expires January 9, 2008               [Page 10]


Internet-Draft         Simulations Results for 3sM             July 2007


3.1.2.  Small Number of Flows in a Single Domain

   For these simulations, it was assumed that the RTT within a single
   domain would be less than 50ms, therefore we simulated with 50ms as
   the RTT.  However, normally RTT between different ingress-egress
   nodes will very, therefore typical results would produce shorter
   delays than the corner case that we simulated using 50ms for delay
   after marking for flow termination.  Small number of flows equates
   approximately 10 to 30 flows depending on the codec mix used to
   generate SR of 0.8 Mbps.

   Parameter setting:

   o  Token bucket of the meter was configured to be 10,000 bytes in
      size

   o  Supportable Rate = 0.8 Mbps

   o  FT-marking reduction factor "s" was set to 1064 bytes.

   The table in Figure 5 summarizes the results of how long it took to
   terminate the excess traffic form 200% of SR to SR.  Also we provide
   the measured traffic rate and variation after flow termination was
   completed.  The rate of remaining traffic was measured over 12 second
   period and results are recorded in table below as average, maximum,
   minimum and the variances.

   ------------------------------------------------------------------
   |          | % Overload, time in sec.  |     Bandwidth in Mbps     |
   |----------+---------------------------+---------------------------|
   |  Traffic | 150% | 125% | 110% | 100% |  AVG |  Max |  Min |  Var |
   |----------+------+------+------+------+------+------+------+------|
   | G.711CBR | 0.20 | 0.25 | 0.30 | 0.40 | 0.80 | 0.80 | 0.80 |  0   |
   |----------+------+------+------+------+------+------+------+------|
   | 3VBR+CVR | 0.25 | 0.35 | 0.40 |  ~2  | 0.74 | 1.07 | 0.50 | 0.57 |
    ------------------------------------------------------------------

        Figure 5: Overload at 200% of SR with "s" set to 1064 bytes

   The table in Figure 6 summarizes the results with FT-marking
   reduction factor "s" set to 2064 bytes.










Babiarz & Liu            Expires January 9, 2008               [Page 11]


Internet-Draft         Simulations Results for 3sM             July 2007


   ------------------------------------------------------------------
   |          | % Overload, time in sec.  |     Bandwidth in Mbps     |
   |----------+---------------------------+---------------------------|
   |  Traffic | 150% | 125% | 110% | 100% |  AVG |  Max |  Min |  Var |
   |----------+------+------+------+------+------+------+------+------|
   | G.711CBR | 0.30 | 0.40 | 0.60 | 0.65 | 0.80 | 0.80 | 0.80 |  0   |
   |----------+------+------+------+------+------+------+------+------|
   | 3VBR+CVR | 0.30 | 0.35 | 0.45 |  ~4  | 0.74 | 1.05 | 0.51 | 0.54 |
    ------------------------------------------------------------------

        Figure 6: Overload at 200% of SR with "s" set to 2064 bytes

3.1.3.  Large Number of Flows in a Multi Domain

   For these simulations, it was assumed that the RTT in a multi domain
   network would be less than 200ms, therefore we simulated with 200ms
   as the RTT.  However, normally RTT between different ingress-egress
   nodes will very, many flows would have shorter than 200ms RTT,
   therefore typical results would produce shorter delays than the
   corner case that we simulated using 200ms for delay after marking for
   flow termination.  Large number of flows equates approximately 500 to
   4,250 flows depending on the codec mix used to generate SR of 40
   Mbps.  Performance results for RTT of 800ms can be found in [SIM-07].

   Parameter setting:

      Token bucket of the meter was configured to be 50,000 bytes in
      size

      Supportable Rate = 40.0 Mbps

      FT-marking reduction factor "s" was set to 4064 bytes.

   The table in Figure 7 summarizes the results of how long it took to
   terminate the excess traffic form 200% of SR to SR.  Also we provide
   the measured traffic rate and variation after flow termination was
   completed.  The rate of remaining traffic was measured over 12 second
   period and results are recorded in table below as average, maximum,
   minimum and the variances.












Babiarz & Liu            Expires January 9, 2008               [Page 12]


Internet-Draft         Simulations Results for 3sM             July 2007


   ------------------------------------------------------------------
   |          | % Overload, time in sec.  |     Bandwidth in Mbps     |
   |----------+---------------------------+---------------------------|
   |  Traffic | 150% | 125% | 110% | 100% |  AVG |  Max |  Min |  Var |
   |----------+------+------+------+------+------+------+------+------|
   | G.711CBR | 0.45 | 0.65 | 0.90 | 1.6  | 40.0 | 40.0 | 40.0 |  0   |
   |----------+------+------+------+------+------+------+------+------|
   | 3VBR+CVR | 0.45 | 0.75 | 1.7  |  ~4  | 38.9 | 42.3 | 36.1 | 6.24 |
    ------------------------------------------------------------------

           Figure 7: Overload at 200% of SR with "s" set to 4064

3.1.4.  Discussion of Parameter Settings

   Token bucket sizes:

      The size of the token bucket filters out short term rate
      variations.  Normally, larger token bucket is need for highly
      variable traffic.  The draw back of configuring token bucket too
      big is that it will delay the start of FT-marking (flow
      termination).

   "s" FT-marking reduction factor:

      The "s" parameter controls how often packets are marked when in
      overload.  SR-meter measures traffic that is in excess of SR and
      FT-marker marks a packet ever "s" bytes of excess traffic.  FT-
      marking is proportional to the overload, the higher the overload
      the higher the number of packets get FT-marked.

      In our simulations we used the following equation to compute the
      value for "s"; average rate of a flow * RTT * 2 = s; we used the
      rate of G.711 at 20ms CBR codec for the average rate in the
      calculations.

      Making "s" too small leads to over flow termination due to the
      delay in the response.  A flow is terminated RTT after it is
      marked.

      As observed in simulations, this flow termination mechanism has
      exponential decay property and to prevent over termination, the
      period between ET-marking when PCN traffic rate is one flow above
      SR needs to be greater than 2 * RTT.  Making "s" too big leads to
      longer termination time.

      The "s" parameter has the biggest impact on how fast or slow
      excess traffic is reduced.




Babiarz & Liu            Expires January 9, 2008               [Page 13]


Internet-Draft         Simulations Results for 3sM             July 2007


   RTT - total delay for termination of flows (network + ingress and
   egress processing delays.)

      Since PCN is a responsive mechanism, node meters traffic and ET-
      mark packets indicate the traffic is in excess of SR, the time
      that it take for the indication that flow needs to be terminated
      and the reduced load on to the overloaded link is what we call
      RTT.  RTT has direct impact on how fast the overload condition can
      be eliminated.

3.2.  Performance of Admission Control

   The purpose of the simulation experiments with admission control is
   to test the ability of the AR-meter and AS- marker of 3sM to support
   admission control in a PCN-enabled network and to observe the
   behavior of the AR-meter and AS-marker as a function of its settings
   and the traffic and network environments.

   For this purpose, we have performed the following preliminary
   simulation tests:

   o  Erlang-B Test: test if the AR-meter and AS-marker can support
      admission control similarly to the Erlang blocking system for CBR
      traffic at a single node.

   o  Overload Protection Test: test the above with 2x base load and
      everything else being the same.

   o  Multiple-congested-node Test: test the performance of the AR-meter
      and AS-marker configured for a single node applies to a three-
      identical congestion-node environment with CBR traffic of 2x base
      load; traffic aggregate A1: route 1->2->3.

   o  Cross-traffic Test: similar to the above, with additional CBR
      traffic aggregates from different routes carried in the ("parking-
      lot") network, where the aggregate traffic at each node with
      cross-traffic is increased proportionally to the combined load; 2
      traffic aggregates are used, A1: route 1->2->3 with 2x base load,
      A2: route 2->3->4 with base load.

   o  VBR Test: test the performance of the AR-meter and AS-marker
      configured for Erlang-B Test applied to VBR traffic at a single
      node, where the AR is set proportionally to the expected data rate
      of the aggregate traffic sources.

   o  Traffic Mix Test: similar to the above, with combined VBR/CBR
      traffic served by the single node.




Babiarz & Liu            Expires January 9, 2008               [Page 14]


Internet-Draft         Simulations Results for 3sM             July 2007


   In all the above cases, the following settings are used unless
   otherwise indicated.

   Traffic settings:

   o  the base load defined as the number of the targeted flows to be
      carried by the system, N, where N=10 for small load (S), N=50 for
      medium load (M), and N=200 for large load (L);

   o  a Poisson arrival rate of Y=45*N flows (calls) per hour per base
      load: i.e., Y=450 flows/hour for small load (S); Y=2250 flows/hour
      for medium load (M); Y=9000 flows/hour for large load (L);

   o  a batch size of 1 flow per arrival;

   o  the mean holding time of 1 minute for each flow;

   o  the maximum media delay of 10 seconds;

   o  CBR traffic data rate of 80 kbps per flow with a fixed packet size
      of 200 bytes (corresponding to G.711 with 20 milliseconds of frame
      time for voice over IP);

   o  VBR traffic with exponentially distributed ON and OFF periods with
      mean ON period of 1.004 seconds and mean OFF period of 1.590
      seconds (corresponding to a voice codec with silence suppression);

   o  the traffic mix with 3 types of flows, each with N/3 flows: type 1
      flow: G.711/20ms VBR (data rate 31 kbps); type 2 flow: G.711/10ms
      VBR (data rate 37.2 kbps); type 3 flow: G.729/20ms VBR (data rate
      9.3 kbps);

   o  all the packets entering the system to be PCN marked.

   AR-meter settings:

   o  AR=TB.rate=the data rate of the base load times (N-1)/N;

   o  TB.size=20K bytes;

   o  TB.thershold=10K bytes

   Admission control setting:

   o  stop blocking timer timeout = 1 second;

   o  RTT=50 milliseconds, fixed for all flows.




Babiarz & Liu            Expires January 9, 2008               [Page 15]


Internet-Draft         Simulations Results for 3sM             July 2007


   Network node settings:

   o  link BW = 2 x the data rate of the traffic load seen at a link;

   o  unlimited buffer size , identical for all the nodes.

   Simulation settings:

   o  the initial number of the flows activated equal to the Poisson
      arrival rate in flows per hour x mean holding time in minutes /60;

   o  the warm-up period of 99 seconds;

   o  the observation period of 120 seconds;

   o  the observation interval of 50 milliseconds;

   o  simulation result measurement based on averaging 10 independent
      samples, each with 120-seconds worth of statistics collected in
      simulation.

3.2.1.  Simulation Results for Admission Control





























Babiarz & Liu            Expires January 9, 2008               [Page 16]


Internet-Draft         Simulations Results for 3sM             July 2007


               Blocking      BW            Data Rate      Worst
               Probability   Utilization   (Mbps)         Overshoot
               S    M    L  | S    M    L | S    M    L   | S  M  L
   ------------------------------------------------------------------
   Erlang-B    12% 0.3%  0% | 62% 72% 73% | 0.5  2.9 11.8 | 0% 4% 0%
   Test
   (Erlang-B
   Theoretical 10%  1%   0% | 75% 75% 75% | 0.6  3   12)
   ------------------------------------------------------------------
   2x Overload
   Protection  37% 32%  40% | 80% 93% 97% | 0.6  3.7 15.6 |16% 20% 17%
   Test
   ------------------------------------------------------------------
   Multiple-
   congestion- *   *    *   | 80% 93% 97% | 0.6  3.7 15.5 | *  *   *
   node Test (2x overload)
   ------------------------------------------------------------------
   Cross-
   Traffic     *   *    *   | 80% 95% 97% | 0.6  3.8 15.5 | *  *   *
   Test (2x overload)
   ------------------------------------------------------------------
   VBR Test    7%   4%  1%  | 51% 71% 77% | 0.16 1.1 4.8  | 0% 0% 0%
   (Erlang-B
   Theoretical 10%  1%  0%  | 75% 75% 75% | 0.24 1.2 4.7)
   ------------------------------------------------------------------
   Traffic Mix 20% 11% 0.2% | 58% 71% 72% | 0.14 0.9 3.8  | 0% 0% 0%
   Test
   (Erlang-B
   Theoretical 10%  1%  0%  | 75% 75% 75% | 0.19 0.96 3.8)
   ------------------------------------------------------------------

   *: not summarized at the time of preparing this draft; but they look
   similar to the corresponding 2x Overload Protection Test results.

   Observations

   o  For CBR traffic, the AR-meter and AS-marker can support blocking
      performance similar to what is expected form Erlang blocking
      system for small to large loads; as expected, the performance of
      small load is not as good as for larger loads.

   o  Protection for 2x provisioned BW with CRR traffic: worst case:
      <=20% overshoot for small to large loads.

   o  For the multiple congestion node and traffic crossing scenarios,
      the AR-meter and AS-marker can provide similar protection to the
      single node for small to large loads; this is expected since the
      control is based on the average rate in all the cases.



Babiarz & Liu            Expires January 9, 2008               [Page 17]


Internet-Draft         Simulations Results for 3sM             July 2007


   o  Similar behaviors of the AR-meter and AS-marker are observed for
      VBR and mixed traffic; as expected, the AR-meter and AS-marker
      will need different settings for VBR/mixed traffic than those for
      CBR traffic to improve performance.

   The AR-meter and AS-marker settings used in the simulation are chosen
   from a number of different settings.  With different AR-meter and AS-
   marker settings, the simulation results can be different in terms of
   the number of flows carried by the system, the blocking probability,
   BW utilization, overshoot, control reaction time, etc.  This behavior
   of the AR-meter and AS-marker suggests that the AR-meter and AS-
   marker has certain ability to assist the admission control to limit
   traffic load in the system to the desired level.

   All the results shown in the above have considered the impact of the
   media delay.  Without the media delay, the performance of the
   simulation is expected to improve according to our preliminary tests.

   Conclusions

   o  AR meter parameters can be adjusted to provide the following
      desired behaviors: (1) admit traffic to the expected data rate;
      (2) reduce over-/under-shoot to some degree; (3) change reaction
      time to some degree; (4) be applicable to a variety of traffic
      characteristics and multiple congested-node network with cross-
      traffic.

   o  Limitations observed: (a) difficult to avoid over-/under-shoot for
      large media delay; (b) difficult to avoid over-/under-shoot for
      VBR/mixed traffic with small load.


4.  Simulation Results Prior to 68th IETF

   This section captures the simulation work that was done prior to 68th
   IETF meeting.  Documented are 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 4.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 4.2 to Section 4.6
   discusses results of the voice-related simulation, and Section 4.7
   briefly discusses the preliminary video-related simulation results.
   All the simulations were performed using the token bucket algorithm
   documented in Section 4.8.

   Note: Since the terminology for this work is evolving, we provide a



Babiarz & Liu            Expires January 9, 2008               [Page 18]


Internet-Draft         Simulations Results for 3sM             July 2007


   brief explanation of terms used in the simulation results.

      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.

      pcn_tb = token bucket depth.

   In our simulations, we graphically show architectural performance
   comparison criteria for:

   o  Convergence time in response to a step overload.

   o  Convergence time in response to multiple steps of overload.

   o  Convergence time in response to packet loss.

4.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



Babiarz & Liu            Expires January 9, 2008               [Page 19]


Internet-Draft         Simulations Results for 3sM             July 2007


      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 (occurring at 500 time intervals, or
      approximately 25 seconds in the simulation) 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.

4.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 4.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:



Babiarz & Liu            Expires January 9, 2008               [Page 20]


Internet-Draft         Simulations Results for 3sM             July 2007


   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.

   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
      suppressed 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.

4.3.  Small Number of Voice Flows

   Here (on slides 21 to 28) 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 configured such that there is no packet
      loss in these simulations.  See Section 4.5 for results with



Babiarz & Liu            Expires January 9, 2008               [Page 21]


Internet-Draft         Simulations Results for 3sM             July 2007


      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.

   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



Babiarz & Liu            Expires January 9, 2008               [Page 22]


Internet-Draft         Simulations Results for 3sM             July 2007


   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.

4.4.  Large Number of Voice Flows with Packet Loss

   Now (see slides 29 to 38) 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.

   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.  This is
      because some of the marked packets are lost.

   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.



Babiarz & Liu            Expires January 9, 2008               [Page 23]


Internet-Draft         Simulations Results for 3sM             July 2007


4.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.

   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.






Babiarz & Liu            Expires January 9, 2008               [Page 24]


Internet-Draft         Simulations Results for 3sM             July 2007


4.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
      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 be x times larger than need.  Page 50 [SIM-07]
      shows the impact of setting pcn_px 2x bigger then needed.

4.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),





Babiarz & Liu            Expires January 9, 2008               [Page 25]


Internet-Draft         Simulations Results for 3sM             July 2007


   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;

   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-



Babiarz & Liu            Expires January 9, 2008               [Page 26]


Internet-Draft         Simulations Results for 3sM             July 2007


   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,

   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.

4.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:




Babiarz & Liu            Expires January 9, 2008               [Page 27]


Internet-Draft         Simulations Results for 3sM             July 2007


      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

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 9


5.  Security Considerations

   Not applicable for this draft.


6.  Acknowledgements

   The authors would like to thank the Dave McDysan for review of 00
   version of this document and for his suggestions to make it more
   complete.






Babiarz & Liu            Expires January 9, 2008               [Page 28]


Internet-Draft         Simulations Results for 3sM             July 2007


7.  Informative References

   [I-D.babiarz-pcn-3sm]
              Babiarz, J., "Three State PCN Marking",
              draft-babiarz-pcn-3sm-00 (work in progress), July 2007.

   [I-D.eardley-pcn-architecture]
              Eardley, P., "Pre-Congestion Notification Architecture",
              draft-eardley-pcn-architecture-00 (work in progress),
              June 2007.

   [Maglaris-88]
              Maglaris et al, "Performance Models of Statistical
              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.

   [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.

   [SIM1-07]  Liu, X-G. and J. Babiarz, "Simulation Results for Three
              State PCN Marking for Admission Control and Flow
              Termination,
              http://standards.nortel.com/pcn/3sM-Simulation-1.pdf",
              July 2007.


Authors' Addresses

   Jozef Z. Babiarz
   Nortel
   3500 Carling Avenue
   Ottawa, Ont.  K2H 8E9
   Canada

   Phone: +1-613-763-6098
   Email: babiarz@nortel.com





Babiarz & Liu            Expires January 9, 2008               [Page 29]


Internet-Draft         Simulations Results for 3sM             July 2007


   Xiao-Gao Liu
   Nortel
   3500 Carling Avenue
   Ottawa, Ont.  K2H 8E9
   Canada

   Phone: +1-613-763-7516
   Email: xgliu@nortel.com











































Babiarz & Liu            Expires January 9, 2008               [Page 30]


Internet-Draft         Simulations Results for 3sM             July 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 & Liu            Expires January 9, 2008               [Page 31]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/