Subject: [PCN] Fwd: [Gen-art] Gen-ART Review of draft-ietf-pcn-baseline-encoding-05

From: Lars Eggert <[email-masked]>
Date: Tue, 25 Aug 2009 16:11:44 +0200

Begin forwarded message:

> From: Spencer Dawkins <[email-masked]>
> Date: August 25, 2009 14:47:49 GMT+02:00
> To: "[email-masked]" 	<[email-masked] 
> >
> Cc: General Area Review Team <[email-masked]>,         "[email-masked] 
> " 	<[email-masked]>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: <[email-masked]>
Date: Tue, 25 Aug 2009 10:48:15 -0400

Spencer,

Thanks for the careful review.  Comments in-line.

>> To: "[email-masked]"
>> 	<[email-masked]
>> >

I agree that we should clarify that.

>> wonder what is special about THIS requirement that isn't true of the  

I'm sorry, but I'm having a hard time following this comment.  Could you
please clarify?

>> "replaces" to describe the relationship in both locations.

Ok

>> you might want to use the same wording here.

Ok

>> shepherding AD to see if he agrees.

What is your opinion Lars?

>>   o  Multimedia Conferencing (AF4)

Regards,

// Steve

---

From: <[email-masked]>
Date: Tue, 25 Aug 2009 15:53:51 +0100

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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Lars Eggert
> Sent: 25 August 2009 15:12
> To: [email-masked]
> Subject: [PCN] Fwd: [Gen-art] Gen-ART Review
ofdraft-ietf-pcn-baseline-
> > To: "[email-masked]"
<draft-ietf-
> [email-masked]
> > >
> > reviewer for this draft (for background on Gen-ART, please see
> > posting a new version of the draft.
> >
> > 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
> >
> > 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.
> >
> > 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.
> >
> > point, the domain is substituting one behavior for another. I might
> > suggest "replaces" to describe the relationship in both locations.
> >
> > better than "disables", but if you go for "replaces" previously and
> in
> > section 6, you might want to use the same wording here.
> >
> > 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.
> >

---

From: Tom Taylor <[email-masked]>
Date: Tue, 25 Aug 2009 14:38:13 -0400

How about adding "PCN" in front of "traffic" in: "The overall rate of the 
traffic is metered ...", and in front of each instance of "flow"?

[email-masked] wrote:
> PCN mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pcn
>

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 25 Aug 2009 19:42:26 +0100

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

---

From: <[email-masked]>
Date: Wed, 26 Aug 2009 09:06:08 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf Of Bob Briscoe
Sent: Tuesday, August 25, 2009 8:42 PM
To: [email-masked]; [email-masked]
Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05

Toby,

Bob

---

From: Michael Menth <[email-masked]>
Date: Wed, 26 Aug 2009 09:45:52 +0200

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

[email-masked] schrieb:
>>>> Cc: General Area Review Team <[email-masked]>,
>>>>         
>>> "[email-masked]
>>>       
>>>> "   <[email-masked]>
>>>>   The objective of Pre-Congestion Notification (PCN) is to protect
>>>>         
>>> the
>>>       
>>>>   The overall rate of the PCN-traffic is metered on every link in
>>>>         
>> the
>>     
>>>>   terminate some of the existing flows, thereby protecting the QoS
>>>>         
>> of
>>     
>>>>   domain.  The baseline encoding described here provides for only
>>>>         
>> two
>>     
>>>>      chosen that are already defined for use with admission
>>>>         
>>> controlled
>>>       
>>>> find) that makes reference to the "outermost IP header". I'm not
>>>>         
>> sure
>>     
>>>> Spencer (clarity): here, and in Section 6, the text uses "disables"
>>>>         
>>> to
>>>       
>>>>   behaviours are discussed in [I-D.ietf-pcn-marking-behaviour].
>>>>         
>> This
>>     
>>>>   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
>>>       
>>>>   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
>>>       
>>>>   DSCPs are in increasingly short supply.  Thirdly PCN should be
>>>>         
>> seen
>>     
>>>>   as being essentially a marking behaviour similar to ECN but
>>>>         
>>> intended
>>>       
>>>>   appropriate DSCPs would currently be those for the Real Time
>>>>         
>>> Traffic
>>>       
>>>>   Class [RFC5127].  To be clear the PCN Working Group recommends
>>>>         
>>> using
>>>       

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Wed, 26 Aug 2009 10:54:50 +0200

