Signaling 3 PCN states with baseline encoding
draft-geib-baseline-encoding-3state-00

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 March 23, 2009.

Abstract

Layer 2 transport services like MPLS offer only 2 states to encode ECN state, if DiffServ based Class of Service is operated. Still, a mechanism by which PCN egress nodes can differentiate between the normal behaviour state, admission stop state control state and flow termination state, by using PCN marking of packets is desirable. This document describes how threshold and excess marking can be combined with PCN baseline encoding. A minimalistic approach like the one described in the following has some obvious shortcomings. These shortcomings are also presented and discussed. Currently, the aim of this document is to trigger experimentation feasability studies. Standardisation will be pursued in the future based on the results of the studies.

Table of Contents

1.  Introduction
    1.1.  Requirements Language
2.  Terminology
3.  Signaling 3 PCN states with baseline encoding
    3.1.  Three state signaling with PCN baseline encoding
    3.2.  Benefits of three state signaling with PCN baseline encoding
    3.3.  Simple experimental deployment
    3.4.  Known issues of three state signalling with PCN baseline encoding
4.  Acknowledgements
5.  IANA Considerations
6.  Security Considerations
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

DiffServ and MPLS are state of the art technologies operated in many carrier backbones. Following RFC 5129 (Davie, B., Briscoe, B., and J. Tay, “Explicit Congestion Marking in MPLS,” January 2008.) [RFC5129], only PCN baseline encoding (Moncaster, T., Briscoe, B., and M. Menth, “Baseline Encoding and Transport of Pre-Congestion Information,” July 2008.) [pcn‑baseline‑encoding] is applicable within MPLS networks. Still, it may be desirable to differentiate operation of a pre congested PCN domain interface in the admission stop state from operation in the termination state at the egress and do so without any extra signaling but "M/CE" marked PCN packets.

This draft proposes a method to combine threshold and excess marking with PCN baseline encoding. As the PCN egress node must infer the operational state of a domain's pre-congested PCN interface(s) by marking patterns, shortcomings of the proposed method are obvious. They will be discussed briefly in this document. The intent of this draft is to start experimentation rather than standardisation. Any form of standardisation will only be started, if experiments show, that the known drawbacks of the proposed two state marking with PCN baseline encoding can be overcome without introducing complex solutions.

1.1.  Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

2.  Terminology

This draft does not introduce any new functionalities. The terminology in this document follows the one used by the PCN WG at the time of writing, in detail:

• draft-ietf-pcn-architecture-06 (Eardley, P., “Pre-Congestion Notification Architecture,” August 2008.) [pcn‑architecture],
• draft-moncaster-pcn-baseline-encoding-02 (Moncaster, T., Briscoe, B., and M. Menth, “Baseline Encoding and Transport of Pre-Congestion Information,” July 2008.) [pcn‑baseline‑encoding],
• draft-eardley-pcn-marking-behaviour-01 (Eardley, P., “Marking behaviour of PCN-nodes,” June 2008.) [pcn‑marking‑behaviour], and
• draft-menth-pcn-psdm-encoding-00 (Menth, M., Babiarz, J., Moncaster, T., and B. Briscoe, “PCN Encoding for Packet-Specific Dual Marking (PSDM),” July 2008.) [pcn‑psdm‑encoding].

3.  Signaling 3 PCN states with baseline encoding

PCN based admission control functions best with threshold marking. This means, that once PCN traffic is above a links PCN-threshold-rate, all PCN packets passing this link are marked. With baseline encoding, only two codepoints are available to signal a links pre-congestion state. As all PCN traffic is marked with the single available codepoint to indicate any (pre) congestion state, there's little solution space to further differentiate crossing of the PCN-excess-rate by a codepoint or by excess marking (the latter being the more suitable marking behaviour to indicate that a links PCN load reached termination state).

3.1.  Three state signaling with PCN baseline encoding

Admission control is realised by threshold marking of PCN traffic, once the PCN traffic is above a links PCN-treshold-rate. If PSDM (Menth, M., Babiarz, J., Moncaster, T., and B. Briscoe, “PCN Encoding for Packet-Specific Dual Marking (PSDM),” July 2008.) [pcn‑psdm‑encoding] is applied, no PCN egress measurement functionalities need to be supported to operate admission control. Admission control is thus operated as suggested by combining mechanisms already proposed for standardisation.

Assuming that the PCN rate is strictly limited above the PCN-excess-rate by the links physical bandwidth or by a policer and further assuming this PCN rate limit to be, say, no more than 10% above the PCN-excess-rate, then excess marking would result in no more than 10% of the packets above PCN-excess-rate to be marked. If admission control is applied to path coupled signaling packets with a piggybacked probing functionality between PCN boundary nodes (which consists of setting the ECN field of that signaling packet), starting to mark only packets above the PCN-excess-rate as "M/CE" once the latter is passed doesn't result in desirable operational conditions. As only a small percentage of traffic is marked, most PSDM coded admission requests have a good chance to pass the pre-congested link without being marked and lead to admission of new PCN traffic. If however the operational regime of the excess rate marker is "inverted", and the percentage of traffic excessing the PCN-excess-rate is left unmarked (i.e. "NM" coded), then PSDM admission control will prevent admission of 90% or more of the user sessions requesting admission. Please note, that the threshold marker still continues to mark all packets crossing the link and so the excess marker would indeed have to unmark packets again (if marking is realised eg. by sequential single rate token buckets).

The marking behaviour as described in pcn-marking-behaviour (Eardley, P., “Marking behaviour of PCN-nodes,” June 2008.) [pcn‑marking‑behaviour] has to further be changed in the following way to support the functionalities specified by this document.

Two encoding states are available:

• one for "PCN-marked"
• one for "not PCN-marked".

