One document matched: draft-ietf-pcn-marking-behaviour-00.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-00"
ipr="full3978">
<front>
<title abbrev="">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="2" month="October" year="2008" />
<area>Transport Area</area>
<workgroup>PCN Working Group</workgroup>
<keyword>Sample</keyword>
<keyword>Draft</keyword>
<abstract>
<t>This document standardises the two marking behaviours of PCN-nodes:
threshold marking and excess traffic marking. Threshold marking marks
all PCN-packets if the PCN traffic rate is greater than a first
configured rate. Excess traffic marking marks a proportion of
PCN-packets, such that the amount marked equals the traffic rate in
excess of a second configured rate.</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>This document standardises the two 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 marking: its objective is to mark all PCN-packets (with
a "threshold-mark") whenever the rate of PCN-packets is greater than
some configured rate ("PCN-threshold-rate");</t>
<t>excess traffic marking: whenever the rate of PCN-packets is
greater than some configured 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 bit rate of PCN-packets and the
PCN-excess-rate.</t>
</list></t>
<t><xref target="I-D.ietf-pcn-architecture"></xref> describes a general
architecture for how, in a particular DiffServ domain,
PCN-boundary-nodes convert these PCN-markings into decisions about flow
admission and flow termination. Other documents describe the wider
per-domain behaviour and how the PCN-markings are encoded in packet
headers. PCN encoding uses a combination of the DSCP field and ECN field
in the IP header to indicate that a packet is a PCN-packet and whether
it is PCN-marked. The baseline encoding <xref
target="I-D.ietf-pcn-baseline-encoding"></xref> standardises two
encoding states (PCN-marked and not PCN-marked), whilst other documents
(eg <xref target="I-D.moncaster-pcn-3-state-encoding"></xref>) define
extended schemes with three encoding states (PCN-threshold-marked,
PCN-excess-traffic-marked, not PCN-marked). <xref
target="RFC3168"></xref> defines a broadly RED-like default congestion
marking behaviour, but 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 classification: decide whether an incoming
packet is a PCN-packet or not.</t>
<t>Condition: drop packets if the link is overloaded.</t>
<t>Threshold meter: determine whether the rate of PCN-packets is
greater than the configured PCN-threshold-rate. The measurement is
made as an aggregate of all PCN-packets, and not per flow.</t>
<t>Excess traffic meter: measure by how much the rate of PCN-packets
is greater than the configured PCN-excess-rate. The measurement is
made as an aggregate of all PCN-packets, and not per flow.</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 =>|Classify |==>|Condition|==?================>|Marker|==> Packet
Stream | | | | | | | Stream
+---------+ +- - - - -+ | +------+
| +---------+ ^
| | Excess | |
+->| Traffic |-------+
| Meter | Result
+---------+
]]></artwork>
<postamble>Figure 1: Schematic of functions for
PCN-marking</postamble>
</figure></t>
<section title="Terminology">
<t>In addition to the terminology defined in <xref
target="I-D.ietf-pcn-architecture"></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 competes for
the same capacity as PCN-traffic. "Capacity" means the forwarding
bandwidth on a link; "competes" means that
competing-non-PCN-packets will delay PCN-packets in the queue for
the link. 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 below (with the minor exception noted below in
Section 2.5). A PCN-packet MUST be treated as a metered-packet. A
competing-non-PCN-packet MAY be treated as a metered-packet.</t>
</list></t>
</section>
</section>
<section title="Specified PCN-marking behaviour">
<t>This section specifies the PCN-marking behaviour. The descriptions
are functional and are not intended to restrict the implementation.. The
Informative Appendixes supplement it.</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. 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 for the same capacity as
PCN-traffic. "Capacity" means the forwarding bandwidth on a link;
"competes" means that competing-non-PCN-packets will delay PCN-packets
in the queue for the link.</t>
</section>
<section title="Traffic conditioning function">
<t>Note: if the PCN-node's queue overflows then naturally packets are
dropped; traffic conditioning is action additional to this.</t>
<t>On all links in the PCN-domain, traffic conditioning MAY be done
by:</t>
<t><list style="symbols">
<t>metering all metered-packets to determine if the level of
metered-traffic is sufficiently high to overload the PCN behaviour
aggregate. (According to <xref target="RFC2475"></xref> metering
is "the process of measuring the temporal properties (eg rate) of
a traffic stream".)</t>
<t>if the level of metered-traffic is sufficiently 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 bit rate, termed PCN-threshold-rate. The amount of tokens
in the token bucket is termed TBthreshold.fill. Tokens are added at
the PCN-threshold-rate, to a maximum value TBthreshold.max. Tokens are
removed equal to the size in bits of the metered-packet, to a minimum
TBthreshold.fill=0.</t>
<t>The token bucket has a configured intermediate depth, termed
TBthreshold.threshold. If TBthreshold.fill < TBthreshold.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 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 it is metered by the Excess traffic Meter.</t>
<t>A PCN-node MUST implement an Excess traffic 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 bit rate, termed PCN-excess-rate. The amount of tokens in
the token bucket is termed TBexcess.fill. Tokens are added at the
PCN-excess-rate, to a maximum value TBexcess.max. Tokens are removed
equal to the size in bits of the metered-packet, to a minimum
TBexcess-fill=0. The PCN-excess-rate is greater than (or equal to) the
PCN-threshold-rate.</t>
<t>If the token bucket is empty (TBexcess.fill = 0), then the meter
indicates to the Marking function that the packet is to be
excess-traffic-marked.</t>
<t>In addition to the above, if the token bucket is within an MTU of
being empty, then the meter SHOULD indicate to the Marking function
that the packet is to be excess-traffic-marked; MTU means the maximum
size of PCN-packets on the link. Otherwise the meter MUST NOT indicate
marking.</t>
</section>
<section title="Marking function">
<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>A PCN-packet MUST be marked to reflect the metering results by
setting its encoding state appropriately, as specified below. The
encoding states are defined values of the DSCP and ECN fields, as
specified in the appropriate encoding document.</t>
<t>There are three possibilities, depending on how many encoding
states are available:</t>
<t><list style="symbols">
<t>if three encoding states are available (one for
threshold-marked, one for excess-traffic-marked and one for "not
PCN-marked") then:<list style="symbols">
<t>the encoding state of a packet that has already been
excess-traffic-marked is not altered, whatever the meters
indicate;</t>
<t>Otherwise:<list style="symbols">
<t>if both meters indicate marking, then the packet is
excess-traffic-marked;</t>
<t>if the threshold meter indicates marking and the excess
traffic meter doesn't, then threshold-marking is
applied;</t>
<t>if the excess traffic meter indicates marking and the
threshold traffic meter doesn't, then
excess-traffic-marking is applied;</t>
<t>if neither meter indicates marking, then the packet's
encoding state is not altered.</t>
</list></t>
</list></t>
<t>if two encoding states are available (one for threshold-marked
and one for "not PCN-marked") then:<list style="symbols">
<t>if the Threshold Meter indicates marking, then the packet
is threshold-marked;</t>
<t>otherwise the packet's encoding state is not altered.</t>
</list></t>
<t>if two encoding states are available (one for
excess-traffic-marked and one for "not PCN-marked") then:<list
style="symbols">
<t>if the Excess traffic Meter indicates marking, then the
packet is excess-traffic-marked;</t>
<t>otherwise the packet's encoding state is not altered.</t>
</list></t>
</list></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>See <xref target="I-D.ietf-pcn-architecture"></xref></t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Michael Menth, Joe Babiarz, Anna Charny reviewed a preliminary
version of the draft-eardley-pcn-marking-behaviour-00 draft.</t>
<t>Thanks to those who've made comments on this draft: Michael Menth,
Joe Babiarz, Anna Charny, Ruediger Geib, Wei Gengyu, Fortune Huang, Bob
Briscoe, Toby Moncaster, Christian Hublet, Ingemar Johansson, Ken
Carlberg, Georgios Karagiannis.</t>
<t>All the work by many people in the PCN WG.</t>
<t></t>
</section>
<section title="Changes">
<t></t>
<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 anchor="Authors" title="Authors">
<t>Many people need to be added.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.I-D.ietf-pcn-baseline-encoding" ?>
<?rfc include="reference.I-D.ietf-pcn-architecture"?>
<?rfc ?>
<?rfc ?>
<?rfc include="reference.RFC.2474"?>
<?rfc include="reference.RFC.2475"?>
<?rfc ?>
<?rfc ?>
<?rfc ?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.1633"?>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.3086"?>
<?rfc include="reference.RFC.3168"?>
<?rfc include="reference.RFC.5129"?>
<?rfc include="reference.I-D.charny-pcn-comparison" ?>
<?rfc include="reference.I-D.ietf-pcn-architecture" ?>
<?rfc include="reference.I-D.ietf-tsvwg-admitted-realtime-dscp" ?>
<?rfc include="reference.I-D.moncaster-pcn-3-state-encoding" ?>
<?rfc include="reference.I-D.briscoe-tsvwg-byte-pkt-mark" ?>
<?rfc include="reference.I-D.briscoe-tsvwg-cl-architecture" ?>
<reference anchor="Menth"
target="http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08-PCN-Comparison.pdf">
<front>
<title>Menth</title>
<author fullname="Michael Menth" surname=""></author>
<date month="" year="2008" />
</front>
</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="Menth"></xref>.</t>
<t>There is no attempt to optimise the algorithms. It implements the
metering and marking functions 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>TBthreshold.PCN-threshold-rate: token rate of token bucket
(bits/second)</t>
<t>TBthreshold.max: depth of token bucket (bits)</t>
<t>TBthreshold.threshold: marking threshold of token bucket
(bits)</t>
<t>TBthreshold.lastUpdate: time the token bucket was last updated
(seconds)</t>
<t>TBthreshold.fill: 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 are the parameters:<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>TBthreshold.fill = min(TBthreshold.max, TBthreshold.fill + (now
- TBthreshold.lastUpdate) * TBthreshold.PCN-threshold-rate); //
add tokens to token bucket</t>
<t>TBthreshold.fill = max(0, TBthreshold.fill - packet.size); //
remove tokens from token bucket</t>
<t>if ((TBthreshold.fill < TBthreshold.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>TBthreshold.lastUpdate = now</t>
</list></t>
</section>
<section title="Excess traffic metering and marking">
<t>A token bucket with the following parameters:<list style="symbols">
<t>TBexcess.PCN-excess-rate: token rate of token bucket
(bits/second)</t>
<t>TBexcess.max: depth of TB in token bucket (bits)</t>
<t>TBexcess.lastUpdate: time the token bucket was last updated
(seconds)</t>
<t>TBexcess.fill: 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 are the parameters:<list style="symbols">
<t>now: the current time (seconds)</t>
<t>MTU: the maximum transfer unit of the link (or the known
maximum size of PCN-packets on the link) (bits)</t>
</list></t>
<t>The following steps are performed when a PCN-packet arrives on a
link:</t>
<t><list style="symbols">
<t>TBexcess.fill = min(TBexcess.max, TBexcess.fill + (now -
TBexcess.lastUpdate) * TBexcess.PCN-excess-rate); // add tokens to
token bucket</t>
<t>if (packet.mark != excess-traffic-marked) then TBexcess.fill =
max(0, TBexcess.fill - packet.size); // remove tokens from token
bucket, but do not meter packets that are already
excess-traffic-marked</t>
<t>if (TBexcess.fill < MTU) then packet.mark =
excess-traffic-marked; // do (packet size independent) excess
traffic marking</t>
<t>TBthreshold.lastUpdate = now</t>
</list></t>
</section>
</section>
<section title="Implementation notes">
<t>Note: This Appendix is informative, not normative. It comments on
Section 2.</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="I-D.ietf-pcn-architecture"></xref>. But if there is
competing-non-PCN-traffic, then there needs to be:</t>
<t><list style="numbers">
<t>a mechanism to limit it, for example:<list style="symbols">
<t>limiting the rate at 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 police (traffic condition)
the competing-non-PCN-traffic on each link, ie drop
competing-non-PCN-packets in excess of some rate.</t>
<t>policing of competing-non-PCN-traffic at the
PCN-ingress-nodes. For example, as in the DiffServ
architecture - although its static traffic conditioning
agreements risk a focussed overload of traffic from several
PCN-ingress-nodes on one link.</t>
<t>design: it is known by design 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 by:<list style="symbols">
<t>competing-non-PCN-traffic contributes to the PCN meters (ie
competing-non-PCN-packets are treated as metered-packets).</t>
<t>each PCN-node reduces, on its links, the PCN-threshold-rate
and PCN-excess-rate, in order to allow 'headroom' for the
competing-non-PCN-traffic; also limiting 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>
</list>It is left up to the operator to decide on appropriate
action. Traffic conditioning is discussed further in the separate
section below.</t>
<t>One specific example of competing-non-PCN-traffic occurs if the
PCN-compatible Diffserv codepoint is the Voice-admit codepoint, and
there is voice-admit traffic in the PCN-domain.</t>
<t>Another example would occur if there was more than one
PCN-compatible Diffserv codepoint in a PCN-domain. For instance,
suppose there were 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, eg by the design of the network topology, that
some links can never be pre-congested (even in unusual circumstances,
eg after the failure of some links). There is then no need to deploy
PCN behaviour on those links.</t>
<t>The meter and marker can be implemented on the ingoing or outgoing
interface of a PCN-node. It may be that existing hardware can support
only one meter and marker per ingoing interface and one per outgoing
interface. Then for instance threshold metering and marking could be
run on all the ingoing interfaces and excess traffic metering and
marking 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>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 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 this scenario means that
the Marking function ignores indications from one of the meters, they
might 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 PCN.</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.</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="Traffic conditioning">
<t>If there is no competing-non-PCN-traffic, then it is not expected
that traffic conditioning is needed, since PCN's flow admission and
termination mechanisms limit the amount of PCN-traffic. Even so,
traffic conditioning still might be implemented as a back stop against
misconfiguration of the PCN-domain, for instance.</t>
<t>The objective of traffic conditioning 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. The details will depend on how the router's
implementation handles the two sorts of traffic <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;</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>The traffic conditioning action is to drop packets. Downgrading of
packets to a lower priority BA is left as a theoretical possibility
(beware of packet mis-ordering). Shaping ("the process of delaying
packets" <xref target="RFC2475"></xref>) is not suitable here as the
traffic is expected to come from real time applications. In general it
is reasonable for competing-non-PCN-traffic to get harsher treatment
than PCN-traffic (ie 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 policer
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". This avoids over-termination, with the CL/SM
edge behaviour, in the event of multiple bottlenecks in the PCN-domain
<xref target="I-D.charny-pcn-comparison"></xref>.</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: "PCN-packets that are dropped
(downgraded) SHOULD NOT be metered by the Excess traffic Meter." This
avoids over-termination, with the CL/SM edge behaviour, in the event
of multiple bottlenecks <xref
target="I-D.charny-pcn-comparison"></xref>. Effectively it means that
traffic conditioning 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 implementation is not standardised.</t>
<t>Section 2.3 defines: "If TBthreshold.fill <
TBthreshold.threshold, then the meter indicates to the Marking
function that the packet is to be threshold-marked; otherwise it does
not." Note that the PCN-packet (that causes the token bucket to cross
TBthreshold.threshold) is marked without explicit additional bias for
the packet's size.</t>
<t>The behaviour must be functionally equivalent to the description
above. "Functionally equivalent" means the observable 'black box'
behaviour is the same or very similar. 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 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 TBthreshold.fill, then the precise change in
TBthreshold.fill is up to the implementation. A behaviour is
functionally equivalent if either precisely the same set of
packets is marked, or if the set is shifted by one packet. For
instance, the following should all be considered as "functionally
equivalent":<list style="symbols">
<t>set TBthreshold.fill = 0 and indicate threshold-mark to the
Marking function.</t>
<t>check whether TBthreshold.fill < TBthreshold.threshold
and if it is then indicate threshold-mark to the Marking
function; then set TBthreshold.fill = 0.</t>
<t>leave TBthreshold.fill 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 large than (TBthreshold.max - TBthreshold.fill),
then the precise change in TBthreshold.fill is up to the
implementation.</t>
<t>Note that all packets, even if already marked, are metered by
the threshold meter function (unlike the excess traffic meter
function - see below) - 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>As in Section B.3, "functionally equivalent" allows some
implementation flexibility when the token bucket is very nearly empty
or very nearly full.</t>
<t>Packet size independent marking is specified as a SHOULD in Section
2.4 ( "If the token bucket is within an MTU of being empty, then the
meter SHOULD indicate to the Marking function that the packet is to be
excess-traffic-marked; MTU means the maximum size of PCN-packets on
the link.") Without it, large packets are more likely to be
excess-traffic-marked than small packets and 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="Menth"></xref>.</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". 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 Classification
function.</t>
<t>Section 2.4 specifies: "A packet SHOULD NOT be metered (by this
excess traffic meter function) ... If this PCN-node drops (downgrades)
the packet because the link is overloaded." This avoids
over-termination <xref target="Menth"></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 PCN-marking all packets.)</t>
<t>Note that TBexcess.max is independent of TBthreshold.max;
TBexcess.fill is independent of TBthreshold.fill (except in that a
packet changes 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 MUST NOT traffic
condition by downgrading a PCN-packet into a lower priority DiffServ
BA. The bullet needs to be modified if the WG decides to allow such
traffic conditioning.</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>
<t>In some environments encoding states may be scarce, for example
MPLS <xref target="RFC5129"></xref>, and then it may be preferable to
have only two encoding states, as in the baseline encoding <xref
target="I-D.ietf-pcn-baseline-encoding"></xref>. In other environments
it will be possible to use one of the extension encodings that specify
three encoding states.</t>
<t>Section 2.5 states: "if three encoding states are available ... if
the threshold meter indicates marking and the excess traffic meter
doesn't, then threshold-marking is applied; if the excess traffic
meter indicates marking and the threshold traffic meter doesn't, then
excess-traffic-marking is applied". The latter case seems infeasible
but is possible for a short time - because the meters might react at
different speeds when the traffic rate changes.</t>
</section>
</section>
<section title="Per-domain Behaviour">
<t>Note: This Appendix is informative, and to be deleted in next
version. It simply archives material from the previous draft which
concerns PCN-boundary-node behaviour and/or per-domain behaviour <xref
target="RFC3086"></xref>.</t>
<section title="(from Introduction)">
<t>[ietf-pcn-architecture] describes a general architecture for flow
admission and termination based on pre-congestion information in order
to protect the quality of service of established inelastic flows
within a single DiffServ domain. The pre-congestion information
consists of specific markings of PCN-packets. The edge nodes of the
DiffServ domain read these markings and convert them into flow
admission and termination decisions.</t>
<t></t>
<t>So in a particular deployment the operator may have three encoding
states available (so allowing both threshold marking and excess
traffic marking) or may have only two encoding states (so allowing
either threshold marking and excess traffic marking). As described in
<xref target="I-D.ietf-pcn-architecture"></xref>, flow termination is
based on excess traffic marked packets, whilst admission control can
be based on either threshold marked or excess traffic marked packets
(the former is more accurate, <xref
target="I-D.charny-pcn-comparison"></xref>). This leads to the
following four use cases:</t>
<t><list style="numbers">
<t>an operator requires both admission control and flow
termination, and has three encoding states available. Then
admission control is triggered from PCN-packets that are
threshold-marked, and flow termination from PCN-packets that are
excess-traffic-marked.</t>
<t>an operator requires both admission control and flow
termination, and has only two encoding states available. Then both
admission control and flow termination are triggered from
PCN-packets that are excess-traffic-marked.</t>
<t>an operator requires only admission control. Then admission
control is triggered from PCN-packets that are threshold-marked
and only two encoding states are needed. (Flow termination may be
provided by a non PCN mechanism; this is out of scope.)</t>
<t>an operator requires only flow termination. Then flow
termination is triggered from PCN-packets that are
excess-traffic-marked and only two encoding states are needed.
(Admission control may be provided by a non PCN mechanism; this is
out of scope.)</t>
</list></t>
</section>
<section title="Scope">
<t>The functions defined in the following sub-sections SHOULD be
implemented on all links in the PCN-domain.</t>
<t>There are three possibilities regarding encoding states:</t>
<t><list style="symbols">
<t>three encoding states are available,<list style="symbols">
<t>one for threshold marks,</t>
<t>one for excess rate marks</t>
<t>one for "not PCN-marked";</t>
</list></t>
<t>two encoding states are available,<list style="symbols">
<t>one for threshold marks</t>
<t>one for "not PCN-marked";</t>
</list></t>
<t>two encoding states are available,<list style="symbols">
<t>one for excess rate marks</t>
<t>one for "not PCN-marked".</t>
</list></t>
</list>The same choice of encoding states MUST be used throughout a
PCN-domain.</t>
<t></t>
</section>
<section title="Classify">
<t>Configuration action defines the values of DSCP & ECN fields
associated with PCN across the domain.</t>
<t></t>
</section>
<section title="Colour">
<t>PCN-ingress-nodes MUST colour PCN-traffic (if necessary) by
altering the DSCP and ECN fields to values appropriate for the
PCN-domain.</t>
<t></t>
</section>
<section title="Traffic conditioning ">
<t></t>
<t>In addition, PCN-ingress-nodes MUST police PCN-traffic by</t>
<t>[NOTE; discussion in Dublin: make this a SHOULD, as PCN may well be
a small % traffic and is prioritised]:</t>
<t><list style="symbols">
<t>metering PCN-packets that are part of a previously admitted
PCN-flow, to check that it keeps to the agreed rate or flowspec
(eg <xref target="RFC1633"></xref> for a microflow, and its NSIS
equivalent).</t>
<t>checking that any packets received that demand PCN treatment do
indeed belong to a previously admitted flow.</t>
<t>dropping or downgrading packets that fail the above checks.</t>
</list></t>
<t>In addition, PCN-ingress-nodes MUST police other-traffic by:</t>
<t><list style="symbols">
<t>metering other-traffic to check that it meets its traffic
conditioning agreement, which is the parameters of the traffic
that will be accepted from a customer. Typically it is statically
defined as part of the subscription-time service level agreement,
as in the DiffServ architecture <xref
target="RFC2475"></xref>.</t>
<t>dropping or downgrading packets that fail the above check.</t>
</list></t>
<t>In addition, an operator MAY measure the amount of traffic entering
(or leaving) its network for accounting reasons. Consideration is out
of scope of this document.</t>
<t></t>
</section>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 08:30:22 |