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