[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
So would the following sound better? :
Pre-Congestion Notification (PCN) is a metering and marking scheme
that protects 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.
Just for clarity here was the earlier version I proposed:
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.
I personally disagree with Tom's suggestion to add PCN to all the defined
terms (e.g. PCN flow, PCN traffic) - that is fine within the body of the
document but in this abstract we should avoid using any terms that readers
won't be already familiar with.
> -----Original Message-----
> From: Michael Menth [mailto:menth at informatik.uni-wuerzburg.de]
> Sent: 26 August 2009 08:46
> To: Ruediger.Geib at telekom.de
> Cc: bob at homefarmparham.co.uk; Moncaster,T,Toby,DER3 R; pcn at ietf.org
> Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-
> baseline-encoding-05
>
> Hi all,
>
> Rüdiger touches an issue that I also feel is not optimally solved in
> the
> current abstract. The objective of PCN is provide marking information
> to
> egress node and the objective of admission control and flow termination
> is to protect QoS. I use the following short explanation for PCN. Maybe
> this idea could be added to the current abstract.
>
> Pre-congestion notification (PCN) is a metering and marking scheme for
> Differentiated Services (DiffServ) IP networks which provides egress
> nodes with information about load conditions inside the network
> \cite{RFC5559}. This information is used for admission control and flow
> termination to support quality of service (QoS) for admitted inelastic
> realtime flows that are carried with prioritization within the DiffServ
> domain.
> This document specifies how nodes encode the marking information in the
> IP header by re-using the Explicit Congestion Notification (ECN)
> codepoints within a controlled DiffServ domain. The baseline encoding
> described here provides for only two PCN encoding states which are
> not-marked and PCN-marked.
>
> Regards,
>
> Michael
>
> Ruediger.Geib at telekom.de schrieb:
> > 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
> > _______________________________________________
> > PCN mailing list
> > PCN at ietf.org
> > https://www.ietf.org/mailman/listinfo/pcn
> >
>
> --
> Dr. Michael Menth, Assistant Professor
> University of Wuerzburg, Institute of Computer Science
> Am Hubland, D-97074 Wuerzburg, Germany, room B206
> phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632
> mailto:menth at informatik.uni-wuerzburg.de
> http://www3.informatik.uni-wuerzburg.de/research/ngn