Network Working Group                                         J. Babiarz
Internet-Draft                                                  X-G. Liu
Intended status: Informational                                   K. Chan
Expires: May 22, 2008                                             Nortel
                                                                M. Menth
                                                 University of Wuerzburg
                                                       November 19, 2007


                        Three State PCN Marking
                        draft-babiarz-pcn-3sm-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 May 22, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document proposes a mechanism for admission control and flow
   termination.  It is based on the concept of pre-congestion
   notification (PCN) using three different codepoints: "no pre-
   congestion", "admission-stop", and "excess-traffic" for packet
   marking.  Therefore, the proposal is called three state marking



Babiarz, et al.           Expires May 22, 2008                  [Page 1]


Internet-Draft           Three State PCN Marking           November 2007


   (3sm).  The behaviour of edge nodes is presented which distinguishes
   from other proposals through little complexity and its ability to
   cope with multipath routing.  Algorithms required for packet metering
   and marking are explained in detail.















































Babiarz, et al.           Expires May 22, 2008                  [Page 2]


Internet-Draft           Three State PCN Marking           November 2007


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.1.  Requirements Notation  . . . . . . . . . . . . . . . . . .  6
     1.2.  Terminology Used in this Document  . . . . . . . . . . . .  6
     1.3.  Adapted Terminology  . . . . . . . . . . . . . . . . . . .  6
     1.4.  New Terminology  . . . . . . . . . . . . . . . . . . . . .  7
   2.  The 3sm Proposal . . . . . . . . . . . . . . . . . . . . . . .  8
     2.1.  Packet Marking in 3sm  . . . . . . . . . . . . . . . . . .  8
     2.2.  Admission Control in 3sm . . . . . . . . . . . . . . . . .  9
       2.2.1.  Explicit Edge-to-Edge Tunnels (E3Tunnel) . . . . . . .  9
     2.3.  End-to-End on-Path Signalling (End2PS) . . . . . . . . . . 11
       2.3.1.  Operation of Standard RSVP . . . . . . . . . . . . . . 11
       2.3.2.  Modification of Standard RSVP to Perform PCN-Based
               Admission Control  . . . . . . . . . . . . . . . . . . 12
     2.4.  Edge-to-Edge on-Path Signalling (Edge2PS)  . . . . . . . . 12
     2.5.  Flow Termination in 3sm  . . . . . . . . . . . . . . . . . 13
       2.5.1.  Marked Flow Termination (MFT)  . . . . . . . . . . . . 13
       2.5.2.  Measured Rate Termination (MRT)  . . . . . . . . . . . 14
   3.  Three State PCN Marker with Marking Frequency Reduction
       (MFR) for Marked Flow Termination (MFT)  . . . . . . . . . . . 14
     3.1.  ET-Marker  . . . . . . . . . . . . . . . . . . . . . . . . 15
       3.1.1.  Behaviour of SR-Metering and ET-Marking  . . . . . . . 15
       3.1.2.  Pseudo Code for the ET-Marker  . . . . . . . . . . . . 16
       3.1.3.  Configuration of the ET-Marker . . . . . . . . . . . . 16
       3.1.4.  Characteristics of the Proposed ET-Marker  . . . . . . 17
     3.2.  AS-Marker  . . . . . . . . . . . . . . . . . . . . . . . . 17
       3.2.1.  Behaviour of AR-Metering and AS-Marking  . . . . . . . 18
       3.2.2.  Pseudo Code for AS-Marker  . . . . . . . . . . . . . . 18
       3.2.3.  Configuration of the AS-Marker . . . . . . . . . . . . 18
       3.2.4.  Characteristics of the Proposed AS-Marker  . . . . . . 19
     3.3.  Marking Codepoints . . . . . . . . . . . . . . . . . . . . 19
   4.  Benefits and Shortcomings of the 3sm Proposal  . . . . . . . . 19
     4.1.  Benefits . . . . . . . . . . . . . . . . . . . . . . . . . 20
     4.2.  Shortcomings of 3sm  . . . . . . . . . . . . . . . . . . . 21
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   6.  Changes from Previous Revision . . . . . . . . . . . . . . . . 21
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
   8.  Informative References . . . . . . . . . . . . . . . . . . . . 23
   Appendix A.  Overview of Token Bucket (TB) and Virtual Queue
                (VQ)  . . . . . . . . . . . . . . . . . . . . . . . . 24
     A.1.  New features for marking algorithm . . . . . . . . . . . . 24
       A.1.1.  Virtual Queue (VQ) . . . . . . . . . . . . . . . . . . 24
       A.1.2.  Token Bucket (TB)  . . . . . . . . . . . . . . . . . . 25
       A.1.3.  Tail Marking . . . . . . . . . . . . . . . . . . . . . 25
       A.1.4.  Tail Marking with Marking Frequency Reduction (MFR)  . 26
       A.1.5.  Tail Marking with Packet Size Independent Marking
               (PSIM) and Proportional Marking Frequency



Babiarz, et al.           Expires May 22, 2008                  [Page 3]


Internet-Draft           Three State PCN Marking           November 2007


               Reduction (PMFR) . . . . . . . . . . . . . . . . . . . 27
       A.1.6.  Threshold Marking  . . . . . . . . . . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
   Intellectual Property and Copyright Statements . . . . . . . . . . 31















































Babiarz, et al.           Expires May 22, 2008                  [Page 4]


Internet-Draft           Three State PCN Marking           November 2007


1.  Introduction

   Pre-Congestion Notification (PCN) builds on the concepts of
   [RFC3168], "The addition of Explicit Congestion Notification (ECN) to
   IP".  It is used to implement admission control and flow termination
   for real-time flows (such as voice, video and multimedia streaming)
   in DiffServ [RFC2474], [RFC2475] enabled networks.  Flow admission
   control determines whether a new flow can be added into the network
   without overloading any of its links, whereas flow termination
   reduces the current PCN traffic load by terminating marked flows when
   at least one link in the network is overloaded for some reason.  For
   a general overview, the reader is referred to
   [I-D.ietf-pcn-architecture].

   This document describes the 3sm proposal which is a special
   implementation of the general PCN framework
   [I-D.ietf-pcn-architecture].  It relies on three different packet
   markings: "no pre-congestion" (NP), "admission-stop" (AS), or
   "excess-traffic" (ET).  Packets enter a network with NP (unmarked).
   The basic idea is as follows.  Each link in a PCN domain has an
   admissible rate (AR).  If the current PCN traffic rate of a link
   exceeds its AR, all PCN packets on that link are re-marked with AS.
   The PCN egress nodes monitor the packet markings and trigger the PCN
   ingress nodes to admit or reject new flow requests depending on
   whether they observe AS-marked packets or not.  Similarly, each link
   has a supportable rate (SR).  If the current PCN traffic rate of a
   link exceeds its SR, some of the PCN packets on that link are re-
   marked with ET.  The PCN egress nodes detect ET-marked packets and
   pass their flow IDs to the appropriate flow termination entity.  This
   concept is called marked flow termination (MFT).

   The 3sm architecture expects the above mentioned marking behaviour
   from PCN interior nodes.  We propose simple metering and marking
   algorithms for that purpose.  Those are threshold marking for AS-
   marking and tail marking with marking frequency reduction (MFR) for
   ET-marking.  We describe them in Section 3 based on a token bucket
   approach.  To improve the termination behaviour of MFT, we suggest
   packet size independent marking (PSIM) and proportional MFR (PMFR) in
   the Appendix A and show that the same behaviour can be specified
   based on a virtual queue.

   The document is structured as follows.  After a short section on
   terminology, Section 2 focuses on the edge behaviour of the 3sm
   proposal.  Section 3 provides detailed algorithms for the metering
   and marking behaviour expected from interior nodes in 3sm.  Section 4
   list benefits and shortcomings of the 3sm proposal.  Appendix A
   summarizes background information about token bucket (TB) and virtual
   queue (VQ) metering and marking as they are the base for the proposed



