[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-eardley-pcn-marking-behaviour) 00 01 02 03 04 05 RFC 5670

PCN Working Group                               Philip. Eardley (Editor)
Internet-Draft                                                        BT
Intended status: Standards Track                          August 3, 2009
Expires: February 4, 2010


              Metering and marking behaviour of PCN-nodes
                  draft-ietf-pcn-marking-behaviour-05

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   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 February 4, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal



Eardley (Editor)        Expires February 4, 2010                [Page 1]

Internet-Draft          PCN metering and marking             August 2009


   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   The objective of Pre-Congestion Notification (PCN) is to protect the
   quality of service (QoS) of inelastic flows within a Diffserv domain,
   in a simple, scalable, and robust fashion.  This document defines the
   two metering and marking behaviours of PCN-nodes.  Threshold-metering
   and -marking marks all PCN-packets if the rate of PCN-traffic is
   greater than a configured rate ("PCN-threshold-rate").  Excess-
   traffic-metering and -marking marks a proportion of PCN-packets, such
   that the amount marked equals the rate of PCN-traffic in excess of a
   configured rate ("PCN-excess-rate").  The level of marking allows
   PCN-boundary-nodes to make decisions about whether to admit or
   terminate PCN-flows.

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



























Eardley (Editor)        Expires February 4, 2010                [Page 2]

Internet-Draft          PCN metering and marking             August 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Specified PCN-metering and -marking behaviours . . . . . . . .  6
     2.1.  Behaviour aggregate classification function  . . . . . . .  6
     2.2.  Dropping function  . . . . . . . . . . . . . . . . . . . .  6
     2.3.  Threshold-meter function . . . . . . . . . . . . . . . . .  7
     2.4.  Excess-traffic-meter function  . . . . . . . . . . . . . .  7
     2.5.  Marking function . . . . . . . . . . . . . . . . . . . . .  8
   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Changes (to be removed by RFC Editor)  . . . . . . . . . . . . 10
     6.1.  Changes to -05 from -04  . . . . . . . . . . . . . . . . . 10
     6.2.  Changes to -04 from -03  . . . . . . . . . . . . . . . . . 11
     6.3.  Changes to -03 from -02  . . . . . . . . . . . . . . . . . 11
     6.4.  Changes to -02 from -01  . . . . . . . . . . . . . . . . . 12
     6.5.  Changes to -01 from -00  . . . . . . . . . . . . . . . . . 12
     6.6.  Changes to -00 . . . . . . . . . . . . . . . . . . . . . . 13
   7.  References note (to be removed by RFC Editor)  . . . . . . . . 13
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Appendix A.  Example algorithms  . . . . . . . . . . . . . . . . . 16
     A.1.  Threshold-metering and -marking  . . . . . . . . . . . . . 16
     A.2.  Excess-traffic-metering and -marking . . . . . . . . . . . 17
   Appendix B.  Implementation notes  . . . . . . . . . . . . . . . . 18
     B.1.  Competing-non-PCN-traffic  . . . . . . . . . . . . . . . . 18
     B.2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     B.3.  Behaviour aggregate classification . . . . . . . . . . . . 20
     B.4.  Dropping . . . . . . . . . . . . . . . . . . . . . . . . . 20
     B.5.  Threshold-metering . . . . . . . . . . . . . . . . . . . . 22
     B.6.  Excess-traffic-metering  . . . . . . . . . . . . . . . . . 23
     B.7.  Marking  . . . . . . . . . . . . . . . . . . . . . . . . . 24
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24















Eardley (Editor)        Expires February 4, 2010                [Page 3]

Internet-Draft          PCN metering and marking             August 2009


