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

[Bob Briscoe <[e-mail]>]

Michael,

I agree that we should use the term PCN to mean 
the notification part, not the whole traffic 
control system built around it. We had this 
discussion when publishing the architecture.

* CORRECT: what Phil did in the Intro to the architecture.
"The objective of Pre-Congestion Notification (PCN) is to protect the
    quality of service (QoS) of inelastic flows within a Diffserv domain
    in a simple, scalable, and robust fashion.
"
(paraphrasing: the *objective* of notification is to protect QoS)

* INCORRECT: The first sentence of Toby's abstract says:
"Pre-Congestion Notification (PCN) is a metering and marking scheme that
     protects the quality of service (QoS) of 
inelastic flows within a Diffserv
     domain."
(paraphrasing: notification *is* a scheme that protects QoS)

Suggestion to fix the first 
sentence:"Pre-Congestion Notification (PCN) is a 
scheme for metering and marking     packets that 
can be used to protect the quality of service 
(QoS) of inelastic flows within a Diffserv domain."



Bob

At 16:12 26/08/2009, Michael Menth wrote:
>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