Babiarz, et al.           Expires May 22, 2008                  [Page 5]


Internet-Draft           Three State PCN Marking           November 2007


   metering and marking mechanisms.

1.1.  Requirements Notation

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

1.2.  Terminology Used in this Document

   The terminology used in this document conforms to the terminology of
   [I-D.ietf-pcn-architecture].  However, we adapted some terminology
   for better readability and added some new terminology that we found
   useful in this document.

1.3.  Adapted Terminology

   [I-D.ietf-pcn-architecture] has chosen very general terms for the
   rate thresholds as they have different semantic meanings in different
   proposals for the implementation of the general PCN architecture.
   For better readability, we use names that are more intuitive within
   the 3sm proposal.

   o  Admissible rate (AR) - PCN-lower-rate

   o  Supportable rate (SR) - PCN-upper-rate

   o  AR-overload - Condition that PCN traffic rate exceeds AR of a link

   o  SR-overload - Condition that PCN traffic rate exceeds SR of a link

   o  No pre-congestion (NP) - Default marking for PCN packets that have
      not been carried over links with any type of pre-congestion (AR-
      overload or SR-overload).

   o  Admission-stop (AS) - PCN-lower-rate-marking

   o  Excess-traffic (ET) - PCN-upper-rate-marking

   o  AS-marking - Action of re-marking of NP-marked packets to AS

   o  ET-marking - Action of re-marking of NP- or AS-marked packets to
      ET








Babiarz, et al.           Expires May 22, 2008                  [Page 6]


Internet-Draft           Three State PCN Marking           November 2007


1.4.  New Terminology

   We provide a brief definition of the terminology used in this
   document.

   o  PCN - Pre-Congestion Notification meters traffic rates per service
      class on a link and notifies the PCN egress nodes using packet
      marking whether a certain rate threshold is exceeded on any link
      of the path through the PCN-enabled network taken by the packet.
      The rate thresholds may be significantly lower than the line rates
      such that PCN egress nodes are notified long before queues build
      up in the buffers and real congestion occurs.  PCN is intended for
      the implementation of measurement-based admission control and flow
      termination for real-time inelastic traffic, e.g., voice.  The PCN
      marking in the packet headers need to be standardized.

   o  ECN Field - Refers to the use of the standardized two bit field in
      the IP header that is used for signalling Explicit Congestion
      Notification [RFC3168].  In the PCN framework the ECN field maybe
      reused to signal two levels of PCN marking.

   o  Service class - By service class we mean a grouping of packets
      belonging to one or more applications or services that generated
      traffic with similar characteristics and requiring similar QoS
      treatment.  See [RFC4594] for details.

   o  Admission Control - It is the function of admitting or blocking
      requests of new flows or sessions for access to the network to
      prevent AR-overload.

   o  Flow Termination - It is the function of terminating already
      admitted flows in the sense that they cannot continue to send PCN
      traffic.  Only flows contributing to SR-overload are terminated to
      reduce SR-overload.

   o  Deployment model - A method to find the PCN information for the
      path of a new flow that requests admission to the PCN domain and
      to perform the required admission decision.  Deployment models
      take advantage of information or protocols available in the
      networking scenario where PCN is to be deployed.

   o  Marked flow termination (MFT) - Flow termination function
      terminating marked flows.

   o  Measured rate termination (MRT) - Flow termination function
      terminating a certain rate of traffic that was directly or
      indirectly measured by the system.




Babiarz, et al.           Expires May 22, 2008                  [Page 7]


Internet-Draft           Three State PCN Marking           November 2007


   o  Marking frequency reduction (MFR) - Marked flow termination (MFT)
      requires that only some instead of all PCN packets exceeding the
      supportable rate (SR) of a link are marked.  This is achieved by
      MFR.  This can be achieved by adding a slowdown factor of "s"
      tokens to the fill state of the token bucket whenever a packet is
      ET-marked.

   o  Token bucket (TB) - One base mechanism for packet metering.

   o  Virtual queue (VQ) - Another, equivalent base mechanism for packet
      marking.


2.  The 3sm Proposal

   First, a high-level overview of the packet marking in 3sm is
   presented.  Then, the edge behaviour for the admission control and
   flow termination function is explained.

2.1.  Packet Marking in 3sm

   PCN traffic can be classified by DSCP or a group of DSCPs and is
   forwarded by an appropriated PHB.  PCN configures for each link an
   admissible and a supportable rate (AR, SR).  PCN traffic enters the
   network with a "no-precongestion" (NP) mark.  PCN nodes meter the PCN
   traffic on every link.  When the PCN traffic rate on a link exceeds
   the corresponding AR, the PCN node re-marks all NP-marked PCN packets
   to "admission-stop" (AS).

   Similarly, they re-mark some non-ET-marked PCN packets to "excess-
   traffic" (ET) when the PCN traffic rate on a link exceeds the
   corresponding SR.  Figure 1 summarizes the relation between the AR
   and SR thresholds and the marking behaviour.  The SR normally is at
   least a delta above the AR and a delta below the maximum service rate
   for PCN traffic for the sake of stability of the measurement-based
   reactive system.  If the PCN traffic rate is below AR, no packets are
   re-marked; if it is between AR and SR, all NP-marked PCN packets are
   re-marked to AS; and if it is above SR, some non-ET-marked PCN
   packets are re-marked to ET and all other NP-marked PCN packets are
   re-marked to AS.  Hence, the meters and markers operate in a marking-
   aware mode: NP-marked packets can be re-marked to AS or ET, AS-marked
   packets can be re-marked to ET but not to NP, and ET-marked packets
   cannot be re-marked at all.








Babiarz, et al.           Expires May 22, 2008                  [Page 8]


