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

[Michael Menth <[e-mail]>]

Hi Ruediger,

taking Bob's proposal, I am almost happy. I have a slight improvement 
based on Bob's proposal.

Pre-congestion notification (PCN) is a scheme for metering and marking 
packets within a DiffServ domain and for transporting packet markings to 
egress nodes. This PCN information can be used by feedback-based 
admission control and flow termination to protect the qualtiy of service 
of prioritized, inelastic, realtime flows.

Regards,

    Michael




[e-mail] schrieb:
> 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
>>     

-- 
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