The metering and marking function MUST be implemented to support the following threshold and excess-traffic marking functions:

All PCN packets MUST be counted by the PCN meter.

Threshold marking MUST be executed prior to (or simultaneously with) excess traffic marking.

To threshold mark a packet, its PCN mark is set to "PCN-marked" (M/CE following pcn-baseline-encoding (Moncaster, T., Briscoe, B., and M. Menth, “Baseline Encoding and Transport of Pre-Congestion Information,” July 2008.) [pcn‑baseline‑encoding]).

To excess-traffic mark a packet, its PCN mark is set to "not PCN-marked" (NM/ECT0 following pcn-baseline-encoding (Moncaster, T., Briscoe, B., and M. Menth, “Baseline Encoding and Transport of Pre-Congestion Information,” July 2008.) [pcn‑baseline‑encoding]).

Additionally, this document has outlined already, that two marking behaviours are combined with PCN baseline encoding and this so far isn't part of pcn-marking-behaviour (Eardley, P., “Marking behaviour of PCN-nodes,” June 2008.) [pcn‑marking‑behaviour].

The concept is illustrated by Figure 1.

         Rate of    ^
    PCN-traffic on  |
   bottleneck link  |                             (as below and also)
                    |     (as below)              Drop some PCN-pkts
                    |
    scheduler rate -| -----------------------------------------------
   (for PCN-traffic)|
                    |    Some pkts                Terminate some
                    |  "not PCN-marked"           admitted flows
                    |         &                        &
                    |     Rest of pkts         Block most new flows
                    |    "PCN-marked"
                    |
   PCN-excess-rate -|------------------------------------------------
                    |
                    |      All pkts               Block new flows
                    |    "PCN-marked"
                    |
PCN-threshold-rate -|------------------------------------------------
                    |
                    |      All pkts               Admit new flows
                    |   "not PCN-marked"

Schematic of how PCN's baseline encoding-3state admission control and flow termination mechanisms kick in as the rate of PCN-traffic increases, for a PCN-domain with three encoding states (modified from [architecture]). pcn-architecture (Eardley, P., “Pre-Congestion Notification Architecture,” August 2008.) [pcn‑architecture].

A way to further increase the probability of blocking new flows requesting admission, while a PCN interface reached termination state is to generally "unmark" only a known share of the excess traffic (say 50% or 10% of the packets to be unmarked at the excess rate instead of all of them). This however may make it more difficult for an egress node to correctly determine the termination rate of a small PCN aggregate that has passed a link in termination state.

3.2.  Benefits of three state signaling with PCN baseline encoding

If the behaviour exposed in the case of termination marking allows an egress node to non ambiguously identify termination state for an aggregate, then it can request the sources to terminate (or reduce) their traffic.

As only a single code point is used to signal pre congestion states and two different marking behaviours indicate the pre-congestion status, this solution may be deployed within MPLS networks, where only 8 Codepoints are available to support DiffServ and ECN.

Finally, it should be noted that by support of PSDM no rate measurements are required for admission control and that for termination, the egress node is able to measure traffic rates and take decisions on termination without having to provide feedback to another PCN node within its PCN domain.

3.3.  Simple experimental deployment

Experimental simulation may not require the development of new code for policers if egress and ingress policers can be simulated on both ends of a PCN link. The egress policer of the PCN egress interface operates the threshold policer at the PCN-threshold-rate. The ingress policer of the ingress interface of the PCN node connected by the link is set to meter packets marked as "PCN/CE". Operated in "excess mode", it starts to mark packets as "PCN/NM", once the rate of PCN/CE marked packets crosses the "PCN-excess-rate" which it is configured for. Obviously, the termination threshold MUST be bigger or equal to the admissible rate configured at the other end of the link.

Routers supporting ingress and egress policing could also be used, which would allow experiments with real equipment, if desired.

3.4.  Known issues of three state signalling with PCN baseline encoding

The question, whether it is at all possible to infer the current operational state of one or more pre-congested interface(s) of a PCN domain by interpretation of the marking behaviour observed by the PCN egress nodes can't be answered yet. This section lists a few operational conditions under which the proposed two state marking three state signaling method must work reliably or reasonably stable, respectively.

• Differing oscillating "admission"/"admission stop" state from termination state. This operational condition is likely to be present and the egress node MUST be able to reliably differ admission stop state from termination, if such oscillating "admission"/"admission stop" state is occurring.
• Admission of sessions during termination state. As a certain percentage of packets will pass the pre congested interface unmarked during termination state, a number of new sessions will be admitted while others are terminated. The egress nodes MUST be able to terminate more traffic swiftly to push the PCN traffic rate below the PCN-excess-rate despite admission of new sessions while this link is in termination state.
• If traffic that has passed a PCN interface in termination state later on passes a PCN interface in admission stop state, an end node will no longer be able to recognise the termination state of the prior PCN node, as all packets passing the interface in admission stop state will be "PCN-marked".
• If traffic that has passed a PCN interface in termination state later on passes another PCN interface in termination state, an end node will only recognise the termination state of the last PCN node by the relation of "not PCN-marked" to "PCN-marked" packets as created by the last interface in termination mode.

4.  Acknowledgements

Thanks to Ana Charney, Bob Briscoe and Joe Babiarz for brief discussions on the idea and thanks to Steven Blake for the opportunity to present 3 slides on the idea. Thanks also to Mayutan Arumaithurai of University of Göttingen for a review of this draft.

5.  IANA Considerations

This memo includes no request to IANA.

6.  Security Considerations

The security section of pcn-architecture (Eardley, P., “Pre-Congestion Notification Architecture,” August 2008.) [pcn‑architecture] applies also to this draft. It does not introduce additional security issues.

7.  References

7.1. Normative References

7.2. Informative References

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2008).

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.