Network Working Group                                          A. Charny
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Standards Track                                J. Zhang
Expires: September 6, 2007               Cisco Systems, Inc. and Cornell
                                                              University
                                                          F. Le Faucheur
                                                              V. Liatsos
                                                     Cisco Systems, Inc.
                                                           March 5, 2007


Pre-Congestion Notification Using Single Marking for Admission and Pre-
                                emption
                 draft-charny-pcn-single-marking-01.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 6, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   Pre-Congestion Notification [I-D.briscoe-tsvwg-cl-architecture]
   approach proposes the use of an Admission Control mechanism to limit



Charny, et al.          Expires September 6, 2007               [Page 1]


Internet-Draft           PCN with Single Marking              March 2007


   the amount of real-time PCN traffic to a configured level during the
   normal operating conditions, and the use of a Pre-emption mechanism
   to tear-down some of the flows to bring the PCN traffic level down to
   a desirable amount during unexpected events such as network failures,
   with the goal of maintaining the QoS assurances to the remaining
   flows.  In [I-D.briscoe-tsvwg-cl-architecture], Admission and Pre-
   emption use two different markings and two different metering
   mechanisms in the internal nodes of the PCN region.  This draft
   proposes a mechanism using a single marking and metering for both
   Admission and Pre-emption, and presents a preliminary analysis of the
   tradeoffs.  A side-effect of this proposal that a different marking
   and metering Admission mechanism than that proposed
   in[I-D.briscoe-tsvwg-cl-architecture] may be also feasible.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].
































Charny, et al.          Expires September 6, 2007               [Page 2]


Internet-Draft           PCN with Single Marking              March 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Changes from -00 version . . . . . . . . . . . . . . . . .  4
     1.2.  Background and Motivation  . . . . . . . . . . . . . . . .  4
     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
   2.  The Single Marking Approach  . . . . . . . . . . . . . . . . .  6
     2.1.  High Level description . . . . . . . . . . . . . . . . . .  6
     2.2.  Operation at the PIN . . . . . . . . . . . . . . . . . . .  7
     2.3.  Operation at the Egress PEN  . . . . . . . . . . . . . . .  7
     2.4.  Operation at the Ingress PEN . . . . . . . . . . . . . . .  8
       2.4.1.  Admission Decision . . . . . . . . . . . . . . . . . .  8
       2.4.2.  Pre-emption Decision . . . . . . . . . . . . . . . . .  9
   3.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.1.  Benefits . . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.2.  Tradeoffs, Issues and Discussion . . . . . . . . . . . . . 10
       3.2.1.  Restrictions on Pre-emption-to-admission Thresholds  . 10
       3.2.2.  Assumptions on Loss  . . . . . . . . . . . . . . . . . 10
       3.2.3.  Effect of Reaction Timescale of Admission Mechanism  . 10
       3.2.4.  Performance Implications and Tradeoffs . . . . . . . . 11
       3.2.5.  Effect on Proposed Anti-cheating Mechanisms  . . . . . 11
       3.2.6.  Standards Implications . . . . . . . . . . . . . . . . 12
   4.  Performance Evaluation Comparison  . . . . . . . . . . . . . . 12
     4.1.  Relationship to other drafts . . . . . . . . . . . . . . . 12
     4.2.  Limitations, Conclusions and Direction for Future Work . . 12
       4.2.1.  High Level Conclusions . . . . . . . . . . . . . . . . 12
       4.2.2.  Future work  . . . . . . . . . . . . . . . . . . . . . 13
   5.  Appendix A:  Simulation Details  . . . . . . . . . . . . . . . 14
     5.1.  Network and Signaling Model  . . . . . . . . . . . . . . . 14
     5.2.  Traffic Models . . . . . . . . . . . . . . . . . . . . . . 16
       5.2.1.  CBR Voice (CBR)  . . . . . . . . . . . . . . . . . . . 17
       5.2.2.  VBR Voice (VBR)  . . . . . . . . . . . . . . . . . . . 17
       5.2.3.  "Synthetic Video":  High Rate ON-OFF traffic with
               Video-like  Mean and Peak Rates ("SVD")  . . . . . . . 17
       5.2.4.  Real Video Traces (VTR)  . . . . . . . . . . . . . . . 17
     5.3.  Parameter Settings . . . . . . . . . . . . . . . . . . . . 18
       5.3.1.  Queue-based settings . . . . . . . . . . . . . . . . . 18
       5.3.2.  Token Bucket Settings  . . . . . . . . . . . . . . . . 18
     5.4.  Simulation Details . . . . . . . . . . . . . . . . . . . . 19
       5.4.1.  Queue-based Results  . . . . . . . . . . . . . . . . . 19
       5.4.2.  Token Bucket-based Results . . . . . . . . . . . . . . 23
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 27
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 27
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
   Intellectual Property and Copyright Statements . . . . . . . . . . 30



Charny, et al.          Expires September 6, 2007               [Page 3]


Internet-Draft           PCN with Single Marking              March 2007


1.  Introduction

1.1.  Changes from -00 version

   Added miscellaneous clarifications based on comments received on
   version -00.  Added simulation results for multi-hop topologies and
   video trace data to the Appendix.

1.2.  Background and Motivation

   Pre-Congestion Notification [I-D.briscoe-tsvwg-cl-architecture]
   approach proposes to use an Admission Control mechanism to limit the
   amount of real-time PCN traffic to a configured level during the
   normal operating conditions, and to use a Pre-emption mechanism to
   tear-down some of the flows to bring the PCN traffic level down to a
   desirable amount during unexpected events such as network failures,
   with the goal of maintaining the QoS assurances to the remaining
   flows.  In [I-D.briscoe-tsvwg-cl-architecture], Admission and Pre-
   emption use different two different markings and two different
   metering mechanisms in the internal nodes of the PCN region.
   Admission Control algorithms for variable-rate real-time traffic such
   as video have traditionally been based on the observation of the
   queue length, and hence re-using these techniques and ideas in the
   context of pre-congestion notification is highly attractive, and
   motivated the virtual-queue-based marking and metering approach
   specified in [I-D.briscoe-tsvwg-cl-architecture] for Admission.  On
   the other hand, for Pre-emption, it is desirable to know how much
   traffic needs to be pre-empted, and that in turn motivates rate-based
   Pre-emption metering.  This provides some motivation for employing
   different metering algorithm for Admission and for Preemption.

   Furthermore, it is frequently desirable to trigger Pre-emption at a
   substantially higher traffic level than the level at which no new
   flows are to be admitted.  There are multiple reasons for the
   requirement to enforce a different Admission Threshold and Preemption
   Threshold.  These include, for example:

   o  End-users are typically more annoyed by their established call
      dying than by getting a busy tone at call establishment.

   o  There are often very tight (possibly legal) obligations on network
      operators to not drop established calls.

   o  Voice Call Routing often has the ability to route/establish the
      call on another network (e.g., PSTN) if it is determined at call
      establishment that one network (e.g., packet network) can not
      accept the call.  Therefore, not admitting a call on the packet
      network at initial establishment may not impact the end-user.  In



Charny, et al.          Expires September 6, 2007               [Page 4]