Internet-Draft           Three State PCN Marking           November 2007


              PCN traffic rate
                100%^
                    |   AR- and SR-overload:
                    |   re-mark SOME non-ET-marked
                    |   packets to ET and the remaining to AS,
                    |   indicating that AR and SR are exceeded
    Supportable rate|----------------------------------------------
          SR        |   AR-overload:
                    |   re-mark ALL NP-marked packets to AS,
                    |   indicating admissible rate is exceeded
    Admissible rate |----------------------------------------------
          AR        |
                    |   No overload: do not re-mark any packets
                    |
                  0%+------------------------------------------------->

                 Figure 1: Packet re-marking by PCN nodes.

2.2.  Admission Control in 3sm

   The admission of a flow requests depends on the marking that is
   currently observed on the path the data packet of the future flow
   will take.  However, it is not trivial to provide this information
   and may be achieved differently depending on the networking scenario.
   Therefore, we introduce three deployment models that use their own
   methods to get the PCN information for the path of a future data
   flow.  These deployment models are adapted to special networking
   scenarios that are in use today and are named after the concept that
   helps to find the path of future data packets:

   o  explicit edge-to-edge tunnels (E2Tunnel)

   o  end-to-end on-path signalling (End2PS)

   o  edge-to-edge on-path signalling (Edge2PS)

2.2.1.  Explicit Edge-to-Edge Tunnels (E3Tunnel)

   Explicit edge-to-edge tunnels provide an IP adjacency from a PCN
   ingress node to a PCN egress node.  As a consequence, the information
   about the PCN egress node of a packet can be derived from the routing
   table.  In addition, we assume that each tunnel is set up on an
   explicit path.  This can be realized, e.g. by MPLS label switched
   paths (LSPs) or IP-in-IP tunnelling.  We use the name E3Tunnel to
   abbreviate the term "explicit edge-to-edge tunnel" and as the name
   for the corresponding deployment model.  An E3Tunnel aggregate is the
   ensemble of PCN traffic carries through the PCN domain through a
   common explicit E3Tunnel.



Babiarz, et al.           Expires May 22, 2008                  [Page 9]


Internet-Draft           Three State PCN Marking           November 2007


   In the presence of E3Tunnels, the tunnel a packet is forwarded over
   is derived from the forwarding table of the PCN ingress node.  This
   information is required that a new flow can request admission to the
   appropriate E3Tunnel.  The PCN ingress and egress nodes have a
   context for each E3Tunnel they support.  The PCN ingress node works
   per context in two different modes:

   o  the reject mode and

   o  the accept mode.

   In the reject mode, the PCN ingress node rejects new admission
   requests while it admits them in its accept mode.

   Similarly, the PCN egress node works per context in two corresponding
   modes:

   o  the admission-stop mode and

   o  the admission-continue mode.

   The PCN egress node monitors the markings of the packets received
   from a specific E3Tunnel and depending on their marking, it switches
   to the admission-stop or admission-continue mode.  Depending on its
   mode, the PCN egress node periodically sends "admission-stop" or
   "admission-continue" messages to the PCN ingress node belonging to
   the same E3Tunnel.  If the PCN egress node receives an "admission-
   stop" message, it switches within the corresponding E3Tunnel context
   to its reject mode and if it receives an "admission-continue"
   message, it switches to its accept mode.

   Different algorithms can be applied by the PCN egress node to decide
   when to send which control messages.  We give two examples.

   o  Option 1 (single-packet-based): If the PCN egress node observes a
      single marked packet from a specific E3Tunnel, it turns to the
      admission-stop mode.  It returns to the admission-continue mode
      after some time unless it still observes marked packets
      occasionally.  This option can be implemented without rate
      measurement and even without any counters requiring per-packet
      modification.

   o  Option 2 (CLE-based): The PCN egress node tracks the number of
      marked and umarked packets from a specific E3Tunnel within a
      measurement interval.  It calculates the congestion level estimate
      (CLE) which is the fraction of the marked and all packets observed
      during this interval.  If no packet was received within the last
      measurement interval, the PCN egress node switches to the



Babiarz, et al.           Expires May 22, 2008                 [Page 10]


Internet-Draft           Three State PCN Marking           November 2007


      admission-continue mode.  If the PCN egress node is in the
      admission-continue mode and the CLE of the last measurement
      interval is larger than a predefined admission-stop threshold, it
      switches to the admission-stop mode.  If the PCN egress node is in
      the admission-stop mode and the CLE is smaller than a predefined
      admission-continue threshold, it switches to the admission-
      continue mode.

2.3.  End-to-End on-Path Signalling (End2PS)

   End-to-end on-path signalling sends PATH messages downstream to
   discover the path of future data packets and RESV messages upstream
   to trigger the admission request for the correct forward path using
   the gathered PATH information.  The deployment model End2PS reuses
   the end-to-end on-path signalling protocol for probing on which the
   admission decision is based.  We first explain the basic operation of
   standard RSVP and then adapt it to perform PCN-based admission
   control.

2.3.1.  Operation of Standard RSVP

   A popular protocol example is RSVP [RFC2205].  With RSVP, the data
   source issues a PATH message which is carried hop-by-hop over the
   same path future data packets will go.  To that end, the PATH message
   uses the same source and destination address as future data packets
   and also all other header fields that are possible input for routing
   and load balancing decisions need to be the same.  When a PATH
   message arrives at an RSVP-capable node, a PATH state is established
   pointing to the previous hop before the PATH message is forwarded
   further downstream.  When the PATH message arrives at the
   destination, the destination triggers the end-to-end reservation for
   the flow by sending a RESV message upstream along the nodes that set
   up a PATH state.  In these nodes, the RESV message is processed.  In
   particular, resource admission control is performed for the new flow
   request and if it succeeds, the node forwards the RESV message to the
   previous hop recorded by the PATH state.  This two pass signalling
   approach guarantees that the reservation is done on the downstream
   path of the future data flow.  In contrast to PATH messages, RESV
   messages have the source address of the sending node and the
   destination address of the hop pointed to by the PATH state.  That
   way, the information about the downstream next hop of the future data
   stream is conveyed to the previous hop and the flow-related
   information is stored in a RESV state.  RSVP is a soft-state
   protocol, i.e., the PATH and RESV control messages are periodically
   sent to keep the PATH and RESV states alive and, thereby, the flow
   reservations.  Admission control needs to be performed for a flow
   only once when no RESV state is set up, yet.




Babiarz, et al.           Expires May 22, 2008                 [Page 11]


Internet-Draft           Three State PCN Marking           November 2007


