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

[<[e-mail]>]

Bob, Toby, Michael

Bob's proposal below is allright to me. My only intention is, to explain PCN to the 
casual reader in the first sentence. That also works well the way Bob phrased.

Michael, does Bobs suggestion address your concerns?

Toby, would decomposing the unwieldy long second sentence be an option? 
An example:

It does so by measuring pre-congestion information at the boundaries 
of the domain. This information is used to determine whether to admit 
new flows or (in abnormal circumstances) terminate some existing flows. 
Thereby the QoS of previously admitted flows is protected. 

I think, at least ending the first statement after "the boundaries of 
the domain" is acceptable. But I'm not a native speaker, of course.

Regards,

Ruediger
  

-----Original Message-----
From: Bob Briscoe [mailto:[e-mail]] 
Sent: Wednesday, August 26, 2009 5:50 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

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