Internet-Draft           PCN with Single Marking              March 2007


      contrast, it is usually not possible to reroute an established
      call onto another network mid-call.  This means that call
      Preemption can not be hidden to the end-user.

   o  Preemption is typically useful in failure situations where some
      loads get rerouted thereby increasing the load on remaining links.
      Because the failure may only be temporary, the operator may be
      ready to tolerate a small degradation during the interim failure
      period.

   o  A congestion notification based Admission scheme has some inherent
      inaccuracies because of its reactive nature and thus may
      potentially over admit in some situations (such as burst of calls
      arrival).  If the Preemption scheme reacted at the same Threshold
      as the Admission Threshold, calls may get routinely dropped after
      establishment because of over admission, even under steady state
      conditions.

   These considerations argue for metering for Admission and Pre-emption
   at different traffic levels and hence, implicitly, for different
   markings and metering schemes.

   Different marking schemes require different codepoints.  Thus, such
   separate markings consume valuable real-estate in the packet header,
   especially scarce in the case of MPLS Pre-Congestion Notification
   [I-D.davie-ecn-mpls] .  Furthermore, two different measurement/
   metering techniques involve additional complexity in the datapath of
   the internal routers of the PCN domain.

   To this end, [I-D.briscoe-tsvwg-cl-architecture] proposes an
   approach, referred to as implicit pre-emption marking, that does not
   require separate pre-emption marking.  However, it does require two
   separate measurement schemes: one measurement for Admission and
   another measurement for Preemption/Dropping.  Furthermore, this
   approach mandates that the configured preemption rate be set to a
   drop rate.  This approach effectively uses dropping as the way to
   convey information about how much traffic can "fit" under the
   preemption limit, instead of using a separate preemption marking.
   This is a significant restriction in that it results in preemption
   only taking effect once packets actually get dropped.

   This document presents an approach that allows the use of a single
   PCN marking and a single metering technique at the internal devices
   without requiring that the dropping and pre-emption thresholds be the
   same.  This document also investigates some of the tradeoffs
   associated with this approach.





Charny, et al.          Expires September 6, 2007               [Page 5]


Internet-Draft           PCN with Single Marking              March 2007


1.3.  Terminology

   o  Pre-Congestion Notification (PCN): two algorithms that determine
      when a PCN-enabled router Admission Marks and Pre-emption Marks a
      packet, depending on the traffic level.

   o  Admission Marking condition- the traffic level is such that the
      router Admission Marks packets.  The router provides an "early
      warning" that the load is nearing the engineered admission control
      capacity, before there is any significant build-up in the queue of
      packets belonging to the specified real-time service class.

   o  Pre-emption Marking condition- the traffic level is such that the
      router Pre-emption Marks packets.  The router warns explicitly
      that pre-emption may be needed.

   o  Configured-admission-rate - the reference rate used by the
      admission marking algorithm in a PCN-enabled router.

   o  Configured-pre-emption-rate - the reference rate used by the pre-
      emption marking algorithm in a PCN-enabled router.

   o  CLE - congestion level estimate computed by the egress node by
      estimating as the fraction of admission-marked packets it
      receives.

   o  PIN - PCN internal node - an internal node in the PCN region.

   o  PEN - PCN edge node - an ingress or egress edge node of the PCN
      region.

   o  SAR - Sustainable Admission rate - the rate of unmarked traffic
      received by the Ingress PEN from the egress PEN

   o  SPR - Sustainable Preemption rate


2.  The Single Marking Approach

2.1.  High Level description

   The proposed approach is based on several simple ideas:

   o  Replace virtual-queue-based marking for Admission Control by
      excess rate marking:

      *  meter traffic exceeding the Admission Threshold and mark excess
         traffic (e.g. using a token bucket with the rate configured to



Charny, et al.          Expires September 6, 2007               [Page 6]


Internet-Draft           PCN with Single Marking              March 2007


         Admission Rate Threshold)

      *  at the edges, stop admitting traffic when the fraction of
         marked traffic for a given edge-to-edge aggregate exceeds a
         configured threshold (e.g. stop admitting when 3% of all
         traffic in the edge-to-edge aggregate received at the ingress
         is marked)

   o  Impose a PCN-region-wide constraint on the ratio between the
      Admission threshold on a link and Pre-emption threshold on that
      link (e.g. pre-emption threshold is 20% higher than Admission
      threshold on all links in the PCN region)

   o  The edge PCN device determines whether Pre-emption level is
      reached anywhere in the network *implicitly* by measuring the
      amount of unmarked traffic (assuming the marked traffic actually
      is above the threshold triggering blocking admission), i.e. the
      traffic that did not get admission marked.  This is analogous to
      the notion of sustainable pre-emption rate in
      [I-D.briscoe-tsvwg-cl-architecture].  The rate of unmarked traffic
      in this case signifies the bottleneck admission threshold.  The
      bottleneck pre-emption threshold is by design within the chosen
      ratio of that admission threshold.  The ingress PCN edge device
      preempts all traffic above the bottleneck preemption threshold.

   The remaining part of this section gives more detailed of a possible
   operation of the system.

2.2.  Operation at the PIN

   The PCN Internal Node (PIN) meters the aggregate PCN traffic and
   marks the excess rate.  A number of implementations are possible to
   achieve that.  A token bucket implementation is particularly
   attractive because of its relative simplicity, and even more so
   because a token bucket implementation is readily available in the
   vast majority of existing equipment.  The rate of the token bucket is
   configured to correspond to the target Admission rate, and the depth
   of the token bucket can be configured by an operator based on the
   desired tolerance to PCN traffic burstiness.

   Note that no preemption threshold is explicitly configured at the
   PIN, and the PIN does nothing at all to enforce it or mark traffic
   based on Pre-emption threshold.

2.3.  Operation at the Egress PEN

   The PCN Egress Node (PEN) measures the rate of both marked and
   unmarked traffic on a per-ingress PEN basis, and reports to the



Charny, et al.          Expires September 6, 2007               [Page 7]


Internet-Draft           PCN with Single Marking              March 2007


   ingress PEN two values: the rate of unmarked traffic from this
   ingress PEN, which we deem Sustainable Admission Rate (SAR) and the
   Congestion Level Estimate (CLE), which is the fraction of the marked
   traffic received from this ingress PEN.  Note that Sustainable
   Admission Rate is analogous to the sustainable pre-emption rate of
   [I-D.briscoe-tsvwg-cl-architecture], except in this case it is based
   on the admission threshold rather than pre-emption threshold, while
   the CLE is exactly the same as that of
   [I-D.briscoe-tsvwg-cl-architecture].  The details of the rate
   measurement are outside the scope of this draft.

2.4.  Operation at the Ingress PEN

2.4.1.  Admission Decision

   Just as in [I-D.briscoe-tsvwg-cl-architecture], the admission
   decision is based on the CLE.  The ingress PEN stops admission of new
   flows if the CLE is above a pre-defined threshold (e.g. 3%).  Note
   that although the logic of the decision is exactly the same as in the
   case of [I-D.briscoe-tsvwg-cl-architecture], the detailed semantics
   of the marking is different.  This is because the marking used for
   admission in this proposal reflects the excess rate over the
   admission threshold, while in [I-D.briscoe-tsvwg-cl-architecture],
   the marking is based on exceeding a virtual queue threshold.
   Notably, in the current proposal, if the average sustained rate of
   admitted traffic is 5% over the admission threshold, then 5% of the
   traffic is expected to be marked, whereas in the context of
   [I-D.briscoe-tsvwg-cl-architecture] a steady 5% overload should
   eventually result in 100% of all traffic being admission marked.  A
   consequence of this is that for smooth traffic, the approach
   presented here will not mark any traffic at all until the rate of the
   traffic exceeds the configured admission threshold by the amount
   corresponding to the chosen CLE threshold.  At first glance this may
   seem to result in a violation of the pre-congestion notification
   premise that attempts to stop admission before the desired traffic
   level is reached.  However, in reality one can simply embed the CLE
   level into the desired configuration of the admission threshold.
   That is, if a certain rate X is the actual target admission
   threshold, then one should configure the rate of the metering device
   (e.g. the rate of the token bucket) to X-y where y corresponds to the
   level of CLE that would trigger admission blocking decision.

   A more important distinction is that virtual-queue based marking
   reacts to short-term burstiness of traffic, while the excess-rate
   based marking is only capable of reacting to rate violations at the
   timescale chosen for rate measurement.  Based on our investigation,
   it seems that this distinction is not crucial in the context of PCN
   when no actual queuing is expected even if the virtual queue is full.



