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

[<[e-mail]>]

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, <[e-mail]> Networks Research Centre, BT
B54/70 Adastral Park, Ipswich, IP53RE, UK.  [phone] 


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Geib, Ruediger
> Sent: 03 March 2008 08:09
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> 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:[e-mail]
> | Telephone:[phone]
> | -----Original Message-----
> | From: Michael Menth [mailto:[e-mail]]
> | Sent: February 20, 2008 5:50 AM
> | To: [e-mail]
> | Cc: [e-mail]; [e-mail]; Chan, Kwok-Ho 
> | (BL60:470); Babiarz, Jozef (CAR:0S03); [e-mail]; 
> | [e-mail]; [e-mail]; 
> [e-mail]
> | 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
> | 
> | [e-mail] 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, <[e-mail]> Networks Research 
> | Centre, BT 
> | > B54/70 Adastral Park, Ipswich, IP53RE, UK.  [phone]
> | >   
> | 
> | -- 
> | Dr. Michael Menth, Assistant Professor
> | University of Wuerzburg, Institute of Computer Science
> | Am Hubland, D-97074 Wuerzburg, Germany, room B206
> | phone: [phone], fax: [phone]
> | mailto:[e-mail]
> | http://www3.informatik.uni-wuerzburg.de/research/ngn
> | 
> | _______________________________________________
> | 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