This potentially raises an issue for all future PCN documents since the
abstract was based on our agreed standard elevator-pitch introduction to
PCN... Specifically Spencer raises the question of using the defined
term PCN-domain in the abstract. Any thoughts from anyone as to whether
this is confusing? Would it be clearer to just use "domain" (e.g. drop
the "PCN-"). In which case should I alter the whole abstract as follows
(note: I realise this is strictly incorrect as it now doesn't seek to
distinguish the non-PCN and PCN traffic from each other but is this
clearer for a casual reader?):
The objective of Pre-Congestion Notification (PCN) is to protect the
quality of service (QoS) of inelastic flows within a Diffserv domain.
The overall rate of the traffic is metered on every link in the
domain, and packets are appropriately marked when certain
configured rates are exceeded. Boundary nodes can measure the level
of marking and thus 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 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.
Toby
-----Original Message-----
From: pcn-bounces at ietf.org [mailto:pcn-bounces at ietf.org] On Behalf Of
Lars Eggert
Sent: 25 August 2009 15:12
To: pcn at ietf.org
Subject: [PCN] Fwd: [Gen-art] Gen-ART Review
ofdraft-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
_______________________________________________
PCN mailing list
PCN at ietf.org
https://www.ietf.org/mailman/listinfo/pcn