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)
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf