[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PCN] Fwd: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline-encoding-05



Begin forwarded message:


From: Spencer Dawkins <spencer at wonderhamster.org>
Date: August 25, 2009 14:47:49 GMT+02:00
To: "draft-ietf-pcn-baseline-encoding at tools.ietf.org" <draft-ietf-pcn-baseline-encoding at tools.ietf.org > Cc: General Area Review Team <gen-art at ietf.org>, "ietf at ietf.org " <ietf at ietf.org> Subject: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline- encoding-05
I have been selected as the General Area Review Team (Gen-ART) reviewer for 
this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please wait for direction from your document shepherd or AD before posting a 
new version of the draft.

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)

_______________________________________________
Gen-art mailing list
Gen-art at ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Attachment: smime.p7s
Description: S/MIME cryptographic signature