Hi all

I think that the text provided by Toby on replacing the term PCN domain in
the Abstract
together with the addition proposed by Tom makes sense.

Best regards,
Georgios

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Tom Taylor
> Sent: dinsdag 25 augustus 2009 20:38
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [PCN] Fwd: [Gen-art] Gen-ARTReview 
> ofdraft-ietf-pcn-baseline-encoding-05
> 
> How about adding "PCN" in front of "traffic" in: "The overall 
> rate of the traffic is metered ...", and in front of each 
> instance of "flow"?
> 
> > 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

---

From: <[email-masked]>
Date: Wed, 26 Aug 2009 12:12:55 +0100

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:

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.

> From: Michael Menth [mailto:[email-masked]]
> Sent: 26 August 2009 08:46
> To: [email-masked]
> Cc: [email-masked]; Moncaster,T,Toby,DER3 R; [email-masked]
> Bob Briscoe

---

From: <[email-masked]>
Date: Wed, 26 Aug 2009 12:14:36 +0100

Will add them to the list of changes I already have! I won't release a 
version -06 until the end of the IETF LC in case we get any further 
review comments...

Toby

> From: Bob Briscoe [mailto:[email-masked]]
> Sent: 25 August 2009 19:37
> To: Moncaster,T,Toby,DER3 R
> Cc: Lars Eggert; [email-masked]
> Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review of draft-ietf-pcn-
> baseline-encoding-05
> 
> Toby,
> 
> These all seem sensble requests and straightforward to fix. Are you
> OK with dealing with these?
> 
> 
> 
> Bob
> 
> At 15:11 25/08/2009, Lars Eggert wrote:
> 
> 
> >Begin forwarded message:
> >
> >>To:
> >>"[email-masked]"
> >><[email-masked] >
> >>Cc: General Area Review Team
> >><[email-masked]>,         "[email-masked] "       <[email-masked]>
sure

---

From: <[email-masked]>
Date: Wed, 26 Aug 2009 14:05:53 +0200

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

---

From: <[email-masked]>
Date: Wed, 26 Aug 2009 14:39:22 +0100

OK, as there seems to be more of a consensus that the abstract needs to maintain the idea of PCN traffic being distinct I will try to do a hybrid of your and my abstracts... Incidentally I quite like your approach to how to formulate the abstract...

Pre-Congestion Notification (PCN) is a metering and marking scheme
that protects the quality of service (QoS) of inelastic flows 
within a Diffserv domain. It does so by measuring pre-congestion 
information at the boundaries of the domain and using this 
information to determine whether to admit new flows or (in abnormal
circumstances) terminate some existing flows, thereby protecting 
the QoS of previously admitted flows. This 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.

The only slight concern I have is that the second sentence is getting rather long and unwieldy...

Toby

