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

"Jozef Babiarz" <babiarz@nortel.com> Sat, 01 March 2008 17:37 UTC

Return-Path: <pcn-bounces@ietf.org>
X-Original-To: ietfarch-pcn-archive@core3.amsl.com
Delivered-To: ietfarch-pcn-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BDD53A6D02; Sat, 1 Mar 2008 09:37:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.766
X-Spam-Level:
X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-2.329, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdsjnJ80JHDN; Sat, 1 Mar 2008 09:37:05 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEACF3A6D00; Sat, 1 Mar 2008 09:37:03 -0800 (PST)
X-Original-To: pcn@core3.amsl.com
Delivered-To: pcn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C9A93A6CED for <pcn@core3.amsl.com>; Sat, 1 Mar 2008 09:37:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yikZMmScShFz for <pcn@core3.amsl.com>; Sat, 1 Mar 2008 09:37:01 -0800 (PST)
Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id C2E013A6B7B for <pcn@ietf.org>; Sat, 1 Mar 2008 09:37:00 -0800 (PST)
Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m21HaUc12759; Sat, 1 Mar 2008 17:36:30 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Sat, 01 Mar 2008 12:36:28 -0500
Message-ID: <9671A92C3C8B5744BC97F855F7CB646514C776BF@zcarhxm1.corp.nortel.com>
In-Reply-To: <47BC05DA.7090701@informatik.uni-wuerzburg.de>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: FW: RE: PCN encoding option
Thread-Index: AchzroZ862SQI1gCRgmjiFy0a2+oIAIE+Inw
References: <BAB4DC0CD5148948A86BD047A85CE2A704EB03AD@E03MVZ4-UKDY.domain1.systemhost.net> <47BC05DA.7090701@informatik.uni-wuerzburg.de>
From: Jozef Babiarz <babiarz@nortel.com>
To: menth@informatik.uni-wuerzburg.de, toby.moncaster@bt.com
Cc: pcn@ietf.org, bob.briscoe@bt.com
Subject: Re: [PCN] FW: RE: PCN encoding option
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PCN WG list <pcn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/pcn>
List-Post: <mailto:pcn@ietf.org>
List-Help: <mailto:pcn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: pcn-bounces@ietf.org
Errors-To: pcn-bounces@ietf.org

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