[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05
Toby, Bob
if the abstract is to mention PCN functionalities not defined within
this document in a rather simplified way, would the purpose of PCN
be to enable a Diffserv domain to support measurement based
admission control as defined by PCN architecture?
Regards,
Ruediger
-----Original Message-----
From: pcn-bounces at ietf.org [mailto:pcn-bounces at ietf.org] On Behalf Of Bob Briscoe
Sent: Tuesday, August 25, 2009 8:42 PM
To: toby.moncaster at bt.com; pcn at ietf.org
Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05
Toby,
I think this isn't just good for a casual reader, but it is actually
still correct and doesn't require defining PC-domain (which is just
the Diffserv domain once the described measures - the PDB - have been
put in place).
Bob
At 15:53 25/08/2009, 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