1.  Introduction

   The objective of Pre-Congestion Notification (PCN) is to protect the
   quality of service (QoS) of inelastic flows within a Diffserv domain,
   in a simple, scalable, and robust fashion.  Two mechanisms are used:
   admission control, to decide whether to admit or block a new flow
   request, and (in abnormal circumstances) flow termination to decide
   whether to terminate some of the existing flows.  To achieve this,
   the overall rate of PCN-traffic is metered on every link in the
   domain, and PCN-packets are appropriately marked when certain
   configured rates are exceeded.  These configured rates are below the
   rate of the link thus providing notification to boundary nodes about
   overloads before any congestion occurs (hence "pre-congestion
   notification").  The level of marking allows boundary nodes to make
   decisions about whether to admit or terminate.  Within the domain,
   PCN-traffic is forwarded in a prioritised Diffserv traffic class
   [RFC2475].

   This document defines the two metering and marking behaviours of PCN-
   nodes.  Their aim is to enable PCN-nodes to give an "early warning"
   of potential congestion before there is any significant build-up of
   PCN-packets in their queues.  In summary, their objectives are:

   o  threshold-metering and -marking: its objective is to mark all PCN-
      packets (with a "threshold-mark") when the bit rate of PCN-traffic
      is greater than its configured reference rate ("PCN-threshold-
      rate");

   o  excess traffic marking: when the bit rate of PCN-packets is
      greater than its configured reference rate ("PCN-excess-rate"),
      its objective is to mark PCN-packets (with an "excess-traffic-
      mark") at a rate equal to the difference between the rate of PCN-
      traffic and the PCN-excess-rate.

   Note that although [RFC3168] defines a broadly RED-like (Random Early
   Detection) default congestion marking behaviour, it allows
   alternatives to be defined; this document defines such an
   alternative.

   Section 2 below describes the functions involved, which in outline
   (see Figure 1) are:

   o  Behaviour aggregate (BA) classification: decide whether an
      incoming packet is a PCN-packet or not.

   o  Dropping (optional): drop packets if the link is overloaded.





Eardley (Editor)        Expires February 4, 2010                [Page 4]

Internet-Draft          PCN metering and marking             August 2009


   o  Threshold-meter: determine whether the bit rate of PCN-traffic
      exceeds its configured reference rate (PCN-threshold-rate).  The
      meter operates on all PCN-packets on the link, and not on
      individual flows.

   o  Excess-traffic-meter: measure by how much the bit rate of PCN-
      traffic exceeds its configured reference rate (PCN-excess-rate).
      The meter operates on all PCN-packets on the link, and not on
      individual flows.

   o  PCN-mark: actually mark the PCN-packets, if the meter functions
      indicate to do so.


                                        +---------+    Result
                                     +->|Threshold|-------+
                                     |  |  Meter  |       |
                                     |  +---------+       V
         +----------+   +- - - - -+  |                +------+
         |   BA     |   |         |  |                |      |    Marked
Packet =>|Classifier|==>| Dropper |==?===============>|Marker|==> Packet
Stream   |          |   |         |  |                |      |    Stream
         +----------+   +- - - - -+  |                +------+
                                     |  +---------+       ^
                                     |  | Excess  |       |
                                     +->| Traffic |-------+
                                        |  Meter  |    Result
                                        +---------+

   Figure 1: Schematic of PCN-interior-node functionality.

   Appendix A gives an example of algorithms that fulfil the
   specification of Section 2, and Appendix B provides some explanations
   of and comments on Section 2.  Both the Appendices are informative.

   The general architecture for PCN is described in [RFC3168], whilst
   [Menth09] is an overview of PCN.

1.1.  Terminology

   In addition to the terminology defined in [RFC5559] and [RFC2474],
   the following terms are defined:

   o  Competing-non-PCN-packet: a non PCN-packet that shares a link with
      PCN-packets and competes with them for its forwarding bandwidth.
      Competing-non-PCN-packets MUST NOT be PCN-marked (only PCN-packets
      can be PCN-marked).  Note: In general it is not advised to have
      any competing-non-PCN-traffic.  Note: there is likely to be



Eardley (Editor)        Expires February 4, 2010                [Page 5]

Internet-Draft          PCN metering and marking             August 2009


      traffic (such as best effort) that is forwarded at lower priority
      than PCN-traffic; although it shares the link with PCN-traffic it
      doesn't compete for forwarding bandwidth, and hence it is not
      competing-non-PCN-traffic.  See Appendix B.1 for further
      discussion about competing-non-PCN-traffic.

   o  Metered-packet: a packet that is metered by the metering functions
      specified in Sections 2.3 and 2.4.  A PCN-packet MUST be treated
      as a metered-packet (with the minor exception noted below in
      Section 2.4).  A competing-non-PCN-packet MAY be treated as a
      metered-packet.


2.  Specified PCN-metering and -marking behaviours

   This section defines the two PCN-metering and -marking behaviours.
   The descriptions are functional and are not intended to restrict the
   implementation.  The informative Appendices supplement this section.

2.1.  Behaviour aggregate classification function

   A PCN-node MUST classify a packet as a PCN-packet if the value of its
   DSCP and ECN fields correspond to a PCN-enabled codepoint, as defined
   in the encoding scheme applicable to the PCN-domain (for example,
   [I-D.ietf-pcn-baseline-encoding] defines the baseline encoding).
   Otherwise the packet MUST NOT be classified as a PCN-packet.

   A PCN-node MUST classify a packet as a competing-non-PCN-packet if it
   is not a PCN-packet and it competes with PCN-packets for its
   forwarding bandwidth on a link.

2.2.  Dropping function

   Note: if the PCN-node's queue overflows then naturally packets are
   dropped.  This section describes additional action.

   On all links in the PCN-domain, dropping MAY be done by:

   o  metering all metered-packets to determine if the rate of metered-
      traffic on the link is greater than the rate allowed for such
      traffic.

   o  if the rate of metered-traffic is too high, then drop metered-
      packets.

   If the PCN-node drops PCN-packets then:





Eardley (Editor)        Expires February 4, 2010                [Page 6]

Internet-Draft          PCN metering and marking             August 2009


   o  PCN-packets that arrive at the PCN-node already excess-traffic-
      marked SHOULD be preferentially dropped;

   o  the PCN-node's excess-traffic-meter SHOULD NOT meter the PCN-
      packets that it drops.

2.3.  Threshold-meter function

   A PCN-node MUST implement a threshold-meter that has behaviour
   functionally equivalent to the following.

   The meter acts like a token bucket, which is sized in bits and has a
   configured reference rate (bits per second).  The amount of tokens in
   the token bucket is termed F_tm.  Tokens are added at the reference
   rate (PCN-threshold-rate), to a maximum value BS_tm.  Tokens are
   removed equal to the size in bits of the metered-packet, to a minimum
   F_tm = 0.  (Explanation of abbreviations: F is short for Fill of the
   token bucket, BS for bucket size, and tm for threshold-meter.)

   The token bucket has a configured intermediate depth, termed
   threshold.  If F_tm < threshold, then the meter indicates to the
   marking function that the packet is to be threshold-marked; otherwise
   it does not.

2.4.  Excess-traffic-meter function

   A packet SHOULD NOT be metered (by this excess-traffic-meter
   function) in the following two cases:

   o  If the PCN-packet is already excess-traffic-marked on arrival at
      the PCN-node;

   o  If this PCN-node drops the packet.

   Otherwise the PCN-packet MUST be treated as a metered-packet, that is
   it is metered by the excess-traffic-meter.

   A PCN-node MUST implement an excess-traffic-meter.  The excess-
   traffic-meter SHOULD indicate packets to be excess-traffic-marked
   independent of their size ("packet size independent marking"); if
   "packet size independent marking" is not implemented then the excess-
   traffic-meter MUST use the "classic" metering behaviour.

   For the "classic" metering behaviour the excess-traffic-meter has
   behaviour functionally equivalent to the following.

   The meter acts like a token bucket, which is sized in bits and has a
   configured reference rate (bits per second).  The amount of tokens in



Eardley (Editor)        Expires February 4, 2010                [Page 7]

Internet-Draft          PCN metering and marking             August 2009


   the token bucket is termed F_etm.  Tokens are added at the reference
   rate (PCN-excess-rate), to a maximum value BS_etm.  Tokens are
   removed equal to the size in bits of the metered-packet, to a minimum
   F_etm = 0.  If the token bucket is empty (F_etm = 0), then the meter
   indicates to the marking function that the packet is to be excess-
   traffic-marked.  (Explanation of abbreviations: F is short for Fill
   of the token bucket, BS for bucket size, and etm for excess-traffic-
   meter.)

   For "packet size independent marking" the excess-traffic-meter has
   behaviour functionally equivalent to the following.  The meter acts
   like a token bucket, which is sized in bits and has a configured
   reference rate (bits per second).  The amount of tokens in the token
   bucket is termed F_etm.  Tokens are added at the reference rate (PCN-
   excess-rate), to a maximum value BS_etm.  If the token bucket is not
   negative, then tokens are removed equal to the size in bits of the
   metered-packet (and the meter does not indicate to the marking
   function that the packet is to be excess-traffic-marked).  If the
   token bucket is negative (F_etm < 0), then the meter indicates to the
   marking function that the packet is to be excess-traffic-marked (and
   no tokens are removed).  (Explanation of abbreviations: F is short
   for Fill of the token bucket, BS for bucket size, and etm for excess-
   traffic-meter.)

   Otherwise the meter MUST NOT indicate marking.

2.5.  Marking function

   A PCN-packet MUST be marked to reflect the metering results by
   setting its encoding state appropriately, as specified by the
   specific encoding scheme that applies in the PCN-domain.  A
   consistent choice of encoding scheme MUST be made throughout a PCN-
   domain.

   A PCN-node MUST NOT:

   o  PCN-mark a packet that is not a PCN-packet;

   o  change a non PCN-packet into a PCN-packet;

   o  change a PCN-packet into a non PCN-packet.

   Note: although competing-non-PCN-packets MAY be metered, they MUST
   NOT be PCN-marked.







Eardley (Editor)        Expires February 4, 2010                [Page 8]

Internet-Draft          PCN metering and marking             August 2009


3.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


4.  Security Considerations

   It is assumed that all PCN-nodes are PCN-enabled and are trusted for
   truthful PCN-metering and PCN-marking.  If this isn't the case then
   there are numerous potential attacks.  For instance, a rogue PCN-
   interior-node could PCN-mark all packets so that no flows were
   admitted.  Another possibility is that it doesn't PCN-mark any
   packets, even when it is pre-congested.

   Note that PCN-interior-nodes are not flow-aware.  This prevents some
   security attacks where an attacker targets specific flows in the data
   plane -- for instance, for DoS or eavesdropping.

   As regards Security Operations and Management, PCN adds few specifics
   to the general good practice required in this field [RFC4778].  For
   example, it may be sensible for a PCN-node to raise an alarm if it is
   persistently PCN-marking.

   Security considerations are further discussed in [RFC5559].


5.  Acknowledgements

   This document is the result of extensive collaboration within the PCN
   WG.  Amongst the most active contributors to the development of the
   ideas specified in this document have been Jozef Babiarz, Bob
   Briscoe, Kwok-Ho Chan, Anna Charny, Philip Eardley, Georgios
   Karagiannis, Michael Menth, Toby Moncaster, Daisuke Satoh, and Joy
   Zhang.  Appendix A is based on text from Michael Menth.

   This document is a development of [I-D.briscoe-tsvwg-cl-phb].  Its
   authors are therefore also contributors to this document: Jozef
   Babiarz, Attila Bader, Bob Briscoe, Kwok-Ho Chan, Anna Charny,
   Stephen Dudley, Philip Eardley, Georgios Karagiannis, Francois Le
   Faucheur, Vassilis Liatsos, Dave Songhurst, Lars Westberg.

   Thanks to those who've made comments on the draft: Joe Babiarz, Fred
   Baker, David Black, Bob Briscoe, Ken Carlberg, Anna Charny, Ralph
   Droms, Mehmet Ersue, Adrian Farrel, Ruediger Geib, Wei Gengyu,
   Fortune Huang, Christian Hublet, Ingemar Johansson, Georgios



Eardley (Editor)        Expires February 4, 2010                [Page 9]

Internet-Draft          PCN metering and marking             August 2009


   Karagiannis, Alexey Melnikov, Michael Menth, Toby Moncaster, Dimitri
   Papadimitriou, Tim Polk, Daisuke Satoh, Magnus Westerlund.


6.  Changes (to be removed by RFC Editor)

6.1.  Changes to -05 from -04

   Updates to take account of IESG comments as follows:

   o  S1: added refs to PCN background

   o  S1: corrected "standardises" to "describes"

   o  S1: for clarity added: "Within the domain, PCN-traffic is
      forwarded in a prioritised Diffserv traffic class [RFC2475]."

   o  S1.1: added note to clarify that Best Effort traffic isn't
      competing-non-PCN-traffic: "Note: there is likely to be traffic
      (such as best effort) that is forwarded at lower priority than
      PCN-traffic; although it shares the link with PCN-traffic it
      doesn't compete for forwarding bandwidth, and hence it is not
      competing-non-PCN-traffic.  See Appendix B.1 for further
      discussion about competing-non-PCN-traffic."

   o  S2.3 & 2.4: added units for reference rate of token buckets:
      "(bits per second)"

   o  S2.4, "Packet size independent (excess-traffic-)marking": added
      clarification about behaviour if token bucket is negative: "(and
      no tokens are removed)".  Swapped two sentences round for clarity,
      so first describe behaviour if token bucket is non negative and
      then behaviour if token bucket is negative.

   o  S4: deleted the sentence "More subtly...", as this might be
      misconstrued as implying PCN-interior-nodes are flow-aware.

   o  S8: upgraded RFC2119 to normative ref

   o  SB.6, "Packet size independent (excess-traffic-)marking": added
      clarification: <Note that with "packet size independent marking",
      either the packet is marked or tokens are removed -- never both.
      Hence the token bucket cannot become more negative than the
      maximum packet size on the link.>

   o  Expanded RED, and other minor typos and clarifications





Eardley (Editor)        Expires February 4, 2010               [Page 10]

Internet-Draft          PCN metering and marking             August 2009


6.2.  Changes to -04 from -03

   Updates to take account of IETF last call comments, including a Gen-
   ART review from David Black and OPS DIR review from Mehmet Ersue, as
   follows:

   o  re-phrased of S2.2 first bullet for clarity

   o  S2.4 re-phrased, so that competing-non-PCN-packets that are
      metered are covered by the "SHOULD NOT be metered ..." text

   o  "Packet size independent (excess-traffic-)marking": re-phrased the
      para in 2.4 for clarity; altered the algorithm in Appendix A so it
      does PSIM; clarified the explanation in Appendix B.6 in light of
      this.  Clarified that if packet size independent marking (the
      SHOULD behaviour) is implemented, then the 'classic' marking
      doesn't have to be (ie it's only a MUST if PSIM isn't
      implemented).  Also added info on 'functionally equivalent'
      behaviour for PSIM.

   o  added Security Considerations, based on material from RFC5559

   o  other minor typos and clarifications

6.3.  Changes to -03 from -02

   Updates to take account of last call comments as follows:

   o  renamed from "marking" to "metering and marking" (throughout) -
      the former was intended as shorthand for the latter, but this was
      found confusing

   o  added 'common capsule' summary of PCN to Introduction and removed
      extraneous material

   o  replaced the term 'traffic conditioning' by 'dropping'
      (throughout) - since the former has a wider meaning than just
      dropping.

   o  discussion of the case with baseline encoding where there are two
      PCN states - this is now done just once - in Section B.2.

   o  added in Section B.5 "The PCN-threshold-rate is configured at less
      than the rate allocated to the PCN-traffic class" and in B.6 "The
      PCN-excess-rate is configured at less than (or possibly equal to)
      the rate allocated to the PCN-traffic class".





Eardley (Editor)        Expires February 4, 2010               [Page 11]

Internet-Draft          PCN metering and marking             August 2009


   o  configuring the PCN-excess-rate at greater than (or possibly equal
      to) the PCN-threshold-rate - this is now in one place, as advice
      is B5 & B6.

   o  SB.1: "voice-admit" corrected with references to I-D ietf-tsvwg-
      admitted-realtime-dscp and RFC5127.

   o  "CL/SM edge behaviour" altered to the less obscure "controlled
      load edge behaviour" and a reference added.

   o  S2.3, 2.4 & Appendix A: altered some of the abbreviations, for
      better consistency with approach of RFC2698. eg TBthreshold.fill
      => F_tm.

   o  the ACKs section improved

   o  other minor corrections and clarifications

6.4.  Changes to -02 from -01

   Updates as follows:

   o  added notes (end of S1.1 & 2.5) to clarify what "excess-traffic-
      marked" means when there is only one encoding for PCN-marking

   o  added explanations for in Section B.4 and B.6 about why various
      things are SHOULD or SHOULD NOT rather than MUST or MUST NOT.

   o  Deleted a couple of paragraphs about encoding states, as they are
      relevant to encoding documents rather than this document.

6.5.  Changes to -01 from -00

   Updates as follows:

   o  corrected the term 'not PCN-marked' to 'not-marked' (throughout)

   o  re-phrased the definition of competing-non-PCN-packets

   o  corrected the definition of metered-packet

   o  delete most of Section 2.5 (marking function).  The material
      deleted belongs as part of [I-D.ietf-pcn-baseline-encoding]; other
      encoding schemes would need to include similar material.

   o  deleted Appendix C (it was only a temporary archive of material
      concerning per domain behaviour and PCN-boundary-node operation)




Eardley (Editor)        Expires February 4, 2010               [Page 12]

Internet-Draft          PCN metering and marking             August 2009


   o  clarifications throughout

   o  made all references Informative

6.6.  Changes to -00

   First version of WG draft, derived from
   draft-eardley-pcn-marking-behaviour-01, with the following changes:

   o  Removed material concerning per domain behaviour and PCN-boundary-
      node operation (temporarily archived to Appendix C)

   o  Removed mention of downgrading as an option for per-hop traffic
      conditioning.  In fact, downgrading is no longer allowed because S
      2.6 now says "A PCN-node MUST NOT ...change a PCN-packet into a
      non PCN-packet".

   o  Traffic conditioning is now a MAY.  Since in general flow
      termination (not traffic conditioning) is PCN's method for
      handling problems of too much traffic.

   o  Metered-packets: competing-non-PCN-packets now MAY be metered.
      Since it is recommended that the operator doesn't allow any
      competing-non-PCN-traffic, and (if there is) there are potentially
      other ways of coping.

   o  No changes (outside traffic conditioning & metering of competing-
      non-PCN-traffic) to the Normative sections of the draft.

   o  Appendix B.1 added about competing-non-PCN-traffic.  Recommended
      that there is no such traffic, but guidance given if there is.


7.  References note (to be removed by RFC Editor)

   Note for RFC Editor: since RFCs can't include reference names such as
   ietf-pcn-baseline-encoding, please make the following changes:

   o  I-D.ietf-pcn-baseline-encoding => Moncaster09

   o  I-D.ietf-tsvwg-admitted-realtime-dscp => Baker08

   o  I-D.briscoe-tsvwg-byte-pkt-mark => Briscoe08

   o  I-D.briscoe-tsvwg-cl-architecture => Briscoe06-1

   o  I-D.briscoe-tsvwg-cl-phb => Briscoe06-2




Eardley (Editor)        Expires February 4, 2010               [Page 13]

Internet-Draft          PCN metering and marking             August 2009


   o  I-D.charny-pcn-comparison => Charny07

   o  I-D.taylor-pcn-cl-edge-behaviour => Taylor09

   Note: For several drafts the I-D database on xml2rfc doesn't pick up
   all the authors, please correct as follows:

   o  I-D.briscoe-tsvwg-cl-architecture: Briscoe, B., Eardley, P.,
      Songhurst, D., Le Faucheur, F., Charny, A., Babiarz, J., Chan, K.,
      Dudley, S., Karagiannis, G., Bader, A., and L. Westberg

   o  I-D.briscoe-tsvwg-cl-phb: Briscoe, B., Eardley, P., Songhurst, D.,
      Le Faucheur, F., Charny, A., Liatsos, V., Babiarz, J., Chan, K.,
      Dudley, S., Karagiannis, G., Bader, A., and L. Westberg

   o  I-D.charny-pcn-comparison: Charny, A., Babiarz, J., Menth, M., and
      X. Zhang


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-byte-pkt-mark]
              Briscoe, B., "Byte and Packet Congestion Notification",
              draft-briscoe-tsvwg-byte-pkt-mark-02 (work in progress),
              February 2008.

   [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.charny-pcn-comparison]
              Charny, A., "Comparison of Proposed PCN Approaches",
              draft-charny-pcn-comparison-00 (work in progress),
              November 2007.