2.3.2.  Modification of Standard RSVP to Perform PCN-Based Admission
        Control

   We assume that interior nodes of a PCN domain are RSVP-disabled.
   That means that they just forward RSVP messages without processing
   them and PCN ingress and egress nodes are neighboring RSVP-capable
   nodes.  As a consequence, PCN ingress nodes decide whether new flows
   can be admitted and carried through domain or not.

   When the initial PATH message travels downstream, it is either marked
   or not, and eventually received by the PCN egress node.  If no PATH
   state can be found for this flow at the PCN egress node, this PATH
   message is the first one and not a REFRESH message.  If the PATH
   message is the first of the flow and if it is marked with "admission-
   stop", the RSVP engine sends back a PATHERR message to reject the
   flow.  If the PATH message is not marked (NP), the RSVP PATH state is
   established at the PCN egress node and the PATH message is forwarded
   further downstream.  REFRESH messages are just forwarded according to
   standard RSVP.  When the PATH message arrives at the destination and
   a RESV message is sent.  Eventually, the corresponding RESV message
   arrives at the PCN ingress node.  When no RESV state is set up yet,
   this is the first RESV message and admission control must be
   performed.  By the mere fact that the RESV message arrives, the PCN
   ingress node knows that the corresponding initial PATH message was
   not marked.  Thus, it can admit any flow for which a new RESV message
   arrives.

   A single probe is sufficient in 3sm because 3sm marks all packets
   when AR-overload occurs.  Note that RSVP is only an example for
   End2PS, but End2PS works equally well with other two pass on-path
   signalling protocols.

2.4.  Edge-to-Edge on-Path Signalling (Edge2PS)

   In the absence of explicit edge-to-edge tunnels or other on-path
   signalling protocols, PCN information about the path future packets
   of a new flow will take is required for a qualified admission
   decision at the PCN ingress node.  To that end, we propose to use an
   edge-to-edge on-path signalling protocol (Edge2PS).

   Again, we assume that all interior nodes of the PCN domain are RSVP-
   disabled.  When a request for the admission of a new flow arrives,
   e.g. signalled via SIP INVITE or other means, the PCN ingress and
   egress node act as RSVP proxies for the source and destination node
   of the data flow and set up a reservation request between PCN ingress
   and egress node.  The source and destination address of the PATH
   messages are those of the actual data flow.  This guarantees that
   they are carried on the same path as future data packet will be.  The



Babiarz, et al.           Expires May 22, 2008                 [Page 12]


Internet-Draft           Three State PCN Marking           November 2007


   PCN edge nodes do not forward the RSVP control messages outside the
   PCN domain.  Instead, the PCN egress node returns a RESV message to
   the PCN ingress node.  The RSVP messages created by PCN nodes on
   behalf of the flow need to be discerned somehow from regular end-to-
   end RSVP messages because they must not be forwarded outside the PCN
   domain.

   With this addition, the above presented modification of standard RSVP
   can be used to admit flows based on a single probe message.  Note
   that there is no stringent need to use RSVP for Edge2PS.  A less
   complex two-pass protocol suffices.

2.5.  Flow Termination in 3sm

   Although flows are admitted only if the PCN traffic rate does not
   exceed the admissible rate (AR) on any link of their paths, it is
   possible that the PCN traffic rate on a link exceeds the SR, e.g.,
   due to changed sending behaviour of admitted flows or due to route
   changes after a failure.

   With 3sm two different options for flow termination can be supported:
   marked flow termination (MFT) and measured rate termination (MRT).
   We explain them in the following.

2.5.1.  Marked Flow Termination (MFT)

   Each PCN egress node monitors its received PCN traffic.  If it
   detects an ET-marked packet, the corresponding PCN ingress node is
   identified and the PCN egress node sends the flow ID belonging to the
   ET-marked packet in a "traffic-reduction" message to the flow
   termination entity (e.g. the appropriate PCN ingress node) for
   termination.  To save signalling overhead, several IDs may be
   signalled in a single "traffic reduction" message.

   Marked flow termination can be applied with any deployment model.
   How the PCN ingress node of an ET-marked packet is derived depends on
   the deployment model:

   o  E3Tunnel: the adjacency from which the packet is received defines
      the E3Tunnel such that the corresponding PCN ingress node is
      known.

   o  With End2PS or Edge2PS, the PCN egress nodes can map the packets
      to RSVP reservations using RSVP classifiers, and the corresponding
      RSVP PATH state contains the address of the PCN ingress node.

   Marked flow termination (MFT) requires that only some of the packets
   that exceed the supportable rate are ET-marked.  Otherwise, MFT



Babiarz, et al.           Expires May 22, 2008                 [Page 13]


Internet-Draft           Three State PCN Marking           November 2007


   terminates too many flows.  With MFT, only a small fraction of the
   traffic is removed within a round-trip time, but the process
   continues if the PCN traffic rate still exceeds the supportable rate
   (SR).  Therefore, the PCN traffic rate is gradually reduced until it
   drops below SR.  Then, the flow termination process stops since no
   more packets are ET-marked.

2.5.2.  Measured Rate Termination (MRT)

   Measured rate termination can be applied only in the E3Tunnel
   deployment model.  It requires that all packets exceeding SR are ET-
   marked.  The PCN egress nodes measure the rate of ET-marked (ETR)
   packets per E3Tunnel and if it is larger than zero, it signals that
   ETR to the corresponding flow termination entity in a "traffic-
   reduction" message.  The flow termination entity may be the
   corresponding PCN ingress node which then terminates a subset of the
   flows carried over the respective E3Tunnel such that the rate of
   these flows is about ETR.  However, this is not an easy task since
   the actual rates of the flows are in general not known.  If SR-
   overload continues in spite of the flow termination, the PCN egress
   node must wait some time before it sends a new "traffic-reduction"
   message to guarantee that the impact of the previous one is already
   reflected by the new measured rate of ET-marked traffic (ETR).

   Measured rate termination can reduce SR-overload very quickly, but it
   has several drawbacks:

   o  Rate measurement of ET-marked packets is complex.

   o  The choice of the right subset of flows is difficult and requires
      that the rates of individual flows are known.

   As marked flow termination (MFT) is simpler than measured rate
   termination (MRT), we propose MFT as preferred method for flow
   termination in 3sm.


3.  Three State PCN Marker with Marking Frequency Reduction (MFR) for
    Marked Flow Termination (MFT)

   The three state PCN marker (3sm) meters PCN packet streams per link
   and performs packet re-marking according to Figure 1.  As a
   consequence the following three marking states are required:

   o  no pre-congestion (NP),

   o  admission-stop (AS), and




Babiarz, et al.           Expires May 22, 2008                 [Page 14]


