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
- [PCN] FW: RE: PCN encoding option toby.moncaster
- Re: [PCN] FW: RE: PCN encoding option Michael Menth
- Re: [PCN] FW: RE: PCN encoding option philip.eardley
- Re: [PCN] FW: RE: PCN encoding option philip.eardley
- Re: [PCN] FW: RE: PCN encoding option toby.moncaster
- Re: [PCN] FW: RE: PCN encoding option Michael Menth
- Re: [PCN] FW: RE: PCN encoding option Michael Menth
- Re: [PCN] FW: RE: PCN encoding option Ingemar Johansson S
- Re: [PCN] FW: RE: PCN encoding option philip.eardley
- Re: [PCN] FW: RE: PCN encoding option Michael Menth
- Re: [PCN] FW: RE: PCN encoding option philip.eardley
- Re: [PCN] FW: RE: PCN encoding option Michael Menth
- Re: [PCN] FW: RE: PCN encoding option Georgios Karagiannis
- Re: [PCN] FW: RE: PCN encoding option toby.moncaster
- Re: [PCN] FW: RE: PCN encoding option philip.eardley
- Re: [PCN] FW: RE: PCN encoding option toby.moncaster
- Re: [PCN] FW: RE: PCN encoding option Georgios Karagiannis
- Re: [PCN] FW: RE: PCN encoding option Ingemar Johansson S
- Re: [PCN] FW: RE: PCN encoding option philip.eardley
- [PCN] Routers and ECMP (part of FW: RE: PCN encod… Geib, Ruediger
- Re: [PCN] FW: RE: PCN encoding option Georgios Karagiannis
- Re: [PCN] FW: RE: PCN encoding option toby.moncaster
- Re: [PCN] FW: RE: PCN encoding option toby.moncaster
- Re: [PCN] FW: RE: PCN encoding option philip.eardley
- Re: [PCN] FW: RE: PCN encoding option Georgios Karagiannis
- Re: [PCN] FW: RE: PCN encoding option Geib, Ruediger
- Re: [PCN] FW: RE: PCN encoding option Lars Eggert
- Re: [PCN] FW: RE: PCN encoding option Michael Menth
- Re: [PCN] FW: RE: PCN encoding option Geib, Ruediger
- Re: [PCN] FW: RE: PCN encoding option Ingemar Johansson S
- Re: [PCN] FW: RE: PCN encoding option Michael Menth
- Re: [PCN] FW: RE: PCN encoding option Geib, Ruediger
- Re: [PCN] FW: RE: PCN encoding option Ingemar Johansson S
- Re: [PCN] FW: RE: PCN encoding option toby.moncaster
- Re: [PCN] FW: RE: PCN encoding option Geib, Ruediger
- Re: [PCN] FW: RE: PCN encoding option Michael Menth
- Re: [PCN] FW: RE: PCN encoding option Michael Menth
- Re: [PCN] FW: RE: PCN encoding option Ingemar Johansson S
- Re: [PCN] FW: RE: PCN encoding option Michael Menth
- Re: [PCN] FW: RE: PCN encoding option philip.eardley
- Re: [PCN] FW: RE: PCN encoding option Michael Menth
- Re: [PCN] FW: RE: PCN encoding option philip.eardley
- [PCN] Resetting ECT to non-ECT Michael Menth
- Re: [PCN] FW: RE: PCN encoding option Jozef Babiarz
- Re: [PCN] FW: RE: PCN encoding option Steven Blake
- Re: [PCN] FW: RE: PCN encoding option Geib, Ruediger
- Re: [PCN] FW: RE: PCN encoding option toby.moncaster
- Re: [PCN] FW: RE: PCN encoding option Geib, Ruediger