Eardley (Editor)        Expires February 4, 2010               [Page 14]

Internet-Draft          PCN metering and marking             August 2009


   [I-D.ietf-pcn-baseline-encoding]
              Moncaster, T., Briscoe, B., and M. Menth, "Baseline
              Encoding and Transport of Pre-Congestion Information",
              draft-ietf-pcn-baseline-encoding-04 (work in progress),
              May 2009.

   [I-D.ietf-tsvwg-admitted-realtime-dscp]
              Baker, F., Polk, J., and M. Dolly, "DSCP for Capacity-
              Admitted Traffic",
              draft-ietf-tsvwg-admitted-realtime-dscp-05 (work in
              progress), November 2008.

   [I-D.taylor-pcn-cl-edge-behaviour]
              Charny, A., Huang, F., Menth, M., and T. Taylor, "PCN
              Boundary Node Behaviour for the Controlled Load (CL) Mode
              of Operation", draft-taylor-pcn-cl-edge-behaviour-00 (work
              in progress), March 2009.

   [Menth09]  Menth, M., Lehrieder, F., Briscoe, B., Eardley, P.,
              Moncaster, T., Babiarz, J., Chan, K., Charny, A.,
              Karagiannis, G., Zhang, X., Taylor, T., Satoh, D., and R.
              Geib, "A Survey of PCN-Based Admission Control and Flow
              Termination", IEEE Communications Surveys and Tutorials, <
              http://www3.informatik.uni-wuerzburg.de/staff/menth/
              Publications/papers/Menth08-PCN-Overview.pdf>.

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

   [RFC4778]  Kaeo, M., "Operational Security Current Practices in
              Internet Service Provider Environments", RFC 4778,
              January 2007.

   [RFC5127]  Chan, K., Babiarz, J., and F. Baker, "Aggregation of
              DiffServ Service Classes", RFC 5127, February 2008.

   [RFC5559]  Eardley, P., "Pre-Congestion Notification (PCN)
              Architecture", RFC 5559, June 2009.