Internet-Draft           Three State PCN Marking           November 2007


   o  excess-traffic (ET).

   In theory, the meter meters each packet and passes the packet and the
   metering result to the marker, and the marker marks packets according
   to the results of the meter.  This is illustrated in Figure 2.  The
   marking may be coded in the ECN field [RFC3168] of the packet for a
   specified PHB in a specific manner.

                         +------------+
                         |   Result   |
                         |            V
                     +-------+    +--------+
                     |       |    |        |
   Packet stream ===>| Meter |===>| Marker |===> Marked packet stream
                     |       |    |        |
                     +-------+    +--------+

           Figure 2: Block diagram of meter and marker function.

   The behaviour of the two functions is often described by a single
   metering and marking algorithm.  Therefore, we call the algorithm
   metering packets relative to admissible rate (AR) and re-marking them
   to AS simply AS-marker, and the algorithm metering packets relative
   to supportable rate (SR) and re-marking them to ET simply ET-marker.

   In the following, we explain the behaviour of the ET- and AS-marker
   using token bucket (TB) based algorithms.  The packet sizes counted
   by the meters and markers pertain to the size of the IP packet
   including its header bytes.  Equivalent virtual queue (VQ) based
   algorithms are presented in Appendix A.  Other implementations
   approximating the described behaviours can be used.

3.1.  ET-Marker

   We describe the behaviour for SR-metering and ET-marking, present
   pseudo code, explain its configuration, and discuss its behaviour.
   We use object-oriented notation for most variables.

3.1.1.  Behaviour of SR-Metering and ET-Marking

   We propose an ET-marker based on a token bucket with tail marking and
   marking frequency reduction (see Appendix A for explanation of
   different options).  The TB has a bucket of size TB.size which is
   continuously filled with tokens at rate TB.rate.  When a 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 slowdown parameter



Babiarz, et al.           Expires May 22, 2008                 [Page 15]


Internet-Draft           Three State PCN Marking           November 2007


   "s" reduces the marking frequency of the algorithm.

3.1.2.  Pseudo Code for the ET-Marker

   The behaviour of the token bucket with tail marking and marking
   frequency reduction for SR-metering and ET-marking is expressed by
   the following pseudo code.  It requires the time variable
   TB.lastUpdate indicating when the fill state of TB was last updated
   and a global variable "now" providing the current time.  A PCN packet
   has the variables packet.mark showing its marking (NP, AS, ET) and
   packet.size showing its size.

    Input: pcn packet

      TB.fill = min(TB.size, TB.fill + TB.rate * (now - TB.lastUpdate));
      TB.lastUpdate = now;
      if (TB.fill < packet.size)
          packet.mark = ET;
          TB.fill = min(TB.size, TB.fill + s);
      else
          TB.fill = TB.fill - packet.size;
      endif

    Output: void

   Several enhancements of this algorithm are presented in
   Appendix A.1.5.  It marks packet independent of its size and applies
   MFR proportionally to the packet size.  Early results show that this
   equalizes the termination probability for flows with different packet
   sizes and makes the time to remove the overload independent of packet
   sizes.  In addition, MFR is also applied when packets are already ET-
   marked by previous nodes.  This reduces the potential overtermination
   in case of multiple bottleneck links.  These enhancements are simple,
   but still make the algorithm slightly more complex.  Therefore, more
   performance results and discussions are needed to decide whether
   these enhancements should be standard marking behaviour or not
   [I-D.babiarz-pcn-explicit-marking], [I-D.menth-pcn-performance].

3.1.3.  Configuration of the ET-Marker

   The following parameters must be configured:

   o  TB.rate: supportable rate (SR)

   o  TB.size: supportable burst size (SBS), needs to be set
      appropriately





Babiarz, et al.           Expires May 22, 2008                 [Page 16]


Internet-Draft           Three State PCN Marking           November 2007


   o  Slowdown parameter "s": needs to be set appropriately

3.1.4.  Characteristics of the Proposed ET-Marker

   The proposed algorithm can be applied with and without marking
   frequency reduction (MFR), i.e., s>0 and s=0, respectively.

   a) No marking frequency reduction (noMFR, s=0)

   If the slowdown parameter is set to s=0, MFR is switched off.  As an
   alternative, a simplified version of the given algorithm can be used.
   If the PCN traffic rate on a link constantly exceeds its SR, the fill
   state of the TB decreases.  Arriving packets for which the number of
   tokens in the bucket does not suffice are ET-marked.  The size of the
   token bucket (supportable burst size (SBS)) controls how fast the
   marker reacts to a traffic rate above SR: if it is set to a low
   value, packets are already marked at a rate lower than SR in the
   presence of bursts, if it set to a high value, marking starts delayed
   if the PCN traffic rate exceeds SR.  A nice property of this option
   is that the rate of the ET-marked packets is exactly the rate of the
   traffic that exceeds SR (excess traffic rate) under the assumption
   that there was no packet loss.  This observation can be used for
   "measured rate termination" (MRT): the rate of ET-marked traffic is
   measured per ingress-egress aggregate by the PCN egress node and
   signalled to the corresponding flow termination entity.

   Measured rate termination (MRT) is also an option to realize flow
   termination in 3sm, but the preferred option for 3sm is marked flow
   termination (MFT).  The drawback of "no MFR" arises in conjunction
   with MFT.  Then too many packets are ET-marked and too many flows are
   terminated.  That is the motivation to reduce the marking frequency
   by setting s>0.

   b) Marking frequency reduction (MFR, s>0)

   If the slowdown parameter is set to a value s>0, MFR is achieved
   because for each marked packet up to additional "s" bytes that exceed
   SR can pass the ET-marker without being re-marked to ET.  Thus,
   increasing the slowdown parameter "s" decreases the number of ET-
   marked packets in a short time period.  In combination with MFT, a
   suitable "s" is required to achieve a fast termination of
   sufficiently many flows without terminating more flows than
   necessary.

3.2.  AS-Marker

   We explain the behaviour for AR-metering and AS-marking, present
   pseudo code, explain its configuration, and discuss its behaviour.



Babiarz, et al.           Expires May 22, 2008                 [Page 17]


Internet-Draft           Three State PCN Marking           November 2007


3.2.1.  Behaviour of AR-Metering and AS-Marking

   We propose an AS-marker based on a token bucket with threshold
   marking (see Appendix A for explanation of different options).  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 fillstate 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.

   The AS-marker is sensitive to ET-markings in the sense that only non-
   ET-marked packets are considered for remarking.

3.2.2.  Pseudo Code for AS-Marker

   The behaviour of the token bucket with threshold marking for AR-
   metering and AS-marking is expressed by the following pseudo code
   using the same nomenclature like above.

   Input: pcn packet

      TB.fill = min(TB.size, TB.fill+TB.rate*(now-TB.lastUpdate));
      TB.lastUpdate = now
      if (packet.mark <> ET) //mark only non-ET-marked packets
        if (TB.fill < TB.threshold)
            packet.mark = AS;
        endif
        TB.fill = max(0, TB.fill - packet.size);
      endif

   Output: void

3.2.3.  Configuration of the AS-Marker

   The following parameters must be configured:

   o  TB.rate: admissible rate (AR)

   o  TB.size (TBS): admissible burst size (ABS) needs to be set
      appropriately

   o  TB.threshold: needs to be set appropriately