Charny, et al.          Expires September 6, 2007               [Page 8]


Internet-Draft           PCN with Single Marking              March 2007


   More discussion on this is presented later in the draft.

2.4.2.  Pre-emption Decision

   When the ingress observes a non-zero CLE and Sustainable Admission
   Rate (SAR), it first computes the Sustainable Pre-Emption rate (SPR)
   by simply multiplying SAR by the system-wide constant u, where u is
   the system-wide ratio between pre-emption and admission thresholds on
   all links in the PCN domain: SPR = SAR*u.  The ingress PEN then
   performs exactly the same operation as is proposed in
   [I-D.briscoe-tsvwg-cl-architecture] with respect to SPR.  Namely, it
   pre-empts the appropriate number of flows to ensure that the rate of
   traffic it sends to the corresponding egress PEN does not exceed SPR.
   Just as in the case of [I-D.briscoe-tsvwg-cl-architecture], an
   implementation may decide to slow down the pre-emption process by
   preempting fewer flows than is necessary to cap its traffic to SPR by
   employing a variety of techniques such as safety factors or
   hysteresis.  In summary, the operation of pre-emption at the ingress
   PEN is identical to that of [I-D.briscoe-tsvwg-cl-architecture], with
   the only exception that the sustainable pre-emption rate is computed
   from the sustainable admission rate rather than derived from a
   separate marking.  As discussed earlier, this is enabled by imposing
   a system-wide restriction on the pre-emption-to-admission thresholds
   ratio and changing the semantics of the admission marking.


3.  Discussion

3.1.  Benefits

   The key benefits of using a single metering/marking scheme for both
   Admission and Preemption presented in this document are summarized
   below:

   o  Reduced implementation requirements on core routers due to a
      single metering implementation instead of two different ones.

   o  Ease of use on existing hardware: given that the proposed approach
      is particularly amenable to a token bucket implementation, the
      availability of token buckets on virtually all commercially
      available routers makes this approach especially attractive.

   o  Reduced number of codepoints which need to be conveyed in the
      packet header.  If the PCN-bits used in the packets header to
      convey the congestion notification information are the ECN-bits in
      an IP core and the EXP-bits in an MPLS core, as is currently
      proposed in [put marking draft reference here] and
      [I-D.davie-ecn-mpls], those are very expensive real-estate.  The



Charny, et al.          Expires September 6, 2007               [Page 9]


Internet-Draft           PCN with Single Marking              March 2007


      current proposals need 5 codepoints, which is especially important
      in the context of MPLS where there is only a total of 8 EXP
      codepoints which must also be shared with Diffserv.  Eliminating
      one codepoint considerably helps.

   o  A possibility of using a token-bucket-, excess-rate- based
      implementation for admission provides extra flexibility for the
      choice of an admission mechanism, even if two separate markings
      and thresholds are used.

3.2.  Tradeoffs, Issues and Discussion

   While the benefits of the proposed approach are attractive, there are
   several issues and tradeoffs that need to be carefully considered.

3.2.1.  Restrictions on Pre-emption-to-admission Thresholds

   An obvious restriction necessary for the single-marking approach is
   that the ratio of (implicit) pre-emption and admission thresholds
   remains the same on all links in the PCN region.  While clearly a
   limitation, this does not appear to be particularly crippling, and
   does not appear to outweigh the benefits of reducing the overhead in
   the router implementation and savings in codepoints in the case of a
   single PCN domain, or in the case of multiple concatenated PCN
   regions.  The case when this limitation becomes more inconvenient is
   when an operator wants to merge two previously separate PCN regions
   (which may have different admission-to-preemption ratios) into a
   single PCN region.  In this case it becomes necessary to do a
   network-wide reconfiguration to align the settings.

3.2.2.  Assumptions on Loss

   Just as in the case of [I-D.briscoe-tsvwg-cl-architecture], the
   approach presented in this draft assumes that the Admission Threshold
   is configured at each link below the service rate of the traffic
   using PCN.  This assumption is significant because the algorithm
   relies on the fact that if admission threshold is exceeded, enough
   marked traffic reaches the egress PEN to reach the configured CLE
   level.  If this condition does not hold, then traffic may get dropped
   without ever triggering admission decision.

3.2.3.  Effect of Reaction Timescale of Admission Mechanism

   As mentioned earlier in this draft, there is a potential concern that
   slower reaction time of admissions mechanism presented in this draft
   compared to [I-D.briscoe-tsvwg-cl-architecture] may result in
   overshoot when the load grows rapidly, and undershoot when the load
   drops rapidly.  While this is a valid concern theoretically, it



Charny, et al.          Expires September 6, 2007              [Page 10]


Internet-Draft           PCN with Single Marking              March 2007


   should be noted that at least for the traffic and parameters used in
   the simulation study reported here, there was no indication that this
   was a problem.  However, the comparison has so far been done for
   Poisson arrivals only.  Future work would look in performing a
   similar comparison for burstier arrivals.

3.2.4.  Performance Implications and Tradeoffs

   Replacement of a relatively well-studied queue-based measurement-
   based admission control approach by a cruder excess-rate measurement
   technique raises a number of algorithmic and performance concerns
   that need to be carefully evaluated.  For example, a token-bucket
   excess rate measurement is expected to be substantially more
   sensitive to traffic burstiness and parameter setting, which may have
   a significant effect in the case of lower levels of traffic
   aggregation, especially for variable-rate traffic such as video.  In
   addition, the appropriate timescale of rate measurement needs to be
   carefully evaluated, and in general it depends on the degree of
   expected traffic variability which is frequently unknown.

   In view of that, an initial performance comparison of the token-
   bucket based measurement is presented in the following section.
   Within the constraints of this preliminary study, the performance
   tradeoffs observed between the queue-based technique suggested in
   [I-D.briscoe-tsvwg-cl-architecture] and a simpler token-bucket-based
   excess rate measurement do not appear to be a cause of substantial
   concern for cases when traffic aggregation is reasonably high at the
   bottleneck links as well as on a per ingress-egress pair basis.
   Details of the simulation study, as well as additional discussion of
   its implications are presented in section 4.

   Also, one mitigating consideration in favor of the simpler mechanism
   is that in a typical DiffServ environment, the real-time traffic is
   expected to be served at a higher priority and/or the target
   admission rate is expected to be substantially below the speed at
   which the real-time queue is actually served.  If these assumptions
   hold, then there is some margin of safety for an admission control
   algorithm, making the requirements for admission control more
   forgiving to bounded errors - see additional discussion in section 4.

3.2.5.  Effect on Proposed Anti-cheating Mechanisms

   Replacement of the queue-based admission control mechanism of
   [I-D.briscoe-tsvwg-cl-architecture] by an excess-rate based admission
   marking changing the semantics of the pre-congestion marking, and
   consequently interfereres with mechanisms for cheating detection
   discussed in [I-D.briscoe-tsvwg-re-ecn-border-cheat].  Implications
   of excess-rate based marking on the anti-cheating mechanisms need to



Charny, et al.          Expires September 6, 2007              [Page 11]


Internet-Draft           PCN with Single Marking              March 2007


   be considered.

