Subject: Re: [PCN] FW: RE: PCN encoding option

From: "Jozef Babiarz" <[email-masked]>
Date: Sat, 1 Mar 2008 12:36:28 -0500

I agree with Michael's views. Two DSCP is high prices to pay to address
misconfiguration problem and only sometimes.

Regards, Joe
email:[email-masked]
Telephone:613-763-6098
-----Original Message-----
From: Michael Menth [mailto:[email-masked]] 
Sent: February 20, 2008 5:50 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; Chan, Kwok-Ho (BL60:470);
Babiarz, Jozef (CAR:0S03); [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: FW: RE: PCN encoding option

Hi Toby,

as I understand the proposal, the motivation is to avoid 01/10 
codepoints as it is not good if they leak out of the network since 01/10

is interpreted as ECN-capable ECT(0/1) by ECN nodes. However, there is 
the same problem with 11 marking, i.e. 11-packets may not be dropped by 
ECN nodes outside the PCN domain although endpoints are not ECN capable.

Even if 11-packets trigger flow termination, it is not guaranteed that 
exactly the marked flow going over an overloaded ECN node is terminated.

Just want to say that this solution wants to solve a problem that exists

only in case of misconfiguration (leaking packets), but does not fully 
achieve that objective. Therefore, I feel that spending two DSCP values 
is quite expensive.

Regards,

    Michael

[email-masked] wrote:
>  
> All,
>  
> Phil and I have just been discussing the encoding draft and feel we
may
> have lit upon a neat solution that seems to have lots of pros and few
> cons... In order to get a better feeling for this proposal I will go
> through the simplified version without Affected marking first:
>
> PCN Meaning		ECN 	 DSCP
>
> PCN capable		00	 PCN 1
> Admission Mark	11	 PCN 1
> Termination Mark	11/00	 PCN 2
>
> PCN 1 and PCN 2 are 2 different codepoints with the same PCN behaviour
> aggregate.
>
> Pros:
>  o  Termination marking and admission marking are independent, eg
> termination marking can be done after a packet has been admission
> marked. Therefore a router can write AM or TM without having to read
the
> packet's PCN marking first, which is easier to implement. (Note:
> Over-writing a TM with AM is not allowed for 3SM & CL, see
> draft-charny-pcn-comparison.)
>
> o  This scheme avoids giving semantics to ECT(0) and ECT(1). This is
> safest option if packets leak outside the PCN region, due to some fort
> of misconfiguration of the PCN-boundary-nodes (relevant for a single
> domain deployment of PCN).  
>
> o  It leaves open the possibility of using ECT(0) and ECT(1) in some
> mysterious way in a future end-to-end PCN deployment
>
> o  For a router to classify a packet as PCN, it simply reads its DSCP.
> This is probably easier than checking both its DSCP & ECN fields. 
>
> o  Incremental deployment steps are possible
> [1] could deploy SM initially and later AM/TM. Just add the second
DSCP.
> If a router isn't upgraded at the same time nothing too horrific
> happens. 
> [2] could just deploy admission control & add termination later, just
by
> adding a new DSCP; there is no need to change the encoding and check
for
> backwards compatibility? Vice-versa is also ok?
>
> Cons:
> o  It needs an extra DSCP, per PCN behaviour aggregate. (Although
> possibly it's OK to use the same DSCP for TM for all PCN BAs?)
>
> o  If a packet (in a PCN flow) arrives at the egress with its ECN = 11
> and it really is required to preserve this info across the PCN-domain,
> then some complexity is needed at the PCN-boundary-nodes (tunnelling)
>
> o  If the PCN-domain is operating multipath routing (ECMP) that uses
the
> DSCP to select routes, then there may be mis-ordering of packets
within
> a flow. This may be OK as (1) no-one has yet said they know of an ECMP
> algorithm that in practie uses the DSCP; (2) a risk of mis-ordering
when
> there is termination marking may be acceptable
>
> If Affected marking is needed then the scheme can be modified as
> follows:
>
> PCN Meaning		ECN 	DSCP
>
> PCN capable		00	PCN 1
> Admission Mark	11	PCN 1
> Termination Mark	11	PCN 2
> Affected Mark	00	PCN 2
>
> The pros for this scheme are broadly similar to the above. However
there
> is a new con which may or may not matter: If a packet is affected
marked
> and a later node is doing admission marking then it will reset the
> affected mark to a termination mark. Work would be needed to see if
this
> skews the results and causes significant over-termination or not.
>
> Please could people look through this scheme and highlight any
> additional concerns that they may have (and extra benefits too). I
would
> like to get as many opinions as possible. 
>
> What I want to avoid is people just emailing back with "why not try
this
> scheme instead". Currently we seem to have a plethora of possible
> schemes on the table and people need to start putting down much
clearer
> pros and cons for the schemes they support... So it could be good to
> have a similar "one page" email about a specific scheme that only uses
> one DSCP for PCN, but uses the 01/10 codepoints instead. 
>
> Toby 
> ____________________________________________________________________
> Toby Moncaster, <[email-masked]> Networks Research Centre, BT 
> B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 1473 648734
>   

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

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

---

From: Steven Blake <[email-masked]>
Date: Sat, 01 Mar 2008 22:06:50 -0500

> misconfiguration problem and only sometimes.

We are currently tasked to define PCN for use within a single Diffserv
domain.  EXP/LU DSCP values (RFC 2474) are not scarce.

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven Blake                <[email-masked]>
Ericsson/Redback Networks               +1 919-472-9913

---

From: "Geib, Ruediger" <[email-masked]>
Date: Mon, 3 Mar 2008 09:08:30 +0100

Hi Joe, hi Michael, 

I share you views and I'd like to repeat my point that routers 
can be misconfigured in many ways and locations. This may end 
in undesired behaviour. I can't recall that its a task 
of standardisation to deal with unplanned misconfigurations, 
it's rather a task of operation.

Regards,

Rudiger

| I agree with Michael's views. Two DSCP is high prices to pay 
| to address misconfiguration problem and only sometimes.
| 
| Regards, Joe
| email:[email-masked]
| Telephone:613-763-6098
| -----Original Message-----
| From: Michael Menth [mailto:[email-masked]]
| Sent: February 20, 2008 5:50 AM
| To: [email-masked]
| Cc: [email-masked]; [email-masked]; Chan, Kwok-Ho 
| (BL60:470); Babiarz, Jozef (CAR:0S03); [email-masked]; 
| [email-masked]; [email-masked]; [email-masked]
| Subject: Re: FW: RE: PCN encoding option
| 
| Hi Toby,
| 
| as I understand the proposal, the motivation is to avoid 
| 01/10 codepoints as it is not good if they leak out of the 
| network since 01/10
| 
| is interpreted as ECN-capable ECT(0/1) by ECN nodes. However, 
| there is the same problem with 11 marking, i.e. 11-packets 
| may not be dropped by ECN nodes outside the PCN domain 
| although endpoints are not ECN capable.
| 
| Even if 11-packets trigger flow termination, it is not 
| guaranteed that exactly the marked flow going over an 
| overloaded ECN node is terminated.
| 
| Just want to say that this solution wants to solve a problem 
| that exists
| 
| only in case of misconfiguration (leaking packets), but does 
| not fully achieve that objective. Therefore, I feel that 
| spending two DSCP values is quite expensive.
| 
| Regards,
| 
|     Michael
| 
| [email-masked] wrote:
| >  
| > All,
| >  
| > Phil and I have just been discussing the encoding draft and feel we
| may
| > have lit upon a neat solution that seems to have lots of 
| pros and few 
| > cons... In order to get a better feeling for this proposal 
| I will go 
| > through the simplified version without Affected marking first:
| >
| > PCN Meaning		ECN 	 DSCP
| >
| > PCN capable		00	 PCN 1
| > Admission Mark	11	 PCN 1
| > Termination Mark	11/00	 PCN 2
| >
| > PCN 1 and PCN 2 are 2 different codepoints with the same 
| PCN behaviour 
| > aggregate.
| >
| > Pros:
| >  o  Termination marking and admission marking are independent, eg 
| > termination marking can be done after a packet has been admission 
| > marked. Therefore a router can write AM or TM without having to read
| the
| > packet's PCN marking first, which is easier to implement. (Note:
| > Over-writing a TM with AM is not allowed for 3SM & CL, see
| > draft-charny-pcn-comparison.)
| >
| > o  This scheme avoids giving semantics to ECT(0) and 
| ECT(1). This is 
| > safest option if packets leak outside the PCN region, due 
| to some fort 
| > of misconfiguration of the PCN-boundary-nodes (relevant for 
| a single 
| > domain deployment of PCN).
| >
| > o  It leaves open the possibility of using ECT(0) and 
| ECT(1) in some 
| > mysterious way in a future end-to-end PCN deployment
| >
| > o  For a router to classify a packet as PCN, it simply 
| reads its DSCP.
| > This is probably easier than checking both its DSCP & ECN fields. 
| >
| > o  Incremental deployment steps are possible [1] could deploy SM 
| > initially and later AM/TM. Just add the second
| DSCP.
| > If a router isn't upgraded at the same time nothing too horrific 
| > happens.
| > [2] could just deploy admission control & add termination 
| later, just
| by
| > adding a new DSCP; there is no need to change the encoding and check
| for
| > backwards compatibility? Vice-versa is also ok?
| >
| > Cons:
| > o  It needs an extra DSCP, per PCN behaviour aggregate. (Although 
| > possibly it's OK to use the same DSCP for TM for all PCN BAs?)
| >
| > o  If a packet (in a PCN flow) arrives at the egress with 
| its ECN = 11 
| > and it really is required to preserve this info across the 
| PCN-domain, 
| > then some complexity is needed at the PCN-boundary-nodes 
| (tunnelling)
| >
| > o  If the PCN-domain is operating multipath routing (ECMP) that uses
| the
| > DSCP to select routes, then there may be mis-ordering of packets
| within
| > a flow. This may be OK as (1) no-one has yet said they know 
| of an ECMP 
| > algorithm that in practie uses the DSCP; (2) a risk of mis-ordering
| when
| > there is termination marking may be acceptable
| >
| > If Affected marking is needed then the scheme can be modified as
| > follows:
| >
| > PCN Meaning		ECN 	DSCP
| >
| > PCN capable		00	PCN 1
| > Admission Mark	11	PCN 1
| > Termination Mark	11	PCN 2
| > Affected Mark	00	PCN 2
| >
| > The pros for this scheme are broadly similar to the above. However
| there
| > is a new con which may or may not matter: If a packet is affected
| marked
| > and a later node is doing admission marking then it will reset the 
| > affected mark to a termination mark. Work would be needed to see if
| this
| > skews the results and causes significant over-termination or not.
| >
| > Please could people look through this scheme and highlight any 
| > additional concerns that they may have (and extra benefits too). I
| would
| > like to get as many opinions as possible. 
| >
| > What I want to avoid is people just emailing back with "why not try
| this
| > scheme instead". Currently we seem to have a plethora of possible 
| > schemes on the table and people need to start putting down much
| clearer
| > pros and cons for the schemes they support... So it could 
| be good to 
| > have a similar "one page" email about a specific scheme 
| that only uses 
| > one DSCP for PCN, but uses the 01/10 codepoints instead.
| >
| > Toby
| > ____________________________________________________________________
| > Toby Moncaster, <[email-masked]> Networks Research 
| Centre, BT 
| > B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 1473 648734
| >   
| 
| -- 
| Dr. Michael Menth, Assistant Professor
| University of Wuerzburg, Institute of Computer Science
| Am Hubland, D-97074 Wuerzburg, Germany, room B206
| phone: (+49)-931/888-6644, fax: (+49)-931/888-6632
| mailto:[email-masked]
| http://www3.informatik.uni-wuerzburg.de/research/ngn
| 
| _______________________________________________
| 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: Tue, 4 Mar 2008 17:18:49 -0000

I am happy to accept this as a view if that is what others agree with. I
am now becoming increasingly unclear as to what we will need to actually
do to ensure we are compliant with RFC4774. The idea of my scheme is to
allow for possible leakage of packets into the non-PCN region. As
Ruediger correctly points out, strictly this is an operational issue not
a design issue. However I do think that we would need to highlight the
potential risks that exist if there is any misconfiguration...

However I still like the extra flexibility that is offered by my
proposal. It seems to allow for incremental deployment (start with
single marking then add termination marking), it allows extra codepoints
for a possible future extension to an end-to-end deployment and it
seemed (when I wrote it) to completely address all the concerns raised
in RFC4774.

Toby

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Geib, Ruediger
> Sent: 03 March 2008 08:09
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [PCN] FW: RE: PCN encoding option
> 
> Hi Joe, hi Michael, 
>

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 5 Mar 2008 08:36:17 +0100

Hi Toby,

I don't object to your position in general, my point of view is:

- no standardisation to avoid unplanned misconfiguartion.
- standardisation to avoid "planned misconfiguration" (misuse).
- standardisation to tackle with different interpretation of 
  the same bits by different domains (see eg. DiffServ).
- description of misconfiguration scenarios and how to deal 
  with them in appropriate sections of a standard (sometimes 
  this is security, sometimes operation).

Otherwise, I welcome every PCN solution starting with single 
marking and evolving to more complex schemes. The main argument 
I see for such an approach is applicability within MPLS domains 
by support of a single codepoint mechanism. I also regard 
support of a single codepoint mechanism as a "MUST" for every 
PCN solution searching deployment in the backbone (of the company 
I work for, to state it correctly).

Regards,

Rudiger 

| -----Original Message-----
| From: [email-masked] [mailto:[email-masked]] 
| Sent: Tuesday, March 04, 2008 6:19 PM
| To: Geib, Rüdiger; [email-masked]; 
| [email-masked]
| Cc: [email-masked]
| Subject: RE: [PCN] FW: RE: PCN encoding option
| 
| I am happy to accept this as a view if that is what others 
| agree with. I am now becoming increasingly unclear as to what 
| we will need to actually do to ensure we are compliant with 
| RFC4774. The idea of my scheme is to allow for possible 
| leakage of packets into the non-PCN region. As Ruediger 
| correctly points out, strictly this is an operational issue 
| not a design issue. However I do think that we would need to 
| highlight the potential risks that exist if there is any 
| misconfiguration...
| 
| However I still like the extra flexibility that is offered by 
| my proposal. It seems to allow for incremental deployment 
| (start with single marking then add termination marking), it 
| allows extra codepoints for a possible future extension to an 
| end-to-end deployment and it seemed (when I wrote it) to 
| completely address all the concerns raised in RFC4774.
| 
| Toby
| ____________________________________________________________________
| Toby Moncaster, <[email-masked]> Networks Research 
| Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 
| 1473 648734 
| 
| 
| > -----Original Message-----
| > From: [email-masked] [mailto:[email-masked]] On 
| Behalf Of 
| > Geib, Ruediger
| > Sent: 03 March 2008 08:09
| > To: [email-masked]; [email-masked]
| > Cc: [email-masked]
| > Subject: Re: [PCN] FW: RE: PCN encoding option
| > 
| > Hi Joe, hi Michael,
| > 
| > I share you views and I'd like to repeat my point that 
| routers can be 
| > misconfigured in many ways and locations. This may end in undesired 
| > behaviour. I can't recall that its a task of 
| standardisation to deal 
| > with unplanned misconfigurations, it's rather a task of operation.
| > 
| > Regards,
| > 
| > Rudiger
| > 
| > | I agree with Michael's views. Two DSCP is high prices to pay to 
| > | address misconfiguration problem and only sometimes.
| > | 
| > | Regards, Joe
| > | email:[email-masked]
| > | Telephone:613-763-6098
| > | -----Original Message-----
| > | From: Michael Menth [mailto:[email-masked]]
| > | Sent: February 20, 2008 5:50 AM
| > | To: [email-masked]
| > | Cc: [email-masked]; [email-masked]; Chan, Kwok-Ho 
| (BL60:470); 
| > | Babiarz, Jozef (CAR:0S03); [email-masked]; 
| > | [email-masked]; [email-masked];
| > [email-masked]
| > | Subject: Re: FW: RE: PCN encoding option
| > | 
| > | Hi Toby,
| > | 
| > | as I understand the proposal, the motivation is to avoid 01/10 
| > | codepoints as it is not good if they leak out of the 
| network since 
| > | 01/10
| > | 
| > | is interpreted as ECN-capable ECT(0/1) by ECN nodes. 
| However, there 
| > | is the same problem with 11 marking, i.e. 11-packets may not be 
| > | dropped by ECN nodes outside the PCN domain although 
| endpoints are 
| > | not ECN capable.
| > | 
| > | Even if 11-packets trigger flow termination, it is not guaranteed 
| > | that exactly the marked flow going over an overloaded ECN node is 
| > | terminated.
| > | 
| > | Just want to say that this solution wants to solve a problem that 
| > | exists
| > | 
| > | only in case of misconfiguration (leaking packets), but does not 
| > | fully achieve that objective. Therefore, I feel that spending two 
| > | DSCP values is quite expensive.
| > | 
| > | Regards,
| > | 
| > |     Michael
| > | 
| > | [email-masked] wrote:
| > | >  
| > | > All,
| > | >  
| > | > Phil and I have just been discussing the encoding draft
| > and feel we
| > | may
| > | > have lit upon a neat solution that seems to have lots of
| > | pros and few
| > | > cons... In order to get a better feeling for this proposal
| > | I will go
| > | > through the simplified version without Affected marking first:
| > | >
| > | > PCN Meaning		ECN 	 DSCP
| > | >
| > | > PCN capable		00	 PCN 1
| > | > Admission Mark	11	 PCN 1
| > | > Termination Mark	11/00	 PCN 2
| > | >
| > | > PCN 1 and PCN 2 are 2 different codepoints with the same
| > | PCN behaviour
| > | > aggregate.
| > | >
| > | > Pros:
| > | >  o  Termination marking and admission marking are 
| independent, eg 
| > | > termination marking can be done after a packet has been 
| admission 
| > | > marked. Therefore a router can write AM or TM without
| > having to read
| > | the
| > | > packet's PCN marking first, which is easier to implement. (Note:
| > | > Over-writing a TM with AM is not allowed for 3SM & CL, see
| > | > draft-charny-pcn-comparison.)
| > | >
| > | > o  This scheme avoids giving semantics to ECT(0) and
| > | ECT(1). This is
| > | > safest option if packets leak outside the PCN region, due
| > | to some fort
| > | > of misconfiguration of the PCN-boundary-nodes (relevant for
| > | a single
| > | > domain deployment of PCN).
| > | >
| > | > o  It leaves open the possibility of using ECT(0) and
| > | ECT(1) in some
| > | > mysterious way in a future end-to-end PCN deployment
| > | >
| > | > o  For a router to classify a packet as PCN, it simply
| > | reads its DSCP.
| > | > This is probably easier than checking both its DSCP & 
| ECN fields. 
| > | >
| > | > o  Incremental deployment steps are possible [1] could 
| deploy SM 
| > | > initially and later AM/TM. Just add the second
| > | DSCP.
| > | > If a router isn't upgraded at the same time nothing too 
| horrific 
| > | > happens.
| > | > [2] could just deploy admission control & add termination
| > | later, just
| > | by
| > | > adding a new DSCP; there is no need to change the
| > encoding and check
| > | for
| > | > backwards compatibility? Vice-versa is also ok?
| > | >
| > | > Cons:
| > | > o  It needs an extra DSCP, per PCN behaviour aggregate. 
| (Although 
| > | > possibly it's OK to use the same DSCP for TM for all PCN BAs?)
| > | >
| > | > o  If a packet (in a PCN flow) arrives at the egress with
| > | its ECN = 11
| > | > and it really is required to preserve this info across the
| > | PCN-domain,
| > | > then some complexity is needed at the PCN-boundary-nodes
| > | (tunnelling)
| > | >
| > | > o  If the PCN-domain is operating multipath routing
| > (ECMP) that uses
| > | the
| > | > DSCP to select routes, then there may be mis-ordering of packets
| > | within
| > | > a flow. This may be OK as (1) no-one has yet said they know
| > | of an ECMP
| > | > algorithm that in practie uses the DSCP; (2) a risk of
| > mis-ordering
| > | when
| > | > there is termination marking may be acceptable
| > | >
| > | > If Affected marking is needed then the scheme can be modified as
| > | > follows:
| > | >
| > | > PCN Meaning		ECN 	DSCP
| > | >
| > | > PCN capable		00	PCN 1
| > | > Admission Mark	11	PCN 1
| > | > Termination Mark	11	PCN 2
| > | > Affected Mark	00	PCN 2
| > | >
| > | > The pros for this scheme are broadly similar to the 
| above. However
| > | there
| > | > is a new con which may or may not matter: If a packet 
| is affected
| > | marked
| > | > and a later node is doing admission marking then it will
| > reset the
| > | > affected mark to a termination mark. Work would be needed
| > to see if
| > | this
| > | > skews the results and causes significant 
| over-termination or not.
| > | >
| > | > Please could people look through this scheme and highlight any 
| > | > additional concerns that they may have (and extra 
| benefits too). I
| > | would
| > | > like to get as many opinions as possible. 
| > | >
| > | > What I want to avoid is people just emailing back with
| > "why not try
| > | this
| > | > scheme instead". Currently we seem to have a plethora 
| of possible 
| > | > schemes on the table and people need to start putting down much
| > | clearer
| > | > pros and cons for the schemes they support... So it could
| > | be good to
| > | > have a similar "one page" email about a specific scheme
| > | that only uses
| > | > one DSCP for PCN, but uses the 01/10 codepoints instead.
| > | >
| > | > Toby
| > | > 
| > ____________________________________________________________________
| > | > Toby Moncaster, <[email-masked]> Networks Research
| > | Centre, BT
| > | > B54/70 Adastral Park, Ipswich, IP53RE, UK.  +44 1473 648734
| > | >   
| > | 
| > | --
| > | Dr. Michael Menth, Assistant Professor University of Wuerzburg, 
| > | Institute of Computer Science Am Hubland, D-97074 Wuerzburg, 
| > | Germany, room B206
| > | phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 
| > | mailto:[email-masked]
| > | http://www3.informatik.uni-wuerzburg.de/research/ngn
| > | 
| > | _______________________________________________
| > | PCN mailing list
| > | [email-masked]
| > | https://www.ietf.org/mailman/listinfo/pcn
| > | 
| > _______________________________________________
| > PCN mailing list
| > [email-masked]
| > https://www.ietf.org/mailman/listinfo/pcn
| > 
| 
_______________________________________________
PCN mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pcn