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:babiarz@nortel.com
| Telephone:613-763-6098
| -----Original Message-----
| From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de]
| Sent: February 20, 2008 5:50 AM
| To: toby.moncaster@bt.com
| Cc: pcn@ietf.org; philip.eardley@bt.com; Chan, Kwok-Ho 
| (BL60:470); Babiarz, Jozef (CAR:0S03); sob@harvard.edu; 
| steven.blake@ericsson.com; karagian@cs.utwente.nl; bob.briscoe@bt.com
| 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
| 
| toby.moncaster@bt.com 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, <toby.moncaster@bt.com> 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:menth@informatik.uni-wuerzburg.de
| http://www3.informatik.uni-wuerzburg.de/research/ngn
| 
| _______________________________________________
| PCN mailing list
| PCN@ietf.org
| https://www.ietf.org/mailman/listinfo/pcn
| 
_______________________________________________
PCN mailing list
PCN@ietf.org
https://www.ietf.org/mailman/listinfo/pcn