3.2.6.  Standards Implications

   The change of the meaning of admission marking for pre-congestion
   notification from the queue-based to excess-rate marking poses a
   question of coexistence of devices having different interpretation of
   admissions marking (and hence different metering and marking
   mechanisms in the core.  The question of how and if the two
   mechanisms can co-exist in one PCN region has obvious impact on
   standardization efforts, and needs to be carefully considered.


4.  Performance Evaluation Comparison

4.1.  Relationship to other drafts

   Initial simulation results of admission and pre-emption mechanisms of
   [I-D.briscoe-tsvwg-cl-architecture] were reported in
   [I-D.briscoe-tsvwg-cl-phb].  A follow-up study of these mechanisms is
   presented in a companion draft
   draft-zhang-cl-performance-evaluation-01.txt.  The current draft
   concentrates on a performance comparison of the admission control
   mechanism of [I-D.briscoe-tsvwg-cl-phb] and the token-bucket-based
   admission control described in section 2 of this draft.

4.2.  Limitations, Conclusions and Direction for Future Work

   Due to time constraints, the study performed so far was limited to a
   small set of topologies, described in the Appendix.  The key
   questions that have been investigated are the comparative sensitivity
   of the two schemes to parameter settings and the effect of traffic
   burstiness and of the degree of aggregation on a per ingress-egress
   pair on the performance of the admission control algorithms under
   study.  The study is limited to the case where there is no packet
   loss.  While this is a reasonable initial assumption for an admission
   control algorithm that is supposed to maintain the traffic level
   significantly below the service capacity of the corresponding queue,
   nevertheless future study is necessary to evaluate the effect of
   packet loss.

4.2.1.  High Level Conclusions

   The results of this (preliminary) study indicate that there is a
   potential that a reasonable complexity/performance tradeoff may be
   viable for the choice of admission control algorithm.  In turn, this
   suggests that using a single codepoint and metering technique for
   admission and pre-emption may be a viable option.



Charny, et al.          Expires September 6, 2007              [Page 12]


Internet-Draft           PCN with Single Marking              March 2007


   The key high-level conclusions of the simulation study comparing the
   performance of queue-based and token-based admission control
   algorithms are summarized below:

   1.  At reasonable level of aggregation at the bottleneck and per
       ingress-egress pair traffic, both algorithms perform reasonably
       well for the range of traffic models considered (see section 4.3.
       for detail).

   2.  Both schemes are stressed for small levels of ingress-egress pair
       aggregation levels of bursty traffic (e.g. a single video-like
       bursty SVD flow per ingress-egress pair).  However, while the
       queue-based scheme results in tolerable performance even at low
       levels of per ingress-egress aggregation, the token-bucket-based
       scheme is substantially more sensitive to parameter setting than
       the queue-based scheme, and its performance for the high rate
       bursty SVD traffic with low levels of ingress-egress aggregation
       is quite poor unless parameters are chosen carefully to curb the
       error.  It should be noted that the SVD traffic model used in
       this study is expected to be substantially more challenging for
       both admission and pre-emption mechanisms that the actual video
       traffic, as the latter is expected to be much smoother than the
       busrty on-off model with high peak-to-mean ratio we used.  This
       expectation is confirmed by the fact that simulations with actual
       video traces reported in this version of the draft reveal that
       the performance of the video traces is much closer to that of VBR
       voice than of our crude SVD on-off model.

   3.  Even for small per ingress-egress pair aggregation, reasonable
       performance across a range of traffic models can be obtained for
       both algorithms (with a narrower range of parameter setting for
       the token-bucket based approach) .

   4.  The absolute value of round-trip time (RTT) or the RTT difference
       between different ingress-egress pair within the range of
       continental propagation delays does not appear to have a visible
       effect on the performance of both algorithms.

4.2.2.  Future work

   This study is but the first step in performance evaluation of the
   token-bucket based admission control.  Further evaluation should
   include a range of investigation, including the following:

   o  fairness issues (how different ingress-egress pairs get access to
      bottleneck bandwidth)





Charny, et al.          Expires September 6, 2007              [Page 13]


Internet-Draft           PCN with Single Marking              March 2007


   o  interactions between admission control and preemption

   o  effect of loss of marked packets

   o  much more


5.  Appendix A:  Simulation Details

5.1.  Network and Signaling Model

   Network topologies used in this study are shown in the Figures below.
   The network is modeled as either Single Link (Fig. A.1), Multi Link
   Network with a single bottleneck (termed "RTT", Fig. A.2), or a range
   of multi-bottleneck topologies shown in Fig. A.3 (termed "Parking
   Lot").


                          A --- B


   Figure A.1: Simulated Single Link Network.


                             A

                                \

                             B  -  D - F

                                /

                             C

   Figure A.2: Simulated Multi Link Network.


         A--B--C     A--B--C--D      A--B--C--D--E--F
         |  |  |     |  |  |  |      |  |  |  |  |  |
         |  |  |     |  |  |  |      |  |  |  |  |  |
         D  E  F     E  F  G  H      G  H  I  J  K  L

           (a)          (b)                (c)

   Figure A.3: Simulated Multiple-bottleneck (Parking Lot )Topologies.

   Figure A.1 shows a single link between an ingress and an egress node,
   all flows enter at node A and depart at node B. In Figure A.2, A set



Charny, et al.          Expires September 6, 2007              [Page 14]


Internet-Draft           PCN with Single Marking              March 2007


   of ingresses (A,B,C) connected to an interior node in the network
   (D).  The number of ingresses varied in different simulation
   experiments in the range of 2-100.  All links have generally
   different propagation delays, in the range 1ms - 100 ms.  This node D
   in turn is connected to the egress (F).  In this topology, different
   sets of flows between each ingress and the egress converge on the
   single link D-F, where pre-congestion notification algorithm is
   enabled.  The capacities of the ingress links are not limiting, and
   hence no PCN is enable on those.  The bottleneck link D-F is modeled
   with a 10ms propagation delay in all simulations.  Therefore the
   range of round-trip delays in the experiments is from 22ms to 220ms.
   Our simulations concentrated primarily on capacities of 'bottleneck'
   links with sufficient aggregation - OC3 for voice and for SVD
   traffic, up to 1 Gbps.  In the simulation model, a call requests
   arrive at the ingress and immediately sends a message to the egress.
   The message arrives at the egress after the propagation time plus
   link processing time (but no queuing delay).  When the egress
   receives this message, it immediately responds to the ingress with
   the current Congestion-Level-Estimate.  If the Congestion-Level-
   Estimate is below the specified CLE-threshold, the call is admitted,
   otherwise it is rejected.  An admitted call sends packets according
   to one of the chosen traffic models for the duration of the call (see
   next section).  Propagation delay from source to the ingress and from
   destination to the egress is assumed negligible and is not modeled.

   Another type of network of interest is multi-bottleneck (or Parking
   Lot, PLT for short) topology.  The simplest PLT with 2 bottlenecks is
   illustrated in Fig A.3(a).  An example traffic matrix with this
   network on this topology is as follows:

   o  an aggregate of "2-hop" flows entering the network at A and
      leaving at C (via the two links A-B-C)

   o  an aggregate of "1-hop" flows entering the network at D and
      leaving at E (via A-B)

   o  an aggregate of "1-hop" flows entering the network at E and
      leaving at F (via B-C)

   In the 2-hop PLT shown in Fig. A.3(a) the points of congestion are
   links A--B and B--C.  Capacity of all other links is not limiting.
   We also experiment with larger PLT topologies with 3 bottlenecks(see
   Fig A.3(b)) and 5 bottlenecks ( Fig A.3 (c)).  In all cases, we
   simulated one ingress-egress pair that carries the aggregate of
   "long" flows traversing all the N bottlenecks (where N is the number
   of bottleneck links in the PLT topology), and N ingress-egress pairs
   that carry flows traversing a single bottleneck link and exiting at
   the next "hop".  In all cases, only the "horizontal" links in Fig.



Charny, et al.          Expires September 6, 2007              [Page 15]


Internet-Draft           PCN with Single Marking              March 2007


   A.3 were the bottlenecks, with capacities of all "vertical" links
   non-limiting.  Propagation delays for all links in all PLT topologies
   are set to 1ms.

   Due to time limitations, other possible traffic matrices (e.g. some
   of the flows traversing a subset of several bottleneck links) have
   not yet been considered and remain the area for future investigation.
   Our simulations concentrated primarily on the range of capacities of
   'bottleneck' links with sufficient aggregation - above 10 Mbps for
   voice and 622 Mbps for SVD, up to 2.4 Gbps.  But we also investigated
   slower 'bottleneck' links down to 512 Kbps in some experiments.  In
   the simulation model of admission control, a call request arrives at
   the ingress and immediately sends a message to the egress.  The
   message arrives at the egress after the propagation time plus link
   processing time (but no queuing delay).  When the egress receives
   this message, it immediately responds to the ingress with the current
   Congestion Level Estimate.  If the Congestion Level Estimate is below
   the specified CLE- threshold, the call is admitted, otherwise it is
   rejected.  For preemption, once the ingress node of a PCN region
   decides to preempt a call, that call is preempted immediately and
   sends no more packets from that time on.  The life of a call outside
   the domain described above is not modelled.  Propagation delay from
   source to the ingress and from destination to the egress is assumed
   negligible and is not modelled.

5.2.  Traffic Models

   Four types of traffic were simulated (CBR voice, on-off traffic
   approximating voice with silence compression, and on-off traffic with
   higher peak and mean rates (we termed the latter synthetic video
   (SDV) as the chosen peak and mean rate was similar to that of an MPEG
   video stream, although no attempt was made to match any other
   parameters of this traffic to those of a video stream), and finally
   real video traces.  The distribution of flow duration was chosen to
   be exponentially distributed with mean 1min, regardless of the
   traffic type.  In most of the experiments flows arrived according to
   a Poisson distribution with mean arrival rate chosen to achieve a
   desired amount of overload over the configured-admission-limit in
   each experiment.  Overloads in the range 1x to 5x and underload with
   0.95x have been investigated.  Note that the rationale for looking at
   the load 1and below is to see if any significant amount of "false
   rejects" would be seen (i.e. one would assume that all traffic should
   be accepted if the total demand is below the admission threshold).
   For on-off traffic, on and off periods were exponentially distributed
   with the specified mean.  Traffic parameters for each type are
   summarized below:





Charny, et al.          Expires September 6, 2007              [Page 16]


Internet-Draft           PCN with Single Marking              March 2007


5.2.1.  CBR Voice (CBR)

   o  Average rate 64 Kbps

   o  Packet length 160 bytes

   o  packet inter-arrival time 20ms

5.2.2.  VBR Voice (VBR)

   o  Packet length 160 bytes

   o  Long-term average rate 21.76 Kbps

   o  On Period mean duration 340ms; during the on period traffic is
      sent with the CBR voice parameters described above

   o  Off Period mean duration 660ms; no traffic is sent during the off
      period.

5.2.3.  "Synthetic Video":  High Rate ON-OFF traffic with Video-like
        Mean and Peak Rates ("SVD")

   This model is on-off traffic with video-like mean-to-peak ratio and
   mean rate approximating that of an MPEG-2 video stream.  No attempt
   is made to simulate any other aspects of a video stream, and this
   model is merely that of on-off traffic.  Although there is no claim
   that this model represents the performance of video traffic under the
   algorithms in question adequately, intuitively, this model should be
   more challenging for a measurement-based algorithm than the actual
   MPEG video, and as a result, 'good' or "reasonable" performance on
   this traffic model indicates that MPEG traffic should perform at
   least as well.  We term this type of traffic SVD for "Synthetic
   Video".

   o  Long term average rate 4 Mbps

   o  On Period mean duration 340ms; during the on-period the packets
      are sent at 12 Mbps (1500 byte packets, packet inter-arrival: 1ms)

   o  Off Period mean duration 660m

5.2.4.  Real Video Traces (VTR)

   We used a publicly available library of frame size traces of long
   MPEG-4 and H.263 encoded video obtained from
   http://www.tkn.tu-berlin.de/research/trace/trace.html (courtesy
   Telecommunication Networks Group of Technical University of Berlin).



Charny, et al.          Expires September 6, 2007              [Page 17]


Internet-Draft           PCN with Single Marking              March 2007


   Each trace is roughly 60 minutes in length, consisting of a list of
   records in the format of <FrameArrivalTime, FrameSize>.  Among the
   160 available traces, we picked the two with the highest average rate
   (averaged over the trace length, in this case, 60 minutes.  In
   addition, the two also have a similar average rate).  The trace file
   used in the simulation is the concatenation of the two.  Since the
   duration of the flow is much smaller than the length of the trace, we
   need to check how does the expect rate of flow related the trace's
   long term average.  To do so, we simulate a number of flows starting
   from random locations in the trace with duration chosen to be
   exponentially distributed with mean 1min.  The results show that the
   expected rate of flow is roughly the same as the trace's average.
   Traffic characteristics are summarized below:

   o  Average rate 769 Kbps

   o  Each frame is sent with packet length 1500 bytes and packet inter-
      arrival time 1ms

   o  No traffic is sent between frames.

5.3.  Parameter Settings

5.3.1.  Queue-based settings

   All the queue-based simulations were run with the following Virtual
   Queue thresholds:

   o  virtual-queue-rate: configured admission rate, 1/2 link speed

   o  min-marking-threshold: 5ms at virtual-queue-rate

   o  max-marking-threshold: 15ms at virtual-queue-rate

   o  virtual-queue-upper-limit: 20ms at virtual-queue-rate

   At the egress, the CLE is computed as an exponential weighted moving
   average (EWMA) on an interval basis, with 100ms measurement interval
   chosen in all simulations.  We simulated the weight ranging 0.1 to
   0.9.  The CLE threshold is chosen to be 0.05, 0.15, 0.25, and 0.5.

5.3.2.  Token Bucket Settings

   The token bucket rate is set to the configured admission rate, which
   is half of the link speed in all experiments.  Token bucket depth
   ranges from 64 to 512 packets.  Our simulation results indicate that
   depth of token bucket has no significant impact on the performance of
   the algorithms and hence, in the rest of the section, we only present



Charny, et al.          Expires September 6, 2007              [Page 18]


Internet-Draft           PCN with Single Marking              March 2007


   the result with 256 packets bucket depth.

   The CLE is calculated in the same way as in queue-based approach with
   weights from 0.1 to 0.9.  The CLE thresholds are chosen to be 0.0001,
   0.001, 0.01, 0.05 in this case.  Note that the since meaning of the
   CLE is different for the Token bucket and queue-based algorithms, so
   there is no direct correspondence between the choice of the CLE
   thresholds in the two cases.

5.4.  Simulation Details

   To evaluate the performance of the algorithms, we recorded the actual
   admitted load at a granularity of 50ms, from which the mean admitted
   load over the duration of the simulation run can be computed.  We
   verified that the actual admitted load at any time does not deviate
   much from the mean admitted load in each experiment by computing the
   coefficient of variation (CV is consistently 0.07 for CBR, 0.15 for
   VBR, 0.17 for VTR and 0.51 for SVD for all experiments).  Finally,
   the performance of the algorithms is evaluated using a metric called
   over-admission-percentage, which is calculated as a percentage
   difference between the mean admitted load and the configured
   admission rate.  Given reasonably small deviation of the admitted
   rate from the mean admitted in the experiments, this seems
   reasonable.

5.4.1.  Queue-based Results

   We found that the virtual-queue admission control algorithm works
   reliably with the range of parameters we simulated, for all four
   types of traffic.  In addition, for both CBR, VBR and VTR traffic,
   the performance is insensitive to the parameters change under all
   tested topologies.

   Table A.1 summarized over-admission-percentage values from 15
   experiments with different [weight, CLE threshold] settings for CBR,
   VBR and VTR traffic.  For the single bottleneck topologies (S. Link
   and RTT) the overload column represents the ratio of the demand on
   the bottleneck link to the configured admission threshold.  For
   parking lot topologies we report the worst case result across all
   bottlenecks.

   While in our simulations we tested the range of overload from 0.95 to
   5, we present here only the results of the endpoints of this overload
   interval.  For the intermediate values of overload the results are
   even closer to the expected ones than at the two boundary loads.  The
   statistics show that for CBR, VBR and VTR traffic these over-
   admission-percentage values are rather similar across these traffic
   types, with the admitted load roughly staying within -2%+2% range of



Charny, et al.          Expires September 6, 2007              [Page 19]


Internet-Draft           PCN with Single Marking              March 2007


   the desired admission threshold, with quite limited variability
   across the experiments (see the Standard Deviation column).  Note
   also that this is not always true for all experiments with 0.95
   average load due to the variability of traffic generation.















































Charny, et al.          Expires September 6, 2007              [Page 20]


Internet-Draft           PCN with Single Marking              March 2007


    ----------------------------------------------------------
   |     Over Admission Perc Stats     | Over |  Topo  | Type |
   |  Min   |  Mean  |  Max   |  SD    | Load |        |      |
    ----------------------------------------------------------
   |   0    |    0   |    0   |   0    | 0.95 |        |      |
   |------------------------------------------| S.Link |      |
   | 0.224  | 0.849  | 1.905  | 0.275  |  5   |        |      |
   |---------------------------------------------------|      |
   |   0    |    0   |    0   |   0    | 0.95 |        |      |
   |------------------------------------------|  RTT   | CBR  |
   | 0.200  | 0.899  | 1.956  | 0.279  |  5   |        |      |
   |---------------------------------------------------|      |
   | -1.06  | -0.33  | -0.15  | 0.228  | 0.95 |        |      |
   |------------------------------------------|  PLT   |      |
   | -0.58  | 0.740  | 1.149  | 0.404  |  5   |        |      |
   |----------------------------------------------------------
   | -1.45  | -0.98  | -0.86  | 0.117  | 0.95 |        |      |
   |------------------------------------------| S.Link |      |
   | -0.07  | 1.405  | 1.948  | 0.421  |  5   |        |      |
   |---------------------------------------------------|      |
   | -1.56  | -0.80  | -0.69  | 0.16   | 0.95 |        |      |
   |------------------------------------------|  RTT   | VBR  |
   | -0.11  | 1.463  | 2.199  | 0.462  |  5   |        |      |
   |---------------------------------------------------|      |
   | -3.49  | -2.23  | -1.80  | 0.606  | 0.95 |        |      |
   |------------------------------------------|  PLT   |      |
   | -1.37  | 0.978  | 1.501  | 0.744  |  5   |        |      |
    ----------------------------------------------------------
   |   0    |    0   |    0   |   0    | 0.95 |        |      |
   |------------------------------------------| S.Link |      |
   | -0.53  | 1.004  | 1.539  | 0.453  |  5   |        |      |
   |---------------------------------------------------|      |
   |   0    |    0   |    0   |   0    | 0.95 |        |      |
   |------------------------------------------|  RTT   | VTR  |
   | -0.21  | 1.382  | 1.868  | 0.503  |  5   |        |      |
   |---------------------------------------------------|      |
   |  0    |    0   |    0   |   0     | 0.95 |        |      |
   |------------------------------------------|  PLT   |      |
   | -0.86  | 0.686  | 1.117  | 0.452  |  5   |        |      |
    ----------------------------------------------------------
   Table A.1 Summarized performance for CBR, VBR and VTR across
   different settings.

   For SVD, the algorithms does show certain sensitivity to the tested
   parameters.  Table A.2 recorded the over-admission-percentage for
   each combination of weights and CLE threshold.





Charny, et al.          Expires September 6, 2007              [Page 21]


Internet-Draft           PCN with Single Marking              March 2007


    -------------------------------------------------------------------
   |        |               EWMA  Weights              | Over |  Topo  |
   |        |  0.1   |  0.3  |  0.5   |  0.7   |  0.9  | Load |        |
    -------------------------------------------------------------------
   |   0.05 | -4.87  | -3.05 | -2.92  | -2.40  | -2.40 |      |        |
   |   0.15 | -3.67  | -2.99 | -2.40  | -2.40  | -2.40 | 0.95 |        |
   |   0.25 | -2.67  | -2.40 | -2.40  | -2.40  | -2.40 |      |        |
   |   -------------------------------------------------------| Single |
   | C 0.05 | -4.03  | 2.52  | 3.45   | 5.70   | 5.17  |      |  Link  |
   | L 0.15 | -0.81  | 3.29  | 6.35   | 6.80   | 8.13  |  5   |        |
   | E 0.25 | 2.15   | 5.83  | 6.81   | 8.62   | 7.95  |      |        |
   |   ----------------------------------------------------------------
   | T 0.05 | -11.77 | -8.35 | -5.23  | -2.64  | -2.35 |      |        |
   | H 0.15 | -9.71  | -7.14 | -2.01  | -2.21  | -1.13 | 0.95 |        |
   | R 0.25 | -5.54  | -6.04 | -3.28  | -0.88  | -0.27 |      |        |
   | E -------------------------------------------------------|  RTT   |
   | S 0.05 | -5.04  | -0.65 | 4.21   | 6.65   | 9.90  |      |        |
   | S 0.15 | -1.02  | 1.58  | 7.21   | 8.24   | 10.07 |  5   |        |
   | H 0.25 | -0.76  | 1.96  | 7.43   | 9.66   | 11.26 |      |        |
   | E ----------------------------------------------------------------
   | L 0.05 | -2.51  | -0.85 | -0.63  | 0.025  | -0.00 |      |        |
   | D 0.15 | -1.50  | -0.63 | -0.02  | 0.052  | -0.02 | 0.95 |        |
   |   0.25 | -0.26  | 0.122 | 0.041  | -0.02  | 0.132 |      |        |
   |   -------------------------------------------------------|  PLT   |
   |   0.05 | -3.50  | 0.422 | 1.899  | 3.339  | 3.770 |      |        |
   |   0.15 | -1.04  | 2.016 | 3.251  | 3.880  | 3.991 |  5   |        |
   |   0.25 | 0.449  | 2.965 | 3.066  | 4.107  | 4.737 |      |        |
    -------------------------------------------------------------------
   Table A.2 Over-admission-percentage for SVD

   It follows from these results that while performance is tolerable
   across the entire range of parameters, choosing the CLE and EWMA
   weights in the middle of the tested range appear to be more
   beneficial for the overall performance across the chosen range of
   overload, assuming the chosen values for the remaining parameters.
   The high level conclusion that can be drawn from Table A.2. is that
   (predictably) high peak-to-mean ratio SVD traffic is substantially
   more stressful to the queue-based admission control algorithm, but a
   set of parameters exists that keeps the overadmission within about
   -3% - +10% of the expected load even for the bursty SVD traffic.

   Note that for SVD traffic these results hold even though there is no
   aggregation at all on a per-ingress-egress pair in the chosen RTT
   topology there is only a single SVD flow per ingress.  In addition,
   there seems to be no visible influence by multiple bottleneck
   topology, as the results appears to be comparable to the ones in
   single bottleneck cases.  (Note that it may seem from the data in
   A.2, PLT out-performs the Single Link.  The reason is that the



Charny, et al.          Expires September 6, 2007              [Page 22]


Internet-Draft           PCN with Single Marking              March 2007


   bottleneck links in PLT happen to be twice the size of the ones in
   SingleLink cases.  Given the same admission threshold, this implies
   that level of aggregation in PLT is twice as much as in the
   SingleLink.  Hence, the better results in PLT should be viewed as the
   effect of the aggregation rather than the effect multi-bottleneck
   topology.)

5.4.2.  Token Bucket-based Results

   Just as for the case of the queue-based algorithm, under the under-
   loaded conditions for voice-like CBR, VBR and VTR traffic the
   sensitivity to the tested parameters remains limited for the token-
   bucket as well (the latter is summarized in Table A.3).

    ----------------------------------------------------------
   |     Over Admission Perc Stat      | Load |  Topo  | Type |
   |  Min   |  Mean  |  Max   |  SD    |      |        |      |
    ----------------------------------------------------------
   |   0    |    0   |    0   |   0    | 0.95 | S.Link |      |
   |---------------------------------------------------|      |
   |   0    |    0   |    0   |   0    | 0.95 |  RTT   | CBR  |
   |---------------------------------------------------|      |
   | -1.17  | -0.24  | 0.023  | 0.294  | 0.95 |  PLT   |      |
    ----------------------------------------------------------
   | -2.00  | -0.78  | -0.95  | 0.268  | 0.95 | S.Link |      |
   |---------------------------------------------------|      |
   | -2.83  | -0.70  | -1.20  | 0.510  | 0.95 |  RTT   | VBR  |
   |---------------------------------------------------|      |
   | -6.19  | -2.43  | -1.32  | 1.223  | 0.95 |  PLT   |      |
    ----------------------------------------------------------
   |   0    |    0   |    0   |   0    | 0.95 | S.Link |      |
   |---------------------------------------------------|      |
   |   0    |    0   |    0   |   0    | 0.95 |  RTT   | VTR  |
   |---------------------------------------------------|      |
   |   0    |    0   |    0   |   0    | 0.95 |  PLT   |      |
    ----------------------------------------------------------
   Table A.3 Summarized performance for CBR, VBR and VTR across
   different settings for under-loaded conditions.

   However, for the overload conditions (overload greater than 1), the
   token bucket-based admission control algorithm shows substantially
   higher sensitivity to the parameter settings compared to the virtual
   queue based algorithm.  Table A.4 shows over-admission-percentage for
   different settings.  It is important to note here that for the token
   bucket-based admission control no traffic will be marked until the
   rate of traffic exceeds the configured admission rate by the chosen
   CLE.  As a consequence, even with the ideal performance of the
   algorithms, the over-admission-percentage will not be 0, rather it is



Charny, et al.          Expires September 6, 2007              [Page 23]


Internet-Draft           PCN with Single Marking              March 2007


   expected to equal to CLE threshold if the algorithm performs as
   expected.  Therefore, a more meaningful metric for the token-based
   results is actually the over-admission-percentage (listed below)
   minus the corresponding (CLE threshold * 100).  For example, for CLE
   = 0.05, one would expect that 5% overadmission is inherently embedded
   in the algorithm, with the algorithm by design reacting to 5%
   overload (or more) only.  Hence, with CLE = 0.05 a 10% over-admission
   in the token-bucket case should be compared to a 5% overadmission in
   the queue-based algorithm.  When comparing the performance of token
   bucket (with the adjusted over-admission-percentage) to its
   corresponding virtual queue result, we found that token bucket
   performs only slightly worse for voice-like CBR VBR, and VTR traffic.

   The results for SVD traffic require some additional commentary.  Note
   from the results in Table A.4. that even for SVD traffic, in the
   Single Link topology the performance of the token-based solution is
   comparable to the performance of the queue-based scheme in table A.2,
   (adjusted by the CLE as discussed above).  However, for the RTT
   topology, especially for the larger EWMA weights, the performance for
   SVD traffic becomes very bad, with up to 42% (adjusted by CLE) over-
   admission in a high overload situation (5x).  We investigated two
   potential causes of this drastic degradation of performance by
   concentrating on two key differences between the Single Link and the
   RTT topologies: the difference in the round-trip times and the degree
   of aggregation in a per ingress-egress pair aggregate.

   To investigate the effect of the difference in round-trip times, we
   also conducted a subset of the experiments described above using the
   RTT topology that has the same RTT across all ingress-egress pairs
   rather than the range of RTTs in one experiment.  We found out that
   neither the absolute nor the relative difference in RTT between
   different ingress-egress pairs appear to have any visible effect on
   the over-load performance or the fairness of both algorithms (we do
   not present these results here as their are essentially identical to
   those in Table A.4).  In view of that and noting that in the RTT
   topology we used for these experiments for the SVD traffic, there is
   only 1 highly bursty flow per ingress, we believe that the severe
   degradation of performance in this topology is directly attributable
   to the lack of traffic aggregation on the ingress-egress pair basis.
   We also note that even for this highly challenging scenario, it is
   possible to find a range of parameters that limit the overadmission
   case for SVD traffic to quite a reasonable range of -3% + 10%
   (adjusted by the CLE).  Luckily, these are the same parameter
   settings that work quite well for the other types of traffic tested.

   The overall performance on the multiple-bottleneck topology, for all
   types of traffic, is comparable to the ones on the SingleLink, just
   as shown in the queue-based results.  Again, the results for the PLT



Charny, et al.          Expires September 6, 2007              [Page 24]


Internet-Draft           PCN with Single Marking              March 2007


   topology may appear better than those of the SingleLink in the table
   below.  As discussed earlier, this is due to the fact that the
   bottleneck capacity of the PLT topology in these experiments is
   higher than that of the SingleLink and RTT, topologies (2.4Gbps vs
   1Gbps), so the bottleneck aggregation is higher for PLT than for both
   single bottleneck topologies.  The ingress-egress aggregation of the
   PLT topology corresponds to that of a SingleLink.

    -------------------------------------------------------------------
   |         |               EWMA  Weights           |Over| Topo | Type|
   |         |  0.1  |  0.3  |  0.5  |  0.7  |  0.9  |Load|      |     |
    -------------------------------------------------------------------
   | C 0.0001| -0.99 | 0.09  | 0.24  | 0.41  | 0.43  |    |      |     |
   | L 0.001 | 0.02  | 0.37  | 0.43  | 0.46  | 0.45  | 5  | S.   |     |
   | E 0.01  | 1.37  | 1.32  | 1.32  | 1.31  | 1.31  |    | Link |     |
   |   ----------------------------------------------------------      |
   | T 0.0001| 6.50  | 7.96  | 8.37  | 8.42  | 8.84  |    |      |     |
   | H 0.001 | 7.07  | 8.54  | 8.65  | 8.55  | 8.66  | 5  | RTT  | CBR |
   | R 0.01  | 7.93  | 9.08  | 8.71  | 8.63  | 9.40  |    |      |     |
   | S ----------------------------------------------------------      |
   | H 0.0001| -1.88 | 0.21  | 0.58  | 0.65  | 0.62  |    |      |     |
   | L 0.001 | -0.31 | 0.69  | 0.63  | 0.61  | 0.56  | 5  | PLT  |     |
   | D 0.01  | 2.032 | 1.98  | 1.97  | 1.99  | 1.96  |    |      |     |
    -------------------------------------------------------------------
    -------------------------------------------------------------------
   | C 0.0001| -2.95 | -1.39 | -0.63 | 0.23  | 0.78  |    |      |     |
   | L 0.001 | -1.51 | -0.23 | 0.44  | 0.63  | 1.39  | 5  | S.   |     |
   | E 0.01  | 1.37  | 2.01  | 2.29  | 2.60  | 2.76  |    | Link |     |
   |   ----------------------------------------------------------      |
   | T 0.0001| -1.93 | -0.23 | 0.99  | 2.09  | 3.38  |    |      |     |
   | H 0.001 | -0.75 | 0.89  | 2.07  | 3.12  | 4.27  | 5  | RTT  | VBR |
   | R 0.01  | 1.91  | 3.42  | 4.35  | 5.36  | 6.38  |    |      |     |
   | S ----------------------------------------------------------      |
   | H 0.0001| -3.78 | -0.57 | 0.35  | 1.08  | 1.82  |    |      |     |
   | L 0.001 | -1.64 | 0.46  | 1.28  | 1.89  | 2.37  | 5  | PLT  |     |
   | D 0.01  | 1.871 | 2.74  | 3.24  | 3.39  | 3.86  |    |      |     |
    -------------------------------------------------------------------
    -------------------------------------------------------------------
   | C 0.0001| -2.37 | 0.00  | 0.79  | 0.83  | 1.07  |    |      |     |
   | L 0.001 | -0.64 | 0.67  | 0.79  | 1.04  | 1.08  | 5  | S.   |     |
   | E 0.01  | 1.59  | 1.64  | 1.66  | 1.79  | 2.04  |    | Link |     |
   |   ----------------------------------------------------------      |
   | T 0.0001| -1.09 | 0.86  | 1.29  | 1.57  | 1.98  |    |      |     |
   | H 0.001 | 0.00  | 1.39  | 1.63  | 1.86  | 2.58  | 5  | RTT  | VTR |
   | R 0.01  | 1.99  | 2.32  | 2.88  | 3.54  | 4.35  |    |      |     |
   | S ----------------------------------------------------------      |
   | H 0.0001| -1.99 | 0.09  | 0.58  | 0.96  | 1.15  |    |      |     |
   | L 0.001 | -0.55 | 0.57  | 1.09  | 1.30  | 1.49  | 5  | PLT  |     |



Charny, et al.          Expires September 6, 2007              [Page 25]


Internet-Draft           PCN with Single Marking              March 2007


   | D 0.01  | 2.22  | 2.44  | 2.42  | 2.61  | 2.65  |    |      |     |
    -------------------------------------------------------------------
    -------------------------------------------------------------------
   |   0.0001| -10.67|-10.58 | -7.95 | -6.27 | -4.99 |    |      |     |
   |   0.001 | -8.67 | -8.04 | -7.61 | -4.37 | -2.89 |0.95|      |     |
   |   0.01  | -4.28 | -2.59 | -4.44 | -2.13 | -2.20 |    | S.   |     |
   | C ---------------------------------------------------| Link |     |
   | L 0.0001| -16.36|-10.24 | -6.50 | -2.17 | 2.74  |    |      |     |
   | E 0.001 | -10.54| -5.63 | -2.70 | 0.94  | 3.54  | 5  |      |     |
   |   0.01  | -4.11 | 1.26  | 5.38  | 5.75  | 8.82  |    |      |     |
   |   ----------------------------------------------------------      |
   | T 0.0001| -15.83|-10.35 | -2.96 | 0.17  | 5.42  |    |      |     |
   | H 0.001 | -12.82| -7.62 | -0.47 | 2.24  | 6.59  |0.95|      |     |
   | R 0.01  | -6.17 | -0.11 | 2.16  | 5.28  | 10.34 |    |      |     |
   | E ---------------------------------------------------| RTT  | SVD |
   | S 0.0001| -8.51 | 1.86  | 11.14 | 22.51 | 30.24 |    |      |     |
   | S 0.001 | -4.80 | 1.49  | 15.35 | 24.56 | 33.96 | 5  |      |     |
   | H 0.01  | 0.56  | 8.26  | 25.71 | 35.63 | 42.72 |    |      |     |
   | O ----------------------------------------------------------      |
   | L 0.0001| -12.35| -8.73 | -7.46 | -5.97 | -5.95 |    |      |     |
   | D 0.001 | -9.06 | -7.66 | -5.99 | -5.19 | -4.77 |0.95|      |     |
   |   0.01  | -5.13 | -4.77 | -4.62 | -3.54 | -3.52 |    |      |     |
   |   ---------------------------------------------------| PLT  |     |
   |   0.0001| -10.07| -5.05 | -3.17 | 0.75  | 2.138 |    |      |     |
   |   0.001 | -7.41 | -3.38 | -0.53 | 1.89  | 5.071 | 5  |      |     |
   |   0.01  | -0.81 | 2.816 | 5.115 | 6.03  | 6.421 |    |      |     |
    -------------------------------------------------------------------
   Table A.4.  Token bucket admission control performance.

   An additional differences in token-bucket case vs the queue-based
   admissions in the PLT topology case revealed in our experiments is
   that there appears to be a consistent relationship between the
   position of the bottleneck link (how far downstream it is) and its
   over-admission-percentage.  In Table A.5, we show a snapshot of the
   behavior with 5 bottleneck topology.  Here, the over-admission-
   percentage displayed is an average across all 15 experiments with
   different [weight, CLE] setting.  (We do observe the same behavior in
   each of the individual experiment, hence providing a summarized
   statistics does not invalidate the results).  The data shows the
   further downstream the bottleneck is, the more it tends to over-
   admit, regardless the type of the traffic.  The exact cause of this
   phenomenon is yet to be explained, but the effect of it seems to be
   insignificant in magnitude, at least in the experiments we ran.








Charny, et al.          Expires September 6, 2007              [Page 26]


Internet-Draft           PCN with Single Marking              March 2007


    --------------------------------------------------------
   | Traffic |            Bottleneck LinkId          | Over |
   |   Type  |   1   |   2   |   3   |   4   |   5   | Load |
    --------------------------------------------------------
   |   CBR   | 0.270 | 0.421 | 0.529 | 0.669 | 0.791 |  5   |
   |--------------------------------------------------------
   |   VBR   | 0.152 | 0.512 | 0.715 | 0.901 | 1.169 |  5   |
   |--------------------------------------------------------
   |   VTR   | 0.350 | 0.492 | 0.756 | 0.874 | 1.125 |  5   |
    --------------------------------------------------------

   Table A.5 Summarized performance for CBR, VBR and VTR across the
   links in the PLT topology for Token Bucket Admission


6.  IANA Considerations

   This document places no requests on IANA.


7.  Security Considerations

   TBD


8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2.  Informative References

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

   [I-D.briscoe-tsvwg-re-ecn-border-cheat]
              Briscoe, B., "Emulating Border Flow Policing using Re-ECN
              on Bulk Data", draft-briscoe-tsvwg-re-ecn-border-cheat-01



Charny, et al.          Expires September 6, 2007              [Page 27]


Internet-Draft           PCN with Single Marking              March 2007


              (work in progress), June 2006.

   [I-D.briscoe-tsvwg-re-ecn-tcp]
              Briscoe, B., "Re-ECN: Adding Accountability for Causing
              Congestion to TCP/IP", draft-briscoe-tsvwg-re-ecn-tcp-03
              (work in progress), October 2006.

   [I-D.davie-ecn-mpls]
              Davie, B., "Explicit Congestion Marking in MPLS",
              draft-davie-ecn-mpls-01 (work in progress), October 2006.

   [I-D.lefaucheur-emergency-rsvp]
              Faucheur, F., "RSVP Extensions for Emergency Services",
              draft-lefaucheur-emergency-rsvp-02 (work in progress),
              June 2006.


Authors' Addresses

   Anna Charny
   Cisco Systems, Inc.
   1414 Mass. Ave.
   Boxborough, MA  01719
   USA

   Email: acharny@cisco.com


   Xinyang (Joy) Zhang
   Cisco Systems, Inc. and Cornell University
   1414 Mass. Ave.
   Boxborough, MA  01719
   USA

   Email: joyzhang@cisco.com


   Francois Le Faucheur
   Cisco Systems, Inc.
   Village d'Entreprise Green Side - Batiment T3 ,
   400 Avenue de Roumanille, 06410 Biot Sophia-Antipolis,
   France

   Email: flefauch@cisco.com







Charny, et al.          Expires September 6, 2007              [Page 28]


Internet-Draft           PCN with Single Marking              March 2007


   Vassilis Liatsos
   Cisco Systems, Inc.
   1414 Mass. Ave.
   Boxborough, MA  01719
   USA

   Email: vliatsos@cisco.com












































Charny, et al.          Expires September 6, 2007              [Page 29]


Internet-Draft           PCN with Single Marking              March 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).





Charny, et al.          Expires September 6, 2007              [Page 30]