Subject: [PCN] FW: New Version Notification for draft-ietf-pcn-baseline-encoding-05

From: <[email-masked]>
Date: Thu, 20 Aug 2009 16:19:23 +0100

I hope this accurately reflects the ML discussions over the past few days? I have also corrected all the nits and hopefully haven't left any spelling mistakes or typos...

Toby

____________________________________________________________________ 
Toby Moncaster, <[email-masked]> Networks Research Centre, BT 
B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 7918 901170 

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: 20 August 2009 16:17
To: Moncaster,T,Toby,DER3 R
Cc: Briscoe,RJ,Bob,DER3 R; [email-masked]
Subject: New Version Notification for draft-ietf-pcn-baseline-encoding-05 

A new version of I-D, draft-ietf-pcn-baseline-encoding-05.txt has been successfuly submitted by T Moncaster and posted to the IETF repository.

Filename:	 draft-ietf-pcn-baseline-encoding
Revision:	 05
Title:		 Baseline Encoding and Transport of Pre-Congestion Information
Creation_date:	 2009-08-20
WG ID:		 pcn
Number_of_pages: 14

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

The IETF Secretariat.

---

From: <[email-masked]>
Date: Thu, 20 Aug 2009 17:37:00 +0100

Few minor comments:

Table 1 has
>EXP(01)*
>Valid* [in IN EXP(01) OUT PM(11) box]
> * This SHOULD cause an alarm to be raised at a higher layer. The
       packet MUST be treated as if it carried the NM codepoint.

I think your comment ["*This SHOULD.."] really only applies to the "EXP(01)*" - ie if the codepoint in is EXP(01) then raise an alarm as this shouldn't happen.

Both the "Valid" boxes in this row could have a comment:
** these transitions MAY be allowed be some future experimental extensions to the baseline encoding. However a PCN-node that hasn't be upgraded (ie is still doing baseline) mustn't block this so it MUST treat this transition as valid; it MAY also raise an alarm. 
[Not sure " MAY also raise an alarm" is needed, since alarm already raised since EXP(01) is the codepoint in]

> alarm to be raised at a higher layer
is 'higher layer' right? how about "management alarm"?

> A PCN-egress-node SHOULD set the not-PCN (00) codepoint on all
   packets it forwards out of the PCN-domain.  The only exception to
   this is if the PCN-egress-node is certain that revealing other
   codepoints outside the PCN-domain won't contravene the guidance given
   in [RFC4774].
I wonder if this needs a bit more explanation about how to do this, or where to find more guidance?

4.3.1
Co-existence of PCN and not-PCN traffic
I wonder if it's worth adding pointer to S3.5 rfc5559 (or draft-ietf-pcn-marking-behaviour Section B.1) which says
>> It is not advised to have competing-non-PCN-traffic but, if there
      is such traffic, there needs to be a mechanism to limit it.
      "Competing-non-PCN-traffic" means traffic that shares a link with
      PCN-traffic and competes for its forwarding bandwidth.  Hence,
      more competing-non-PCN-traffic results in poorer QoS for PCN.
      Further, the unpredictable amount of competing-non-PCN-traffic
      makes the PCN mechanisms less accurate and so reduces PCN's
      ability to protect the QoS of admitted PCN-flows.

5
> The 11 codepoint in the ECN field MUST indicate PCN-marked (though
      this does not exclude the 01 Experimental codepoint from carrying
      the same meaning).
I think better would be " Experimental codepoint from also indicating PCN-marking" [it would indicate a 2nd level of pcn-marking, which you could say is not the "same" meaning]

A.1
The approach & wording is basically good.
>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
   admission control for the following service classes:

   o  Telephony (EF)

   o  Real-time interactive (CS4)

   o  Broadcast Video (CS3)

   o  Multimedia Conferencing (AF4)

I think "sufficient aggregation" would be better than "uniformly high link rates" [similarly, "sufficiently" not "highly" in the next para]
" Real Time Traffic Class" - 5127 calls it Treatment Aggregate, at least in Fig 2
you might want to say why CS5 is excluded from pcn (all the other dscps in the RT treatement aggregate are included]
rfc4594 needed as a ref somewhere here as that defines these dscps