Eardley (Editor)        Expires February 4, 2010               [Page 15]

Internet-Draft          PCN metering and marking             August 2009


Appendix A.  Example algorithms

   Note: This Appendix is informative, not normative.  It is an example
   of algorithms that implement Section 2 and is based on
   [I-D.charny-pcn-comparison] and [Menth09].

   There is no attempt to optimise the algorithms.  The metering and
   marking functions are implemented together.  It is assumed that three
   encoding states are available (one for threshold-marked, one for
   excess-traffic-marked, and one for not PCN-marked).  It is assumed
   that all metered-packets are PCN-packets and that the link is never
   overloaded.  For excess-traffic-marking, "packet size independent
   marking" applies.

A.1.  Threshold-metering and -marking

   A token bucket with the following parameters:

   o  PCN-threshold-rate: token rate of token bucket (bits/second)

   o  BS_tm: depth of token bucket (bits)

   o  threshold: marking threshold of token bucket (bits)

   o  lastUpdate: time the token bucket was last updated (seconds)

   o  F_tm: amount of tokens in token bucket (bits)

   A PCN-packet has the following parameters:

   o  packet_size: the size of the PCN-packet (bits)

   o  packet_mark: the PCN encoding state of the packet

   In addition there is the parameter:

   o  now: the current time (seconds)

   The following steps are performed when a PCN-packet arrives on a
   link:

   o  F_tm = min(BS_tm, F_tm + (now - lastUpdate) * PCN-threshold-rate);
      // add tokens to token bucket

   o  F_tm = max(0, F_tm - packet_size); // remove tokens from token
      bucket