Babiarz, et al.           Expires May 22, 2008                 [Page 18]


Internet-Draft           Three State PCN Marking           November 2007


3.2.4.  Characteristics of the Proposed AS-Marker

   If the AR is exceeded, the TB fill state continuously decreases, it
   eventually falls below its marking threshold TB.threshold, and it
   only increases again if the PCN traffic rate on the link falls below
   AR.  As a consequence, all packets are AS-marked during that time and
   admission of further flows is stopped until the PCN traffic rate
   drops below AR.  In particular, all probe packets are AS-marked.

   [TR437] investigates the impact of the TB parameters on the marking
   characteristics, i.e. the percentage of marked packets depending on
   the PCN traffic rate relative to AR.  If the PCN traffic rate is
   above AR, all packets must be marked with AS.  To that end,
   TB.threshold must be set large enough.  If the PCN traffic rate is
   below AR, no packets should be marked.  To that end TB.size-
   TB.threshold must be set large enough.  Then, we get marking with
   clear decisions, i.e. packets are marked if the PCN rate is above AR
   and they are not marked if the PCN rate is below AR.  This type of
   marking is required for 3sm.  [I-D.menth-pcn-performance] provides a
   summary of [TR437].

3.3.  Marking Codepoints

   PCN metering and marking requires classification of traffic which is
   subject to PCN metering and PCN marking (PCN-capable).  Furthermore,
   PCN-aware flows that are subject to PCN-marking require at least the
   following codepoints:

   o  "no-precongestion" (NP),

   o  "admission-stop" (AS), and

   o  "excess-traffic" (ET).

   These signals may be encoded by re-using the two-bit ECN field or by
   different DS codepoints.  The actual encoding is out of the scope of
   this document.


4.  Benefits and Shortcomings of the 3sm Proposal

   This section highlights some benefits of the 3sm proposal that we
   think are important.  Some of them are based on performance results
   reported in [SIM-07], [I-D.babiarz-pcn-explicit-marking],
   [I-D.menth-pcn-performance], and [TR437].






Babiarz, et al.           Expires May 22, 2008                 [Page 19]


Internet-Draft           Three State PCN Marking           November 2007


4.1.  Benefits

   o  3sm does not require the standardization of the exact algorithm in
      the PCN interior node but only the standardization of the
      behavior.

   o  3sm does not require periodic transmission of measurement results
      from PCN egress to PCN ingress.

   o  The supportable rate of a link can be chosen independently of the
      admissible rate as long as it is not smaller.  This is maximum
      freedom and does not imply any degradation in resource efficiency
      for resilient admission control [PCN-Config].

   o  3sm works well with multipath routing due to marked flow
      termination and the application of probing when needed.

      *  A flow is terminated only if it is carried over an SR-
         overloaded path and if one of its packets was ET-marked.
         Therefore, its termination reduces the SR-overload on a
         bottleneck link.

      *  Conversely, flows that are not carried over a bottleneck link
         cannot be ET-marked and, therefore, not terminated.

   o  Marked flow termination is very robust

      *  The slowdown factor "s" can be reasonably chosen such that the
         time to remove the overload is short and that not more traffic
         than necessary is terminated.

      *  It works well with low and high packet loss.  Packet loss just
         increases the time to remove the overload.

      *  It works well with a small and large number of flows.  In
         particular, the right number of flows is terminated if there is
         only one flow per aggregate and an SR-overload of, e.g., 30%.

      *  It works well with constant bit rate (CBR) voice, on/off voice,
         and variable bit rate (VBR) traffic.  It is not very sensitive
         to different traffic characteristics [SIM-07].

      *  It works well with multiple bottleneck links in the path of a
         flow.

      *  It works well with flows that have significantly different
         round-trip times (RTT) or flow termination delays.  In
         particular, flows with different RTTs suffer the same flow



Babiarz, et al.           Expires May 22, 2008                 [Page 20]


Internet-Draft           Three State PCN Marking           November 2007


         termination probability.

      *  In case of terminating bidirectional flows, the termination of
         a flow entails the termination of the downstream and upstream
         flow.  In case of overload on both the downstream and upstream
         path, flows are terminated on both path.  This leads to
         increased termination aggressiveness.  However, marked flow
         termination leads only to little overtermination as it
         terminates traffic only gradually.

      *  Different slowdown factors "s" may be used for the
         configuration of marking frequency reduction on different links
         within a single PCN domain.

      *  It leads to higher termination probabilities for flows with
         larger packets.  This can be repaired by packet size
         independent marking (PSIM, in Appendix A.1.5)

4.2.  Shortcomings of 3sm

   o  Marked flow termination leads to higher termination probabilities
      for flows with larger packet frequency (higher rate flows).
      Currently, there is no mechanism to improve this.


5.  Security Considerations

   The Three State PCN Marker has no known security concerns.


6.  Changes from Previous Revision

   Changes in version -01 compared to version -00:

   * Abstract: adapted: more general, better summary

   * shortened introduction and adapted it to new document structure

   * put "1.3 Terminology" into separate section, clarification and some
   minor changes

   * put "1.2 Overview of PCN" into a separate section on 3sm edge
   behaviour

   * added more structure and content to that section

   o  deployment scenarios for admission control




Babiarz, et al.           Expires May 22, 2008                 [Page 21]


Internet-Draft           Three State PCN Marking           November 2007


   o  added measured rate termination (MRT) as a non-preferred option to
      marked flow termination (MFT) in 3sm

   * introduced AS-meter as abbreviation for AR-metering and AS-marking
   function

   * introduced ET-meter as abbreviation for SR-metering and ET-marking
   function

   * removed comment about similarity of 3sm marking and srTCM (RFC2697)

   * current 3.1 did some reformulation and added some new simulation
   insights, moved optimizations into Appendix A.1.5

   * current 3.2 did some reformulation and added some new simulation
   insights, changed the AS-marker according to

   o  Joe Babiarz's comment saying all packets need to be considered for
      AR-metering

   o  Bob Brisco's comment saying TB.fill should be set to zero if it is
      smaller than packet.size

   o  provided insights for the setting of TB parameters to obtain
      desired marking behaviour

   * new section on benefits of the 3sm proposal added

   * A.1 - A.1.4 minor changes (rewording)

   * A.1.5 new section on optimization for 3sm marker (PSIM, PMFR, MFR
   for already marked packets)

   * A.1.6 simplified threshold marking according to Bob's comments

   * old A.6 Section on Related Work (srTCM) removed as srTCM without
   change cannot be reused for implementation of threshold marking

   * removed Appendix B and integrated the comments into the previous
   sections of the document if necessary


7.  Acknowledgements

   The authors would like to thank the following people for reviewing
   this draft or earlier versions thereof and for their suggestions to
   make this document more complete: Dave McDysan, Nicolas Chevrollier,
   Frank Lehrieder, Bob Brisco, and Ben Strulo.



