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

[<[e-mail]>]

OK, my last 2 suggested versions. PLEASE can we just make a decision now!

Version 1 (13 lines):

Pre-Congestion Notification (PCN) is a scheme for packet metering
and marking that can be used within a Diffserv domain to protect
the quality of service (QoS) of inelastic flows.  It does this 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 protecting the QoS of previously admitted flows. 
The pre-congestion information is provided by marking packets 
when the overall rate of PCN traffic on a link exceeds certain 
configured rates.  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.


Version 2 (11 lines):

Pre-Congestion Notification (PCN) is a scheme for packet metering and 
marking that can help protect the quality of service (QoS) of 
inelastic flows within a Diffserv domain.  Within the domain nodes 
measure the rate of PCN traffic on each link and mark packets if that 
rate exceeds a configured threshold.  This pre-congestion information 
is measured at the boundaries of the domain and is then used to 
determine whether to admit new flows or (in extremis) terminate some 
existing flows.  This protects 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: Bob Briscoe [mailto:[e-mail]]
> Sent: 26 August 2009 17:15
> To: Moncaster,T,Toby,DER3 R
> Subject: Fwd: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-
> baseline-encoding-05
> 
> Toby,
> 
> inline, following up my own post...
> 
> >Date: Wed, 26 Aug 2009 16:50:15 +0100
> >To: [e-mail], [e-mail]
> >From: Bob Briscoe <[e-mail]>
> >Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART
> >Review        ofdraft-ietf-pcn-baseline-encoding-05
> >Cc: [e-mail], [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."
> 
> Just realised that's ambiguous: "scheme that can
> be used" or "packets that can be used"?
> 
> 2nd attempt:
> "Pre-Congestion Notification (PCN) is a scheme
> for packet metering and marking 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