Eardley (Editor)        Expires February 4, 2010               [Page 16]

Internet-Draft          PCN metering and marking             August 2009


   o  if ((F_tm < threshold) AND (packet_mark != excess-traffic-marked))
      then packet_mark = threshold-marked; // do threshold marking, but
      don't re-mark packets that are already excess-traffic-marked

   o  lastUpdate = now // Note: 'now' has the same value as in step 1

A.2.  Excess-traffic-metering and -marking

   A token bucket with the following parameters:

   o  PCN-excess-rate: token rate of token bucket (bits/second)

   o  BS_etm: depth of TB in token bucket (bits)

   o  lastUpdate: time the token bucket was last updated (seconds)

   o  F_etm: amount of tokens in token bucket (bits)

   A PCN-packet has the following parameters:

   o  packet_size: the size of the PCN-packet (bits)

   o  packet_mark: the PCN encoding state of the packet

   In addition there is the parameter:

   o  now: the current time (seconds)

   The following steps are performed when a PCN-packet arrives on a
   link:

   o  F_etm = min(BS_etm, F_etm + (now - lastUpdate) * PCN-excess-rate);
      // add tokens to token bucket

   o  if (packet_mark != excess-traffic-marked) then // do not meter
      packets that are already excess-traffic-marked

   o

      *  if (F_etm < 0) then packet_mark = excess-traffic-marked; // do
         excess-traffic-marking.  The algorithm ensures this is
         independent of packet size

      *  else F_etm = F_etm - packet_size; // remove tokens from token
         bucket if don't mark packet






