Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05

[<[e-mail]>]

I think my understanding was that, although strictly PCN is just a metering and marking algorithm, the PCN architecture puts it into a context where the new capability it provides is measurement-based admission control and flow termination. My thought is, for the purposes of understanding the context that the baseline encoding is written in, this is an important aspect.

However this does perhaps need some more thought since at one point we were talking about the encoding being the base for the whole system and being able to be applied in other contexts. Having said that, this is the output of one working group and is intended to be the enabler for one architecture. If people seek to use it in other contexts they will probably need to provide a different architecture that specifies how to use it in those contexts.

Ultimately the abstract only needs to set the scene and summarise the solution in a brief fashion that allows people to quickly parse the important information. To my mind the important information for this scheme is: it can encode two states, it is intended for use in PCN, specifically in the context of the PCN architecture, and it re-uses the ECN bits in the IP header. I believe the scene is set by explaining that the motivation behind PCN was to provide a mechanism to protect the QoS of inelastic flows through the use of MBAC and FT...

However we are now starting to go in circles and probably should turn to either Steve (as document shepherd) or Lars (as shepherding AD) for a decision on this!

Toby

> -----Original Message-----
> From: Michael Menth [mailto:[e-mail]]
> Sent: 26 August 2009 16:13
> To: [e-mail]
> Cc: Moncaster,T,Toby,DER3 R; [e-mail]; [e-mail]
> Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-
> baseline-encoding-05
> 
> Hi Ruediger, Toby,
> 
> [e-mail] schrieb:
> > Toby,
> >
> > you simply ommited some "PCN" in your new version. I think the
> > problem addressed by Spencer may be that you try to sum up
> > RFC5559 rather then refer to it.
> >
> > Below there's an abstract proposal, structured top-down:
> > - What's PCN: a copy of the abstract of RFC5559.
> > - What's the functionality relevant for this document: marking
> > - What's specified by this document: baseline encoding
> >
> > My try:
> >
> > PCN specifies flow admission and termination based on pre-congestion
> > information in order to protect the quality of service of
> established,
> > inelastic flows within a single Diffserv domain.
> What is PCN? Or is admission control and flow termination also part of
> PCN? My take on this is that PCN is only the marking scheme and the way
> the information is carried to egress nodes. AC and FT is just built on
> top of PCN. And to support QoS is the objective of AC and FT, not
> primarily or only indirectly the objective of the marking scheme.
> 
> Regards,
> 
>     Michael
> 
> > As a part of this
> > specification, the overall rate of the PCN coloured traffic is
> metered
> > on every link in the domain, and these packets are appropriately
> marked
> > when certain configured rates are exceeded.
> > 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.
> >
> >
> >
> > Please maintain the notion of "overall rate of PCN traffic" or
> > "PCN coloured traffic" which is being metered in the version of
> > abstract you go on with.
> >
> > Regards,
> >
> > Ruediger
> >
> >
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]]
> > Sent: Wednesday, August 26, 2009 1:13 PM
> > To: [e-mail]; Geib, Rüdiger
> > Cc: [e-mail]; [e-mail]
> > Subject: 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:[e-mail]]
> >> Sent: 26 August 2009 08:46
> >> To: [e-mail]
> >> Cc: [e-mail]; Moncaster,T,Toby,DER3 R; [e-mail]
> >> 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
> >>
> >> [e-mail] 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: [e-mail] [mailto:[e-mail]] On Behalf
> Of
> >>>
> >> Bob Briscoe
> >>
> >>> Sent: Tuesday, August 25, 2009 8:42 PM
> >>> To: [e-mail]; [e-mail]
> >>> 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, [e-mail] 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: [e-mail] [mailto:[e-mail]] On
> Behalf
> >>>>>
> >> Of
> >>
> >>>>> Lars Eggert
> >>>>> Sent: 25 August 2009 15:12
> >>>>> To: [e-mail]
> >>>>> Subject: [PCN] Fwd: [Gen-art] Gen-ART Review
> >>>>>
> >>>>>
> >>>> ofdraft-ietf-pcn-baseline-
> >>>>
> >>>>
> >>>>> encoding-05
> >>>>>
> >>>>>
> >>>>>
> >>>>> Begin forwarded message:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> From: Spencer Dawkins <[e-mail]>
> >>>>>> Date: August 25, 2009 14:47:49 GMT+02:00
> >>>>>> To: "[e-mail]"
> >>>>>>
> >>>>>>
> >>>> <draft-ietf-
> >>>>
> >>>>
> >>>>> [e-mail]
> >>>>>
> >>>>>
> >>>>>> Cc: General Area Review Team <[e-mail]>,
> >>>>>>
> >>>>>>
> >>>>> "[e-mail]
> >>>>>
> >>>>>
> >>>>>> "   <[e-mail]>
> >>>>>> 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
> >>>>>> [e-mail]
> >>>>>> https://www.ietf.org/mailman/listinfo/gen-art
> >>>>>>
> >>>>>>
> >>>> _______________________________________________
> >>>> PCN mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/pcn
> >>>>
> >>>>
> >>> _______________________________________________
> >>> PCN mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/pcn
> >>> _______________________________________________
> >>> PCN mailing list
> >>> [e-mail]
> >>> 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: [phone] (new), fax: [phone]
> >> mailto:[e-mail]
> >> http://www3.informatik.uni-wuerzburg.de/research/ngn
> >>
> 
> --
> Dr. Michael Menth, Assistant Professor
> University of Wuerzburg, Institute of Computer Science
> Am Hubland, D-97074 Wuerzburg, Germany, room B206
> phone: [phone] (new), fax: [phone]
> mailto:[e-mail]
> http://www3.informatik.uni-wuerzburg.de/research/ngn