| TOC |
|
This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 9, 2009.
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain, in a simple, scalable and robust fashion. This document specifies the two metering and marking behaviours of PCN-nodes. Threshold-metering and -marking marks all PCN-packets if the PCN traffic rate is greater than a configured rate ("PCN-threshold-rate"). Excess-traffic-metering and -marking marks a proportion of PCN-packets, such that the amount marked equals the traffic rate in excess of a configured rate ("PCN-excess-rate"). The level of marking allows PCN-boundary-nodes to make decisions about whether to admit or terminate PCN-flows.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].
1.
Introduction
1.1.
Terminology
2.
Specified PCN-metering and -marking behaviours
2.1.
Behaviour aggregate classification function
2.2.
Dropping function
2.3.
Threshold-meter function
2.4.
Excess-traffic-meter function
2.5.
Marking function
3.
IANA Considerations
4.
Security Considerations
5.
Acknowledgements
6.
Changes (to be removed by RFC Editor)
6.1.
Changes to -03 from -02
6.2.
Changes to -02 from -01
6.3.
Changes to -01 from -00
6.4.
Changes to -00
7.
Informative References
Appendix A.
Example algorithms
A.1.
Threshold-metering and -marking
A.2.
Excess-traffic-metering and -marking
Appendix B.
Implementation notes
B.1.
Competing-non-PCN-traffic
B.2.
Scope
B.3.
Behaviour aggregate classification
B.4.
Dropping
B.5.
Threshold-metering
B.6.
Excess-traffic-metering
B.7.
Marking
§
Author's Address
| TOC |
The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain, in a simple, scalable and robust fashion. Two mechanisms are used: admission control, to decide whether to admit or block a new flow request, and (in abnormal circumstances) flow termination to decide whether to terminate some of the existing flows. To achieve this, the overall rate of PCN traffic is metered on every link in the domain, and PCN packets are appropriately marked when certain configured rates are exceeded. These configured rates are below the rate of the link thus providing notification to boundary nodes about overloads before any congestion occurs (hence "pre-congestion notification"). The level of marking allows boundary nodes to make decisions about whether to admit or terminate.
This document standardises the two metering and marking behaviours of PCN-nodes. Their aim is to enable PCN-nodes to give an "early warning" of potential congestion before there is any significant build-up of PCN-packets in their queues. In summary, their objectives are:
[RFC3168] (Ramakrishnan, K., Floyd, S., and D. Black, “The Addition of Explicit Congestion Notification (ECN) to IP,” September 2001.) defines a broadly RED-like default congestion marking behaviour, but allows alternatives to be defined; this document defines such an alternative.
Section 2 below specifies the functions involved, which in outline (see Figure 1) are:
+---------+ Result
+->|Threshold|-------+
| | Meter | |
| +---------+ V
+----------+ +- - - - -+ | +------+
| BA | | | | | | Marked
Packet =>|Classifier|==>| Dropper |==?===============>|Marker|==> Packet
Stream | | | | | | | Stream
+----------+ +- - - - -+ | +------+
| +---------+ ^
| | Excess | |
+->| Traffic |-------+
| Meter | Result
+---------+
Figure 1: Schematic of functions for PCN-metering and -marking
Appendix A gives an example of algorithms that fulfil the specification of Section 2, and Appendix B provides some explanations of and comments on Section 2. Both the Appendices are informative.
| TOC |
In addition to the terminology defined in [I‑D.ietf‑pcn‑architecture] (Eardley, P., “Pre-Congestion Notification (PCN) Architecture,” April 2009.) and [RFC2474] (Nichols, K., Blake, S., Baker, F., and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,” December 1998.), the following terms are defined:
| TOC |
This section specifies the two PCN-metering and -marking behaviours. The descriptions are functional and are not intended to restrict the implementation. The informative Appendices supplement this section.
| TOC |
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.
A PCN-node MUST classify a packet as a competing-non-PCN-packet if it is not a PCN-packet and it competes with PCN-packets for its forwarding bandwidth on a link.
| TOC |
Note: if the PCN-node's queue overflows then naturally packets are dropped. This section describes additional action.
On all links in the PCN-domain, dropping MAY be done by:
If the PCN-node drops PCN-packets then:
| TOC |
A PCN-node MUST implement a threshold-meter that has behaviour functionally equivalent to the following.
The meter acts like a token bucket, which is sized in bits and has a configured bit rate, termed PCN-threshold-rate. The amount of tokens in the token bucket is termed Ttm. Tokens are added at the PCN-threshold-rate, to a maximum value BStm. Tokens are removed equal to the size in bits of the metered-packet, to a minimum Ttm=0. (Explanation of abbreviations: T is short for Tokens, BS for bucket size, and tm for threshold-meter.)
The token bucket has a configured intermediate depth, termed threshold. If Ttm < threshold, then the meter indicates to the marking function that the packet is to be threshold-marked; otherwise it does not.
| TOC |
A PCN-packet SHOULD NOT be metered (by this excess-traffic-meter function) in the following two cases:
Otherwise the PCN-packet MUST be treated as a metered-packet, that is it is metered by the excess-traffic-meter.
A PCN-node MUST implement an excess-traffic-meter that has behaviour functionally equivalent to the following.
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 Tetm. Tokens are added at the PCN-excess-rate, to a maximum value BSetm. Tokens are removed equal to the size in bits of the metered-packet, to a minimum Tetm=0. If the token bucket is empty (Tetm = 0), then the meter indicates to the marking function that the packet is to be excess-traffic-marked. (Explanation of abbreviations: T is short for Tokens, BS for bucket size, and etm for excess-traffic-meter.)
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 ("packet size independent marking").
Otherwise the meter MUST NOT indicate marking.
| TOC |
A PCN-packet MUST be marked to reflect the metering results by setting its encoding state appropriately, as specified by the specific encoding scheme that applies in the PCN-domain. A consistent choice of encoding scheme MUST be made throughout a PCN-domain.
A PCN-node MUST NOT:
| TOC |
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an RFC.
| TOC |
Security considerations are discussed in detail in [I‑D.ietf‑pcn‑architecture] (Eardley, P., “Pre-Congestion Notification (PCN) Architecture,” April 2009.).
| TOC |
This document is the result of extensive collaboration within the PCN WG. Amongst the most active contributors to the development of the ideas specified in this document have been Jozef Babiarz, Bob Briscoe, Kwok-Ho Chan, Anna Charny, Philip Eardley, Georgios Karagannis, Michael Menth, Toby Moncaster, Daisuke Satoh, and Joy Zhang. Appendix A is based on text from Michael Menth.
This document is a development of [I‑D.briscoe‑tsvwg‑cl‑phb] (Briscoe, B., “Pre-Congestion Notification marking,” October 2006.). Its authors are therefore contributors to this document: Bob Briscoe, Philip Eardley, Dave Songhurst, Francois Le Faucheur, Anna Charny, Vassilis Liatsos, Jozef Babiarz, Kwok-Ho Chan, Stephen Dudley, Georgios Karagiannis, Attila Bader, Lars Westberg.
Thanks to those who've made comments on this draft: Michael Menth, Joe Babiarz, Fred Baker, Bob Briscoe, Ken Carlberg, Anna Charny, Ruediger Geib, Wei Gengyu, Fortune Huang, Christian Hublet, Ingemar Johansson, Georgios Karagiannis, Toby Moncaster, Dimitri Papadimitriou, Daisuke Satoh. Michael Menth, Joe Babiarz, Anna Charny reviewed a preliminary version of the prior individual internet draft.
| TOC |
| TOC |
Updates to take account of last call comments as follows:
| TOC |
Updates as follows:
| TOC |
Updates as follows:
| TOC |
First version of WG draft, derived from draft-eardley-pcn-marking-behaviour-01, with the following changes:
| TOC |
| TOC |
Note: This Appendix is informative, not normative. It is an example of algorithms that implement Section 2 and is based on [I‑D.charny‑pcn‑comparison] (Charny, A., “Comparison of Proposed PCN Approaches,” November 2007.) and [Menth] (, “Menth,” 2008.).
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.
| TOC |
A token bucket with the following parameters:
A PCN-packet has the following parameters:
In addition there are the parameters:
The following steps are performed when a PCN-packet arrives on a link:
| TOC |
A token bucket with the following parameters:
A PCN-packet has the following parameters:
In addition there are the parameters:
The following steps are performed when a PCN-packet arrives on a link:
| TOC |
Note: This Appendix is informative, not normative. It comments on Section 2.
| TOC |
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 [I‑D.ietf‑pcn‑architecture] (Eardley, P., “Pre-Congestion Notification (PCN) Architecture,” April 2009.). But if there is competing-non-PCN-traffic, then there needs to be:
It is left up to the operator to decide on appropriate action. Dropping is discussed further in Section B.4.
One specific example of competing-non-PCN-traffic occurs if the PCN-compatible Diffserv codepoint is one of those that [I‑D.ietf‑tsvwg‑admitted‑realtime‑dscp] (Baker, F., Polk, J., and M. Dolly, “DSCP for Capacity-Admitted Traffic,” March 2010.)) defines as suitable for use with admission control, and there is such non PCN-traffic in the PCN-domain. A similar example could occur for Diffserv codepoints of the Real-Time Treatment Aggregate [RFC5127] (Chan, K., Babiarz, J., and F. Baker, “Aggregation of DiffServ Service Classes,” February 2008.)). In such cases PCN-traffic and competing-non-PCN-traffic are distinguished by different values of the ECN field [I‑D.ietf‑pcn‑baseline‑encoding] (Moncaster, T., Briscoe, B., and M. Menth, “Baseline Encoding and Transport of Pre-Congestion Information,” September 2009.).
Another example would occur if there is more than one PCN-compatible Diffserv codepoint in a PCN-domain. For instance, suppose there are two PCN-BAs treated at different priorities. Then as far as the lower priority PCN-BA is concerned, the higher priority PCN-traffic needs to be treated as competing-non-PCN-traffic.
| TOC |
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.
The meters can be implemented on the ingoing or outgoing interface of a PCN-node. It may be that existing hardware can support only one meter per ingoing interface and one per outgoing interface. Then for instance threshold-metering could be run on all the ingoing interfaces and excess-traffic-metering on all the outgoing interfaces; note that the same choice must be made for all the links in a PCN-domain to ensure that the two metering behaviours are applied exactly once for all the links.
The baseline encoding [I‑D.ietf‑pcn‑baseline‑encoding] (Moncaster, T., Briscoe, B., and M. Menth, “Baseline Encoding and Transport of Pre-Congestion Information,” September 2009.) specifies only two encoding states (PCN-marked and not-marked). In this case, "excess-traffic-marked" means a packet that is PCN-marked as a result of the excess-traffic-meter function, and "threshold-marked" means a packet that is PCN-marked as a result of the threshold-meter function. As far as terminology is concerned, this interpretation is consistent with that defined in [I‑D.ietf‑pcn‑architecture] (Eardley, P., “Pre-Congestion Notification (PCN) Architecture,” April 2009.). Note that a deployment needs to make a consistent choice throughout the PCN-domain whether PCN-marked is interpreted as excess-traffic-marked or threshold-marked.
Note that even if there are only two encoding states, it is still required that both the meters are implemented, in order to ease compatibility between equipment, and to remove a configuration option and associated complexity. Hardware with limited availability of token buckets could be configured to run only one of the meters, but it must be possible to enable either meter. Although in the scenario with two encoding states indications from one of the meters are ignored by the marking function, they may be logged or acted upon in some other way, for example by the management system or an explicit signalling protocol; such considerations are out of scope of this document.
| TOC |
Configuration of PCN-nodes will define what values of the DSCP and ECN fields indicate a PCN-packet in a particular PCN-domain.
Configuration will also define what values of the DSCP and ECN fields indicate a competing-non-PCN-packet in a particular PCN-domain.
| TOC |
The objective of the dropping function is to minimise the queueing delay suffered by metered-traffic at a PCN-node, since PCN-traffic (and perhaps competing-non-PCN-traffic) is expected to be inelastic traffic generated by real time applications. In practice it would be defined as exceeding a specific traffic profile, typically based on a token bucket.
If there is no competing-non-PCN-traffic, then it is not expected that the dropping function is needed, since PCN's flow admission and termination mechanisms limit the amount of PCN-traffic. Even so, it still might be implemented as a back stop against misconfiguration of the PCN-domain, for instance.
If there is competing-non-PCN-traffic, then the details of the dropping function will depend on how the router's implementation handles the two sorts of traffic (the discussion here is based on that in [I‑D.ietf‑tsvwg‑admitted‑realtime‑dscp] (Baker, F., Polk, J., and M. Dolly, “DSCP for Capacity-Admitted Traffic,” March 2010.)):
Note that only dropping of packets is allowed. Downgrading of packets to a lower priority BA is not allowed (see B.7), since it would lead to packet mis-ordering. Shaping ("the process of delaying packets" [RFC2475] (Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, “An Architecture for Differentiated Services,” December 1998.)) is not suitable if the traffic comes 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 dropper should not be needed for the PCN-traffic.
Preferential dropping of excess-traffic-marked packets: Section 2.3 specifies: "If the PCN-node drops PCN-packets then ... PCN-packets that arrive at the PCN-node already excess-traffic-marked SHOULD be preferentially dropped". In brief, the reason is that, with the "controlled load" edge behaviour [I‑D.taylor‑pcn‑cl‑edge‑behaviour] (Charny, A., Huang, F., Menth, M., and T. Taylor, “PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation,” March 2009.) this avoids over-termination in the event of multiple bottlenecks in the PCN-domain [I‑D.charny‑pcn‑comparison] (Charny, A., “Comparison of Proposed PCN Approaches,” November 2007.). A fuller explanation is as follows. The optimal dropping behaviour depends on the particular edge behaviour [Menth] (, “Menth,” 2008.). A single dropping behaviour is defined, as it is simpler to standardise, implement and operate. The standardised dropping behaviour is at least adequate for all edge behaviours (and good for some), whereas others are not (for example with tail dropping far too much traffic may be terminated with the "controlled load" edge behaviour, in the event of multiple bottlenecks in the PCN-domain [I‑D.charny‑pcn‑comparison] (Charny, A., “Comparison of Proposed PCN Approaches,” November 2007.)). The dropping behaviour is defined as a ‘SHOULD’, rather than a ‘MUST’, in recognition that other dropping behaviour may be preferred in particular circumstances, for example: (1) with the "marked flow" termination edge behaviour, preferential dropping of unmarked packets may be better [Menth] (, “Menth,” 2008.); (2) tail dropping may make PCN marking behaviour easier to implement on current routers.
Exactly what "preferentially dropped" means is left to the implementation. It is also left to the implementation what to do if there are no excess-traffic-marked PCN-packets available at a particular instant.
Section 2.2 also specifies: "the PCN-node's excess-traffic-meter SHOULD NOT meter the PCN-packets that it drops." This avoids over-termination [Menth] (, “Menth,” 2008.). Effectively it means that the dropping function (if present) should be done before the meter functions - which is natural.
| TOC |
The description is in terms of a ‘token bucket with threshold’ (which [I‑D.briscoe‑tsvwg‑cl‑architecture] (Briscoe, B., “An edge-to-edge Deployment Model for Pre-Congestion Notification: Admission Control over a DiffServ Region,” October 2006.) views as a virtual queue). However the description is not intended to standardise implementation.
The PCN-threshold-rate is configured at less than the rate allocated to the PCN-traffic class. Also, the PCN-threshold-rate is less than, or possibly equal to, the PCN-excess-rate.
Section 2.3 defines: "If Ttm < threshold, then the meter indicates to the marking function that the packet is to be threshold-marked; otherwise it does not." Note that a PCN-packet is marked without explicit additional bias for the packet's size.
The behaviour must be functionally equivalent to the description in Section 2.3. "Functionally equivalent" means the observable 'black box' behaviour is the same or very similar, for example if either precisely the same set of packets is marked, or if the set is shifted by one packet. It is intended to allow implementation freedom over matters such as:
similarly, when the token bucket is very nearly full and a packet arrives larger than (BStm - Ttm), then the precise change in Ttm is up to the implementation.
| TOC |
The description is in terms of a token bucket, however the implementation is not standardised.
The PCN-excess-rate is configured at less than (or possibly equal to) the rate allocated to the PCN-traffic class. Also, the PCN-excess-rate is greater than, or possibly equal to, the PCN-threshold-rate.
As in Section B.3, "functionally equivalent" allows some implementation flexibility when the token bucket is very nearly empty or very nearly full.
Section 2.4 specifies: "A packet SHOULD NOT be metered (by this excess traffic meter function) ... If the packet is already excess-traffic-marked on arrival at the PCN-node". This avoids over-termination (with some edge behaviours) in the event that the PCN-traffic passes through multiple bottlenecks in the PCN-domain [I‑D.charny‑pcn‑comparison] (Charny, A., “Comparison of Proposed PCN Approaches,” November 2007.). Note that an implementation could determine whether the packet is already excess-traffic-marked as an integral part of its BA classification function. The behaviour is defined as a ‘SHOULD NOT’, rather than a ‘MUST NOT’, because it may be slightly harder to implement than a metering function that is blind to previous packet markings.
Section 2.4 specifies: "A packet SHOULD NOT be metered (by this excess traffic meter function) ... If this PCN-node drops the packet." This avoids over-termination [Menth] (, “Menth,” 2008.). (A similar statement could also be made for the threshold meter function, but is irrelevant, as a link that is overloaded will already be substantially pre-congested and hence threshold-marking all packets.) It seems natural to perform the dropping function before the metering functions, although for some equipment it may be harder to implement; hence the behaviour is defined as a ‘SHOULD NOT’, rather than a ‘MUST NOT’.
Packet size independent marking 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 [I‑D.briscoe‑tsvwg‑byte‑pkt‑mark] (Briscoe, B., “Byte and Packet Congestion Notification,” February 2008.) [Menth] (, “Menth,” 2008.). The behaviour is a ‘SHOULD’, rather than a ‘MUST’, because packet size independent marking may be slightly harder for some equipment to implement, and the impact of not doing it is undesirable but moderate (sufficient traffic is terminated, but flows with large packets are more likely to be terminated).
Note that BSetm is independent of BStm; Tetm is independent of Ttm (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).
| TOC |
Section 2.5 defines: "A PCN-node MUST NOT ...change a PCN-packet into a non PCN-packet". This means that a PCN-node is not allowed to downgrade a PCN-packet into a lower priority Diffserv BA (eg it is not allowed as an alternative to dropping, Section 2.2).
Section 2.5 defines: "A PCN-node MUST NOT ...PCN-mark a packet that is not a PCN-packet". This means that in the scenario where competing-non-PCN-packets are treated as metered-packets, a meter may indicate a packet is to be PCN-marked, but the marking function knows it cannot be marked. It is left open to the implementation exactly what to do in this case; one simple possibility is to mark the next PCN-packet. Note that unless the PCN-packets are a large fraction of all the metered-packets then the PCN mechanisms may not work well.
Although the metering functions are described separately from the marking function, they can be implemented in an integrated fashion.
| TOC |
| Philip Eardley | |
| BT | |
| Adastral Park, Martlesham Heath | |
| Ipswich IP5 3RE | |
| UK | |
| Email: | philip.eardley@bt.com |