Eardley (Editor)        Expires February 4, 2010               [Page 17]

Internet-Draft          PCN metering and marking             August 2009


   o  lastUpdate = now // Note: 'now' has the same value as in step 1


Appendix B.  Implementation notes

   Note: This Appendix is informative, not normative.  It comments on
   Section 2, including reasoning about whether MUSTs or SHOULDs are
   required.  For guidance on Operations and Management considerations,
   please see [RFC5559].

B.1.  Competing-non-PCN-traffic

   In general it is not advised to have any competing-non-PCN-traffic,
   essentially because the unpredictable amount of competing-non-PCN-
   traffic makes the PCN mechanisms less accurate and so reduces PCN's
   ability to protect the QoS of admitted PCN-flows [RFC5559].  But if
   there is competing-non-PCN-traffic, then:

   1.  There should be a mechanism to limit it, for example:

       *  limit the rate at which competing-non-PCN-traffic can be
          forwarded on each link in the PCN-domain.  One method for
          achieving this is to queue competing-non-PCN-packets
          separately from PCN-packets, and to limit the scheduling rate
          of the former.  Another method is to drop competing-non-PCN-
          packets in excess of some rate.

       *  police competing-non-PCN-traffic at the PCN-ingress-nodes.
          For example, as in the Diffserv architecture - however, its
          static traffic conditioning agreements risk a focused overload
          of traffic from several PCN-ingress-nodes onto one link.

       *  by design it is known that the level of competing-non-PCN-
          traffic is always very small - perhaps it consists of operator
          control messages only.

   2.  In general PCN's mechanisms should take account of competing-non-
       PCN-traffic, in order to improve the accuracy of the decision
       about whether to admit (or terminate) a PCN-flow.  For example:

       *  competing-non-PCN-traffic contributes to the PCN meters:
          competing-non-PCN-packets are treated as metered-packets.

       *  each PCN-node, on its links: (1) reduces the reference rates
          (PCN-threshold-rate and PCN-excess-rate), in order to allow
          'headroom' for the competing-non-PCN-traffic; (2) limits the
          maximum forwarding rate of competing-non-PCN-traffic to be
          less than the 'headroom'.  In this case competing-non-PCN-



Eardley (Editor)        Expires February 4, 2010               [Page 18]

Internet-Draft          PCN metering and marking             August 2009


          packets are not treated as metered-packets.

   3.  The operator should decide on what appropriate action.  Dropping
       is discussed further in Section B.4.

   One specific example of competing-non-PCN-traffic occurs if the PCN-
   compatible Diffserv codepoint is one of those that
   [I-D.ietf-tsvwg-admitted-realtime-dscp]) defines as suitable for use
   with admission control, and there is such non PCN-traffic in the PCN-
   domain.  A similar example could occur for Diffserv codepoints of the
   Real-Time Treatment Aggregate [RFC5127]).  In such cases PCN-traffic
   and competing-non-PCN-traffic are distinguished by different values
   of the ECN field [I-D.ietf-pcn-baseline-encoding].

   Another example would occur if there is more than one PCN-compatible
   Diffserv codepoint in a PCN-domain.  For instance, suppose there are
   two PCN-BAs treated at different priorities.  Then as far as the
   lower priority PCN-BA is concerned, the higher priority PCN-traffic
   needs to be treated as competing-non-PCN-traffic.

B.2.  Scope

   It may be known, for instance by the design of the network topology,
   that some links can never be pre-congested (even in unusual
   circumstances, such as after the failure of some links).  There is
   then no need to deploy the PCN metering and marking behaviour on
   those links.

   The meters can be implemented on the ingoing or outgoing interface of
   a PCN-node.  It may be that existing hardware can support only one
   meter per ingoing interface and one per outgoing interface.  Then for
   instance threshold-metering could be run on all the ingoing
   interfaces and excess-traffic-metering on all the outgoing
   interfaces; note that the same choice must be made for all the links
   in a PCN-domain to ensure that the two metering behaviours are
   applied exactly once for all the links.

   The baseline encoding [I-D.ietf-pcn-baseline-encoding] specifies only
   two encoding states (PCN-marked and not-marked).  In this case,
   "excess-traffic-marked" means a packet that is PCN-marked as a result
   of the excess-traffic-meter function, and "threshold-marked" means a
   packet that is PCN-marked as a result of the threshold-meter
   function.  As far as terminology is concerned, this interpretation is
   consistent with that defined in [RFC5559].  Note that a deployment
   needs to make a consistent choice throughout the PCN-domain whether
   PCN-marked is interpreted as excess-traffic-marked or threshold-
   marked.




Eardley (Editor)        Expires February 4, 2010               [Page 19]

