Document: draft-ietf-pcn-baseline-encoding-05
Reviewer: Spencer Dawkins
IETF LC End Date: 2009-09-03
Review Date: 2009-08-21
IESG Telechat date: (not known)

Summary: this specification is almost ready for publication as a Proposed Standard. I have one minor question below (flagged as "Spencer (minor)"), along with some editorial suggestions to be considered when this document is edited (either in the working group or by the RFC Editor).

Abstract

   The objective of Pre-Congestion Notification (PCN) is to protect the
   quality of service (QoS) of inelastic flows within a Diffserv domain.

Spencer (clarity): I'm not sure what the relationship between a Diffserv domain and a PCN-domain is - this couuld be clearer, especially in an Abstract. I note that RFC 5559 doesn't use the term PCN-domain in its Abstract ... I can guess, but I'm just guessing.

   The overall rate of the PCN-traffic is metered on every link in the
   PCN-domain, and PCN-packets are appropriately marked when certain
   configured rates are exceeded.  The level of marking allows the
   boundary nodes to make decisions about whether to admit or block a
   new flow request, and (in abnormal circumstances) whether to
   terminate some of the existing flows, thereby protecting the QoS of
   previously admitted flows.  This document specifies how such marks
   are to be encoded into the IP header by re-using the Explicit
   Congestion Notification (ECN) codepoints within this controlled
   domain.  The baseline encoding described here provides for only two
   PCN encoding states, Not-marked and PCN-marked.

4.  Encoding two PCN States in IP

   The following rules apply to all PCN traffic:

   o  PCN-traffic MUST be marked with a PCN-compatible Diffserv
      Codepoint.  To conserve DSCPs, Diffserv Codepoints SHOULD be
      chosen that are already defined for use with admission controlled
      traffic.  Appendix A.1 gives guidance to implementiors on suitable

Spencer (clarity): s/implementiors/implementers/?

      DSCPs.  Guidelines for mixing traffic-types within a PCN-domain
      are given in [I-D.ietf-pcn-marking-behaviour].

   o  Any packet that is not-PCN but which shares the same Diffserv
      codepoint as PCN-enabled traffic MUST have the ECN field of its
      outermost IP header equal to 00.

Spencer (minor): this is the only point in the specification (that I can
find) that makes reference to the "outermost IP header". I'm not sure whether to suggest s/outermost// here or to ask that a statement be added earlier in the document to clearly state that PCN encoding only protects inelastic traffic when it's used for the outermost IP header, but the current text seems to call attention to this in a way that makes the reader wonder what is special about THIS requirement that isn't true of the other requirements listed.

4.3.  PCN-Compatible Diffserv Codepoints

   Enabling PCN marking behaviour for a specific DSCP disables any other
   marking behaviour (e.g. enabling PCN disables the default ECN marking
   behaviour introduced in [RFC3168]).  All traffic metering and marking

Spencer (clarity): here, and in Section 6, the text uses "disables" to describe the relationship between PCN and ECN. If I understand the point, the domain is substituting one behavior for another. I might suggest "replaces" to describe the relationship in both locations.

   behaviours are discussed in [I-D.ietf-pcn-marking-behaviour].  This
   ensures compliance with the BCP guidance set out in [RFC4774].

4.3.1.  Co-existence of PCN and not-PCN traffic

   The scarcity of pool 1 DSCPs coupled with the fact that PCN is
   envisaged as a marking behaviour that could be applied to a number of
   different DSCPs makes it essential that we provide a not-PCN state.
   As stated above (and expanded in Appendix A.1) the aim is for PCN to
   re-use existing DSCPs.  Because PCN re-defines the meaning of the ECN

Spencer (clarity): here, the text uses "re-defines", which I like better than "disables", but if you go for "replaces" previously and in section 6, you might want to use the same wording here.

   field for such DSCPs it is important to allow an operator to still
   use the DSCP for traffic that isn't PCN-enabled.  This is achieved by
   providing a not-PCN state within the encoding scheme.

A.1.  Choice of Suitable DSCPs

   The PCN Working Group chose not to define a single DSCP for use with
   PCN for several reasons.  Firstly the PCN mechanism is applicable to
   a variety of different traffic classes.  Secondly standards track
   DSCPs are in increasingly short supply.  Thirdly PCN should be seen
   as being essentially a marking behaviour similar to ECN but intended
   for inelastic traffic.  The choice of which DSCP is most suitable for
   a given PCN-domain is dependent on the nature of the traffic entering
   that domain and the link rates of all the links making up that
   domain.  In PCN-domains with uniformly high link rates, the
   appropriate DSCPs would currently be those for the Real Time Traffic
   Class [RFC5127].  To be clear the PCN Working Group recommends using

Spencer (clarity): is this 2119 language (apparently not, since this section is not normative), or are you saying "suggests"? My suggestion is that we not use 2119 language, even lowercased, except for normative text - this seems to cause confusion from time to time. But please check with your shepherding AD to see if he agrees.

   admission control for the following service classes:

   o  Telephony (EF)

   o  Real-time interactive (CS4)

   o  Broadcast Video (CS3)

   o  Multimedia Conferencing (AF4)