> From: [email-masked] [mailto:[email-masked]]
> Sent: 26 August 2009 13:06
> Cc: [email-masked]; [email-masked]; [email-masked]
> wuerzburg.de
> Behalf
> > Of
> > >>>>   boundary nodes to make decisions about whether to admit or
> block
> > a
> > >>>> Spencer (minor): this is the only point in the specification
> (that
> > I
> > >>>> can

---

From: Michael Menth <[email-masked]>
Date: Wed, 26 Aug 2009 17:12:33 +0200

Hi Ruediger, Toby,

[email-masked] schrieb:
> 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 
>>> Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-
>>>       
>> baseline-encoding-05
>>     
>>> Toby,
>>>
>>>> abstract was based on our agreed standard elevator-pitch
>>>>         
>> introduction to
>>     
>>>> 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
>>     
>>>>    configured rates are exceeded.  Boundary nodes can measure the
>>>>         
>> level
>>     
>>>>    of marking and thus make decisions about whether to admit or
>>>>         
>> block a
>>     
>>>>    previously admitted flows.  This document specifies how such
>>>>         
>> marks
>>     
>>>>    are encoded into the IP header by re-using the Explicit
>>>>         
>> Congestion
>>     
>>>>    baseline encoding described here provides for only two PCN
>>>>         
>> encoding
>>     
>>>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>>>>           
>> Of
>>     
>>>>> Lars Eggert
>>>>>> considered when this document is edited (either in the working
>>>>>>             
>> group
>>     
>>>>>> or by the RFC Editor).
>>>>>>
>>>>>> Abstract
>>>>>>
>>>>>> especially in an Abstract. I note that RFC 5559 doesn't use the
>>>>>>             
>> term
>>     
>>>>>>   PCN-domain, and PCN-packets are appropriately marked when
>>>>>>             
>> certain
>>     
>>>>>>   boundary nodes to make decisions about whether to admit or block
>>>>>>             
>> a
>>     
>>>>>>   previously admitted flows.  This document specifies how such
>>>>>>             
>> marks
>>     
>>>>>>      DSCPs.  Guidelines for mixing traffic-types within a PCN-
>>>>>>             
>> domain
>>     
>>>>>>      codepoint as PCN-enabled traffic MUST have the ECN field of
>>>>>>             
>> its
>>     
>>>>>> Spencer (minor): this is the only point in the specification (that
>>>>>>             
>> I
>>     
>>>>>> can
>>>>>> whether to suggest s/outermost// here or to ask that a statement
>>>>>>             
>> be
>>     
>>>>>> makes the reader wonder what is special about THIS requirement
>>>>>>             
>> that
>>     
>>>>>> Spencer (clarity): here, and in Section 6, the text uses
>>>>>>             
>> "disables"
>>     
>>>>> to
>>>>>
>>>>>           
>>>>>> point, the domain is substituting one behavior for another. I
>>>>>>             
>> might
>>     
>>>>>>   envisaged as a marking behaviour that could be applied to a
>>>>>>             
>> number
>>     
>>>>>> of
>>>>>>   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
>>>>>>
>>>>>> better than "disables", but if you go for "replaces" previously
>>>>>>             
>> and
>>     
>>>>> in
>>>>>
>>>>>           
>>>>>>   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
>>>>>>   PCN for several reasons.  Firstly the PCN mechanism is
>>>>>>             
>> applicable
>>     
>>>>> to
>>>>>
>>>>>           
>>>>>>   a variety of different traffic classes.  Secondly standards
>>>>>>             
>> track
>>     
>>>>>>   for inelastic traffic.  The choice of which DSCP is most
>>>>>>             
>> suitable
>>     
>>>>>> for
>>>>>> Spencer (clarity): is this 2119 language (apparently not, since
>>>>>>             
>> this
>>

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 26 Aug 2009 16:50:15 +0100

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:
>>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.
>>PCN specifies flow admission and termination 
>>based on pre-congestion information in order to 
>>protect the quality of service of established, 
>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 
>>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
>>
>>
>>
>>From: [email-masked] 
>>[mailto:[email-masked]] Sent: Wednesday, August 26, 2009 1:13 PM
>>Subject: RE: [PCN] Fwd: [Gen-art] Gen-ART 
>>Review ofdraft-ietf-pcn-baseline-encoding-05
>>
>>    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
>>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

---

From: <[email-masked]>
Date: Wed, 26 Aug 2009 16:27:41 +0100

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

> Sent: 26 August 2009 16:13
> Cc: Moncaster,T,Toby,DER3 R; [email-masked]; [email-masked]
> within
> >> current abstract. The objective of PCN is provide marking
> information
> >> to

---

From: Michael Menth <[email-masked]>
Date: Wed, 26 Aug 2009 17:07:58 +0200

Hi Toby,

the text still does not reflect the point that PCN just provides 
information to egress nodes. Based on this PCN information, admission 
control and flow termination is built which support QoS.

Regards,

    Michael

[email-masked] schrieb:
>>> egress node and the objective of admission control and flow
>>>       
>> termination
>>     
>>> is to protect QoS. I use the following short explanation for PCN.
>>>       
>> Maybe
>>     
>>> Pre-congestion notification (PCN) is a metering and marking scheme
>>>       
>> for
>>     
>>> \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
>>     
>>> codepoints within a controlled DiffServ domain.  The baseline
>>>       
>> encoding
>>     
>>>> if the abstract is to mention PCN functionalities not defined
>>>>         
>> within
>>     
>>>> I think this isn't just good for a casual reader, but it is
>>>>         
>> actually
>>     
>>>> the Diffserv domain once the described measures - the PDB - have
>>>>         
>> been
>>     
>>>> put in place).
>>>>
>>>>
>>>> Bob
>>>>
>>>>> This potentially raises an issue for all future PCN documents
>>>>>           
>> since
>>     
>>> the
>>>       
>>>>> PCN... Specifically Spencer raises the question of using the
>>>>>           
>> defined
>>     
>>>>> distinguish the non-PCN and PCN traffic from each other but is
>>>>>           
>> this
>>     
>>>>>    The objective of Pre-Congestion Notification (PCN) is to
>>>>>           
>> protect
>>     
>>> the
>>>       
>>>>>    terminate some of the existing flows, thereby protecting the
>>>>>           
>> QoS
>>     
>>> of
>>>       
>>>>>    Notification (ECN) codepoints within this controlled domain.
>>>>>           
>> The
>>     
>>>>>>> Please wait for direction from your document shepherd or AD
>>>>>>>               
>> before
>>     
>>>>>>>   The objective of Pre-Congestion Notification (PCN) is to
>>>>>>>               
>> protect
>>     
>>>>>> the
>>>>>>
>>>>>>             
>>>>>>> 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
>>>>>
>>>>>           
>>>>>>>   configured rates are exceeded.  The level of marking allows
>>>>>>>               
>> the
>>     
>>>>>>>   terminate some of the existing flows, thereby protecting the
>>>>>>>               
>> QoS
>>     
>>>>> of
>>>>>
>>>>>           
>>>>>>>   Congestion Notification (ECN) codepoints within this
>>>>>>>               
>> controlled
>>     
>>>>>>>   domain.  The baseline encoding described here provides for
>>>>>>>               
>> only
>>     
>>>>> two
>>>>>
>>>>>           
>>>>>>>      Codepoint.  To conserve DSCPs, Diffserv Codepoints SHOULD
>>>>>>>               
>> be
>>     
>>>>>>>   o  Any packet that is not-PCN but which shares the same
>>>>>>>               
>> Diffserv
>>     
>>>>>>> but the current text seems to call attention to this in a way
>>>>>>>               
>> that
>>     
>>>>>>>   Enabling PCN marking behaviour for a specific DSCP disables
>>>>>>>               
>> any
>>     
>>>>>>> other
>>>>>>> describe the relationship between PCN and ECN. If I understand
>>>>>>>               
>> the
>>     
>>>>>>> suggest "replaces" to describe the relationship in both
>>>>>>>               
>> locations.
>>     
>>>>>>> Spencer (clarity): here, the text uses "re-defines", which I
>>>>>>>               
>> like
>>     
>>>>>>>   The PCN Working Group chose not to define a single DSCP for
>>>>>>>               
>> use
>>     
>>>>>> with
>>>>>>
>>>>>>             
>>>>>>> normative text - this seems to cause confusion from time to
>>>>>>>               
>> time.
>>     
>>>>> But
>>>>>
>>>>>

---

From: <[email-masked]>
Date: Thu, 27 Aug 2009 08:51:27 +0200

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:[email-masked]] 
Sent: Wednesday, August 26, 2009 5:50 PM
To: [email-masked]; Geib, Rüdiger
Cc: [email-masked]; [email-masked]
Subject: Re: [PCN] Fwd: [Gen-art] Gen-ART Review ofdraft-ietf-pcn-baseline-encoding-05

Michael,

Bob

---

From: Michael Menth <[email-masked]>
Date: Thu, 27 Aug 2009 09:41:17 +0200

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