Internet-Draft          PCN metering and marking             August 2009


   Note that even if there are only two encoding states, it is still
   required that both the meters are implemented, in order to ease
   compatibility between equipment, and to remove a configuration option
   and associated complexity.  Hardware with limited availability of
   token buckets could be configured to run only one of the meters, but
   it must be possible to enable either meter.  Although in the scenario
   with two encoding states, indications from one of the meters are
   ignored by the marking function, they may be logged or acted upon in
   some other way, for example by the management system or an explicit
   signalling protocol; such considerations are out of scope of this
   document.

B.3.  Behaviour aggregate classification

   Configuration of PCN-nodes will define what values of the DSCP and
   ECN fields indicate a PCN-packet in a particular PCN-domain.  For
   instance [I-D.ietf-pcn-baseline-encoding] defines the baseline
   encoding.

   Configuration will also define what values of the DSCP and ECN fields
   indicate a competing-non-PCN-packet in a particular PCN-domain.

B.4.  Dropping

   The objective of the dropping function is to minimise the queueing
   delay suffered by metered-traffic at a PCN-node, since PCN-traffic
   (and perhaps competing-non-PCN-traffic) is expected to be inelastic
   traffic generated by real time applications.  In practice it would be
   defined as exceeding a specific traffic profile, typically based on a
   token bucket.

   If there is no competing-non-PCN-traffic, then it is not expected
   that the dropping function is needed, since PCN's flow admission and
   termination mechanisms limit the amount of PCN-traffic.  Even so, it
   still might be implemented as a back stop against misconfiguration of
   the PCN-domain, for instance.

   If there is competing-non-PCN-traffic, then the details of the
   dropping function will depend on how the router's implementation
   handles the two sorts of traffic (the discussion here is based on
   that in [I-D.ietf-tsvwg-admitted-realtime-dscp]):

   o  a common queue for PCN-traffic and competing-non-PCN-traffic, and
      a traffic conditioner for the competing-non-PCN-traffic; or

   o  separate queues.  In this case the amount of competing-non-PCN-
      traffic can be limited by limiting the rate at which the scheduler
      (for the competing-non-PCN-traffic) forwards packets.



Eardley (Editor)        Expires February 4, 2010               [Page 20]

Internet-Draft          PCN metering and marking             August 2009


   Note that only dropping of packets is allowed.  Downgrading of
   packets to a lower priority BA is not allowed (see B.7), since it
   would lead to packet mis-ordering.  Shaping ("the process of delaying
   packets" [RFC2475]) is not suitable if the traffic comes from real
   time applications.

   Preferential dropping of competing-non-PCN-traffic: In general it is
   reasonable for competing-non-PCN-traffic to get harsher treatment
   than PCN-traffic (that is, competing-non-PCN-packets are
   preferentially dropped), because PCN's flow admission and termination
   mechanisms are stronger than the mechanisms that are likely to be
   applied to the competing-non-PCN-traffic.  The PCN mechanisms also
   mean that a dropper should not be needed for the PCN-traffic.

   Preferential dropping of excess-traffic-marked packets: Section 2.3
   specifies: "If the PCN-node drops PCN-packets then ...  PCN-packets
   that arrive at the PCN-node already excess-traffic-marked SHOULD be
   preferentially dropped".  In brief, the reason is that, with the
   "controlled load" edge behaviour [I-D.taylor-pcn-cl-edge-behaviour]
   this avoids over-termination in the event of multiple bottlenecks in
   the PCN-domain [I-D.charny-pcn-comparison].  A fuller explanation is
   as follows.  The optimal dropping behaviour depends on the particular
   edge behaviour [Menth09].  A single dropping behaviour is defined, as
   it is simpler to standardise, implement and operate.  The
   standardised dropping behaviour is at least adequate for all edge
   behaviours (and good for some), whereas others are not (for example
   with tail dropping far too much traffic may be terminated with the
   "controlled load" edge behaviour, in the event of multiple
   bottlenecks in the PCN-domain [I-D.charny-pcn-comparison]).  The
   dropping behaviour is defined as a 'SHOULD', rather than a 'MUST', in
   recognition that other dropping behaviour may be preferred in
   particular circumstances, for example: (1) with the "marked flow"
   termination edge behaviour, preferential dropping of unmarked packets
   may be better [Menth09]; (2) tail dropping may make PCN-marking
   behaviour easier to implement on current routers.

   Exactly what "preferentially dropped" means is left to the
   implementation.  It is also left to the implementation what to do if
   there are no excess-traffic-marked PCN-packets available at a
   particular instant.

   Section 2.2 also specifies: "the PCN-node's excess-traffic-meter
   SHOULD NOT meter the PCN-packets that it drops."  This avoids over-
   termination [Menth09].  Effectively it means that the dropping
   function (if present) should be done before the meter functions -
   which is natural.





Eardley (Editor)        Expires February 4, 2010               [Page 21]

Internet-Draft          PCN metering and marking             August 2009


B.5.  Threshold-metering

   The description is in terms of a 'token bucket with threshold' (which
   [I-D.briscoe-tsvwg-cl-architecture] views as a virtual queue).
   However the description is not intended to standardise
   implementation.

   The reference rate of the threshold-meter (PCN-threshold-rate) is
   configured at less than the rate allocated to the PCN-traffic class.
   Also, the PCN-threshold-rate is less than, or possibly equal to, the
   PCN-excess-rate.

   Section 2.3 defines: "If F_tm < threshold, then the meter indicates
   to the marking function that the packet is to be threshold-marked;
   otherwise it does not."  Note that a PCN-packet is marked without
   explicit additional bias for the packet's size.

   The behaviour must be functionally equivalent to the description in
   Section 2.3.  "Functionally equivalent" means the observable 'black
   box' behaviour is the same or very similar, for example if either
   precisely the same set of packets is marked, or if the set is shifted
   by one packet.  It is intended to allow implementation freedom over
   matters such as:

   o  whether tokens are added to the token bucket at regular time
      intervals or only when a packet is processed.

   o  whether the new token bucket depth is calculated before or after
      it is decided whether to PCN-mark the packet.  The effect of this
      is simply to shift the sequence of marks by one packet.

   o  when the token bucket is very nearly empty and a packet arrives
      larger than F_tm, then the precise change in F_tm is up to the
      implementation.  For instance:

      *  set F_tm = 0 and indicate threshold-mark to the Marking
         function.

      *  check whether F_tm < threshold and if it is then indicate
         threshold-mark to the Marking function; then set F_tm = 0.

      *  leave F_tm unaltered and indicate threshold-mark to the Marking
         function.

   o  similarly, when the token bucket is very nearly full and a packet
      arrives larger than (BStm - F_tm), then the precise change in F_tm
      is up to the implementation.




Eardley (Editor)        Expires February 4, 2010               [Page 22]

Internet-Draft          PCN metering and marking             August 2009


   o  Note that all PCN-packets, even if already marked, are metered by
      the threshold-meter function (unlike the excess-traffic-meter
      function), because all packets should contribute to the decision
      whether there is room for a new flow.

B.6.  Excess-traffic-metering

   The description is in terms of a token bucket, however the
   implementation is not standardised.

   The reference rate of the excess-traffic-meter (PCN-excess-rate) is
   configured at less than (or possibly equal to) the rate allocated to
   the PCN-traffic class.  Also, the PCN-excess-rate is greater than, or
   possibly equal to, the PCN-threshold-rate.

   As in Section B.3, "functionally equivalent" allows some
   implementation flexibility, for example the exact algorithm when the
   token bucket is very nearly empty or very nearly full.

   Section 2.4 specifies: "A packet SHOULD NOT be metered (by this
   excess traffic meter function) ...  If the packet is already excess-
   traffic-marked on arrival at the PCN-node".  This avoids over-
   termination (with some edge behaviours) in the event that the PCN-
   traffic passes through multiple bottlenecks in the PCN-domain
   [I-D.charny-pcn-comparison].  Note that an implementation could
   determine whether the packet is already excess-traffic-marked as an
   integral part of its BA classification function.  The behaviour is
   defined as a 'SHOULD NOT', rather than a 'MUST NOT', because it may
   be slightly harder to implement than a metering function that is
   blind to previous packet markings.

   Section 2.4 specifies: "A packet SHOULD NOT be metered (by this
   excess traffic meter function) ...  If this PCN-node drops the
   packet."  This avoids over-termination [Menth09].  (A similar
   statement could also be made for the threshold meter function but is
   irrelevant, as a link that is overloaded will already be
   substantially pre-congested and hence threshold-marking all packets.)
   It seems natural to perform the dropping function before the metering
   functions, although for some equipment it may be harder to implement;
   hence the behaviour is defined as a 'SHOULD NOT', rather than a 'MUST
   NOT'.

   "Packet size independent marking" - excess-traffic-marking that is
   independent of packet size - is specified as a SHOULD rather than a
   'MUST' in Section 2.4, because it may be slightly harder for some
   equipment to implement, and the impact of not doing it is undesirable
   but moderate (sufficient traffic is terminated, but flows with large
   packets are more likely to be terminated).  With the "classic"