Babiarz, et al.           Expires May 22, 2008                 [Page 22]


Internet-Draft           Three State PCN Marking           November 2007


8.  Informative References

   [I-D.babiarz-pcn-explicit-marking]
              Liu, X. and J. Babiarz, "Simulations Results for 3sM",
              draft-babiarz-pcn-explicit-marking-01 (work in progress),
              July 2007.

   [I-D.ietf-pcn-architecture]
              Eardley, P., "Pre-Congestion Notification Architecture",
              draft-ietf-pcn-architecture-01 (work in progress),
              October 2007.

   [I-D.menth-pcn-performance]
              Menth, M. and F. Lehrieder, "Performance Evaluation of
              PCN-Based Algorithms", draft-menth-pcn-performance-00
              (work in progress), November 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.

   [PCN-Config]
              Menth, M. and M. Hartmann, "PCN-Based Resilient Network
              Admission Control: The Impact of a Single Bit", (http://
              www3.informatik.uni-wuerzburg.de/staff/menth/Publications/
              Menth07-PCN-Config.pdf)", 2007.

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

   [RFC2205]  Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, September 1997.

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              December 1998.

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, December 1998.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, September 2001.



Babiarz, et al.           Expires May 22, 2008                 [Page 23]


Internet-Draft           Three State PCN Marking           November 2007


   [RFC4594]  Babiarz, J., Chan, K., and F. Baker, "Configuration
              Guidelines for DiffServ Service Classes", RFC 4594,
              August 2006.

   [SIM-07]   Liu, X-G. and J. Babiarz, "Simulation Results for Explicit
              PCN Marking and Flow Termination
              (http://standards.nortel.com/pcn/Simulation_EPCN.pdf)",
              February 2007.

   [TR437]    Menth, M. and F. Lehrieder, "Comparison of Marking
              Algorithms for PCN-Based Admission Control, Technical
              Report No. 437, (http://               www-
              info3.informatik.uni-wuerzburg.de/TR/tr437.pdf)",
              October 2007.


Appendix A.  Overview of Token Bucket (TB) and Virtual Queue (VQ)

   Token buckets (TB) and virtual queues (VQ) are equivalent base
   mechanisms for algorithms to control whether a packet is conform to
   its flow's indicated rate R and burst size S. Therefore, TB
   parameters are frequently used as traffic descriptors.  TBs and VQs
   are dual approaches: while packets are TB-conform as long as
   sufficient tokens are in the bucket at their arrival times, they are
   VQ-conform as long as sufficient free space is available in the queue
   at their arrival times.  Therefore, TBs and VQs can be used
   interchangeably and, in particular, algorithms given based on a TB
   description can be implemented by a VQ and vice-versa.

   In the following, we explain the basic VQ and TB mechanisms
   (Appendix A.1.1 and Appendix A.1.2).  Packets are marked depending on
   the state of the VQ or TB at their arrival time.  There are different
   marking options.  Only those packets that are not conform to its flow
   description may be marked (tail marking, Appendix A.1.3), or only
   some non-conforming packets may be marked (tail marking with marking
   frequency reduction, Appendix A.1.4), or all packets may be marked
   until the flow again reaches conformity (threshold marking,
   Appendix A.1.6).

A.1.  New features for marking algorithm

A.1.1.  Virtual Queue (VQ)

   We use an object-oriented notation for a more intuitive readability
   of the algorithms.  The VQ has a VQ rate (VQ.rate) and a queue which
   is capable to store up to VQ.size bytes.  The current length of the
   queue is denoted by VQ.length.  This length is reduced over time at
   rate VQ.rate.  When a packet arrives, it is "accepted" by the VQ and



Babiarz, et al.           Expires May 22, 2008                 [Page 24]


Internet-Draft           Three State PCN Marking           November 2007


   increments VQ.length by its size (packet.size) if there is still
   enough free space in the queue to accommodate it; otherwise it is
   "rejected".  As the queue size is decreased continuously over time,
   the behaviour of a VQ is best described by a fluid model.  However,
   the state of the VQ shortly after packet arrivals can be calculated
   based on the current time "now" and the length of the VQ at the last
   update time of the VQ (VQ.lastUpdate) using the following algorithm:

   VQ.length = max(0, VQ.length - (now - VQ.lastUpdate) * VQ.rate);
   VQ.lastUpdate = now;
   if (VQ.length + packet.size <= VQ.size)
           VQ.length = VQ.length + packet.size;
   endif

A.1.2.  Token Bucket (TB)

   The TB is basically the same mechanism, but it looks at the problem
   from a different angle.  The TB has a rate (TB.rate) and a bucket
   which is capable to store up to TB.size tokens.  A token is the
   permission to send one byte.  The current fill state of the bucket is
   denoted by TB.fill.  This fill state is increased over time at rate
   TB.rate.  When a packet arrives, it is "accepted" and decrements
   TB.fill by its size (packet.size) if there are enough tokens in the
   bucket to send the entire packet; otherwise it is "rejected".  As the
   fill state is increased continuously over time, the behaviour of a TB
   is best described by a fluid model.  However, the state of the TB
   shortly after packet arrival can be calculated based on the current
   time "now" and the fill state of the TB at the last update time of
   the TB (TB.lastUpdate) using the following algorithm:

   TB.fill = min(TB.size, TB.fill + (now - TB.lastUpdate) * TB.rate);
   TB.lastUpdate = now;
   if (TB.fill >= packet.size)
           TB.fill = TB.fill - packet.size;
   endif

A.1.3.  Tail Marking

   To control whether packets of a stream with rate R and maximum burst
   size MBS are conform to the description R and MBS, the stream is
   metered either by a VQ with VQ.rate=R and VQ.size=MBS, or by a TB
   with TB.rate=R and TB.size=MBS.  If a packet is accepted by the VQ or
   by the TB, it is marked in-profile.  If it is rejected, it is marked
   out-of-profile.

   The corresponding pseudo codes are for the VQ:





Babiarz, et al.           Expires May 22, 2008                 [Page 25]


Internet-Draft           Three State PCN Marking           November 2007


   VQ.length = max(0, VQ.length - (now - VQ.lastUpdate) * VQ.rate);
   VQ.lastUpdate = now;
   if (VQ.length + packet.size <= VQ.size)
           VQ.length = VQ.length + packet.size;
           packet.mark = in-profile;
   else
           packet.mark = out-of-profile;
   endif

   and for the TB:

   TB.fill = min(TB.size, TB.fill + (now - TB.lastUpdate) * TB.rate);
   TB.lastUpdate = now;
   if (TB.fill >= packet.size)
           TB.fill = TB.fill - packet.size;
           packet.mark = in-profile;
   else
           packet.mark = out-of-profile;
   endif

A.1.4.  Tail Marking with Marking Frequency Reduction (MFR)

   The objective of tail marking with MFR is to mark only some of the
   packets that are out-of-profile.  The strength of the reduction can
   be controlled by the slowdown parameter "s".  When a packet is
   classified out-of-profile, the VQ length is decremented by "s" bytes
   and the TB fill state is incremented by "s" tokens, respectively.  As
   a consequence, the VQ and the TB are not likely to mark consecutive
   packets as out-of-profile which reduces their marking frequency.

   The corresponding pseudo codes are for the VQ:

   VQ.length = max(0, VQ.length - (now - VQ.lastUpdate) * VQ.rate);
   VQ.lastUpdate = now;
   if (VQ.length + packet.size <= VQ.size)
           VQ.length = VQ.length + packet.size;
           packet.mark = in-profile;
   else
      VQ.length = max(0, VQ.length-s); //marking frequency reduction
           packet.mark = out-of-profile;
   endif

   and for the TB:








Babiarz, et al.           Expires May 22, 2008                 [Page 26]


Internet-Draft           Three State PCN Marking           November 2007


   TB.fill = min(TB.size, TB.fill + (now - TB.lastUpdate) * TB.rate);
   TB.lastUpdate = now;
   if (TB.fill >= packet.size)
           TB.fill = TB.fill - packet.size;
           packet.mark = in-profile;
   else
     TB.fill = min(TB.size, TB.fill+s) //marking frequency reduction
      packet.mark = out-of-profile;
   endif

   If the slowdown parameter is set to s=0, the marking algorithm
   behaves like pure tail marking.

A.1.5.  Tail Marking with Packet Size Independent Marking (PSIM) and
        Proportional Marking Frequency Reduction (PMFR)

   For the sake of fairness, large packets should not have a larger
   packet marking probability; otherwise this creates incentives to send
   many small packets instead of a few large packets.  Therefore, we
   propose to test a packet arrival whether an MTU can still be
   supported.  Then, the marking probability depends only on VQ.length
   or TB.fill, respectively.

   For the sake of better control of the termination aggressiveness,
   more flows should be marked and terminated in the presence of low bit
   rate flows than in the presence of high bit rate flows.  To that end,
   we propose to remove (VQ) or add (TB) the slowdown factor
   proportionally to the packet size.

   The reason for adding "s" tokens to the bucket when a packet is
   marked is the anticipation of the termination of that flow.  This is
   done to approximate the fill state with this flow already being
   terminated in order to avoid that too many additional flows are
   marked.  The same condition is met when an already ET-marked packet
   arrives at the ET-marker.  Therefore, the same slowdown factor "s" is
   added to the bucket of the ET-marker as if it had ET-marked the
   packet itself.  This is done to avoid that more traffic than
   necessary is terminated in case that a traffic aggregate crosses
   several bottleneck links.  However, this situation is rather unlikely
   and the effect is well visible only under pathologic conditions.
   Therefore, optimal behaviour is not crucial and the algorithm may be
   simplified by ignoring packets that are already ET-marked.

   These are obvious enhancements of the base algorithm, but they are
   only recommended when solid performance results indicate that the
   improvements have a significant impact in practice.  These studies
   are still ongoing.




Babiarz, et al.           Expires May 22, 2008                 [Page 27]


Internet-Draft           Three State PCN Marking           November 2007


   The following pseudo codes incorporate all proposed enhancements.  We
   give them for a VQ approach:

   VQ.length = max(0, VQ.length - (now - VQ.lastUpdate) * VQ.rate);
   VQ.lastUpdate = now;
   if (packet.mark<>ET)
      if (VQ.length + MTU <= VQ.size)                     // PSIM
         VQ.length = VQ.length + packet.size;
      else
         VQ.length = max(0, VQ.length-s*paket.size/MTU);  // PMFR
         packet.mark = ET;
      endif
   else
      VQ.length = max(0, VQ.length-s*paket.size/MTU);     // PMFR
   endif

   and for the TB:

   TB.fill = min(TB.size, TB.fill + (now - TB.lastUpdate) * TB.rate);
   TB.lastUpdate = now;
   If (packet.mark<>ET)
      if (TB.fill >= MTU)                                 // PSIM
         TB.fill = TB.fill - packet.size;
      else
         TB.fill = min(TB.size, TB.fill+s*packet.size/MTU) // PMFR
         packet.mark = ET;
      endif
   else
      TB.fill = min(TB.size, TB.fill + s*packet.size/MTU); // PMFR
   endif

A.1.6.  Threshold Marking

   The objective of threshold marking is to mark all packets with, e.g.,
   "rate-exceeded" as long as some packets are out-of-profile with
   respect to flow parameters R and MBS.  We achieve that by setting the
   VQ or TB size larger than MBS.  Packets are marked if the VQ length
   exceeds MBS or if the fill state of the TB falls below TB.size-MBS.
   Furthermore, the packet size is always added to the queue or removed
   from the bucket.  Note that marking thresholds need to be configured
   differently for VQ and TB to obtain the same behaviour:

   o  VQ.threshold = MBS;

   o  TB.threshold = TB.size - MBS.

   The corresponding pseudo codes are for the VQ:




Babiarz, et al.           Expires May 22, 2008                 [Page 28]


Internet-Draft           Three State PCN Marking           November 2007


   VQ.length = max(0, VQ.length - (now - VQ.lastUpdate) * VQ.rate);
      VQ.lastUpdate = now;
      if (VQ.length > VQ.threshold)
         packet.mark = "rate-exceeded"; // packet out-of-profile
      endif
      VQ.length = min(VQ.size, VQ.length + packet.size);

   and for the TB:

   TB.fill = min(TB.size, TB.fill + (now - TB.lastUpdate) * TB.rate);
      TB.lastUpdate = now;
      TB.fill = TB.fill - packet.size;
      if (TB.fill < TB.threshold)
          packet.mark = "rate-exceeded"; // packet out-of-profile
      endif
      TB.fill = max(0, TB.fill - packet.size);


Authors' Addresses

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

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


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

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













Babiarz, et al.           Expires May 22, 2008                 [Page 29]


Internet-Draft           Three State PCN Marking           November 2007


   Kwok Ho Chan
   Nortel
   600 Technology Park Drive
   Billerica, MA  01821
   USA

   Phone: +1-978-288-8175
   Email: khchan@nortel.com


   Dr. Michael Menth
   University of Wuerzburg
   Institute of Computer Science
   Am Hubland, D-97074 Wuerzburg,  Room B206
   Germany

   Phone: (+49)-931/888-6644
   Email: menth@informatik.uni-wuerzburg.de

































Babiarz, et al.           Expires May 22, 2008                 [Page 30]


Internet-Draft           Three State PCN Marking           November 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Babiarz, et al.           Expires May 22, 2008                 [Page 31]