[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01
Network Working Group J. Babiarz
Internet-Draft X-G. Liu
Intended status: Informational K. Chan
Expires: May 22, 2008 Nortel
M. Menth
University of Wuerzburg
November 19, 2007
Three State PCN Marking
draft-babiarz-pcn-3sm-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 22, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document proposes a mechanism for admission control and flow
termination. It is based on the concept of pre-congestion
notification (PCN) using three different codepoints: "no pre-
congestion", "admission-stop", and "excess-traffic" for packet
marking. Therefore, the proposal is called three state marking
Babiarz, et al. Expires May 22, 2008 [Page 1]
Internet-Draft Three State PCN Marking November 2007
(3sm). The behaviour of edge nodes is presented which distinguishes
from other proposals through little complexity and its ability to
cope with multipath routing. Algorithms required for packet metering
and marking are explained in detail.
Babiarz, et al. Expires May 22, 2008 [Page 2]
Internet-Draft Three State PCN Marking November 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6
1.2. Terminology Used in this Document . . . . . . . . . . . . 6
1.3. Adapted Terminology . . . . . . . . . . . . . . . . . . . 6
1.4. New Terminology . . . . . . . . . . . . . . . . . . . . . 7
2. The 3sm Proposal . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Packet Marking in 3sm . . . . . . . . . . . . . . . . . . 8
2.2. Admission Control in 3sm . . . . . . . . . . . . . . . . . 9
2.2.1. Explicit Edge-to-Edge Tunnels (E3Tunnel) . . . . . . . 9
2.3. End-to-End on-Path Signalling (End2PS) . . . . . . . . . . 11
2.3.1. Operation of Standard RSVP . . . . . . . . . . . . . . 11
2.3.2. Modification of Standard RSVP to Perform PCN-Based
Admission Control . . . . . . . . . . . . . . . . . . 12
2.4. Edge-to-Edge on-Path Signalling (Edge2PS) . . . . . . . . 12
2.5. Flow Termination in 3sm . . . . . . . . . . . . . . . . . 13
2.5.1. Marked Flow Termination (MFT) . . . . . . . . . . . . 13
2.5.2. Measured Rate Termination (MRT) . . . . . . . . . . . 14
3. Three State PCN Marker with Marking Frequency Reduction
(MFR) for Marked Flow Termination (MFT) . . . . . . . . . . . 14
3.1. ET-Marker . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.1. Behaviour of SR-Metering and ET-Marking . . . . . . . 15
3.1.2. Pseudo Code for the ET-Marker . . . . . . . . . . . . 16
3.1.3. Configuration of the ET-Marker . . . . . . . . . . . . 16
3.1.4. Characteristics of the Proposed ET-Marker . . . . . . 17
3.2. AS-Marker . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.1. Behaviour of AR-Metering and AS-Marking . . . . . . . 18
3.2.2. Pseudo Code for AS-Marker . . . . . . . . . . . . . . 18
3.2.3. Configuration of the AS-Marker . . . . . . . . . . . . 18
3.2.4. Characteristics of the Proposed AS-Marker . . . . . . 19
3.3. Marking Codepoints . . . . . . . . . . . . . . . . . . . . 19
4. Benefits and Shortcomings of the 3sm Proposal . . . . . . . . 19
4.1. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2. Shortcomings of 3sm . . . . . . . . . . . . . . . . . . . 21
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
6. Changes from Previous Revision . . . . . . . . . . . . . . . . 21
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
8. Informative References . . . . . . . . . . . . . . . . . . . . 23
Appendix A. Overview of Token Bucket (TB) and Virtual Queue
(VQ) . . . . . . . . . . . . . . . . . . . . . . . . 24
A.1. New features for marking algorithm . . . . . . . . . . . . 24
A.1.1. Virtual Queue (VQ) . . . . . . . . . . . . . . . . . . 24
A.1.2. Token Bucket (TB) . . . . . . . . . . . . . . . . . . 25
A.1.3. Tail Marking . . . . . . . . . . . . . . . . . . . . . 25
A.1.4. Tail Marking with Marking Frequency Reduction (MFR) . 26
A.1.5. Tail Marking with Packet Size Independent Marking
(PSIM) and Proportional Marking Frequency
Babiarz, et al. Expires May 22, 2008 [Page 3]
Internet-Draft Three State PCN Marking November 2007
Reduction (PMFR) . . . . . . . . . . . . . . . . . . . 27
A.1.6. Threshold Marking . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 31
Babiarz, et al. Expires May 22, 2008 [Page 4]
Internet-Draft Three State PCN Marking November 2007
1. Introduction
Pre-Congestion Notification (PCN) builds on the concepts of
[RFC3168], "The addition of Explicit Congestion Notification (ECN) to
IP". It is used to implement admission control and flow termination
for real-time flows (such as voice, video and multimedia streaming)
in DiffServ [RFC2474], [RFC2475] enabled networks. Flow admission
control determines whether a new flow can be added into the network
without overloading any of its links, whereas flow termination
reduces the current PCN traffic load by terminating marked flows when
at least one link in the network is overloaded for some reason. For
a general overview, the reader is referred to
[I-D.ietf-pcn-architecture].
This document describes the 3sm proposal which is a special
implementation of the general PCN framework
[I-D.ietf-pcn-architecture]. It relies on three different packet
markings: "no pre-congestion" (NP), "admission-stop" (AS), or
"excess-traffic" (ET). Packets enter a network with NP (unmarked).
The basic idea is as follows. Each link in a PCN domain has an
admissible rate (AR). If the current PCN traffic rate of a link
exceeds its AR, all PCN packets on that link are re-marked with AS.
The PCN egress nodes monitor the packet markings and trigger the PCN
ingress nodes to admit or reject new flow requests depending on
whether they observe AS-marked packets or not. Similarly, each link
has a supportable rate (SR). If the current PCN traffic rate of a
link exceeds its SR, some of the PCN packets on that link are re-
marked with ET. The PCN egress nodes detect ET-marked packets and
pass their flow IDs to the appropriate flow termination entity. This
concept is called marked flow termination (MFT).
The 3sm architecture expects the above mentioned marking behaviour
from PCN interior nodes. We propose simple metering and marking
algorithms for that purpose. Those are threshold marking for AS-
marking and tail marking with marking frequency reduction (MFR) for
ET-marking. We describe them in Section 3 based on a token bucket
approach. To improve the termination behaviour of MFT, we suggest
packet size independent marking (PSIM) and proportional MFR (PMFR) in
the Appendix A and show that the same behaviour can be specified
based on a virtual queue.
The document is structured as follows. After a short section on
terminology, Section 2 focuses on the edge behaviour of the 3sm
proposal. Section 3 provides detailed algorithms for the metering
and marking behaviour expected from interior nodes in 3sm. Section 4
list benefits and shortcomings of the 3sm proposal. Appendix A
summarizes background information about token bucket (TB) and virtual
queue (VQ) metering and marking as they are the base for the proposed
Babiarz, et al. Expires May 22, 2008 [Page 5]
Internet-Draft Three State PCN Marking November 2007
metering and marking mechanisms.
1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1.2. Terminology Used in this Document
The terminology used in this document conforms to the terminology of
[I-D.ietf-pcn-architecture]. However, we adapted some terminology
for better readability and added some new terminology that we found
useful in this document.
1.3. Adapted Terminology
[I-D.ietf-pcn-architecture] has chosen very general terms for the
rate thresholds as they have different semantic meanings in different
proposals for the implementation of the general PCN architecture.
For better readability, we use names that are more intuitive within
the 3sm proposal.
o Admissible rate (AR) - PCN-lower-rate
o Supportable rate (SR) - PCN-upper-rate
o AR-overload - Condition that PCN traffic rate exceeds AR of a link
o SR-overload - Condition that PCN traffic rate exceeds SR of a link
o No pre-congestion (NP) - Default marking for PCN packets that have
not been carried over links with any type of pre-congestion (AR-
overload or SR-overload).
o Admission-stop (AS) - PCN-lower-rate-marking
o Excess-traffic (ET) - PCN-upper-rate-marking
o AS-marking - Action of re-marking of NP-marked packets to AS
o ET-marking - Action of re-marking of NP- or AS-marked packets to
ET
Babiarz, et al. Expires May 22, 2008 [Page 6]
Internet-Draft Three State PCN Marking November 2007
1.4. New Terminology
We provide a brief definition of the terminology used in this
document.
o PCN - Pre-Congestion Notification meters traffic rates per service
class on a link and notifies the PCN egress nodes using packet
marking whether a certain rate threshold is exceeded on any link
of the path through the PCN-enabled network taken by the packet.
The rate thresholds may be significantly lower than the line rates
such that PCN egress nodes are notified long before queues build
up in the buffers and real congestion occurs. PCN is intended for
the implementation of measurement-based admission control and flow
termination for real-time inelastic traffic, e.g., voice. The PCN
marking in the packet headers need to be standardized.
o ECN Field - Refers to the use of the standardized two bit field in
the IP header that is used for signalling Explicit Congestion
Notification [RFC3168]. In the PCN framework the ECN field maybe
reused to signal two levels of PCN marking.
o Service class - By service class we mean a grouping of packets
belonging to one or more applications or services that generated
traffic with similar characteristics and requiring similar QoS
treatment. See [RFC4594] for details.
o Admission Control - It is the function of admitting or blocking
requests of new flows or sessions for access to the network to
prevent AR-overload.
o Flow Termination - It is the function of terminating already
admitted flows in the sense that they cannot continue to send PCN
traffic. Only flows contributing to SR-overload are terminated to
reduce SR-overload.
o Deployment model - A method to find the PCN information for the
path of a new flow that requests admission to the PCN domain and
to perform the required admission decision. Deployment models
take advantage of information or protocols available in the
networking scenario where PCN is to be deployed.
o Marked flow termination (MFT) - Flow termination function
terminating marked flows.
o Measured rate termination (MRT) - Flow termination function
terminating a certain rate of traffic that was directly or
indirectly measured by the system.
Babiarz, et al. Expires May 22, 2008 [Page 7]
Internet-Draft Three State PCN Marking November 2007
o Marking frequency reduction (MFR) - Marked flow termination (MFT)
requires that only some instead of all PCN packets exceeding the
supportable rate (SR) of a link are marked. This is achieved by
MFR. This can be achieved by adding a slowdown factor of "s"
tokens to the fill state of the token bucket whenever a packet is
ET-marked.
o Token bucket (TB) - One base mechanism for packet metering.
o Virtual queue (VQ) - Another, equivalent base mechanism for packet
marking.
2. The 3sm Proposal
First, a high-level overview of the packet marking in 3sm is
presented. Then, the edge behaviour for the admission control and
flow termination function is explained.
2.1. Packet Marking in 3sm
PCN traffic can be classified by DSCP or a group of DSCPs and is
forwarded by an appropriated PHB. PCN configures for each link an
admissible and a supportable rate (AR, SR). PCN traffic enters the
network with a "no-precongestion" (NP) mark. PCN nodes meter the PCN
traffic on every link. When the PCN traffic rate on a link exceeds
the corresponding AR, the PCN node re-marks all NP-marked PCN packets
to "admission-stop" (AS).
Similarly, they re-mark some non-ET-marked PCN packets to "excess-
traffic" (ET) when the PCN traffic rate on a link exceeds the
corresponding SR. Figure 1 summarizes the relation between the AR
and SR thresholds and the marking behaviour. The SR normally is at
least a delta above the AR and a delta below the maximum service rate
for PCN traffic for the sake of stability of the measurement-based
reactive system. If the PCN traffic rate is below AR, no packets are
re-marked; if it is between AR and SR, all NP-marked PCN packets are
re-marked to AS; and if it is above SR, some non-ET-marked PCN
packets are re-marked to ET and all other NP-marked PCN packets are
re-marked to AS. Hence, the meters and markers operate in a marking-
aware mode: NP-marked packets can be re-marked to AS or ET, AS-marked
packets can be re-marked to ET but not to NP, and ET-marked packets
cannot be re-marked at all.
Babiarz, et al. Expires May 22, 2008 [Page 8]
Internet-Draft Three State PCN Marking November 2007
PCN traffic rate
100%^
| AR- and SR-overload:
| re-mark SOME non-ET-marked
| packets to ET and the remaining to AS,
| indicating that AR and SR are exceeded
Supportable rate|----------------------------------------------
SR | AR-overload:
| re-mark ALL NP-marked packets to AS,
| indicating admissible rate is exceeded
Admissible rate |----------------------------------------------
AR |
| No overload: do not re-mark any packets
|
0%+------------------------------------------------->
Figure 1: Packet re-marking by PCN nodes.
2.2. Admission Control in 3sm
The admission of a flow requests depends on the marking that is
currently observed on the path the data packet of the future flow
will take. However, it is not trivial to provide this information
and may be achieved differently depending on the networking scenario.
Therefore, we introduce three deployment models that use their own
methods to get the PCN information for the path of a future data
flow. These deployment models are adapted to special networking
scenarios that are in use today and are named after the concept that
helps to find the path of future data packets:
o explicit edge-to-edge tunnels (E2Tunnel)
o end-to-end on-path signalling (End2PS)
o edge-to-edge on-path signalling (Edge2PS)
2.2.1. Explicit Edge-to-Edge Tunnels (E3Tunnel)
Explicit edge-to-edge tunnels provide an IP adjacency from a PCN
ingress node to a PCN egress node. As a consequence, the information
about the PCN egress node of a packet can be derived from the routing
table. In addition, we assume that each tunnel is set up on an
explicit path. This can be realized, e.g. by MPLS label switched
paths (LSPs) or IP-in-IP tunnelling. We use the name E3Tunnel to
abbreviate the term "explicit edge-to-edge tunnel" and as the name
for the corresponding deployment model. An E3Tunnel aggregate is the
ensemble of PCN traffic carries through the PCN domain through a
common explicit E3Tunnel.
Babiarz, et al. Expires May 22, 2008 [Page 9]
Internet-Draft Three State PCN Marking November 2007
In the presence of E3Tunnels, the tunnel a packet is forwarded over
is derived from the forwarding table of the PCN ingress node. This
information is required that a new flow can request admission to the
appropriate E3Tunnel. The PCN ingress and egress nodes have a
context for each E3Tunnel they support. The PCN ingress node works
per context in two different modes:
o the reject mode and
o the accept mode.
In the reject mode, the PCN ingress node rejects new admission
requests while it admits them in its accept mode.
Similarly, the PCN egress node works per context in two corresponding
modes:
o the admission-stop mode and
o the admission-continue mode.
The PCN egress node monitors the markings of the packets received
from a specific E3Tunnel and depending on their marking, it switches
to the admission-stop or admission-continue mode. Depending on its
mode, the PCN egress node periodically sends "admission-stop" or
"admission-continue" messages to the PCN ingress node belonging to
the same E3Tunnel. If the PCN egress node receives an "admission-
stop" message, it switches within the corresponding E3Tunnel context
to its reject mode and if it receives an "admission-continue"
message, it switches to its accept mode.
Different algorithms can be applied by the PCN egress node to decide
when to send which control messages. We give two examples.
o Option 1 (single-packet-based): If the PCN egress node observes a
single marked packet from a specific E3Tunnel, it turns to the
admission-stop mode. It returns to the admission-continue mode
after some time unless it still observes marked packets
occasionally. This option can be implemented without rate
measurement and even without any counters requiring per-packet
modification.
o Option 2 (CLE-based): The PCN egress node tracks the number of
marked and umarked packets from a specific E3Tunnel within a
measurement interval. It calculates the congestion level estimate
(CLE) which is the fraction of the marked and all packets observed
during this interval. If no packet was received within the last
measurement interval, the PCN egress node switches to the
Babiarz, et al. Expires May 22, 2008 [Page 10]
Internet-Draft Three State PCN Marking November 2007
admission-continue mode. If the PCN egress node is in the
admission-continue mode and the CLE of the last measurement
interval is larger than a predefined admission-stop threshold, it
switches to the admission-stop mode. If the PCN egress node is in
the admission-stop mode and the CLE is smaller than a predefined
admission-continue threshold, it switches to the admission-
continue mode.
2.3. End-to-End on-Path Signalling (End2PS)
End-to-end on-path signalling sends PATH messages downstream to
discover the path of future data packets and RESV messages upstream
to trigger the admission request for the correct forward path using
the gathered PATH information. The deployment model End2PS reuses
the end-to-end on-path signalling protocol for probing on which the
admission decision is based. We first explain the basic operation of
standard RSVP and then adapt it to perform PCN-based admission
control.
2.3.1. Operation of Standard RSVP
A popular protocol example is RSVP [RFC2205]. With RSVP, the data
source issues a PATH message which is carried hop-by-hop over the
same path future data packets will go. To that end, the PATH message
uses the same source and destination address as future data packets
and also all other header fields that are possible input for routing
and load balancing decisions need to be the same. When a PATH
message arrives at an RSVP-capable node, a PATH state is established
pointing to the previous hop before the PATH message is forwarded
further downstream. When the PATH message arrives at the
destination, the destination triggers the end-to-end reservation for
the flow by sending a RESV message upstream along the nodes that set
up a PATH state. In these nodes, the RESV message is processed. In
particular, resource admission control is performed for the new flow
request and if it succeeds, the node forwards the RESV message to the
previous hop recorded by the PATH state. This two pass signalling
approach guarantees that the reservation is done on the downstream
path of the future data flow. In contrast to PATH messages, RESV
messages have the source address of the sending node and the
destination address of the hop pointed to by the PATH state. That
way, the information about the downstream next hop of the future data
stream is conveyed to the previous hop and the flow-related
information is stored in a RESV state. RSVP is a soft-state
protocol, i.e., the PATH and RESV control messages are periodically
sent to keep the PATH and RESV states alive and, thereby, the flow
reservations. Admission control needs to be performed for a flow
only once when no RESV state is set up, yet.
Babiarz, et al. Expires May 22, 2008 [Page 11]
Internet-Draft Three State PCN Marking November 2007
2.3.2. Modification of Standard RSVP to Perform PCN-Based Admission
Control
We assume that interior nodes of a PCN domain are RSVP-disabled.
That means that they just forward RSVP messages without processing
them and PCN ingress and egress nodes are neighboring RSVP-capable
nodes. As a consequence, PCN ingress nodes decide whether new flows
can be admitted and carried through domain or not.
When the initial PATH message travels downstream, it is either marked
or not, and eventually received by the PCN egress node. If no PATH
state can be found for this flow at the PCN egress node, this PATH
message is the first one and not a REFRESH message. If the PATH
message is the first of the flow and if it is marked with "admission-
stop", the RSVP engine sends back a PATHERR message to reject the
flow. If the PATH message is not marked (NP), the RSVP PATH state is
established at the PCN egress node and the PATH message is forwarded
further downstream. REFRESH messages are just forwarded according to
standard RSVP. When the PATH message arrives at the destination and
a RESV message is sent. Eventually, the corresponding RESV message
arrives at the PCN ingress node. When no RESV state is set up yet,
this is the first RESV message and admission control must be
performed. By the mere fact that the RESV message arrives, the PCN
ingress node knows that the corresponding initial PATH message was
not marked. Thus, it can admit any flow for which a new RESV message
arrives.
A single probe is sufficient in 3sm because 3sm marks all packets
when AR-overload occurs. Note that RSVP is only an example for
End2PS, but End2PS works equally well with other two pass on-path
signalling protocols.
2.4. Edge-to-Edge on-Path Signalling (Edge2PS)
In the absence of explicit edge-to-edge tunnels or other on-path
signalling protocols, PCN information about the path future packets
of a new flow will take is required for a qualified admission
decision at the PCN ingress node. To that end, we propose to use an
edge-to-edge on-path signalling protocol (Edge2PS).
Again, we assume that all interior nodes of the PCN domain are RSVP-
disabled. When a request for the admission of a new flow arrives,
e.g. signalled via SIP INVITE or other means, the PCN ingress and
egress node act as RSVP proxies for the source and destination node
of the data flow and set up a reservation request between PCN ingress
and egress node. The source and destination address of the PATH
messages are those of the actual data flow. This guarantees that
they are carried on the same path as future data packet will be. The
Babiarz, et al. Expires May 22, 2008 [Page 12]
Internet-Draft Three State PCN Marking November 2007
PCN edge nodes do not forward the RSVP control messages outside the
PCN domain. Instead, the PCN egress node returns a RESV message to
the PCN ingress node. The RSVP messages created by PCN nodes on
behalf of the flow need to be discerned somehow from regular end-to-
end RSVP messages because they must not be forwarded outside the PCN
domain.
With this addition, the above presented modification of standard RSVP
can be used to admit flows based on a single probe message. Note
that there is no stringent need to use RSVP for Edge2PS. A less
complex two-pass protocol suffices.
2.5. Flow Termination in 3sm
Although flows are admitted only if the PCN traffic rate does not
exceed the admissible rate (AR) on any link of their paths, it is
possible that the PCN traffic rate on a link exceeds the SR, e.g.,
due to changed sending behaviour of admitted flows or due to route
changes after a failure.
With 3sm two different options for flow termination can be supported:
marked flow termination (MFT) and measured rate termination (MRT).
We explain them in the following.
2.5.1. Marked Flow Termination (MFT)
Each PCN egress node monitors its received PCN traffic. If it
detects an ET-marked packet, the corresponding PCN ingress node is
identified and the PCN egress node sends the flow ID belonging to the
ET-marked packet in a "traffic-reduction" message to the flow
termination entity (e.g. the appropriate PCN ingress node) for
termination. To save signalling overhead, several IDs may be
signalled in a single "traffic reduction" message.
Marked flow termination can be applied with any deployment model.
How the PCN ingress node of an ET-marked packet is derived depends on
the deployment model:
o E3Tunnel: the adjacency from which the packet is received defines
the E3Tunnel such that the corresponding PCN ingress node is
known.
o With End2PS or Edge2PS, the PCN egress nodes can map the packets
to RSVP reservations using RSVP classifiers, and the corresponding
RSVP PATH state contains the address of the PCN ingress node.
Marked flow termination (MFT) requires that only some of the packets
that exceed the supportable rate are ET-marked. Otherwise, MFT
Babiarz, et al. Expires May 22, 2008 [Page 13]
Internet-Draft Three State PCN Marking November 2007
terminates too many flows. With MFT, only a small fraction of the
traffic is removed within a round-trip time, but the process
continues if the PCN traffic rate still exceeds the supportable rate
(SR). Therefore, the PCN traffic rate is gradually reduced until it
drops below SR. Then, the flow termination process stops since no
more packets are ET-marked.
2.5.2. Measured Rate Termination (MRT)
Measured rate termination can be applied only in the E3Tunnel
deployment model. It requires that all packets exceeding SR are ET-
marked. The PCN egress nodes measure the rate of ET-marked (ETR)
packets per E3Tunnel and if it is larger than zero, it signals that
ETR to the corresponding flow termination entity in a "traffic-
reduction" message. The flow termination entity may be the
corresponding PCN ingress node which then terminates a subset of the
flows carried over the respective E3Tunnel such that the rate of
these flows is about ETR. However, this is not an easy task since
the actual rates of the flows are in general not known. If SR-
overload continues in spite of the flow termination, the PCN egress
node must wait some time before it sends a new "traffic-reduction"
message to guarantee that the impact of the previous one is already
reflected by the new measured rate of ET-marked traffic (ETR).
Measured rate termination can reduce SR-overload very quickly, but it
has several drawbacks:
o Rate measurement of ET-marked packets is complex.
o The choice of the right subset of flows is difficult and requires
that the rates of individual flows are known.
As marked flow termination (MFT) is simpler than measured rate
termination (MRT), we propose MFT as preferred method for flow
termination in 3sm.
3. Three State PCN Marker with Marking Frequency Reduction (MFR) for
Marked Flow Termination (MFT)
The three state PCN marker (3sm) meters PCN packet streams per link
and performs packet re-marking according to Figure 1. As a
consequence the following three marking states are required:
o no pre-congestion (NP),
o admission-stop (AS), and
Babiarz, et al. Expires May 22, 2008 [Page 14]
Internet-Draft Three State PCN Marking November 2007
o excess-traffic (ET).
In theory, the meter meters each packet and passes the packet and the
metering result to the marker, and the marker marks packets according
to the results of the meter. This is illustrated in Figure 2. The
marking may be coded in the ECN field [RFC3168] of the packet for a
specified PHB in a specific manner.
+------------+
| Result |
| V
+-------+ +--------+
| | | |
Packet stream ===>| Meter |===>| Marker |===> Marked packet stream
| | | |
+-------+ +--------+
Figure 2: Block diagram of meter and marker function.
The behaviour of the two functions is often described by a single
metering and marking algorithm. Therefore, we call the algorithm
metering packets relative to admissible rate (AR) and re-marking them
to AS simply AS-marker, and the algorithm metering packets relative
to supportable rate (SR) and re-marking them to ET simply ET-marker.
In the following, we explain the behaviour of the ET- and AS-marker
using token bucket (TB) based algorithms. The packet sizes counted
by the meters and markers pertain to the size of the IP packet
including its header bytes. Equivalent virtual queue (VQ) based
algorithms are presented in Appendix A. Other implementations
approximating the described behaviours can be used.
3.1. ET-Marker
We describe the behaviour for SR-metering and ET-marking, present
pseudo code, explain its configuration, and discuss its behaviour.
We use object-oriented notation for most variables.
3.1.1. Behaviour of SR-Metering and ET-Marking
We propose an ET-marker based on a token bucket with tail marking and
marking frequency reduction (see Appendix A for explanation of
different options). The TB has a bucket of size TB.size which is
continuously filled with tokens at rate TB.rate. When a PCN packet
arrives, it is re-marked with "ET" if the fill state of the bucket
(TB.fill) in tokens is smaller than its size (packet.size) in bytes
and "s" additional tokens are added to the bucket; otherwise, the
fill state is reduced by packet.size tokens. The slowdown parameter
Babiarz, et al. Expires May 22, 2008 [Page 15]
Internet-Draft Three State PCN Marking November 2007
"s" reduces the marking frequency of the algorithm.
3.1.2. Pseudo Code for the ET-Marker
The behaviour of the token bucket with tail marking and marking
frequency reduction for SR-metering and ET-marking is expressed by
the following pseudo code. It requires the time variable
TB.lastUpdate indicating when the fill state of TB was last updated
and a global variable "now" providing the current time. A PCN packet
has the variables packet.mark showing its marking (NP, AS, ET) and
packet.size showing its size.
Input: pcn packet
TB.fill = min(TB.size, TB.fill + TB.rate * (now - TB.lastUpdate));
TB.lastUpdate = now;
if (TB.fill < packet.size)
packet.mark = ET;
TB.fill = min(TB.size, TB.fill + s);
else
TB.fill = TB.fill - packet.size;
endif
Output: void
Several enhancements of this algorithm are presented in
Appendix A.1.5. It marks packet independent of its size and applies
MFR proportionally to the packet size. Early results show that this
equalizes the termination probability for flows with different packet
sizes and makes the time to remove the overload independent of packet
sizes. In addition, MFR is also applied when packets are already ET-
marked by previous nodes. This reduces the potential overtermination
in case of multiple bottleneck links. These enhancements are simple,
but still make the algorithm slightly more complex. Therefore, more
performance results and discussions are needed to decide whether
these enhancements should be standard marking behaviour or not
[I-D.babiarz-pcn-explicit-marking], [I-D.menth-pcn-performance].
3.1.3. Configuration of the ET-Marker
The following parameters must be configured:
o TB.rate: supportable rate (SR)
o TB.size: supportable burst size (SBS), needs to be set
appropriately
Babiarz, et al. Expires May 22, 2008 [Page 16]
Internet-Draft Three State PCN Marking November 2007
o Slowdown parameter "s": needs to be set appropriately
3.1.4. Characteristics of the Proposed ET-Marker
The proposed algorithm can be applied with and without marking
frequency reduction (MFR), i.e., s>0 and s=0, respectively.
a) No marking frequency reduction (noMFR, s=0)
If the slowdown parameter is set to s=0, MFR is switched off. As an
alternative, a simplified version of the given algorithm can be used.
If the PCN traffic rate on a link constantly exceeds its SR, the fill
state of the TB decreases. Arriving packets for which the number of
tokens in the bucket does not suffice are ET-marked. The size of the
token bucket (supportable burst size (SBS)) controls how fast the
marker reacts to a traffic rate above SR: if it is set to a low
value, packets are already marked at a rate lower than SR in the
presence of bursts, if it set to a high value, marking starts delayed
if the PCN traffic rate exceeds SR. A nice property of this option
is that the rate of the ET-marked packets is exactly the rate of the
traffic that exceeds SR (excess traffic rate) under the assumption
that there was no packet loss. This observation can be used for
"measured rate termination" (MRT): the rate of ET-marked traffic is
measured per ingress-egress aggregate by the PCN egress node and
signalled to the corresponding flow termination entity.
Measured rate termination (MRT) is also an option to realize flow
termination in 3sm, but the preferred option for 3sm is marked flow
termination (MFT). The drawback of "no MFR" arises in conjunction
with MFT. Then too many packets are ET-marked and too many flows are
terminated. That is the motivation to reduce the marking frequency
by setting s>0.
b) Marking frequency reduction (MFR, s>0)
If the slowdown parameter is set to a value s>0, MFR is achieved
because for each marked packet up to additional "s" bytes that exceed
SR can pass the ET-marker without being re-marked to ET. Thus,
increasing the slowdown parameter "s" decreases the number of ET-
marked packets in a short time period. In combination with MFT, a
suitable "s" is required to achieve a fast termination of
sufficiently many flows without terminating more flows than
necessary.
3.2. AS-Marker
We explain the behaviour for AR-metering and AS-marking, present
pseudo code, explain its configuration, and discuss its behaviour.
Babiarz, et al. Expires May 22, 2008 [Page 17]
Internet-Draft Three State PCN Marking November 2007
3.2.1. Behaviour of AR-Metering and AS-Marking
We propose an AS-marker based on a token bucket with threshold
marking (see Appendix A for explanation of different options). The
TB has a bucket of size TB.size which is continuously filled with
tokens at rate TB.rate. The AR-meter and AS-marker consider only
packets that are not ET-marked. When a non-ET-marked PCN packet
arrives, it is re-marked to "AS" if the fill state of the bucket
(TB.fill) in tokens is smaller than its size (packet.size) in bytes;
otherwise, the fillstate is reduced by packet.size tokens and if the
fill state is then smaller than the marking threshold (TB.threshold),
the packet is also re-marked to "AS" while if the fill state is then
larger than or equal to the marking threshold, the packet is not re-
marked.
The AS-marker is sensitive to ET-markings in the sense that only non-
ET-marked packets are considered for remarking.
3.2.2. Pseudo Code for AS-Marker
The behaviour of the token bucket with threshold marking for AR-
metering and AS-marking is expressed by the following pseudo code
using the same nomenclature like above.
Input: pcn packet
TB.fill = min(TB.size, TB.fill+TB.rate*(now-TB.lastUpdate));
TB.lastUpdate = now
if (packet.mark <> ET) //mark only non-ET-marked packets
if (TB.fill < TB.threshold)
packet.mark = AS;
endif
TB.fill = max(0, TB.fill - packet.size);
endif
Output: void
3.2.3. Configuration of the AS-Marker
The following parameters must be configured:
o TB.rate: admissible rate (AR)
o TB.size (TBS): admissible burst size (ABS) needs to be set
appropriately
o TB.threshold: needs to be set appropriately
Babiarz, et al. Expires May 22, 2008 [Page 18]
Internet-Draft Three State PCN Marking November 2007
3.2.4. Characteristics of the Proposed AS-Marker
If the AR is exceeded, the TB fill state continuously decreases, it
eventually falls below its marking threshold TB.threshold, and it
only increases again if the PCN traffic rate on the link falls below
AR. As a consequence, all packets are AS-marked during that time and
admission of further flows is stopped until the PCN traffic rate
drops below AR. In particular, all probe packets are AS-marked.
[TR437] investigates the impact of the TB parameters on the marking
characteristics, i.e. the percentage of marked packets depending on
the PCN traffic rate relative to AR. If the PCN traffic rate is
above AR, all packets must be marked with AS. To that end,
TB.threshold must be set large enough. If the PCN traffic rate is
below AR, no packets should be marked. To that end TB.size-
TB.threshold must be set large enough. Then, we get marking with
clear decisions, i.e. packets are marked if the PCN rate is above AR
and they are not marked if the PCN rate is below AR. This type of
marking is required for 3sm. [I-D.menth-pcn-performance] provides a
summary of [TR437].
3.3. Marking Codepoints
PCN metering and marking requires classification of traffic which is
subject to PCN metering and PCN marking (PCN-capable). Furthermore,
PCN-aware flows that are subject to PCN-marking require at least the
following codepoints:
o "no-precongestion" (NP),
o "admission-stop" (AS), and
o "excess-traffic" (ET).
These signals may be encoded by re-using the two-bit ECN field or by
different DS codepoints. The actual encoding is out of the scope of
this document.
4. Benefits and Shortcomings of the 3sm Proposal
This section highlights some benefits of the 3sm proposal that we
think are important. Some of them are based on performance results
reported in [SIM-07], [I-D.babiarz-pcn-explicit-marking],
[I-D.menth-pcn-performance], and [TR437].
Babiarz, et al. Expires May 22, 2008 [Page 19]
Internet-Draft Three State PCN Marking November 2007
4.1. Benefits
o 3sm does not require the standardization of the exact algorithm in
the PCN interior node but only the standardization of the
behavior.
o 3sm does not require periodic transmission of measurement results
from PCN egress to PCN ingress.
o The supportable rate of a link can be chosen independently of the
admissible rate as long as it is not smaller. This is maximum
freedom and does not imply any degradation in resource efficiency
for resilient admission control [PCN-Config].
o 3sm works well with multipath routing due to marked flow
termination and the application of probing when needed.
* A flow is terminated only if it is carried over an SR-
overloaded path and if one of its packets was ET-marked.
Therefore, its termination reduces the SR-overload on a
bottleneck link.
* Conversely, flows that are not carried over a bottleneck link
cannot be ET-marked and, therefore, not terminated.
o Marked flow termination is very robust
* The slowdown factor "s" can be reasonably chosen such that the
time to remove the overload is short and that not more traffic
than necessary is terminated.
* It works well with low and high packet loss. Packet loss just
increases the time to remove the overload.
* It works well with a small and large number of flows. In
particular, the right number of flows is terminated if there is
only one flow per aggregate and an SR-overload of, e.g., 30%.
* It works well with constant bit rate (CBR) voice, on/off voice,
and variable bit rate (VBR) traffic. It is not very sensitive
to different traffic characteristics [SIM-07].
* It works well with multiple bottleneck links in the path of a
flow.
* It works well with flows that have significantly different
round-trip times (RTT) or flow termination delays. In
particular, flows with different RTTs suffer the same flow
Babiarz, et al. Expires May 22, 2008 [Page 20]
Internet-Draft Three State PCN Marking November 2007
termination probability.
* In case of terminating bidirectional flows, the termination of
a flow entails the termination of the downstream and upstream
flow. In case of overload on both the downstream and upstream
path, flows are terminated on both path. This leads to
increased termination aggressiveness. However, marked flow
termination leads only to little overtermination as it
terminates traffic only gradually.
* Different slowdown factors "s" may be used for the
configuration of marking frequency reduction on different links
within a single PCN domain.
* It leads to higher termination probabilities for flows with
larger packets. This can be repaired by packet size
independent marking (PSIM, in Appendix A.1.5)
4.2. Shortcomings of 3sm
o Marked flow termination leads to higher termination probabilities
for flows with larger packet frequency (higher rate flows).
Currently, there is no mechanism to improve this.
5. Security Considerations
The Three State PCN Marker has no known security concerns.
6. Changes from Previous Revision
Changes in version -01 compared to version -00:
* Abstract: adapted: more general, better summary
* shortened introduction and adapted it to new document structure
* put "1.3 Terminology" into separate section, clarification and some
minor changes
* put "1.2 Overview of PCN" into a separate section on 3sm edge
behaviour
* added more structure and content to that section
o deployment scenarios for admission control
Babiarz, et al. Expires May 22, 2008 [Page 21]
Internet-Draft Three State PCN Marking November 2007
o added measured rate termination (MRT) as a non-preferred option to
marked flow termination (MFT) in 3sm
* introduced AS-meter as abbreviation for AR-metering and AS-marking
function
* introduced ET-meter as abbreviation for SR-metering and ET-marking
function
* removed comment about similarity of 3sm marking and srTCM (RFC2697)
* current 3.1 did some reformulation and added some new simulation
insights, moved optimizations into Appendix A.1.5
* current 3.2 did some reformulation and added some new simulation
insights, changed the AS-marker according to
o Joe Babiarz's comment saying all packets need to be considered for
AR-metering
o Bob Brisco's comment saying TB.fill should be set to zero if it is
smaller than packet.size
o provided insights for the setting of TB parameters to obtain
desired marking behaviour
* new section on benefits of the 3sm proposal added
* A.1 - A.1.4 minor changes (rewording)
* A.1.5 new section on optimization for 3sm marker (PSIM, PMFR, MFR
for already marked packets)
* A.1.6 simplified threshold marking according to Bob's comments
* old A.6 Section on Related Work (srTCM) removed as srTCM without
change cannot be reused for implementation of threshold marking
* removed Appendix B and integrated the comments into the previous
sections of the document if necessary
7. Acknowledgements
The authors would like to thank the following people for reviewing
this draft or earlier versions thereof and for their suggestions to
make this document more complete: Dave McDysan, Nicolas Chevrollier,
Frank Lehrieder, Bob Brisco, and Ben Strulo.
Babiarz, et al. Expires May 22, 2008 [Page 22]
Internet-Draft Three State PCN Marking November 2007
8. Informative References
[I-D.babiarz-pcn-explicit-marking]
Liu, X. and J. Babiarz, "Simulations Results for 3sM",
draft-babiarz-pcn-explicit-marking-01 (work in progress),
July 2007.
[I-D.ietf-pcn-architecture]
Eardley, P., "Pre-Congestion Notification Architecture",
draft-ietf-pcn-architecture-01 (work in progress),
October 2007.
[I-D.menth-pcn-performance]
Menth, M. and F. Lehrieder, "Performance Evaluation of
PCN-Based Algorithms", draft-menth-pcn-performance-00
(work in progress), November 2007.
[Maglaris-88]
Maglaris et al, "Performance Models of Statistical
Multiplexing in Packet Video Communications, IEEE
Transactions on Communications 36, pp. 834-844", July
1988.
[PCN-Config]
Menth, M. and M. Hartmann, "PCN-Based Resilient Network
Admission Control: The Impact of a Single Bit", (http://
www3.informatik.uni-wuerzburg.de/staff/menth/Publications/
Menth07-PCN-Config.pdf)", 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
Babiarz, et al. Expires May 22, 2008 [Page 23]
Internet-Draft Three State PCN Marking November 2007
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594,
August 2006.
[SIM-07] Liu, X-G. and J. Babiarz, "Simulation Results for Explicit
PCN Marking and Flow Termination
(http://standards.nortel.com/pcn/Simulation_EPCN.pdf)",
February 2007.
[TR437] Menth, M. and F. Lehrieder, "Comparison of Marking
Algorithms for PCN-Based Admission Control, Technical
Report No. 437, (http:// www-
info3.informatik.uni-wuerzburg.de/TR/tr437.pdf)",
October 2007.
Appendix A. Overview of Token Bucket (TB) and Virtual Queue (VQ)
Token buckets (TB) and virtual queues (VQ) are equivalent base
mechanisms for algorithms to control whether a packet is conform to
its flow's indicated rate R and burst size S. Therefore, TB
parameters are frequently used as traffic descriptors. TBs and VQs
are dual approaches: while packets are TB-conform as long as
sufficient tokens are in the bucket at their arrival times, they are
VQ-conform as long as sufficient free space is available in the queue
at their arrival times. Therefore, TBs and VQs can be used
interchangeably and, in particular, algorithms given based on a TB
description can be implemented by a VQ and vice-versa.
In the following, we explain the basic VQ and TB mechanisms
(Appendix A.1.1 and Appendix A.1.2). Packets are marked depending on
the state of the VQ or TB at their arrival time. There are different
marking options. Only those packets that are not conform to its flow
description may be marked (tail marking, Appendix A.1.3), or only
some non-conforming packets may be marked (tail marking with marking
frequency reduction, Appendix A.1.4), or all packets may be marked
until the flow again reaches conformity (threshold marking,
Appendix A.1.6).
A.1. New features for marking algorithm
A.1.1. Virtual Queue (VQ)
We use an object-oriented notation for a more intuitive readability
of the algorithms. The VQ has a VQ rate (VQ.rate) and a queue which
is capable to store up to VQ.size bytes. The current length of the
queue is denoted by VQ.length. This length is reduced over time at
rate VQ.rate. When a packet arrives, it is "accepted" by the VQ and
Babiarz, et al. Expires May 22, 2008 [Page 24]
Internet-Draft Three State PCN Marking November 2007
increments VQ.length by its size (packet.size) if there is still
enough free space in the queue to accommodate it; otherwise it is
"rejected". As the queue size is decreased continuously over time,
the behaviour of a VQ is best described by a fluid model. However,
the state of the VQ shortly after packet arrivals can be calculated
based on the current time "now" and the length of the VQ at the last
update time of the VQ (VQ.lastUpdate) using the following algorithm:
VQ.length = max(0, VQ.length - (now - VQ.lastUpdate) * VQ.rate);
VQ.lastUpdate = now;
if (VQ.length + packet.size <= VQ.size)
VQ.length = VQ.length + packet.size;
endif
A.1.2. Token Bucket (TB)
The TB is basically the same mechanism, but it looks at the problem
from a different angle. The TB has a rate (TB.rate) and a bucket
which is capable to store up to TB.size tokens. A token is the
permission to send one byte. The current fill state of the bucket is
denoted by TB.fill. This fill state is increased over time at rate
TB.rate. When a packet arrives, it is "accepted" and decrements
TB.fill by its size (packet.size) if there are enough tokens in the
bucket to send the entire packet; otherwise it is "rejected". As the
fill state is increased continuously over time, the behaviour of a TB
is best described by a fluid model. However, the state of the TB
shortly after packet arrival can be calculated based on the current
time "now" and the fill state of the TB at the last update time of
the TB (TB.lastUpdate) using the following algorithm:
TB.fill = min(TB.size, TB.fill + (now - TB.lastUpdate) * TB.rate);
TB.lastUpdate = now;
if (TB.fill >= packet.size)
TB.fill = TB.fill - packet.size;
endif
A.1.3. Tail Marking
To control whether packets of a stream with rate R and maximum burst
size MBS are conform to the description R and MBS, the stream is
metered either by a VQ with VQ.rate=R and VQ.size=MBS, or by a TB
with TB.rate=R and TB.size=MBS. If a packet is accepted by the VQ or
by the TB, it is marked in-profile. If it is rejected, it is marked
out-of-profile.
The corresponding pseudo codes are for the VQ:
Babiarz, et al. Expires May 22, 2008 [Page 25]
Internet-Draft Three State PCN Marking November 2007
VQ.length = max(0, VQ.length - (now - VQ.lastUpdate) * VQ.rate);
VQ.lastUpdate = now;
if (VQ.length + packet.size <= VQ.size)
VQ.length = VQ.length + packet.size;
packet.mark = in-profile;
else
packet.mark = out-of-profile;
endif
and for the TB:
TB.fill = min(TB.size, TB.fill + (now - TB.lastUpdate) * TB.rate);
TB.lastUpdate = now;
if (TB.fill >= packet.size)
TB.fill = TB.fill - packet.size;
packet.mark = in-profile;
else
packet.mark = out-of-profile;
endif
A.1.4. Tail Marking with Marking Frequency Reduction (MFR)
The objective of tail marking with MFR is to mark only some of the
packets that are out-of-profile. The strength of the reduction can
be controlled by the slowdown parameter "s". When a packet is
classified out-of-profile, the VQ length is decremented by "s" bytes
and the TB fill state is incremented by "s" tokens, respectively. As
a consequence, the VQ and the TB are not likely to mark consecutive
packets as out-of-profile which reduces their marking frequency.
The corresponding pseudo codes are for the VQ:
VQ.length = max(0, VQ.length - (now - VQ.lastUpdate) * VQ.rate);
VQ.lastUpdate = now;
if (VQ.length + packet.size <= VQ.size)
VQ.length = VQ.length + packet.size;
packet.mark = in-profile;
else
VQ.length = max(0, VQ.length-s); //marking frequency reduction
packet.mark = out-of-profile;
endif
and for the TB:
Babiarz, et al. Expires May 22, 2008 [Page 26]
Internet-Draft Three State PCN Marking November 2007
TB.fill = min(TB.size, TB.fill + (now - TB.lastUpdate) * TB.rate);
TB.lastUpdate = now;
if (TB.fill >= packet.size)
TB.fill = TB.fill - packet.size;
packet.mark = in-profile;
else
TB.fill = min(TB.size, TB.fill+s) //marking frequency reduction
packet.mark = out-of-profile;
endif
If the slowdown parameter is set to s=0, the marking algorithm
behaves like pure tail marking.
A.1.5. Tail Marking with Packet Size Independent Marking (PSIM) and
Proportional Marking Frequency Reduction (PMFR)
For the sake of fairness, large packets should not have a larger
packet marking probability; otherwise this creates incentives to send
many small packets instead of a few large packets. Therefore, we
propose to test a packet arrival whether an MTU can still be
supported. Then, the marking probability depends only on VQ.length
or TB.fill, respectively.
For the sake of better control of the termination aggressiveness,
more flows should be marked and terminated in the presence of low bit
rate flows than in the presence of high bit rate flows. To that end,
we propose to remove (VQ) or add (TB) the slowdown factor
proportionally to the packet size.
The reason for adding "s" tokens to the bucket when a packet is
marked is the anticipation of the termination of that flow. This is
done to approximate the fill state with this flow already being
terminated in order to avoid that too many additional flows are
marked. The same condition is met when an already ET-marked packet
arrives at the ET-marker. Therefore, the same slowdown factor "s" is
added to the bucket of the ET-marker as if it had ET-marked the
packet itself. This is done to avoid that more traffic than
necessary is terminated in case that a traffic aggregate crosses
several bottleneck links. However, this situation is rather unlikely
and the effect is well visible only under pathologic conditions.
Therefore, optimal behaviour is not crucial and the algorithm may be
simplified by ignoring packets that are already ET-marked.
These are obvious enhancements of the base algorithm, but they are
only recommended when solid performance results indicate that the
improvements have a significant impact in practice. These studies
are still ongoing.
Babiarz, et al. Expires May 22, 2008 [Page 27]
Internet-Draft Three State PCN Marking November 2007
The following pseudo codes incorporate all proposed enhancements. We
give them for a VQ approach:
VQ.length = max(0, VQ.length - (now - VQ.lastUpdate) * VQ.rate);
VQ.lastUpdate = now;
if (packet.mark<>ET)
if (VQ.length + MTU <= VQ.size) // PSIM
VQ.length = VQ.length + packet.size;
else
VQ.length = max(0, VQ.length-s*paket.size/MTU); // PMFR
packet.mark = ET;
endif
else
VQ.length = max(0, VQ.length-s*paket.size/MTU); // PMFR
endif
and for the TB:
TB.fill = min(TB.size, TB.fill + (now - TB.lastUpdate) * TB.rate);
TB.lastUpdate = now;
If (packet.mark<>ET)
if (TB.fill >= MTU) // PSIM
TB.fill = TB.fill - packet.size;
else
TB.fill = min(TB.size, TB.fill+s*packet.size/MTU) // PMFR
packet.mark = ET;
endif
else
TB.fill = min(TB.size, TB.fill + s*packet.size/MTU); // PMFR
endif
A.1.6. Threshold Marking
The objective of threshold marking is to mark all packets with, e.g.,
"rate-exceeded" as long as some packets are out-of-profile with
respect to flow parameters R and MBS. We achieve that by setting the
VQ or TB size larger than MBS. Packets are marked if the VQ length
exceeds MBS or if the fill state of the TB falls below TB.size-MBS.
Furthermore, the packet size is always added to the queue or removed
from the bucket. Note that marking thresholds need to be configured
differently for VQ and TB to obtain the same behaviour:
o VQ.threshold = MBS;
o TB.threshold = TB.size - MBS.
The corresponding pseudo codes are for the VQ:
Babiarz, et al. Expires May 22, 2008 [Page 28]
Internet-Draft Three State PCN Marking November 2007
VQ.length = max(0, VQ.length - (now - VQ.lastUpdate) * VQ.rate);
VQ.lastUpdate = now;
if (VQ.length > VQ.threshold)
packet.mark = "rate-exceeded"; // packet out-of-profile
endif
VQ.length = min(VQ.size, VQ.length + packet.size);
and for the TB:
TB.fill = min(TB.size, TB.fill + (now - TB.lastUpdate) * TB.rate);
TB.lastUpdate = now;
TB.fill = TB.fill - packet.size;
if (TB.fill < TB.threshold)
packet.mark = "rate-exceeded"; // packet out-of-profile
endif
TB.fill = max(0, TB.fill - packet.size);
Authors' Addresses
Jozef Z. Babiarz
Nortel
3500 Carling Avenue
Ottawa, Ont. K2H 8E9
Canada
Phone: +1-613-763-6098
Email: babiarz@nortel.com
Xiao-Gao Liu
Nortel
3500 Carling Avenue
Ottawa, Ont. K2H 8E9
Canada
Phone: +1-613-763-7516
Email: xgliu@nortel.com
Babiarz, et al. Expires May 22, 2008 [Page 29]
Internet-Draft Three State PCN Marking November 2007
Kwok Ho Chan
Nortel
600 Technology Park Drive
Billerica, MA 01821
USA
Phone: +1-978-288-8175
Email: khchan@nortel.com
Dr. Michael Menth
University of Wuerzburg
Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Room B206
Germany
Phone: (+49)-931/888-6644
Email: menth@informatik.uni-wuerzburg.de
Babiarz, et al. Expires May 22, 2008 [Page 30]
Internet-Draft Three State PCN Marking November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Babiarz, et al. Expires May 22, 2008 [Page 31]
Html markup produced by rfcmarkup 1.126, available from
https://tools.ietf.org/tools/rfcmarkup/