Typos etc
Abstract
>This document specifies how such marks are to be encoded
delete 'to be'

4.0 >implementiors

4.2
> There are a number of factors that
   were considered before choosing to set 10
could have a new paragraph before this

4.3.0 
> Thirdly PCN
   should be seen as being essentially a marking behaviour similar to
   ECN but intended for inelastic traffic.  
Re-phrase : Thirdly PCN is not a scheduling behaviour -- rather it should be seen as being essentially a marking behaviour similar to ECN but intended for inelastic traffic.

6
> in decapsulation
'upon' better?

6
> If an
   operator wishes to allow ECN to exist end-to-end they must ensure
   there are no tunnel end-points within the PCN-domain to prevent any
   risk of PCN-markings being exposed to endpoints.
Earlier in the paragraph you talk about a tunnel across the pcn-domain - then there might be another tunnel wholly within the pcn-domain, and this would be ok. (I know what you mean - perhaps slight re-ordering of the para would do the trick)

A.1
>PCn region
PCN-domain

Thanks
phil

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
{ [email-masked]
{ Sent: 20 August 2009 16:19
{ To: [email-masked]; [email-masked]
{ Subject: [PCN] FW: New Version Notification fordraft-ietf-pcn-baseline-
{ encoding-05
{ 
{ I hope this accurately reflects the ML discussions over the past few days?
{ I have also corrected all the nits and hopefully haven't left any spelling
{ mistakes or typos...
{ 
{ Toby
{ 
{ ____________________________________________________________________
{ Toby Moncaster, <[email-masked]> Networks Research Centre, BT
{ B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 7918 901170
{ 
{ 
{ 
{ -----Original Message-----
{ From: IETF I-D Submission Tool [mailto:[email-masked]]
{ Sent: 20 August 2009 16:17
{ To: Moncaster,T,Toby,DER3 R
{ Cc: Briscoe,RJ,Bob,DER3 R; [email-masked]
{ Subject: New Version Notification for draft-ietf-pcn-baseline-encoding-05
{ 
{ 
{ A new version of I-D, draft-ietf-pcn-baseline-encoding-05.txt has been
{ successfuly submitted by T Moncaster and posted to the IETF repository.
{ 
{ Filename:	 draft-ietf-pcn-baseline-encoding
{ Revision:	 05
{ Title:		 Baseline Encoding and Transport of Pre-Congestion
{ Information
{ Creation_date:	 2009-08-20
{ WG ID:		 pcn
{ Number_of_pages: 14
{ 
{ Abstract:
{ 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 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.
{ 
{ 
{ 
{ The IETF Secretariat.
{ 
{ 
{ _______________________________________________
{ PCN mailing list
{ [email-masked]
{ https://www.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Fri, 21 Aug 2009 08:48:27 +0200

I've read A1 only and think this text is allright from what it intends to say. 

Phil had some comments, one of which was related to CS5. While I'm aware of EF 
and some AF codepoints to be commercially deployed, I'd have to study my 
archived material to see, whether any of the class/codepoint schemes I've seen 
uses CS5 on IP level. 

But I don't fundamentally object to adding CS5 to the A1 list of recommended 
DSCP's (as I only know a few class/codepoint concepts).

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, August 20, 2009 5:19 PM
To: [email-masked]; [email-masked]
Subject: [PCN] FW: New Version Notification fordraft-ietf-pcn-baseline-encoding-05

Toby

-----Original Message-----
From: IETF I-D Submission Tool [mailto:[email-masked]] 
Sent: 20 August 2009 16:17
To: Moncaster,T,Toby,DER3 R
Cc: Briscoe,RJ,Bob,DER3 R; [email-masked]
Subject: New Version Notification for draft-ietf-pcn-baseline-encoding-05 

Abstract:

The IETF Secretariat.

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

---

From: <[email-masked]>
Date: Fri, 21 Aug 2009 08:49:15 +0100

Hi ruediger

I'm not sure that cs5 should be added - it's signalling, and adm ctrl should I think be for the data part not for the couple of signalling msgs. 

I was just saying that this was the one RT traffic aggregate dscp not included and that was worth a quick explanation.

{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
{ [email-masked]
{ Sent: 21 August 2009 07:48
{ To: Moncaster,T,Toby,DER3 R; [email-masked]; [email-masked]
{ Subject: Re: [PCN] FW: New Version Notificationfordraft-ietf-pcn-baseline-
{ encoding-05
{ 
{ I've read A1 only and think this text is allright from what it intends to
{ say.
{ 
{ Phil had some comments, one of which was related to CS5. While I'm aware
{ of EF
{ and some AF codepoints to be commercially deployed, I'd have to study my
{ archived material to see, whether any of the class/codepoint schemes I've
{ seen
{ uses CS5 on IP level.
{ 
{ But I don't fundamentally object to adding CS5 to the A1 list of
{ recommended
{ DSCP's (as I only know a few class/codepoint concepts).
{ 
{ Regards,
{ 
{ Ruediger
{ 
{ -----Original Message-----
{ From: [email-masked] [mailto:[email-masked]] On Behalf Of
{ [email-masked]
{ Sent: Thursday, August 20, 2009 5:19 PM
{ To: [email-masked]; [email-masked]
{ Subject: [PCN] FW: New Version Notification fordraft-ietf-pcn-baseline-
{ encoding-05
{ 
{ I hope this accurately reflects the ML discussions over the past few days?
{ I have also corrected all the nits and hopefully haven't left any spelling
{ mistakes or typos...
{ 
{ Toby
{ 
{ ____________________________________________________________________
{ Toby Moncaster, <[email-masked]> Networks Research Centre, BT
{ B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 7918 901170
{ 
{ 
{ 
{ -----Original Message-----
{ From: IETF I-D Submission Tool [mailto:[email-masked]]
{ Sent: 20 August 2009 16:17
{ To: Moncaster,T,Toby,DER3 R
{ Cc: Briscoe,RJ,Bob,DER3 R; [email-masked]
{ Subject: New Version Notification for draft-ietf-pcn-baseline-encoding-05
{ 
{ 
{ A new version of I-D, draft-ietf-pcn-baseline-encoding-05.txt has been
{ successfuly submitted by T Moncaster and posted to the IETF repository.
{ 
{ Filename:	 draft-ietf-pcn-baseline-encoding
{ Revision:	 05
{ Title:		 Baseline Encoding and Transport of Pre-Congestion
{ Information
{ Creation_date:	 2009-08-20
{ WG ID:		 pcn
{ Number_of_pages: 14
{ 
{ Abstract:
{ 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 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.
{ 
{ 
{ 
{ The IETF Secretariat.
{ 
{ 
{ _______________________________________________
{ PCN mailing list
{ [email-masked]
{ https://www.ietf.org/mailman/listinfo/pcn
{ _______________________________________________
{ PCN mailing list
{ [email-masked]
{ https://www.ietf.org/mailman/listinfo/pcn

---

From: <[email-masked]>
Date: Fri, 21 Aug 2009 10:02:32 +0200

Hi Phil,

I agree, signalling doesn't need PCN. 

Regards,

Ruediger

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, August 21, 2009 9:49 AM
To: Geib, Rüdiger; [email-masked]; [email-masked]; [email-masked]
Subject: RE: [PCN] FW: New Version Notificationfordraft-ietf-pcn-baseline-encoding-05

Hi ruediger

---

From: <[email-masked]>
Date: Fri, 21 Aug 2009 09:24:57 +0100

Hi Phil,

Thanks for the comments. I will try and incorporate all of them into the (hopefully) final version after the IETF LC ends in 2 weeks time.

More inline

> From: Eardley,PL,Philip,DER3 R
> Sent: 20 August 2009 17:37
> To: Moncaster,T,Toby,DER3 R; [email-masked]; [email-masked]
> Subject: RE: [PCN] FW: New Version Notification fordraft-ietf-pcn-
> baseline-encoding-05
> 
> Few minor comments:
> 
> Table 1 has
> >EXP(01)*
> I think your comment ["*This SHOULD.."] really only applies to the
> "EXP(01)*" - ie if the codepoint in is EXP(01) then raise an alarm as
> this shouldn't happen.

I think that is what I meant, yes. I will have a look at re-jigging the table to clarify

> ** these transitions MAY be allowed be some future experimental
> extensions to the baseline encoding. However a PCN-node that hasn't be
> upgraded (ie is still doing baseline) mustn't block this so it MUST
> treat this transition as valid; it MAY also raise an alarm.
> [Not sure " MAY also raise an alarm" is needed, since alarm already
> raised since EXP(01) is the codepoint in]

Or something about "In order not to block future extensions from using these transitions..."? I will try and sort something out

> is 'higher layer' right? how about "management alarm"?

Yep, by higher layer I meant control or management layer

> where to find more guidance?

Would an example count as guidance? "For example where the PCN-egress-node has been explicitly informed by the PCN-ingress-node that this flow is ECN-capable" In terms of where to find guidance, currently only in experimental schemes (I think)

> I wonder if it's worth adding pointer to S3.5 rfc5559 (or draft-ietf-
> pcn-marking-behaviour Section B.1) which says

Yep, will do

> I think better would be " Experimental codepoint from also indicating
> PCN-marking" [it would indicate a 2nd level of pcn-marking, which you
> could say is not the "same" meaning]

But I define PCN-marked as having the meaning "...codepoint indicating packets that have been marked at a PCN-interior-node using some PCN marking behaviour..." Which is the same regardless of the relative level of each of those marks! However I am happy to be explicit and say EXP is not excluded from meaning PCN-marked

> I think "sufficient aggregation" would be better than "uniformly high
> link rates" [similarly, "sufficiently" not "highly" in the next para]

Yep

> you might want to say why CS5 is excluded from pcn (all the other dscps
> in the RT treatement aggregate are included]

Will just put "CS5 is excluded since PCN is not expected to be applied to signalling traffic". However that does raise an interesting question with regards to Michael's proposed approach of using admission marking on RSVP PATH messages in PSDM as I would count those as signalling traffic?

> >This document specifies how such marks are to be encoded

OK

> 4.0 >implementiors

Already spotted...

> could have a new paragraph before this
OK

> Re-phrase : Thirdly PCN is not a scheduling behaviour -- rather it
> should be seen as being essentially a marking behaviour similar to ECN
> but intended for inelastic traffic.
> 
OK

> 'upon' better?
Will decide

> Earlier in the paragraph you talk about a tunnel across the pcn-domain
> - then there might be another tunnel wholly within the pcn-domain, and
> this would be ok. (I know what you mean - perhaps slight re-ordering of
> the para would do the trick)
Will have a think about whether I can word this any better...

> PCN-domain
Oops!

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 21 Aug 2009 11:45:06 +0100

Toby,

I just re-reviewed -05 as a whole and my list of comments included 
every single one of Phil's comments (even tho I hadn't read his email first).

== S.4.1. para 2 ==
"  The only valid codepoint transitions within a PCN-interior-node are
                                                 ... and from EXP to
    PM (which MAY be allowed by some future experimental extensions)."

Delete parenthesis and add:

PCN nodes that only implement the baseline encoding MUST be able to 
PCN mark packets that arrive with the EXP codepoint. This should ease 
the design of experimental schemes that want to allow partial 
deployment of experimental nodes alongside nodes that only implement 
the baseline encoding.

The codepoint transition constraints given here apply only to the 
baseline encoding scheme. Constraints on codepoint transitions for 
future experimental scheme are discussed in S.5.

== Table 2. ==
s/* This SHOULD cause an alarm/
  /* This MAY cause an alarm/

== S.6. last sentence ==
"  If an
    operator wishes to allow ECN to exist end-to-end they must ensure
    there are no tunnel end-points within the PCN-domain to prevent any
    risk of PCN-markings being exposed to endpoints.
"
Rather than ruling out tunnel endpoints, I suggest you refer to the 
tunnel guidelines in RFC5559, which lays down the conditions under 
which tunnel endpoints can be used (i.e. the tunnel endpoint must act 
as an appropriate PCN edge node).

Nits:
== S.4.3 last line ==
s/appendix Appendix/Appendix/

== S.5. ==
s/a packet within a PCN-compatible Diffserv Codepoint
  /a packet with a PCN-compatible Diffserv Codepoint/

=== 5th bullet ===
"  o  Any experimental scheme MUST NOT update the meaning of the 00 and
       11 codepoints defined above.
"
Same problem here as Phil pointed out for the 2nd bullet. An 
experimental scheme will probably refine the meaning of the 11 
codepoint (which would update the meaning contrary to the literal 
interpretation of this rule).

== S.6. ==
s/Standard IP-in-IP or IPsec tunnels/
  /RFC3168 IP-in-IP or RFC4301 IPsec tunnels/
== S.8. 1st para ==

"  PCN-marking only carries a meaning within the confines of a PCN-
    domain.  Packets wishing to be treated as belonging to a PCN-flow
    must carry a PCN-compatible DSCP and a PCN-Enabled ECN codepoint.
    This encoding document is intended to stand independently of the
    architecture used to determine how specific packets are authorised to
    be PCN-marked, which will be described in separate documents on PCN-
    boundary-node behaviour.
"
Delete the middle (2nd) sentence, which could be read as implying 
that packets arriving at the PCN ingress have to already carry a 
PCN-compatible DSCP and a PCN-Enabled ECN codepoint.

== Repetitions that read OK, but may not have been intended ==

2nd sentence of S.4.1. repeats the last bullet of the preceding 
section (but they are both relevant in their respective sections).

Opening sentences of A.1 repeat 3rd para of S.4.3.

HTH

Bob

At 09:24 21/08/2009, [email-masked] wrote:
>Hi Phil,
>
>Thanks for the comments. I will try and incorporate all of them into 
>the (hopefully) final version after the IETF LC ends in 2 weeks time.
>
>More inline
>
>Or something about "In order not to block future extensions from 
>using these transitions..."? I will try and sort something out
>
>
> >
>Would an example count as guidance? "For example where the 
>PCN-egress-node has been explicitly informed by the PCN-ingress-node 
>that this flow is ECN-capable" In terms of where to find guidance, 
>currently only in experimental schemes (I think)
>
> >
> > 4.3.1
>But I define PCN-marked as having the meaning "...codepoint 
>indicating packets that have been marked at a PCN-interior-node 
>using some PCN marking behaviour..." Which is the same regardless of 
>the relative level of each of those marks! However I am happy to be 
>explicit and say EXP is not excluded from meaning PCN-marked
>
> >
> > A.1
>Will just put "CS5 is excluded since PCN is not expected to be 
>applied to signalling traffic". However that does raise an 
>interesting question with regards to Michael's proposed approach of 
>using admission marking on RSVP PATH messages in PSDM as I would 
>count those as signalling traffic?
>
> >
> >
> > Typos etc
> > Abstract

---

From: <[email-masked]>
Date: Fri, 21 Aug 2009 12:01:50 +0100

Thanks, I will add these to the other corrections/comments... 

1 inline response

> From: Briscoe,RJ,Bob,XVR9 BRISCORJ R
> Sent: 21 August 2009 11:45
> To: Moncaster,T,Toby,DER3 R; Eardley,PL,Philip,DER3 R; [email-masked];
> [email-masked]
> Subject: Re: [PCN] FW: New Version Notification fordraft-ietf-pcn-
> baseline-encoding-05
> 
> Toby,
> 

My response here is the same as my response to Phil's comment - this
document defines 11 as meaning PCN-marked. PCN-marked is defined as
having been marked as a result of a PCN-marking function - it doesn't
specify which sort of mark this is. In the context of the baseline
encoding, any experimental scheme also needs to ensure that 11 means
PCN-marked...

> > > extensions to the baseline encoding. However a PCN-node that
hasn't
> be
> > > I wonder if this needs a bit more explanation about how to do
this,
> or
> > > where to find more guidance?
> >
> > > { I hope this accurately reflects the ML discussions over the past
> few
> > > days?
> > > { I have also corrected all the nits and hopefully haven't left
any
> > > spelling
> > > { Toby Moncaster, <[email-masked]> Networks Research
Centre,
> BT
> > > { A new version of I-D, draft-ietf-pcn-baseline-encoding-05.txt
has
> > > been