[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
Will add them to the list of changes I already have! I won't release a
version -06 until the end of the IETF LC in case we get any further
review comments...
Toby
> -----Original Message-----
> From: Bob Briscoe [mailto:bob at homefarmparham.co.uk]
> Sent: 25 August 2009 19:37
> To: Moncaster,T,Toby,DER3 R
> Cc: Lars Eggert; pcn at ietf.org
> Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review of draft-ietf-pcn-
> baseline-encoding-05
>
> Toby,
>
> These all seem sensble requests and straightforward to fix. Are you
> OK with dealing with these?
>
>
>
> Bob
>
> At 15:11 25/08/2009, Lars Eggert wrote:
>
>
> >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