Eardley (Editor)        Expires February 4, 2010               [Page 23]

Internet-Draft          PCN metering and marking             August 2009


   excess-traffic-meter behaviour, large packets are more likely to be
   excess-traffic-marked than small packets (because packets are marked
   if the number of tokens in the packet is smaller than the packet
   size).  This means that, with some edge behaviours, flows with large
   packets are more likely to be terminated than flows with small
   packets [I-D.briscoe-tsvwg-byte-pkt-mark] [Menth09].  "Packet size
   independent marking" can be achieved by a small modification of the
   "classic" excess-traffic-meter: the number of tokens in the bucket
   can become negative; if this number is negative at a packet's
   arrival, the packet is marked; otherwise, the amount of tokens equal
   to the packet size is removed from the bucket.  Note that with
   "packet size independent marking", either the packet is marked or
   tokens are removed -- never both.  Hence the token bucket cannot
   become more negative than the maximum packet size on the link.  The
   algorithm described in Appendix A implements this behaviour.

   Note that BS_etm is independent of BStm; F_etm is independent of F_tm
   (except in that a packet can change both); and the two configured
   rates (PCN-excess-rate and PCN-threshold-rate) are independent
   (except that PCN-excess-rate >= PCN-threshold-rate).

B.7.  Marking

   Section 2.5 defines: "A PCN-node MUST NOT ...change a PCN-packet into
   a non PCN-packet".  This means that a PCN-node is not allowed to
   downgrade a PCN-packet into a lower priority Diffserv BA (hence
   downgrading is not allowed as an alternative to dropping).

   Section 2.5 defines: "A PCN-node MUST NOT ...PCN-mark a packet that
   is not a PCN-packet".  This means that in the scenario where
   competing-non-PCN-packets are treated as metered-packets, a meter may
   indicate a packet is to be PCN-marked, but the marking function knows
   it cannot be marked.  It is left open to the implementation exactly
   what to do in this case; one simple possibility is to mark the next
   PCN-packet.  Note that unless the PCN-packets are a large fraction of
   all the metered-packets then the PCN mechanisms may not work well.

   Although the metering functions are described separately from the
   marking function, they can be implemented in an integrated fashion.












Eardley (Editor)        Expires February 4, 2010               [Page 24]

Internet-Draft          PCN metering and marking             August 2009


Author's Address

   Philip Eardley
   BT
   Adastral Park, Martlesham Heath
   Ipswich.  IP5 3RE
   UK

   Email: philip.eardley@bt.com










































Eardley (Editor)        Expires February 4, 2010               [Page 25]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/