[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PCN] Fwd: [Gen-art] Gen-ARTReview ofdraft-ietf-pcn-baseline-encoding-05
Hi all
I think that the text provided by Toby on replacing the term PCN domain in
the Abstract
together with the addition proposed by Tom makes sense.
Best regards,
Georgios
> -----Original Message-----
> From: pcn-bounces at ietf.org [mailto:pcn-bounces at ietf.org] On
> Behalf Of Tom Taylor
> Sent: dinsdag 25 augustus 2009 20:38
> To: toby.moncaster at bt.com
> Cc: pcn at ietf.org
> Subject: Re: [PCN] Fwd: [Gen-art] Gen-ARTReview
> ofdraft-ietf-pcn-baseline-encoding-05
>
> How about adding "PCN" in front of "traffic" in: "The overall
> rate of the traffic is metered ...", and in front of each
> instance of "flow"?
>
> toby.moncaster at bt.com wrote:
> > 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
> >
> _______________________________________________
> PCN mailing list
> PCN at ietf.org
> https://www.ietf.org/mailman/listinfo/pcn
>