One document matched: draft-ietf-pcn-marking-behaviour-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-pcn-marking-behaviour-04"
ipr="pre5378Trust200902">
<front>
<title abbrev="PCN metering and marking">Metering and marking behaviour of
PCN-nodes</title>
<author fullname="Philip Eardley " initials="Philip"
surname="Eardley (Editor)">
<organization>BT</organization>
<address>
<postal>
<street>Adastral Park, Martlesham Heath</street>
<city>Ipswich.</city>
<code>IP5 3RE</code>
<country>UK</country>
</postal>
<email>philip.eardley@bt.com</email>
</address>
</author>
<date day="25" month="June" year="2009" />
<area>Transport Area</area>
<workgroup>PCN Working Group</workgroup>
<keyword>Sample</keyword>
<keyword>Draft</keyword>
<abstract>
<t>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 specifies 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.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>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.</t>
<t>This document standardises 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:</t>
<t><list style="symbols">
<t>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");</t>
<t>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.</t>
</list></t>
<t>Note that although <xref target="RFC3168"></xref> defines a broadly
RED-like default congestion marking behaviour, it allows alternatives to
be defined; this document defines such an alternative.</t>
<t>Section 2 below specifies the functions involved, which in outline
(see Figure 1) are:</t>
<t><list style="symbols">
<t>Behaviour aggregate (BA) classification: decide whether an
incoming packet is a PCN-packet or not.</t>
<t>Dropping (optional): drop packets if the link is overloaded.</t>
<t>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.</t>
<t>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.</t>
<t>PCN-mark: actually mark the PCN-packets, if the meter functions
indicate to do so.</t>
</list></t>
<t></t>
<t><figure>
<preamble></preamble>
<artwork><![CDATA[
+---------+ Result
+->|Threshold|-------+
| | Meter | |
| +---------+ V
+----------+ +- - - - -+ | +------+
| BA | | | | | | Marked
Packet =>|Classifier|==>| Dropper |==?===============>|Marker|==> Packet
Stream | | | | | | | Stream
+----------+ +- - - - -+ | +------+
| +---------+ ^
| | Excess | |
+->| Traffic |-------+
| Meter | Result
+---------+
]]></artwork>
<postamble>Figure 1: Schematic of PCN-interior-node
functionality.</postamble>
</figure></t>
<t>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.</t>
<section title="Terminology">
<t>In addition to the terminology defined in <xref
target="RFC5559"></xref> and <xref target="RFC2474"></xref>, the
following terms are defined:</t>
<t><list style="symbols">
<t>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 (ie
only PCN-packets can be PCN-marked). Note: In general it is not
advised to have any competing-non-PCN-traffic.</t>
<t>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.</t>
</list></t>
</section>
</section>
<section title="Specified PCN-metering and -marking behaviours">
<t>This section specifies 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.</t>
<section title="Behaviour aggregate classification function">
<t>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, <xref target="I-D.ietf-pcn-baseline-encoding"></xref> defines
the baseline encoding). Otherwise the packet MUST NOT be classified as
a PCN-packet.</t>
<t>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.</t>
</section>
<section title="Dropping function">
<t>Note: if the PCN-node's queue overflows then naturally packets are
dropped. This section describes additional action.</t>
<t>On all links in the PCN-domain, dropping MAY be done by:</t>
<t><list style="symbols">
<t>metering all metered-packets to determine if the rate of
metered-traffic on the link is greater than the rate allowed for
such traffic.</t>
<t>if the rate of metered-traffic is too high, then drop
metered-packets.</t>
</list>If the PCN-node drops PCN-packets then:<list style="symbols">
<t>PCN-packets that arrive at the PCN-node already
excess-traffic-marked SHOULD be preferentially dropped;</t>
<t>the PCN-node's excess-traffic-meter SHOULD NOT meter the
PCN-packets that it drops.</t>
</list></t>
<t></t>
</section>
<section title="Threshold-meter function">
<t>A PCN-node MUST implement a threshold-meter that has behaviour
functionally equivalent to the following.</t>
<t>The meter acts like a token bucket, which is sized in bits and has
a configured reference rate. 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.)</t>
<t>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.</t>
</section>
<section title="Excess-traffic-meter function">
<t>A packet SHOULD NOT be metered (by this excess-traffic-meter
function) in the following two cases:</t>
<t><list style="symbols">
<t>If the PCN-packet is already excess-traffic-marked on arrival
at the PCN-node;</t>
<t>If this PCN-node drops the packet.</t>
</list></t>
<t>Otherwise the PCN-packet MUST be treated as a metered-packet, that
is it is metered by the excess-traffic-meter.</t>
<t>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.</t>
<t>For the “classic” metering behaviour the
excess-traffic-meter has behaviour functionally equivalent to the
following.</t>
<t>The meter acts like a token bucket, which is sized in bits and has
a configured reference rate. 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. 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.)</t>
<t>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. 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 negative (F_etm < 0),
then the meter indicates to the marking function that the packet is to
be excess-traffic-marked. 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). (Explanation of abbreviations:
F is short for Fill of the token bucket, BS for bucket size, and etm
for excess-traffic-meter.)</t>
<t>Otherwise the meter MUST NOT indicate marking.</t>
</section>
<section title="Marking function">
<t>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.</t>
<t>A PCN-node MUST NOT:</t>
<t><list style="symbols">
<t>PCN-mark a packet that is not a PCN-packet;</t>
<t>change a non PCN-packet into a PCN-packet;</t>
<t>change a PCN-packet into a non PCN-packet.</t>
</list></t>
<t>Note: although competing-non-PCN-packets MAY be metered, they MUST
NOT be PCN-marked.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>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. More subtly, the rogue PCN-interior-node could perform
these attacks selectively on particular flows, or it could PCN-mark the
correct fraction overall but carefully choose which flows it marked.</t>
<t>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. </t>
<t>As regards Security Operations and Management, PCN adds few specifics
to the general good practice required in this field <xref
target="RFC4778"></xref>. For example, it may be sensible for a PCN-node
to raise an alarm if it is persistently PCN-marking. </t>
<t>Security considerations are further discussed in <xref
target="RFC5559"></xref>.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>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 Karagannis, Michael Menth,
Toby Moncaster, Daisuke Satoh, and Joy Zhang. Appendix A is based on
text from Michael Menth.</t>
<t>This document is a development of <xref
target="I-D.briscoe-tsvwg-cl-phb"></xref>. 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.</t>
<t>Thanks to those who've made comments on the draft: Joe Babiarz, Fred
Baker, David Black, Bob Briscoe, Ken Carlberg, Anna Charny, Mehmet
Ersue, Ruediger Geib, Wei Gengyu, Fortune Huang, Christian Hublet,
Ingemar Johansson, Georgios Karagiannis, Michael Menth, Toby Moncaster,
Dimitri Papadimitriou, Daisuke Satoh.</t>
</section>
<section title="Changes (to be removed by RFC Editor)">
<section title="Changes to -04 from -03">
<t>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:</t>
<t><list style="symbols">
<t>re-phrased of S2.2 first bullet for clarity</t>
<t>S2.4 re-phrased, so that competing-non-PCN-packets that are
metered are covered by the "SHOULD NOT be metered ..." text</t>
<t>"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.</t>
<t>added Security Considerations, based on material from
RFC5559</t>
<t>other minor typos and clarifications</t>
</list></t>
</section>
<t></t>
<section title="Changes to -03 from -02">
<t>Updates to take account of last call comments as follows:</t>
<t><list style="symbols">
<t>renamed from "marking" to "metering and marking" (throughout) -
the former was intended as shorthand for the latter, but this was
found confusing</t>
<t>added 'common capsule' summary of PCN to Introduction and
removed extraneous material</t>
<t>replaced the term 'traffic conditioning' by 'dropping'
(throughout) - since the former has a wider meaning than just
dropping.</t>
<t>discussion of the case with baseline encoding where there are
two PCN states - this is now done just once - in Section B.2.</t>
<t>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".</t>
<t>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.</t>
<t>SB.1: "voice-admit" corrected with references to I-D
ietf-tsvwg-admitted-realtime-dscp and RFC5127.</t>
<t>"CL/SM edge behaviour" altered to the less obscure "controlled
load edge behaviour" and a reference added.</t>
<t>S2.3, 2.4 & Appendix A: altered some of the abbreviations,
for better consistency with approach of RFC2698. eg
TBthreshold.fill => F_tm.</t>
<t>the ACKs section improved</t>
<t>other minor corrections and clarifications</t>
</list></t>
</section>
<section title="Changes to -02 from -01">
<t>Updates as follows:</t>
<t><list style="symbols">
<t>added notes (end of S1.1 & 2.5) to clarify what
"excess-traffic-marked" means when there is only one encoding for
PCN-marking</t>
<t>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.</t>
<t>Deleted a couple of paragraphs about encoding states, as they
are relevant to encoding documents rather than this document.</t>
</list></t>
</section>
<section title="Changes to -01 from -00">
<t>Updates as follows:</t>
<t><list style="symbols">
<t>corrected the term 'not PCN-marked' to 'not-marked'
(throughout)</t>
<t>re-phrased the definition of competing-non-PCN-packets</t>
<t>corrected the definition of metered-packet</t>
<t>delete most of Section 2.5 (marking function). The material
deleted belongs as part of <xref
target="I-D.ietf-pcn-baseline-encoding"></xref>; other encoding
schemes would need to include similar material.</t>
<t>deleted Appendix C (it was only a temporary archive of material
concerning per domain behaviour and PCN-boundary-node
operation)</t>
<t>clarifications throughout</t>
<t>made all references Informative</t>
</list></t>
</section>
<section title="Changes to -00">
<t>First version of WG draft, derived from
draft-eardley-pcn-marking-behaviour-01, with the following
changes:</t>
<t><list style="symbols">
<t>Removed material concerning per domain behaviour and
PCN-boundary-node operation (temporarily archived to Appendix
C)</t>
<t>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".</t>
<t>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.</t>
<t>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.</t>
<t>No changes (outside traffic conditioning & metering of
competing-non-PCN-traffic) to the Normative sections of the
draft.</t>
<t>Appendix B.1 added about competing-non-PCN-traffic. Recommended
that there is no such traffic, but guidance given if there is.</t>
</list></t>
</section>
</section>
<section title="References note (to be removed by RFC Editor)">
<t>Note for RFC Editor: since RFCs can't include reference names such as
ietf-pcn-baseline-encoding, please make the following changes:</t>
<t><list style="symbols">
<t>I-D.ietf-pcn-baseline-encoding => Moncaster09</t>
<t>I-D.ietf-tsvwg-admitted-realtime-dscp => Baker08</t>
<t>I-D.briscoe-tsvwg-byte-pkt-mark => Briscoe08</t>
<t>I-D.briscoe-tsvwg-cl-architecture => Briscoe06-1</t>
<t>I-D.briscoe-tsvwg-cl-phb => Briscoe06-2</t>
<t>I-D.charny-pcn-comparison => Charny07</t>
<t>I-D.taylor-pcn-cl-edge-behaviour => Taylor09</t>
</list>Note: For several drafts the I-D database on xml2rfc doesn't
pick up all the authors, I can add these during the RFC Ediitor or
AUTH48 stage.</t>
</section>
</middle>
<back>
<references title="Informative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2474"?>
<?rfc include="reference.RFC.2475"?>
<?rfc include="reference.RFC.3168"?>
<?rfc include="reference.RFC.4778"?>
<?rfc include="reference.RFC.5127"?>
<?rfc include="reference.RFC.5559"?>
<?rfc include="reference.I-D.ietf-pcn-baseline-encoding" ?>
<?rfc include="reference.I-D.ietf-tsvwg-admitted-realtime-dscp" ?>
<?rfc include="reference.I-D.briscoe-tsvwg-byte-pkt-mark" ?>
<?rfc include="reference.I-D.briscoe-tsvwg-cl-architecture" ?>
<?rfc include="reference.I-D.briscoe-tsvwg-cl-phb" ?>
<?rfc include="reference.I-D.charny-pcn-comparison" ?>
<?rfc include="reference.I-D.taylor-pcn-cl-edge-behaviour" ?>
<reference anchor="Menth09"
target="http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-Overview.pdf>">
<front>
<title>A Survey of PCN-Based Admission Control and Flow
Termination</title>
<author fullname="Michael Menth" initials="M" surname="Menth" />
<author initials="F" surname="Lehrieder" />
<author initials="B" surname="Briscoe" />
<author initials="P" surname="Eardley" />
<author initials="T" surname="Moncaster" />
<author initials="J" surname="Babiarz" />
<author initials="K. H" surname="Chan" />
<author initials="A" surname="Charny" />
<author initials="G" surname="Karagiannis" />
<author initials="X" surname="Zhang" />
<author initials="T" surname="Taylor" />
<author initials="D" surname="Satoh" />
<author initials="R" surname="Geib" />
</front>
<seriesInfo name="IEEE Communications" value="Surveys and Tutorials" />
</reference>
</references>
<section title="Example algorithms">
<t>Note: This Appendix is informative, not normative. It is an example
of algorithms that implement Section 2 and is based on <xref
target="I-D.charny-pcn-comparison"></xref> and <xref
target="Menth09"></xref>.</t>
<t>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.</t>
<section title="Threshold-metering and -marking">
<t>A token bucket with the following parameters:<list style="symbols">
<t>PCN-threshold-rate: token rate of token bucket
(bits/second)</t>
<t>BS_tm: depth of token bucket (bits)</t>
<t>threshold: marking threshold of token bucket (bits)</t>
<t>lastUpdate: time the token bucket was last updated
(seconds)</t>
<t>F_tm: amount of tokens in token bucket (bits)</t>
</list></t>
<t>A PCN-packet has the following parameters:<list style="symbols">
<t>packet_size: the size of the PCN-packet (bits)</t>
<t>packet_mark: the PCN encoding state of the packet</t>
</list></t>
<t>In addition there is the parameter:<list style="symbols">
<t>now: the current time (seconds)</t>
</list></t>
<t>The following steps are performed when a PCN-packet arrives on a
link:</t>
<t><list style="symbols">
<t>F_tm = min(BS_tm, F_tm + (now - lastUpdate) *
PCN-threshold-rate); // add tokens to token bucket</t>
<t>F_tm = max(0, F_tm - packet_size); // remove tokens from token
bucket</t>
<t>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</t>
<t>lastUpdate = now // Note: 'now' has the same value as in step
1</t>
</list></t>
</section>
<section title="Excess-traffic-metering and -marking">
<t>A token bucket with the following parameters:<list style="symbols">
<t>PCN-excess-rate: token rate of token bucket (bits/second)</t>
<t>BS_etm: depth of TB in token bucket (bits)</t>
<t>lastUpdate: time the token bucket was last updated
(seconds)</t>
<t>F_etm: amount of tokens in token bucket (bits)</t>
</list></t>
<t>A PCN-packet has the following parameters:<list style="symbols">
<t>packet_size: the size of the PCN-packet (bits)</t>
<t>packet_mark: the PCN encoding state of the packet</t>
</list></t>
<t>In addition there is the parameter:<list style="symbols">
<t>now: the current time (seconds)</t>
</list></t>
<t>The following steps are performed when a PCN-packet arrives on a
link:</t>
<t><list style="symbols">
<t>F_etm = min(BS_etm, F_etm + (now - lastUpdate) *
PCN-excess-rate); // add tokens to token bucket</t>
<t>if (packet_mark != excess-traffic-marked) then // do not meter
packets that are already excess-traffic-marked</t>
<t><list style="symbols">
<t>if (F_etm < 0) then packet_mark = excess-traffic-marked;
// do excess-traffic-marking. The algorithm ensures this is
independent of packet size</t>
<t>else F_etm = F_etm - packet_size; // remove tokens from
token bucket if don’t mark packet</t>
</list></t>
<t>lastUpdate = now // Note: 'now' has the same value as in step
1</t>
</list></t>
</section>
</section>
<section title="Implementation notes">
<t>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 <xref target="RFC5559"></xref>.</t>
<section title="Competing-non-PCN-traffic">
<t>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
<xref target="RFC5559"></xref>. But if there is
competing-non-PCN-traffic, then:</t>
<t><list style="numbers">
<t>There should be a mechanism to limit it, for example:<list
style="symbols">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t>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:<list style="symbols">
<t>competing-non-PCN-traffic contributes to the PCN meters:
competing-non-PCN-packets are treated as metered-packets.</t>
<t>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-packets are not treated as
metered-packets.</t>
</list></t>
<t>The operator should decide on what appropriate action. Dropping
is discussed further in Section B.4.</t>
</list></t>
<t>One specific example of competing-non-PCN-traffic occurs if the
PCN-compatible Diffserv codepoint is one of those that <xref
target="I-D.ietf-tsvwg-admitted-realtime-dscp"></xref>) 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 <xref
target="RFC5127"></xref>). In such cases PCN-traffic and
competing-non-PCN-traffic are distinguished by different values of the
ECN field <xref target="I-D.ietf-pcn-baseline-encoding"></xref>.</t>
<t>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.</t>
</section>
<section title="Scope">
<t>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.</t>
<t>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.</t>
<t>The baseline encoding <xref
target="I-D.ietf-pcn-baseline-encoding"></xref> 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 <xref target="RFC5559"></xref>. 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.</t>
<t>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.</t>
</section>
<section title="Behaviour aggregate classification">
<t>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 <xref target="I-D.ietf-pcn-baseline-encoding"></xref> defines
the baseline encoding.</t>
<t>Configuration will also define what values of the DSCP and ECN
fields indicate a competing-non-PCN-packet in a particular
PCN-domain.</t>
</section>
<section title="Dropping">
<t>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.</t>
<t>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.</t>
<t>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 <xref target="I-D.ietf-tsvwg-admitted-realtime-dscp"></xref>):</t>
<t><list style="symbols">
<t>a common queue for PCN-traffic and competing-non-PCN-traffic,
and a traffic conditioner for the competing-non-PCN-traffic;
or</t>
<t>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.</t>
</list></t>
<t>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" <xref target="RFC2475"></xref>) is not suitable if the
traffic comes from real time applications.</t>
<t>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.</t>
<t>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 <xref
target="I-D.taylor-pcn-cl-edge-behaviour"></xref> this avoids
over-termination in the event of multiple bottlenecks in the
PCN-domain <xref target="I-D.charny-pcn-comparison"></xref>. A fuller
explanation is as follows. The optimal dropping behaviour depends on
the particular edge behaviour <xref target="Menth09"></xref>. 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 <xref
target="I-D.charny-pcn-comparison"></xref>). 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 <xref target="Menth09"></xref>; (2) tail dropping may
make PCN-marking behaviour easier to implement on current routers.</t>
<t>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.</t>
<t>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 <xref target="Menth09"></xref>. Effectively it means
that the dropping function (if present) should be done before the
meter functions - which is natural.</t>
</section>
<section title="Threshold-metering">
<t>The description is in terms of a ‘token bucket with
threshold’ (which <xref
target="I-D.briscoe-tsvwg-cl-architecture"></xref> views as a virtual
queue). However the description is not intended to standardise
implementation.</t>
<t>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.</t>
<t>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.</t>
<t>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:<list style="symbols">
<t>whether tokens are added to the token bucket at regular time
intervals or only when a packet is processed.</t>
<t>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.</t>
<t>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:<list style="symbols">
<t>set F_tm = 0 and indicate threshold-mark to the Marking
function.</t>
<t>check whether F_tm < threshold and if it is then
indicate threshold-mark to the Marking function; then set F_tm
= 0.</t>
<t>leave F_tm unaltered and indicate threshold-mark to the
Marking function.</t>
</list></t>
</list><list style="symbols">
<t>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.</t>
<t>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.</t>
</list></t>
</section>
<section title="Excess-traffic-metering">
<t>The description is in terms of a token bucket, however the
implementation is not standardised.</t>
<t>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.</t>
<t>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.</t>
<t>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
<xref target="I-D.charny-pcn-comparison"></xref>. 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.</t>
<t>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 <xref target="Menth09"></xref>. (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’.</t>
<t>"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” 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 <xref
target="I-D.briscoe-tsvwg-byte-pkt-mark"></xref> <xref
target="Menth09"></xref>. "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. The algorithm described in Appendix A
implements this behaviour <xref target="Menth09"></xref>.</t>
<t>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).</t>
</section>
<section title="Marking">
<t>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).</t>
<t>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.</t>
<t>Although the metering functions are described separately from the
marking function, they can be implemented in an integrated
fashion.</t>
</section>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 13:19:36 |