[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PCN] Fwd: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline-encoding-05
Spencer,
Thanks for the careful review. Comments in-line.
>> 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.
I agree that we should clarify that.
>> 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.
I'm sorry, but I'm having a hard time following this comment. Could you
please clarify?
>>
>> 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.
Ok
>>
>> 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.
Ok
>>
>> 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.
What is your opinion Lars?
>>
>> admission control for the following service classes:
>>
>> o Telephony (EF)
>>
>> o Real-time interactive (CS4)
>>
>> o Broadcast Video (CS3)
>>
>> o Multimedia Conferencing (AF4)
Regards,
// Steve