From pcn-bounces@ietf.org Sat Mar 1 09:37:06 2008 Return-Path: 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 ; 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 ; 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 ; 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, 1 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: <47BC05DA.7090701@informatik.uni-wuerzburg.de> From: "Jozef Babiarz" To: , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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, 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 From pcn-bounces@ietf.org Sat Mar 1 19:07:08 2008 Return-Path: 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 B412C3A6A60; Sat, 1 Mar 2008 19:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.573 X-Spam-Level: X-Spam-Status: No, score=-1.573 tagged_above=-999 required=5 tests=[AWL=-1.136, 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 sVpSI+EU4Wou; Sat, 1 Mar 2008 19:07:03 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 654D73A6B55; Sat, 1 Mar 2008 19:07: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 867DA3A67FC for ; Sat, 1 Mar 2008 19:07:01 -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 XljSYoH+CjGE for ; Sat, 1 Mar 2008 19:07:00 -0800 (PST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id A78393A6CAD for ; Sat, 1 Mar 2008 19:07:00 -0800 (PST) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m2236pEB010033; Sat, 1 Mar 2008 21:06:52 -0600 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Mar 2008 21:06:51 -0600 Received: from [127.0.0.1] ([147.117.168.117]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 1 Mar 2008 21:06:51 -0600 From: Steven Blake To: Jozef Babiarz In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646514C776BF@zcarhxm1.corp.nortel.com> References: <47BC05DA.7090701@informatik.uni-wuerzburg.de> <9671A92C3C8B5744BC97F855F7CB646514C776BF@zcarhxm1.corp.nortel.com> Date: Sat, 01 Mar 2008 22:06:50 -0500 Message-Id: <1204427210.31825.67.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-OriginalArrivalTime: 02 Mar 2008 03:06:51.0278 (UTC) FILETIME=[761AC2E0:01C87C12] Cc: pcn 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org On Sat, 2008-03-01 at 12:36 -0500, Jozef Babiarz wrote: > I agree with Michael's views. Two DSCP is high prices to pay to address > 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 Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 3 00:02:01 2008 Return-Path: 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 8F2103A69DA; Mon, 3 Mar 2008 00:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[AWL=-0.030, 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 Ru3hz7vNmPrm; Mon, 3 Mar 2008 00:01:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30AAB3A680A; Mon, 3 Mar 2008 00:01:56 -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 3CB593A67A6 for ; Mon, 3 Mar 2008 00:01:54 -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 EC167+xVUVXy for ; Mon, 3 Mar 2008 00:01:48 -0800 (PST) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 529543A69D1 for ; Mon, 3 Mar 2008 00:01:47 -0800 (PST) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Mon, 3 Mar 2008 09:01:35 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Mar 2008 09:01:35 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 3 Mar 2008 09:02:43 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CE0B0F8@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1204323586.9015.31.camel@neutrino> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: draft-ietf-pcn-architecture-03 Thread-Index: Ach7ITXwwoNfTmNSQ2G/rBp+zjgVCAB4r68g References: <1B6169C658325341A3B8066E23919E1CD8C97B@S4DE8PSAANK.mitte.t-com.de> <1204126840.3044.7.camel@neutrino> <1B6169C658325341A3B8066E23919E1CE0ACED@S4DE8PSAANK.mitte.t-com.de> <1204323586.9015.31.camel@neutrino> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 03 Mar 2008 08:01:35.0095 (UTC) FILETIME=[CCE4D870:01C87D04] Cc: pcn@ietf.org Subject: Re: [PCN] FW: draft-ietf-pcn-architecture-03 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Steven, a common mistake is to conclude from the own environment on = others, so I just speak for the company I'm working for. For = Deutsche Telekom, consumption of an MPLS EXP code point is a = serious issue and is in fact a deal breaker. Unless there = are convincing arguments for that (say a fairly good = business case, serious cost reduction in operation or = planning....). That's why I prefer to start with a minimum functionality like = single codepoint marking and then move on to more complex = solutions. Regards, Rudiger | -----Original Message----- | From: Steven Blake [mailto:steven.blake@ericsson.com] = | Sent: Friday, February 29, 2008 11:20 PM | To: Geib, R=FCdiger | Cc: pcn@ietf.org | Subject: RE: [PCN] FW: draft-ietf-pcn-architecture-03 | = | On Fri, 2008-02-29 at 09:10 +0100, Geib, Ruediger wrote: | = | > Hi Steven, | > = | > how many operators and vendors you know deploy or support L-LSPs? | = | Not many, true. Deploying PCN will require at least some = | operational and implementation changes. I guess you are = | telling us that relying on more than two EXP codepoints to = | signal pre-congestion state (and hence having to re-engineer = | the way Diffserv is managed over LSPs) is a deal breaker in = | many networks? | = | = | Regards, | = | =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D | Steven Blake | Ericsson/Redback Networks +1 919-472-9913 | = | = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 3 00:08:00 2008 Return-Path: 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 188BB3A6C55; Mon, 3 Mar 2008 00:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.473 X-Spam-Level: X-Spam-Status: No, score=-0.473 tagged_above=-999 required=5 tests=[AWL=-0.036, 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 hSx1b2ccnFxp; Mon, 3 Mar 2008 00:07:56 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 078293A69E1; Mon, 3 Mar 2008 00:07:56 -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 88F263A6824 for ; Mon, 3 Mar 2008 00:07:54 -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 7TtrH78gE4fy for ; Mon, 3 Mar 2008 00:07:53 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id B8E513A69EA for ; Mon, 3 Mar 2008 00:07:31 -0800 (PST) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail21.telekom.de with ESMTP; Mon, 3 Mar 2008 09:07:22 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Mar 2008 09:07:21 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 3 Mar 2008 09:08:30 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CE0B104@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646514C776BF@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: RE: PCN encoding option Thread-Index: AchzroZ862SQI1gCRgmjiFy0a2+oIAIE+InwAFCx8SA= References: <47BC05DA.7090701@informatik.uni-wuerzburg.de> <9671A92C3C8B5744BC97F855F7CB646514C776BF@zcarhxm1.corp.nortel.com> From: "Geib, Ruediger" To: , X-OriginalArrivalTime: 03 Mar 2008 08:07:21.0721 (UTC) FILETIME=[9B7FC690:01C87D05] Cc: pcn@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org 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, 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 From pcn-bounces@ietf.org Mon Mar 3 01:28:54 2008 Return-Path: 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 BF7B828C4E2; Mon, 3 Mar 2008 01:28:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.343 X-Spam-Level: X-Spam-Status: No, score=0.343 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, 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 YHcXKoqIQRvk; Mon, 3 Mar 2008 01:28:52 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 361713A6A96; Mon, 3 Mar 2008 01:27:24 -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 E69CD3A68D1 for ; Mon, 3 Mar 2008 01:27:23 -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 AgjVtk+BnseD for ; Mon, 3 Mar 2008 01:27:17 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id D8C4728C19F for ; Mon, 3 Mar 2008 01:27:16 -0800 (PST) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m239QThM002616; Mon, 3 Mar 2008 10:26:34 +0100 (MET) From: "Georgios Karagiannis" To: , , References: <000f01c87ab4$e361f990$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B3460C@E03MVZ1-UKDY.domain1.systemhost.net> Date: Mon, 3 Mar 2008 10:26:23 +0100 Message-ID: <000301c87d10$aa3fdd40$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B3460C@E03MVZ1-UKDY.domain1.systemhost.net> Thread-Index: Ach6Idp35cMtk85GQ8Std3J3EpHMGgAAXEngAALAuiAAIWGyEAAEiTTAAJJorMA= X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 03 Mar 2008 10:26:37 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil Yes agree, rsvp hop is being edge to edge & no rsvp processing on the interior nodes occurs. But what I meant is that in the case of the Intserv over Diffserv scenario, RSVP could be used as the Intserv signaling protocol. This means that the RSVP PATH message will be used/processed by PCN-ingress-nodes and PCN-egress-nodes, which are Intserv aware. Furthermore, it is important to note that the RSVP PATH carries a Router Alert option. Now if the RSVP PATH message is used within the PCN domain as a probe packet, then the only additional PCN functionality in the PCN-interior-nodes, is to use the RAO bits carried by the probe packet (i.e., RSVP PATH) for detection rather than an additional ECN/DSCP code. Note that the PCN-Interior-nodes are not Intserv aware, but only PCN aware. Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: vrijdag 29 februari 2008 12:29 > To: karagian@cs.utwente.nl; acharny@cisco.com; > menth@informatik.uni-wuerzburg.de > Cc: pcn@ietf.org > Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > Whoah! The Intserv or diffserv model was always(*) about the > rsvp hop being edge to edge & no rsvp processing on the > interior nodes. (*)ie right back to the first architecture > draft way before the PCN wg. > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: 29 February 2008 09:24 > > To: Eardley,PL,Philip,CXR9 R; acharny@cisco.com; > menth@informatik.uni- > > wuerzburg.de > > Cc: pcn@ietf.org > > Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > > > Hi Phil > > > > Regarding the below comment! > > > > > in terms of encoding, it does have a second encoding, but it uses > > > RAO bits rather than ECN/DSCP bits. > > > > > > I worry a bit about security attacks (because probe pkts > can now be > > > identified) and about deploability barrier (will operators deploy > > > something that slows all their core routers - after all > we claimed > > > one advantage of PCN over hop-by-hop rsvp is that your > core routers > > > are really simple, don't have to do any difficult processing... > > > > In the architecture draft we mention that Intserv over > Diffserv is one > of > > the scenarios that could be > > supported by PCN. In this case I assume that RSVP will be > used as the > > Intserv signaling protocol. > > RSVP PATH carries already a Router Alert option. > > The only additional functionality in the > PCN-interior-nodes, is to use > the > > RAO bits for detection > > rather than an additional ECN/DSCP code. > > > > Best regards, > > Georgios > > > > > > > > > > > -----Original Message----- > > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > On Behalf > > > Of philip.eardley@bt.com > > > Sent: donderdag 28 februari 2008 19:53 > > > To: acharny@cisco.com; menth@informatik.uni-wuerzburg.de > > > Cc: pcn@ietf.org > > > Subject: Re: [PCN] draft-ietf-pcn-architecture-03 > > > > > > Hi > > > > > > Thanks for clarifying Georgios. interesting idea. > > > > > > Just to go back to the basic reason why single marking's > attractive. > > > [1] single marking behaviour on interior routers [2] only single > > > encoding needed > > > > > > your idea at first sight has just one marking behaviour, > ie excess > > > rate marking. Indeed, it only has one token bucket. > > > However, it does have extra code/complexity in order to > do threshold > > > marking for probe pkts, and this involves the pkt being > processed on > > > the slow path within a router. I guess this complexity is for pkt > > > classification & PCN-encoding, rather than for the PCN-metering > > > function. > > > > > > in terms of encoding, it does have a second encoding, but it uses > > > RAO bits rather than ECN/DSCP bits. > > > > > > I worry a bit about security attacks (because probe pkts > can now be > > > identified) and about deploability barrier (will operators deploy > > > something that slows all their core routers - after all > we claimed > > > one advantage of PCN over hop-by-hop rsvp is that your > core routers > > > are really simple, don't have to do any difficult processing... > > > > > > phil > > > > > > > -----Original Message----- > > > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > > > Behalf Of > > > Anna > > > > Charny (acharny) > > > > Sent: 28 February 2008 16:08 > > > > To: menth@informatik.uni-wuerzburg.de > > > > Cc: pcn > > > > Subject: Re: [PCN] draft-ietf-pcn-architecture-03 > > > > > > > > Hi Michael, > > > > > > > > Ah - that makes perfect sense. Thank you for the > concise summary. > > > > > > > > Anna > > > > > > > > > -----Original Message----- > > > > > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > > > > > Sent: Thursday, February 28, 2008 10:51 AM > > > > > To: Anna Charny (acharny) > > > > > Cc: Lars Eggert; pcn > > > > > Subject: Re: [PCN] draft-ietf-pcn-architecture-03 > > > > > > > > > > Hi Anna, > > > > > > > > > > Anna Charny (acharny) wrote: > > > > > > Hi Michael, > > > > > > > > > > > > You lost me on this. The discussion seems to be centered > > > > > around the > > > > > > complexities of appropriately forwarding and processing > > > > > probe packets > > > > > > in the core. What exactly does excess rate marking has to > > > > > do with it? > > > > > > (I do understand the point that excess rate marking needs > > > > > more probes > > > > > > to work reliably than threshold-vased/aka > > > > > vertuall-queue-based marking > > > > > > - I just do not see the connection of this point to the > > > > > discussion it > > > > > > seems to relate to). > > > > > > > > > > > > > > > > Georgios proposes to do excess rate marking and to avoid > multiple > > > > > probes, he wants to make sure that probe packets are always > > > > > AM-marked when a link is precongested with regard to the > > > admissible > > > > > rate. He solves this problem using the router alert > option (RAO) > > > > > taking packets off the fast path. This solves the problem > > > you have > > > > > described above (which is caused by excess rate marking), but > > > > > introduces the problem of RAO. > > > > > That impacts the forwarding of the packets as they > need special > > > > > handling by the routers. The origin of this thread > was that the > > > > > architecture draft said that all pcn packets should be treated > in > > > > > the same way by PCN nodes which is no longer the case > for normal > > > > > data packet and PCN packets. > > > > > > > > > > Regards, > > > > > > > > > > Michael > > > > > > > > > > > If I am missing your point (or the point of the discussion) > > > > > - which is > > > > > > quite possible as I am reading the thread backwards - I > > > would much > > > > > > appreciate a clarification. > > > > > > > > > > > > Anna > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > > > > > On Behalf Of > > > > > >> Michael Menth > > > > > >> Sent: Thursday, February 28, 2008 5:50 AM > > > > > >> To: Lars Eggert > > > > > >> Cc: pcn > > > > > >> Subject: Re: [PCN] draft-ietf-pcn-architecture-03 > > > > > >> > > > > > >> Hi Lars, > > > > > >> > > > > > >> I just want to point out that this complexity is not due > > > > > to probing > > > > > >> itself but due to the use of excess rate marking for > admission > > > > > >> control. > > > > > >> There is no such increased complexity if probing > is done in > > > > > >> combination with exhaustive (threshold) marking for > > > > > admission control. > > > > > >> > > > > > >> Regards, > > > > > >> > > > > > >> Michael > > > > > >> > > > > > >> Lars Eggert wrote: > > > > > >> > > > > > >>> Hi, > > > > > >>> > > > > > >>> I'm not sure if I have fully digested this yet, but it > > > > > >>> > > > > > >> seems like this > > > > > >> > > > > > >>> proposal defines different semantics for what the PCN > > > > > marks mean to > > > > > >>> both the interior and egress nodes, depending on whether a > > > > > >>> > > > > > >> packet is a > > > > > >> > > > > > >>> probe packet or not. That seems to add significant > complexity. > > > > > >>> > > > > > >>> Lars > > > > > >>> > > > > > >>> On 2008-2-28, at 12:19, ext Georgios Karagiannis wrote: > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>>> Hi Phil > > > > > >>>> > > > > > >>>> Sorry for not being clear! > > > > > >>>> > > > > > >>>> As you know if ECMP routing is used then this might cause > > > > > >>>> > > > > > >> problems on > > > > > >> > > > > > >>>> the way of how admission control and flow termination > > > > > >>>> > > > > > >> algorithms are > > > > > >> > > > > > >>>> operating. > > > > > >>>> > > > > > >>>> The ECMP problem is related to the fact that flows can > > > > > belong to a > > > > > >>>> certain ingress-egress-aggregate, which is maintained at > > > > > >>>> > > > > > >> the ingress > > > > > >> > > > > > >>>> adn egress and that operates in admission control > > > state or flow > > > > > >>>> termination state, but that due to the ECMP routing they > are > > > not > > > > > >>>> passing through the congested node. > > > > > >>>> > > > > > >>>> Any measures that are taken on such flows will not solve > the > > > > > >>>> congestion problem, since such flows are not contributing > > > > > >>>> > > > > > >> and causing > > > > > >> > > > > > >>>> the congestion in the PCN-interior-node. > > > > > >>>> > > > > > >>>> Now when probing is used this problem can be solved > > > as follows. > > > > > >>>> When a PCN-interior-node is congested it MUST > > > > > PCN_marking encode a > > > > > >>>> probe packet. > > > > > >>>> > > > > > >>>> > > > > > >>>> Thus if an egress operates, for a certain > > > > > >>>> > > > > > >> ingress-egress-agrregate in > > > > > >> > > > > > >>>> admission control state and it receives a probe packet > > > > > >>>> > > > > > >> which belongs > > > > > >> > > > > > >>>> to a flow associated with the same > > > > > >>>> > > > > > >> ingress-egress-agrregate AND the > > > > > >> > > > > > >>>> probe packet is PCN_marking encoded, then the > egress knows > > > > > >>>> > > > > > >> for sure > > > > > >> > > > > > >>>> that the probe packet passed through one or more > congested > > > > > >>>> PCN-interior-nodes. In this case the probe packet, and > > > > > >>>> > > > > > >> thus also the > > > > > >> > > > > > >>>> requiesting flow can be rejected. > > > > > >>>> > > > > > >>>> If an egress operates, for a certain > ingress-egress-agrregate > > > in > > > > > >>>> admission control state and it receives a probe packet > > > > > >>>> > > > > > >> which belongs > > > > > >> > > > > > >>>> to a flow associated with the same > > > > > >>>> > > > > > >> ingress-egress-agrregate AND the > > > > > >> > > > > > >>>> probe packet is marked as not congested PCN, then the > > > > > egress knows > > > > > >>>> for sure that the probe packet HAS NOT PASSED through a > > > > > congested > > > > > >>>> PCN-interior-node due to e.g., used ECMP routing. In > > > > > this case the > > > > > >>>> probe packet can be accepted, since this flow, even it > > > > > >>>> > > > > > >> belongs to the > > > > > >> > > > > > >>>> ingress-egress-aggergate that operates in admission > > > > > >>>> > > > > > >> control, is not > > > > > >> > > > > > >>>> contributing and causing the congestion in the > > > PCN-interior-node. > > > > > >>>> > > > > > >>>> > > > > > >>>> Okay, but why one should provide the possibility to > > > > > PCN-interior- > > > > > >>>> nodes to distinguish between probe packets and other PCN > > > > > >>>> > > > > > >> aware user > > > > > >> > > > > > >>>> packets? > > > > > >>>> > > > > > >>>> This is related to which admission control and flow > > > termination > > > > > >>>> algorithms and encodings are used in the > PCN-interior-nodes. > > > > > >>>> > > > > > >>>> If an algorithm uses one encoding state for admission > > > > > control and > > > > > >>>> another encoding state for flow termination then probably > > > > > >>>> > > > > > >> it is not > > > > > >> > > > > > >>>> required to provide the possibility to > PC_interior-node to > > > > > >>>> distinguish between probe packets and PCN aware user > packets. > > > > > >>>> This is because when the PCN-interior-node that operates > > > > > >>>> > > > > > >> in admission > > > > > >> > > > > > >>>> control state will AM (admission control encoding state) > > > > > >>>> > > > > > >> encode all > > > > > >> > > > > > >>>> packets, i.e., probe packets and user packets. > > > > > >>>> > > > > > >>>> If an algorithm uses only one encoding state for > > > > > admission control > > > > > >>>> and flow termionation, such as the ones used in the > > > > > single marking > > > > > >>>> (SM) and LC-PCN drafts, then the PCN-interior-node msut > > > > > be able to > > > > > >>>> distinguish between probe packets and user data packets. > > > > > >>>> > > > > > >>>> This is because both algorithms SM and LC-PCN are > > > > > encoding packets > > > > > >>>> proportionaly to the excess rate. > > > > > >>>> This means that when the PCN-interior-node opetrates in > > > > > admission > > > > > >>>> control state it will not SM mark all packets that > > > are passing > > > > > >>>> through the node, but only a proportion that is needed to > > > > > >>>> > > > > > >> represent > > > > > >> > > > > > >>>> the excess rate. Thus if the PCN-interior-node will not > > > > > >>>> > > > > > >> distinguish > > > > > >> > > > > > >>>> between the probe packets and other PCN aware packets, > > > > > >>>> > > > > > >> then it is not > > > > > >> > > > > > >>>> certain that the probe packet will be SM marked when the > > > > > >>>> PCN-interior-node operates in admission control state. > > > > > >>>> Now, if the probe packets carry a Router Alert option, > > > > > and when in > > > > > >>>> Admission control state, the PCN-interior-node marks all > > > > > >>>> > > > > > >> packets that > > > > > >> > > > > > >>>> are carrying a Router Alert option, then the probe packet > > > > > >>>> > > > > > >> will be for > > > > > >> > > > > > >>>> sure marked. > > > > > >>>> > > > > > >>>> Hope that this clarifies your question! > > > > > >>>> > > > > > >>>> Best regards, > > > > > >>>> Georgios > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>> > > > > > >>>>> -----Original Message----- > > > > > >>>>> From: philip.eardley@bt.com > [mailto:philip.eardley@bt.com] > > > > > >>>>> Sent: dinsdag 26 februari 2008 18:16 > > > > > >>>>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com > > > > > >>>>> Cc: pcn@ietf.org > > > > > >>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > > > > >>>>> > > > > > >>>>> Sorry, to repeat: > > > > > >>>>> > > > > > >>>>> I still have not the foggiest idea why on earth someone > > > > > >>>>> > > > > > >> would want > > > > > >> > > > > > >>>>> or need or be interested in the interior node handling > > > > > probe pkts > > > > > >>>>> differently from the way it handles probe pkts. > > > > > >>>>> > > > > > >>>>> So far you have answered a different question, about > whether > > > it > > > > > >>>>> would be possible for someone to devise pcn so that an > > > > > >>>>> > > > > > >> interior node > > > > > >> > > > > > >>>>> could distinguish probe pkts from data pkts. As you > > > > > say, a router > > > > > >>>>> alert option could indeed be used. > > > > > >>>>> > > > > > >>>>> > > > > > >>>>> > > > > > >>>>>> -----Original Message----- > > > > > >>>>>> From: Georgios Karagiannis > [mailto:karagian@cs.utwente.nl] > > > > > >>>>>> Sent: 26 February 2008 17:06 > > > > > >>>>>> To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com > > > > > >>>>>> Cc: pcn@ietf.org > > > > > >>>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > > > > >>>>>> > > > > > >>>>>> Hi Phil > > > > > >>>>>> > > > > > >>>>>> * Regarding Routing NOT, > > > > > >>>>>> * Regarding scheduling, NOT > > > > > >>>>>> * Regarding PCN_marking, it could be handled > differently: > > > > > >>>>>> > > > > > >>>>>> ** if excess rate marking is used AND the > > > PCN-interior-node > > > is > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>> congested > > > > > >>>>> > > > > > >>>>> > > > > > >>>>>> AND > > > > > >>>>>> the probe packet contains the ROUTER ALERT option > THEN > > > > > >>>>>> the probe packet can be distinguished from > the other > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>> PCN packets, > > > > > >>>>> > > > > > >>>>> > > > > > >>>>>> and therefore it will be for sure PCN_marking > encoded. > > > > > >>>>>> > > > > > >>>>>> ** if excess rate marking is used AND the > > > PCN-interior-node > > > is > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>> congested > > > > > >>>>> > > > > > >>>>> > > > > > >>>>>> AND > > > > > >>>>>> the probe packet DOES NOT contain the ROUTER > > > ALERT option > > > > > >>>>>> THEN this MIGHT be PCN_marking encoded, or it MIGHT > not > > > be > > > > > >>>>>> PCN_marking encoded. This depends > > > > > >>>>>> on whether this probe packet is selected > to represent > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>> the excess > > > > > >>>>> > > > > > >>>>> > > > > > >>>>>> rate, or is not selected. > > > > > >>>>>> > > > > > >>>>>> Best regards, > > > > > >>>>>> Georgios > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>> > > > > > >>>>>>> -----Original Message----- > > > > > >>>>>>> From: philip.eardley@bt.com > [mailto:philip.eardley@bt.com] > > > > > >>>>>>> Sent: dinsdag 26 februari 2008 17:45 > > > > > >>>>>>> To: karagian@cs.utwente.nl; steven.blake@ericsson.com > > > > > >>>>>>> Cc: pcn@ietf.org > > > > > >>>>>>> Subject: RE: [PCN] draft-ietf-pcn-architecture-03 > > > > > >>>>>>> > > > > > >>>>>>> But why would the interior node *need* to > distinguish it > > > > > >>>>>>> > > > > > >>>>>>> > > > > > >>>>> from other > > > > > >>>>> > > > > > >>>>> > > > > > >>>>>>> pcn pkts? > > > > > >>>>>>> > > > > > >>>>>>> And even if you have got router alert, the > architecture > > > > > >>>>>>> > > > > > >>>>>>> > > > > > >>>>> draft says: > > > > > >>>>> > > > > > >>>>> > > > > > >>>>>>> "must be handled the same as (ordinary data) > PCN-packets, > > > > > >>>>>>> > > > > > >>>>>>> > > > > > >>>>> in terms > > > > > >>>>> > > > > > >>>>> > > > > > >>>>>>> of routing, scheduling and PCN-marking." > > > > > >>>>>>> Even though your router alert's got it in slow path, > will > > > > > >>>>>>> > > > > > >>>>>>> > > > > > >>>>> it handle > > > > > >>>>> > > > > > >>>>> > > > > > >>>>>>> it any differently in terms of routing scehdulign & > > > > > pcn-marking? > > > > > >>>>>>> > > > > > >>>>>>> > > > > > >>>>>>> > > > > > >>>>>>> > > > > > >>>> _______________________________________________ > > > > > >>>> 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 > > > > > >>> > > > > > >>> > > > > > >> -- > > > > > >> 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 > > > > > >> > > > > > >> > > > > > > > > > > -- > > > > > 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 > > > > > > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 4 03:14:37 2008 Return-Path: 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 7B73E28C66D; Tue, 4 Mar 2008 03:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.489 X-Spam-Level: * X-Spam-Status: No, score=1.489 tagged_above=-999 required=5 tests=[AWL=-1.775, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, J_CHICKENPOX_24=0.6, J_CHICKENPOX_29=0.6, MIME_ASCII0=1.5, MIME_HTML_MOSTLY=0.001, 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 WEQGDPUEeSSe; Tue, 4 Mar 2008 03:14:24 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3D1E28C6C9; Tue, 4 Mar 2008 03:14:11 -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 0CD4F28C6C5 for ; Tue, 4 Mar 2008 03:14:11 -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 OYrapVHFOcOy for ; Tue, 4 Mar 2008 03:13:51 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 9E7A828C6C3 for ; Tue, 4 Mar 2008 03:13:13 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Mar 2008 11:13:03 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 4 Mar 2008 11:13:02 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34628@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34627@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN admission marking algorithm - consensus? Thread-Index: Ach3oGcLq+pZ9d/iRpmXKw/VF5utxgA+v1bgACTdRVABLZ1oMAAAO77Q From: To: X-OriginalArrivalTime: 04 Mar 2008 11:13:03.0063 (UTC) FILETIME=[B6AB6670:01C87DE8] Subject: Re: [PCN] PCN admission marking algorithm - consensus? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1332211516==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1332211516== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87DE8.B642A20C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C87DE8.B642A20C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here are some replies to some comments that Joe sent me (Joe replied to a draft version I sent directly, but all the comments below still apply to the version I sent to list) (hope that's ok joe). =20 Thanks phil =20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of philip.eardley@bt.com Sent: 27 February 2008 11:02 To: pcn@ietf.org Subject: [PCN] PCN admission marking algorithm - consensus? =20 I think we have consensus on the admission marking behaviour. This is a first attempt to capture that in Stds language, is it any use? =20 =20 If an interface of the PCN-domain performs PCN Admission Marking then it performs three functions, which are outlined in draft-ietf-pcn-architecture as follows: =20 o Packet classify - decide whether an incoming packet is a PCN- packet or not. Another PCN WG document will specify encoding, using the DSCP and/or ECN fields. =20 o PCN-meter - measure the 'amount of PCN-traffic'. The measurement is made as an aggregate of all PCN-packets, and not per flow. =20 o PCN-mark - algorithms determine whether to PCN-mark PCN-packets and what packet encoding is used (as specified in another PCN WG document). =20 These functions are now described in more detail. Note: The PCN-node MAY implement these three functions on either its ingoing or outgoing interfaces. The same choice MUST be made for every PCN-node in one PCN-domain.=20 [Joe] Suggest rewording "The same choice MUST be made for every PCN-node in one PCN-domain" to something like "The PCN-domain SHOULD be configured so that all links within the PCN-domain support the PCN function.=20 The work MUST is to strong. I believe it is OK to have a node that does not support the PCN function as long as other nodes provide the PCN functions, i.e., a node may provide PCN-function on both ingoing and outgoing interfaces to compensate for a node that does not provide PCN function.=20 My other issue is really a chart issue, if inside the PCN-domain an operator configures his network in such a way that there are links that can not be congested why would he need PCN-function on those links? =20 [phil] the architecture draft says "However if it's known that an interface cannot become pre-congested then it's not strictly necessary for it to be capable of PCN-marking. But this must be known even in unusual circumstances, eg after the failure of some links. I suppose this makes it a SHOULD =20 =20 Classify function: If a packet's ECN/DSCP fields have the value PCN, as defined in [RFC-encoding], then it MUST be classified as a PCN-packet. If a packet's ECN/DSCP fields do not have the value PCN, as defined in [RFC-encoding], then it MUST NOT be classified as a PCN-packet. [Joe] I would suggest that the second line be reword to say that "all other packets are not PCN-packets". =20 [PHIL] Actually this needs to be updated, since we may need to take account of [quoting arch draft]: There may be traffic that is more important than PCN, perhaps a particular application or an operator's control messages. A PCN- node may dedicate capacity to such traffic or priority schedule it over PCN. In the latter case its traffic needs to contribute to the PCN meters. =20 =20 Meter function: Note: The meter is described as a 'token bucket with threshold', however the implementation is not standardised. For example, it could equally well be implemented as a virtual queue (which operates with negative tokens). =20 A packet classified as a PCN-packet MUST be metered as follows.=20 [Joe] change MUST to MAY in above as this is only an example. =20 [phil] disagree. If we make this a MAY it means the PCN standard doesn't require any particular marking behaviour!! =20 The interface MUST have: [1] a configured bit rate, termed PCN-lower-rate [2] a meter for PCN-packets, which MUST have the following behaviour: [Joe] The above MUST can be changed to SHOULD.=20 =20 [phil] MUST seems right to me.=20 =20 =20 a token bucket, which=20 1A tokens are added at the PCN-lower-rate, to a maximum TB.size 1B tokens are removed equal to the size of the PCN-packet, to a minimum TB.size=3D0 2 if TB.fill < TB.threshold, then the meter indicates "admission mark" to the Mark function [Joe] Need to add that TB.threshold MUST be configured to be less than maximum TB.size and grater than TB.size=3D0 =20 [phil] ok, although I suppose 'equal to' is ok in both cases =20 Note: Step 1A can be triggered by a packet and so can be done at the same time as Step 1B. Note: Step 2 can be performed before or after step 1 [Joe] The two notes are not needed. =20 [phil] they were meant to make it clear that numbering doesn't imply must be done in this order (which the reader might otherwise assume)? =20 If TB.fill < size of the PCN-packet, then the meter MAY: a. leave TB.fill unaltered and indicate "admission mark" to the Mark function b. set TB.fill =3D 0 and indicate "admission mark" to the Mark function c. set TB.fill =3D 0 and check if TB.fill < TB.threshold and if it is, then indicate "admission mark" to the Mark function =20 Note: Option a is expected to be the simplest to implement.=20 [Joe] The above points are not needed as "1B" states that minimum TB size=3D0, it should not go negative. =20 [phil] note, if the meter does choice a, then TB.fill is unaltered. This needs to stated I think. =20 =20 Mark function: If the meter indicates to "admission mark" a PCN-packet, then: [1] this step is REQUIRED, unless [RFC-encoding] standardises an encoding that allows a PCN-packet to be simultaneously "admission marked" and "termination marked": If the PCN-packet's codepoint is already "termination mark" then it MUST NOT be altered, ie the following step is not performed. [2] the PCN-packet's ECN/DSCP fields MUST be set to the codepoint "admission marked", as defined in [RFC-encoding] [Joe]Reword the Marking function to as: The "admission marking" is only applied to unmarked PCN packets. As note could state that "termination marked" packets MUST NOT be remarked, but I believe it is not needed as there may be networks that only do admission control and not flow termination.=20 =20 [phil] however, if the encoding chosen allows a pkt to be both 'adm marked' & 'termin marked' then your check is unnecessary. This is what the text tries to say. However, I don't think this section should be discussed too much at the moment, as hopefully we reach rapid convergence on the encoding option & then we know better what to write here.=20 =20 =20 we could also add an example algorithm, such as that in http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt Fig 10.1 on page 21. =20 Comments? phil ------_=_NextPart_001_01C87DE8.B642A20C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here are some replies to some = comments that Joe sent me (Joe replied to a draft version I sent directly, but = all the comments below still apply to the version I sent to list) (hope = that’s ok joe).

 

Thanks

phil

 

-----Original Message-----
From: = pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On = Behalf Of philip.eardley@bt.com
Sent: 27 February 2008 = 11:02
To: pcn@ietf.org
Subject: [PCN] PCN = admission marking algorithm - consensus?

 

I think we have consensus on the = admission marking behaviour. This is a first attempt to capture that in Stds = language, is it any use?

 

 

If an interface of the PCN-domain performs =
PCN Admission Marking then it performs three functions, which are =
outlined in draft-ietf-pcn-architecture as =
follows:
 
   o  Packet classify - decide =
whether an incoming packet is a PCN-
      packet or =
not.  Another PCN WG document will specify =
encoding,
      using the DSCP =
and/or ECN fields.
 
   o  PCN-meter - measure the =
'amount of PCN-traffic'.  The =
measurement
      is made as an =
aggregate of all PCN-packets, and not per =
flow.
 
   o  PCN-mark - algorithms =
determine whether to PCN-mark PCN-packets
      and what =
packet encoding is used (as specified in another PCN =
WG
      =
document).

 

These functions are now described in more = detail.

Note: The PCN-node MAY implement these three functions on either = its ingoing or outgoing interfaces. The same choice MUST be made for every = PCN-node in one PCN-domain.

[Joe] Suggest rewording “The = same choice MUST be made for every PCN-node in one PCN-domain” to = something like “The PCN-domain SHOULD be configured so that all links within = the PCN-domain support the PCN function.

The work MUST is to strong. I = believe it is OK to have a node that does not support the PCN function as long as = other nodes provide the PCN functions, i.e., a node may provide PCN-function = on both ingoing and outgoing interfaces to compensate for a node that does not = provide PCN function.

My other issue is really a chart = issue, if inside the PCN-domain an operator configures his network in such a way = that there are links that can not be congested why would he need PCN-function = on those links?

 

[phil] the architecture draft says =
“However if it's known
   that an interface cannot become =
pre-congested then it's not strictly
   necessary for it to be capable =
of PCN-marking.  But this must be
   known even in unusual =
circumstances, eg after the failure of =
some
   links.

I suppose this makes it a = SHOULD

 

 

Classify function:

If a packet’s ECN/DSCP fields have the value PCN, as = defined in [RFC-encoding], then it MUST be classified as a = PCN-packet.

If a packet’s ECN/DSCP fields do not have the value PCN, = as defined in [RFC-encoding], then it MUST NOT be classified as a = PCN-packet.

[Joe] I would suggest that the = second line be reword to say that “all other packets are not = PCN-packets”.

 

[PHIL] Actually this needs to be = updated, since we may need to take account of [quoting arch = draft]:

There may be traffic that is more important =
than PCN, perhaps a
      particular =
application or an operator's control messages.  A =
PCN-
      node may =
dedicate capacity to such traffic or priority schedule =
it
      over =
PCN.  In the latter case its traffic needs to contribute =
to
      the PCN =
meters.

 

 

Meter function:

Note: The meter is described as a ‘token bucket with threshold’, however the implementation is not standardised. For = example, it could equally well be implemented as a virtual queue (which operates = with negative tokens).

 

A packet classified as a PCN-packet MUST be metered as follows. =

[Joe] change MUST to MAY in above = as this is only an example.

 

[phil] disagree. If we make this a = MAY it means the PCN standard doesn’t require any particular marking = behaviour!!

 

The interface MUST have:

[1] a configured bit rate, termed = PCN-lower-rate

[2] a meter for PCN-packets, which MUST have the following = behaviour:

[Joe] The above MUST can be = changed to SHOULD.

 

[phil] MUST seems right to me. =

 

 

a token bucket, which

1A tokens are added at the PCN-lower-rate, to a maximum = TB.size

1B tokens are removed equal to the size of the PCN-packet, to a = minimum TB.size=3D0

2 if TB.fill < TB.threshold, then the meter indicates “admission mark” to the Mark function

[Joe] Need to add that = TB.threshold MUST be configured to be less than maximum TB.size and grater than = TB.size=3D0

 

[phil] ok, although I suppose = ‘equal to’ is ok in both cases

 

Note: Step 1A can be triggered by a packet and so can be done at = the same time as Step 1B.

Note: Step 2 can be performed before or after step 1

[Joe] The two notes are not = needed.

 

[phil] they were meant to make it = clear that numbering doesn’t imply must be done in this order (which the = reader might otherwise assume)?

 

If TB.fill < size of the PCN-packet, then the meter = MAY:

a. leave TB.fill unaltered and indicate “admission = mark” to the Mark function

b. set TB.fill =3D 0 and indicate “admission mark” = to the Mark function    

c. set TB.fill =3D 0 and check if TB.fill < TB.threshold and = if it is, then indicate “admission mark” to the Mark function       

Note: Option a is expected to be the simplest to implement. =

[Joe] The above points are not = needed as “1B” states that minimum TB size=3D0, it should not go = negative.

 

[phil] note, if the meter does = choice a, then TB.fill is unaltered. This needs to stated I = think.

 

 

Mark function:

If the meter indicates to “admission mark” a = PCN-packet, then:

[1] this step is REQUIRED, unless [RFC-encoding] standardises an encoding that allows a PCN-packet to be simultaneously “admission marked” and “termination marked”:

If the PCN-packet’s codepoint is already = “termination mark” then it MUST NOT be altered, ie the following step is not performed.

[2] the PCN-packet’s ECN/DSCP fields MUST be set to the = codepoint “admission marked”, as defined in = [RFC-encoding]

[Joe]Reword the Marking function = to as:

The “admission = marking” is only applied to unmarked PCN packets.

As note could state that = “termination marked” packets MUST NOT be remarked, but I believe it is not = needed as there may be networks that only do admission  control and not flow termination.

 

[phil] however, if the encoding = chosen allows a pkt to be both ‘adm marked’ & ‘termin = marked’ then your check is unnecessary. This is what the text tries to say. = However, I don’t think this section should be discussed too much at the moment, as = hopefully we reach rapid convergence on the encoding option & then we know better = what to write here.

 

 

we could also add an example = algorithm, such as that in http://www.ietf.org/internet-drafts/draft-charny-pcn-= comparison-00.txt Fig 10.1 on page 21.

 

Comments?

phil

=00 ------_=_NextPart_001_01C87DE8.B642A20C-- --===============1332211516== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============1332211516==-- From pcn-bounces@ietf.org Tue Mar 4 03:25:11 2008 Return-Path: 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 8A7FF28C63A; Tue, 4 Mar 2008 03:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.678 X-Spam-Level: X-Spam-Status: No, score=0.678 tagged_above=-999 required=5 tests=[AWL=-1.086, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=1, J_CHICKENPOX_24=0.6, J_CHICKENPOX_29=0.6, MIME_HTML_MOSTLY=0.001, 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 bU5eClrPBVQa; Tue, 4 Mar 2008 03:25:05 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC5B328C64A; Tue, 4 Mar 2008 03:24:52 -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 836933A697D for ; Tue, 4 Mar 2008 03:24:51 -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 STndRfPy7Mt3 for ; Tue, 4 Mar 2008 03:24:46 -0800 (PST) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 074DE28C6D5 for ; Tue, 4 Mar 2008 03:23:33 -0800 (PST) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Tue, 4 Mar 2008 12:23:13 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Mar 2008 12:23:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 4 Mar 2008 12:24:21 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CE0B756@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34628@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN admission marking algorithm - consensus? Thread-Index: Ach3oGcLq+pZ9d/iRpmXKw/VF5utxgA+v1bgACTdRVABLZ1oMAAAO77QAADllVA= References: <75A199C5D243C741BF3D3F1EBCEF9BA503B34627@E03MVZ1-UKDY.domain1.systemhost.net> <75A199C5D243C741BF3D3F1EBCEF9BA503B34628@E03MVZ1-UKDY.domain1.systemhost.net> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 04 Mar 2008 11:23:10.0963 (UTC) FILETIME=[21019430:01C87DEA] Cc: pcn@ietf.org Subject: Re: [PCN] PCN admission marking algorithm - consensus? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0678396065==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0678396065== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C87DEA.20B2406C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C87DEA.20B2406C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Phil, =20 I agree to you to requiring "MUST" for the following two fundamental PCN = functions: =20 A packet classified as a PCN-packet MUST be metered as follows.=20 [Joe] change MUST to MAY in above as this is only an example. =20 [phil] disagree. If we make this a MAY it means the PCN standard doesn't = require any particular marking behaviour!! =20 The interface MUST have: [1] a configured bit rate, termed PCN-lower-rate [2] a meter for PCN-packets, which MUST have the following behaviour: =20 But I agree with Joe that the example should be separated from the = requirements. =20 Regards, =20 Rudiger =20 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = philip.eardley@bt.com Sent: Tuesday, March 04, 2008 12:13 PM To: pcn@ietf.org Subject: Re: [PCN] PCN admission marking algorithm - consensus? =09 =09 Here are some replies to some comments that Joe sent me (Joe replied to = a draft version I sent directly, but all the comments below still apply = to the version I sent to list) (hope that's ok joe). =20 Thanks phil =20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = philip.eardley@bt.com Sent: 27 February 2008 11:02 To: pcn@ietf.org Subject: [PCN] PCN admission marking algorithm - consensus? =20 I think we have consensus on the admission marking behaviour. This is a = first attempt to capture that in Stds language, is it any use? =20 =20 If an interface of the PCN-domain performs PCN Admission Marking then = it performs three functions, which are outlined in = draft-ietf-pcn-architecture as follows: =20 o Packet classify - decide whether an incoming packet is a PCN- packet or not. Another PCN WG document will specify encoding, using the DSCP and/or ECN fields. =20 o PCN-meter - measure the 'amount of PCN-traffic'. The measurement is made as an aggregate of all PCN-packets, and not per flow. =20 o PCN-mark - algorithms determine whether to PCN-mark PCN-packets and what packet encoding is used (as specified in another PCN WG document). =20 These functions are now described in more detail. Note: The PCN-node MAY implement these three functions on either its = ingoing or outgoing interfaces. The same choice MUST be made for every = PCN-node in one PCN-domain.=20 [Joe] Suggest rewording "The same choice MUST be made for every = PCN-node in one PCN-domain" to something like "The PCN-domain SHOULD be = configured so that all links within the PCN-domain support the PCN = function.=20 The work MUST is to strong. I believe it is OK to have a node that does = not support the PCN function as long as other nodes provide the PCN = functions, i.e., a node may provide PCN-function on both ingoing and = outgoing interfaces to compensate for a node that does not provide PCN = function.=20 My other issue is really a chart issue, if inside the PCN-domain an = operator configures his network in such a way that there are links that = can not be congested why would he need PCN-function on those links? =20 [phil] the architecture draft says "However if it's known that an interface cannot become pre-congested then it's not strictly necessary for it to be capable of PCN-marking. But this must be known even in unusual circumstances, eg after the failure of some links. I suppose this makes it a SHOULD =20 =20 Classify function: If a packet's ECN/DSCP fields have the value PCN, as defined in = [RFC-encoding], then it MUST be classified as a PCN-packet. If a packet's ECN/DSCP fields do not have the value PCN, as defined in = [RFC-encoding], then it MUST NOT be classified as a PCN-packet. [Joe] I would suggest that the second line be reword to say that "all = other packets are not PCN-packets". =20 [PHIL] Actually this needs to be updated, since we may need to take = account of [quoting arch draft]: There may be traffic that is more important than PCN, perhaps a particular application or an operator's control messages. A PCN- node may dedicate capacity to such traffic or priority schedule = it over PCN. In the latter case its traffic needs to contribute to the PCN meters. =20 =20 Meter function: Note: The meter is described as a 'token bucket with threshold', = however the implementation is not standardised. For example, it could = equally well be implemented as a virtual queue (which operates with = negative tokens). =20 A packet classified as a PCN-packet MUST be metered as follows.=20 [Joe] change MUST to MAY in above as this is only an example. =20 [phil] disagree. If we make this a MAY it means the PCN standard = doesn't require any particular marking behaviour!! =20 The interface MUST have: [1] a configured bit rate, termed PCN-lower-rate [2] a meter for PCN-packets, which MUST have the following behaviour: [Joe] The above MUST can be changed to SHOULD.=20 =20 [phil] MUST seems right to me.=20 =20 =20 a token bucket, which=20 1A tokens are added at the PCN-lower-rate, to a maximum TB.size 1B tokens are removed equal to the size of the PCN-packet, to a minimum = TB.size=3D0 2 if TB.fill < TB.threshold, then the meter indicates "admission mark" = to the Mark function [Joe] Need to add that TB.threshold MUST be configured to be less than = maximum TB.size and grater than TB.size=3D0 =20 [phil] ok, although I suppose 'equal to' is ok in both cases =20 Note: Step 1A can be triggered by a packet and so can be done at the = same time as Step 1B. Note: Step 2 can be performed before or after step 1 [Joe] The two notes are not needed. =20 [phil] they were meant to make it clear that numbering doesn't imply = must be done in this order (which the reader might otherwise assume)? =20 If TB.fill < size of the PCN-packet, then the meter MAY: a. leave TB.fill unaltered and indicate "admission mark" to the Mark = function b. set TB.fill =3D 0 and indicate "admission mark" to the Mark function = =20 c. set TB.fill =3D 0 and check if TB.fill < TB.threshold and if it is, = then indicate "admission mark" to the Mark function =20 Note: Option a is expected to be the simplest to implement.=20 [Joe] The above points are not needed as "1B" states that minimum TB = size=3D0, it should not go negative. =20 [phil] note, if the meter does choice a, then TB.fill is unaltered. = This needs to stated I think. =20 =20 Mark function: If the meter indicates to "admission mark" a PCN-packet, then: [1] this step is REQUIRED, unless [RFC-encoding] standardises an = encoding that allows a PCN-packet to be simultaneously "admission = marked" and "termination marked": If the PCN-packet's codepoint is already "termination mark" then it = MUST NOT be altered, ie the following step is not performed. [2] the PCN-packet's ECN/DSCP fields MUST be set to the codepoint = "admission marked", as defined in [RFC-encoding] [Joe]Reword the Marking function to as: The "admission marking" is only applied to unmarked PCN packets. As note could state that "termination marked" packets MUST NOT be = remarked, but I believe it is not needed as there may be networks that = only do admission control and not flow termination.=20 =20 [phil] however, if the encoding chosen allows a pkt to be both 'adm = marked' & 'termin marked' then your check is unnecessary. This is what = the text tries to say. However, I don't think this section should be = discussed too much at the moment, as hopefully we reach rapid = convergence on the encoding option & then we know better what to write = here.=20 =20 =20 we could also add an example algorithm, such as that in = http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt = Fig 10.1 = on page 21. =20 Comments? phil ------_=_NextPart_001_01C87DEA.20B2406C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Phil,
 
I agree to you to requiring "MUST" for the = following two=20 fundamental PCN functions:
 

A packet classified as a PCN-packet MUST be = metered as=20 follows.

[Joe] change MUST to MAY in above = as this=20 is only an example.

 

[phil] = disagree. If we=20 make this a MAY it means the PCN standard doesn=92t require any = particular marking=20 behaviour!!

 

The interface MUST have:

[1] a configured bit rate, termed=20 PCN-lower-rate

[2] a meter for PCN-packets, which MUST have = the=20 following behaviour:

 
But I=20 agree with Joe that the example should be separated from the=20 requirements.
 
Regards,
 
Rudiger

 
From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of=20 philip.eardley@bt.com
Sent: Tuesday, March 04, 2008 = 12:13=20 PM
To: pcn@ietf.org
Subject: Re: [PCN] PCN = admission=20 marking algorithm - consensus?

Here are = some replies=20 to some comments that Joe sent me (Joe replied to a draft version I = sent=20 directly, but all the comments below still apply to the version I sent = to=20 list) (hope that=92s ok joe).

 

Thanks

phil

 

-----Original=20 Message-----
From:=20 pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of=20 philip.eardley@bt.com
Sent: 27 February 2008 = 11:02
To: pcn@ietf.org
Subject: [PCN] PCN admission = marking=20 algorithm - consensus?

 

I think we = have=20 consensus on the admission marking behaviour. This is a first attempt = to=20 capture that in Stds language, is it any use?

 

 

If an =
interface of the PCN-domain performs PCN Admission Marking then it =
performs three functions, which are outlined in =
draft-ietf-pcn-architecture as follows:
 
   o  Packet =
classify - decide whether an incoming packet is a =
PCN-
      packet or =
not.  Another PCN WG document will specify =
encoding,
      =
using the DSCP and/or ECN fields.
 
   o  PCN-meter =
- measure the 'amount of PCN-traffic'.  The =
measurement
      =
is made as an aggregate of all PCN-packets, and not per =
flow.
 
   o  PCN-mark - algorithms determine whether to =
PCN-mark PCN-packets
      =
and what packet encoding is used (as specified in another PCN =
WG
      =
document).

 

These functions are now described in more=20 detail.

Note: The PCN-node MAY implement these three = functions=20 on either its ingoing or outgoing interfaces. The same choice MUST be = made for=20 every PCN-node in one PCN-domain.

[Joe] = Suggest=20 rewording =93The same choice MUST be made for every PCN-node in one = PCN-domain=94=20 to something like =93The PCN-domain SHOULD be configured so that all = links=20 within the PCN-domain support the PCN function.

The work = MUST is to=20 strong. I believe it is OK to have a node that does not support the = PCN=20 function as long as other nodes provide the PCN functions, i.e., a = node may=20 provide PCN-function on both ingoing and outgoing interfaces to = compensate for=20 a node that does not provide PCN function.

My other = issue is=20 really a chart issue, if inside the PCN-domain an operator configures = his=20 network in such a way that there are links that can not be congested = why would=20 he need PCN-function on those links?

 

[phil] the architecture draft says =93However if =
it's known
   that an interface cannot become =
pre-congested then it's not strictly
   necessary for it to be capable of PCN-marking.  =
But this must be
   known even in =
unusual circumstances, eg after the failure of =
some
   links.

I suppose = this makes=20 it a SHOULD

 

 

Classify function:

If a packet=92s ECN/DSCP fields have the = value PCN, as=20 defined in [RFC-encoding], then it MUST be classified as a=20 PCN-packet.

If a packet=92s ECN/DSCP fields do not have = the value=20 PCN, as defined in [RFC-encoding], then it MUST NOT be classified as a = PCN-packet.

[Joe] I would suggest that the = second=20 line be reword to say that =93all other packets are not=20 PCN-packets=94.

 

[PHIL] = Actually this=20 needs to be updated, since we may need to take account of [quoting = arch=20 draft]:

There may be traffic that is =
more important than PCN, perhaps a
      particular application or an =
operator's control messages.  A PCN-
      node may dedicate capacity to such =
traffic or priority schedule it
      over PCN.  In the latter case =
its traffic needs to contribute to
      the PCN meters.

 

 

Meter function:

Note: The meter is described as a =91token = bucket with=20 threshold=92, however the implementation is not standardised. For = example, it=20 could equally well be implemented as a virtual queue (which operates = with=20 negative tokens).

 

A packet classified as a PCN-packet MUST be = metered as=20 follows.

[Joe] change MUST to MAY in = above as this=20 is only an example.

 

[phil] = disagree. If=20 we make this a MAY it means the PCN standard doesn=92t require any = particular=20 marking behaviour!!

 

The interface MUST have:

[1] a configured bit rate, termed=20 PCN-lower-rate

[2] a meter for PCN-packets, which MUST have = the=20 following behaviour:

[Joe] The above MUST can be = changed to=20 SHOULD.

 

[phil] MUST = seems=20 right to me.

 

 

a token bucket, which

1A tokens are added at the PCN-lower-rate, = to a=20 maximum TB.size

1B tokens are removed equal to the size of = the=20 PCN-packet, to a minimum TB.size=3D0

2 if TB.fill < TB.threshold, then the = meter=20 indicates =93admission mark=94 to the Mark function

[Joe] Need to add that = TB.threshold MUST=20 be configured to be less than maximum TB.size and grater than=20 TB.size=3D0

 

[phil] ok, = although I=20 suppose =91equal to=92 is ok in both cases

 

Note: Step 1A can be triggered by a packet = and so can=20 be done at the same time as Step 1B.

Note: Step 2 can be performed before or after = step=20 1

[Joe] The two notes are not=20 needed.

 

[phil] they = were=20 meant to make it clear that numbering doesn=92t imply must be done in = this order=20 (which the reader might otherwise assume)?

 

If TB.fill < size of the PCN-packet, then = the meter=20 MAY:

a. leave TB.fill unaltered and indicate = =93admission=20 mark=94 to the Mark function

b. set TB.fill =3D 0 and indicate = =93admission mark=94 to=20 the Mark function    

c. set TB.fill =3D 0 and check if TB.fill = <=20 TB.threshold and if it is, then indicate =93admission mark=94 to the = Mark=20 function       

Note: Option a is expected to be the = simplest to=20 implement.

[Joe] The above points are not = needed as=20 =931B=94 states that minimum TB size=3D0, it should not go=20 negative.

 

[phil] = note, if the=20 meter does choice a, then TB.fill is unaltered. This needs to stated I = think.

 

 

Mark function:

If the meter indicates to =93admission = mark=94 a=20 PCN-packet, then:

[1] this step is REQUIRED, unless = [RFC-encoding]=20 standardises an encoding that allows a PCN-packet to be simultaneously = =93admission marked=94 and =93termination marked=94:

If the PCN-packet=92s codepoint is already = =93termination=20 mark=94 then it MUST NOT be altered, ie the following step is not=20 performed.

[2] the PCN-packet=92s ECN/DSCP fields MUST = be set to=20 the codepoint =93admission marked=94, as defined in=20 [RFC-encoding]

[Joe]Reword the Marking = function to=20 as:

The =93admission marking=94 is = only applied=20 to unmarked PCN packets.

As note could state that = =93termination=20 marked=94 packets MUST NOT be remarked, but I believe it is not needed = as there=20 may be networks that only do admission  control and not flow = termination.=20

 

[phil] = however, if=20 the encoding chosen allows a pkt to be both =91adm marked=92 & = =91termin marked=92=20 then your check is unnecessary. This is what the text tries to say. = However, I=20 don=92t think this section should be discussed too much at the moment, = as=20 hopefully we reach rapid convergence on the encoding option & then = we know=20 better what to write here.

 

 

we could = also add an=20 example algorithm, such as that in http://www.ietf.org/internet-drafts/draft-charny-pcn-= comparison-00.txt=20 Fig 10.1 on page 21.

 

Comments?

phil

------_=_NextPart_001_01C87DEA.20B2406C-- --===============0678396065== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0678396065==-- From pcn-bounces@ietf.org Tue Mar 4 09:21:54 2008 Return-Path: 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 E5F9628C313; Tue, 4 Mar 2008 09:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[AWL=0.436, 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 VvXVMHaUcsp2; Tue, 4 Mar 2008 09:21:49 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 815F528C4F5; Tue, 4 Mar 2008 09:21:27 -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 894E028C539 for ; Tue, 4 Mar 2008 09:21:25 -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 FKGBNMveLgnx for ; Tue, 4 Mar 2008 09:21:19 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id BC8D528C5DC for ; Tue, 4 Mar 2008 09:18:43 -0800 (PST) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.64]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Mar 2008 17:18:33 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 4 Mar 2008 17:18:49 -0000 Message-ID: In-Reply-To: <1B6169C658325341A3B8066E23919E1CE0B104@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: RE: PCN encoding option Thread-Index: AchzroZ862SQI1gCRgmjiFy0a2+oIAIE+InwAFCx8SAARV9q0A== From: To: , , X-OriginalArrivalTime: 04 Mar 2008 17:18:33.0680 (UTC) FILETIME=[C655FD00:01C87E1B] Cc: pcn@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org 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, Networks Research Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Geib, Ruediger > Sent: 03 March 2008 08:09 > To: babiarz@nortel.com; menth@informatik.uni-wuerzburg.de > Cc: pcn@ietf.org > 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: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, 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 > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 4 23:35:43 2008 Return-Path: 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 288F828C6B3; Tue, 4 Mar 2008 23:35:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.399 X-Spam-Level: X-Spam-Status: No, score=-0.399 tagged_above=-999 required=5 tests=[AWL=0.038, 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 LzuqcAkwMp82; Tue, 4 Mar 2008 23:35:41 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 050FA28C622; Tue, 4 Mar 2008 23:35:41 -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 55C2D3A698F for ; Tue, 4 Mar 2008 23:35:39 -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 DSjADe56zykb for ; Tue, 4 Mar 2008 23:35:18 -0800 (PST) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 2E0CC28C622 for ; Tue, 4 Mar 2008 23:35:18 -0800 (PST) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Wed, 5 Mar 2008 08:35:07 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Mar 2008 08:35:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Mar 2008 08:36:17 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CE87641@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] FW: RE: PCN encoding option Thread-Index: AchzroZ862SQI1gCRgmjiFy0a2+oIAIE+InwAFCx8SAARV9q0AAd1dXg References: <1B6169C658325341A3B8066E23919E1CE0B104@S4DE8PSAANK.mitte.t-com.de> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 05 Mar 2008 07:35:07.0168 (UTC) FILETIME=[6F3DEA00:01C87E93] Cc: pcn@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org 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: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] = | Sent: Tuesday, March 04, 2008 6:19 PM | To: Geib, R=FCdiger; babiarz@nortel.com; = | menth@informatik.uni-wuerzburg.de | Cc: pcn@ietf.org | 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, Networks Research = | Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 = | 1473 648734 = | = | = | > -----Original Message----- | > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On = | Behalf Of = | > Geib, Ruediger | > Sent: 03 March 2008 08:09 | > To: babiarz@nortel.com; menth@informatik.uni-wuerzburg.de | > Cc: pcn@ietf.org | > 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: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 =3D 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, 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 | > = | = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 5 05:18:33 2008 Return-Path: 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 2F4A528C2A5; Wed, 5 Mar 2008 05:18:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.392 X-Spam-Level: * X-Spam-Status: No, score=1.392 tagged_above=-999 required=5 tests=[AWL=-0.767, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_24=0.6, J_CHICKENPOX_29=0.6, MIME_QP_LONG_LINE=1.396, 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 Szt6mLnjS5rl; Wed, 5 Mar 2008 05:18:31 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D331F3A6E3B; Wed, 5 Mar 2008 05:18:30 -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 0488D3A6EBD for ; Wed, 5 Mar 2008 05:18:29 -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 fLA3FH31ZyUu for ; Wed, 5 Mar 2008 05:18:27 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 8720B3A6EF6 for ; Wed, 5 Mar 2008 05:18:08 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id E5022A0685; Wed, 5 Mar 2008 14:17:57 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id D7D83A066F; Wed, 5 Mar 2008 14:17:57 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id A4098A066D; Wed, 5 Mar 2008 14:17:56 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m25DHuV03271; Wed, 5 Mar 2008 14:17:56 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 681D5C88DA; Wed, 5 Mar 2008 14:17:56 +0100 (CET) Message-ID: <47CE9D44.5060801@informatik.uni-wuerzburg.de> Date: Wed, 05 Mar 2008 14:16:52 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: philip.eardley@bt.com, pcn References: <75A199C5D243C741BF3D3F1EBCEF9BA503B34628@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34628@E03MVZ1-UKDY.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Subject: Re: [PCN] PCN admission marking algorithm - consensus? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi, I would like to briefly comment some issues raised along this thread. = Possibly there were also some misunderstandings. There was the debate concerning whether the metering and marking = function has to be done at the head end or tail end of a link. This has = actually no impact on the obtained markings. Therefore, I do not = understand why this must be standardized and the configuration must be = consistent. If we say the location must be the same for all links of a = domain, this is not enough for inter-operability when vendor A = implements all function for the head end and vendor B for the tail end = of a link. Therefore, we should provide either more flexibility or = specify exactly where to implement the functions. The question whether packet metering and marking is done before or after = packet loss occurs has more impact on the correctness of PCN than the = above aspect. For the case of termination marking see 3.2 of http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth07-PCN-Eva= l.pdf Therefore, standardizing this issue could avoid different behavior of = different equipment in challenging situations. However, this possibly = reduces implementation options for vendors. Regards, Michael philip.eardley@bt.com wrote: > > Here are some replies to some comments that Joe sent me (Joe replied = > to a draft version I sent directly, but all the comments below still = > apply to the version I sent to list) (hope that=92s ok joe). > > Thanks > > phil > > -----Original Message----- > *From:* pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] *On Behalf = > Of *philip.eardley@bt.com > *Sent:* 27 February 2008 11:02 > *To:* pcn@ietf.org > *Subject:* [PCN] PCN admission marking algorithm - consensus? > > I think we have consensus on the admission marking behaviour. This is = > a first attempt to capture that in Stds language, is it any use? > > If an interface of the PCN-domain performs PCN Admission Marking then it = performs three functions, which are outlined in draft-ietf-pcn-architecture= as follows: > = > o Packet classify - decide whether an incoming packet is a PCN- > packet or not. Another PCN WG document will specify encoding, > using the DSCP and/or ECN fields. > = > o PCN-meter - measure the 'amount of PCN-traffic'. The measurement > is made as an aggregate of all PCN-packets, and not per flow. > = > o PCN-mark - algorithms determine whether to PCN-mark PCN-packets > and what packet encoding is used (as specified in another PCN WG > document). > > These functions are now described in more detail. > > Note: The PCN-node MAY implement these three functions on either its = > ingoing or outgoing interfaces. The same choice MUST be made for every = > PCN-node in one PCN-domain. > > [Joe] Suggest rewording =93The same choice MUST be made for every = > PCN-node in one PCN-domain=94 to something like =93The PCN-domain SHOULD = > be configured so that all links within the PCN-domain support the PCN = > function. > > The work MUST is to strong. I believe it is OK to have a node that = > does not support the PCN function as long as other nodes provide the = > PCN functions, i.e., a node may provide PCN-function on both ingoing = > and outgoing interfaces to compensate for a node that does not provide = > PCN function. > > My other issue is really a chart issue, if inside the PCN-domain an = > operator configures his network in such a way that there are links = > that can not be congested why would he need PCN-function on those links? > > [phil] the architecture draft says =93However if it's known > that an interface cannot become pre-congested then it's not strictly > necessary for it to be capable of PCN-marking. But this must be > known even in unusual circumstances, eg after the failure of some > links. > > I suppose this makes it a SHOULD > > Classify function: > > If a packet=92s ECN/DSCP fields have the value PCN, as defined in = > [RFC-encoding], then it MUST be classified as a PCN-packet. > > If a packet=92s ECN/DSCP fields do not have the value PCN, as defined in = > [RFC-encoding], then it MUST NOT be classified as a PCN-packet. > > [Joe] I would suggest that the second line be reword to say that =93all = > other packets are not PCN-packets=94. > > [PHIL] Actually this needs to be updated, since we may need to take = > account of [quoting arch draft]: > > There may be traffic that is more important than PCN, perhaps a > particular application or an operator's control messages. A PCN- > node may dedicate capacity to such traffic or priority schedule it > over PCN. In the latter case its traffic needs to contribute to > the PCN meters. > > Meter function: > > Note: The meter is described as a =91token bucket with threshold=92, = > however the implementation is not standardised. For example, it could = > equally well be implemented as a virtual queue (which operates with = > negative tokens). > > A packet classified as a PCN-packet MUST be metered as follows. > > [Joe] change MUST to MAY in above as this is only an example. > > [phil] disagree. If we make this a MAY it means the PCN standard = > doesn=92t require any particular marking behaviour!! > > The interface MUST have: > > [1] a configured bit rate, termed PCN-lower-rate > > [2] a meter for PCN-packets, which MUST have the following behaviour: > > [Joe] The above MUST can be changed to SHOULD. > > [phil] MUST seems right to me. > > a token bucket, which > > 1A tokens are added at the PCN-lower-rate, to a maximum TB.size > > 1B tokens are removed equal to the size of the PCN-packet, to a = > minimum TB.size=3D0 > > 2 if TB.fill < TB.threshold, then the meter indicates =93admission mark= =94 = > to the Mark function > > [Joe] Need to add that TB.threshold MUST be configured to be less than = > maximum TB.size and grater than TB.size=3D0 > > [phil] ok, although I suppose =91equal to=92 is ok in both cases > > Note: Step 1A can be triggered by a packet and so can be done at the = > same time as Step 1B. > > Note: Step 2 can be performed before or after step 1 > > [Joe] The two notes are not needed. > > [phil] they were meant to make it clear that numbering doesn=92t imply = > must be done in this order (which the reader might otherwise assume)? > > If TB.fill < size of the PCN-packet, then the meter MAY: > > a. leave TB.fill unaltered and indicate =93admission mark=94 to the Mark = > function > > b. set TB.fill =3D 0 and indicate =93admission mark=94 to the Mark functi= on > > c. set TB.fill =3D 0 and check if TB.fill < TB.threshold and if it is, = > then indicate =93admission mark=94 to the Mark function > > Note: Option a is expected to be the simplest to implement. > > [Joe] The above points are not needed as =931B=94 states that minimum TB = > size=3D0, it should not go negative. > > [phil] note, if the meter does choice a, then TB.fill is unaltered. = > This needs to stated I think. > > Mark function: > > If the meter indicates to =93admission mark=94 a PCN-packet, then: > > [1] this step is REQUIRED, unless [RFC-encoding] standardises an = > encoding that allows a PCN-packet to be simultaneously =93admission = > marked=94 and =93termination marked=94: > > If the PCN-packet=92s codepoint is already =93termination mark=94 then it = > MUST NOT be altered, ie the following step is not performed. > > [2] the PCN-packet=92s ECN/DSCP fields MUST be set to the codepoint = > =93admission marked=94, as defined in [RFC-encoding] > > [Joe]Reword the Marking function to as: > > The =93admission marking=94 is only applied to unmarked PCN packets. > > As note could state that =93termination marked=94 packets MUST NOT be = > remarked, but I believe it is not needed as there may be networks that = > only do admission control and not flow termination. > > [phil] however, if the encoding chosen allows a pkt to be both =91adm = > marked=92 & =91termin marked=92 then your check is unnecessary. This is w= hat = > the text tries to say. However, I don=92t think this section should be = > discussed too much at the moment, as hopefully we reach rapid = > convergence on the encoding option & then we know better what to write = > here. > > we could also add an example algorithm, such as that in = > http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt = > Fig 10.1 = > = > on page 21. > > Comments? > > phil > > ------------------------------------------------------------------------ > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > = -- = 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 From pcn-bounces@ietf.org Wed Mar 5 05:41:35 2008 Return-Path: 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 49B6A28C73D; Wed, 5 Mar 2008 05:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.573 X-Spam-Level: X-Spam-Status: No, score=0.573 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_24=0.6, J_CHICKENPOX_29=0.6, J_CHICKENPOX_72=0.6, 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 B15oYE+miuy7; Wed, 5 Mar 2008 05:41:33 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6761B28C76E; Wed, 5 Mar 2008 05:41:17 -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 DF0713A6EBD for ; Wed, 5 Mar 2008 05:41:15 -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 koRxW7kK8EPt for ; Wed, 5 Mar 2008 05:41:14 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id E8FD128C794 for ; Wed, 5 Mar 2008 05:38:10 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Mar 2008 13:38:00 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Mar 2008 13:37:58 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B3463F@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <47CE9D44.5060801@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN admission marking algorithm - consensus? Thread-Index: Ach+w1dRsRGzciKfQI+vaw80RvRUTwAAmc/A From: To: , X-OriginalArrivalTime: 05 Mar 2008 13:38:00.0002 (UTC) FILETIME=[20DCBA20:01C87EC6] Subject: Re: [PCN] PCN admission marking algorithm - consensus? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: 05 March 2008 13:17 > To: Eardley,PL,Philip,CXR9 R; pcn > Subject: Re: [PCN] PCN admission marking algorithm - consensus? > > Hi, > > I would like to briefly comment some issues raised along this thread. > Possibly there were also some misunderstandings. > > There was the debate concerning whether the metering and marking > function has to be done at the head end or tail end of a link. This has > actually no impact on the obtained markings. Therefore, I do not > understand why this must be standardized and the configuration must be > consistent. If we say the location must be the same for all links of a > domain, this is not enough for inter-operability when vendor A > implements all function for the head end and vendor B for the tail end > of a link. Therefore, we should provide either more flexibility or > specify exactly where to implement the functions. Yes, I think this is sensible. Does anyone have preferences (Joe has said he prefers the former) > > The question whether packet metering and marking is done before or after > packet loss occurs has more impact on the correctness of PCN than the > above aspect. For the case of termination marking see 3.2 of > http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth07-PCN- > Eval.pdf I think I remember from 'corridor' discussions at last ietf that the router needs to ensure that it first drops pkts (if necessary) and then marks them. Then everything works as expected. If I got this right, then this seems a good thing to add. Thanks phil > Therefore, standardizing this issue could avoid different behavior of > different equipment in challenging situations. However, this possibly > reduces implementation options for vendors. > > Regards, > > Michael > > > philip.eardley@bt.com wrote: > > > > Here are some replies to some comments that Joe sent me (Joe replied > > to a draft version I sent directly, but all the comments below still > > apply to the version I sent to list) (hope that's ok joe). > > > > Thanks > > > > phil > > > > -----Original Message----- > > *From:* pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] *On Behalf > > Of *philip.eardley@bt.com > > *Sent:* 27 February 2008 11:02 > > *To:* pcn@ietf.org > > *Subject:* [PCN] PCN admission marking algorithm - consensus? > > > > I think we have consensus on the admission marking behaviour. This is > > a first attempt to capture that in Stds language, is it any use? > > > > If an interface of the PCN-domain performs PCN Admission Marking then it > performs three functions, which are outlined in draft-ietf-pcn- > architecture as follows: > > > > o Packet classify - decide whether an incoming packet is a PCN- > > packet or not. Another PCN WG document will specify encoding, > > using the DSCP and/or ECN fields. > > > > o PCN-meter - measure the 'amount of PCN-traffic'. The measurement > > is made as an aggregate of all PCN-packets, and not per flow. > > > > o PCN-mark - algorithms determine whether to PCN-mark PCN-packets > > and what packet encoding is used (as specified in another PCN WG > > document). > > > > These functions are now described in more detail. > > > > Note: The PCN-node MAY implement these three functions on either its > > ingoing or outgoing interfaces. The same choice MUST be made for every > > PCN-node in one PCN-domain. > > > > [Joe] Suggest rewording "The same choice MUST be made for every > > PCN-node in one PCN-domain" to something like "The PCN-domain SHOULD > > be configured so that all links within the PCN-domain support the PCN > > function. > > > > The work MUST is to strong. I believe it is OK to have a node that > > does not support the PCN function as long as other nodes provide the > > PCN functions, i.e., a node may provide PCN-function on both ingoing > > and outgoing interfaces to compensate for a node that does not provide > > PCN function. > > > > My other issue is really a chart issue, if inside the PCN-domain an > > operator configures his network in such a way that there are links > > that can not be congested why would he need PCN-function on those links? > > > > [phil] the architecture draft says "However if it's known > > that an interface cannot become pre-congested then it's not strictly > > necessary for it to be capable of PCN-marking. But this must be > > known even in unusual circumstances, eg after the failure of some > > links. > > > > I suppose this makes it a SHOULD > > > > Classify function: > > > > If a packet's ECN/DSCP fields have the value PCN, as defined in > > [RFC-encoding], then it MUST be classified as a PCN-packet. > > > > If a packet's ECN/DSCP fields do not have the value PCN, as defined in > > [RFC-encoding], then it MUST NOT be classified as a PCN-packet. > > > > [Joe] I would suggest that the second line be reword to say that "all > > other packets are not PCN-packets". > > > > [PHIL] Actually this needs to be updated, since we may need to take > > account of [quoting arch draft]: > > > > There may be traffic that is more important than PCN, perhaps a > > particular application or an operator's control messages. A PCN- > > node may dedicate capacity to such traffic or priority schedule it > > over PCN. In the latter case its traffic needs to contribute to > > the PCN meters. > > > > Meter function: > > > > Note: The meter is described as a 'token bucket with threshold', > > however the implementation is not standardised. For example, it could > > equally well be implemented as a virtual queue (which operates with > > negative tokens). > > > > A packet classified as a PCN-packet MUST be metered as follows. > > > > [Joe] change MUST to MAY in above as this is only an example. > > > > [phil] disagree. If we make this a MAY it means the PCN standard > > doesn't require any particular marking behaviour!! > > > > The interface MUST have: > > > > [1] a configured bit rate, termed PCN-lower-rate > > > > [2] a meter for PCN-packets, which MUST have the following behaviour: > > > > [Joe] The above MUST can be changed to SHOULD. > > > > [phil] MUST seems right to me. > > > > a token bucket, which > > > > 1A tokens are added at the PCN-lower-rate, to a maximum TB.size > > > > 1B tokens are removed equal to the size of the PCN-packet, to a > > minimum TB.size=0 > > > > 2 if TB.fill < TB.threshold, then the meter indicates "admission mark" > > to the Mark function > > > > [Joe] Need to add that TB.threshold MUST be configured to be less than > > maximum TB.size and grater than TB.size=0 > > > > [phil] ok, although I suppose 'equal to' is ok in both cases > > > > Note: Step 1A can be triggered by a packet and so can be done at the > > same time as Step 1B. > > > > Note: Step 2 can be performed before or after step 1 > > > > [Joe] The two notes are not needed. > > > > [phil] they were meant to make it clear that numbering doesn't imply > > must be done in this order (which the reader might otherwise assume)? > > > > If TB.fill < size of the PCN-packet, then the meter MAY: > > > > a. leave TB.fill unaltered and indicate "admission mark" to the Mark > > function > > > > b. set TB.fill = 0 and indicate "admission mark" to the Mark function > > > > c. set TB.fill = 0 and check if TB.fill < TB.threshold and if it is, > > then indicate "admission mark" to the Mark function > > > > Note: Option a is expected to be the simplest to implement. > > > > [Joe] The above points are not needed as "1B" states that minimum TB > > size=0, it should not go negative. > > > > [phil] note, if the meter does choice a, then TB.fill is unaltered. > > This needs to stated I think. > > > > Mark function: > > > > If the meter indicates to "admission mark" a PCN-packet, then: > > > > [1] this step is REQUIRED, unless [RFC-encoding] standardises an > > encoding that allows a PCN-packet to be simultaneously "admission > > marked" and "termination marked": > > > > If the PCN-packet's codepoint is already "termination mark" then it > > MUST NOT be altered, ie the following step is not performed. > > > > [2] the PCN-packet's ECN/DSCP fields MUST be set to the codepoint > > "admission marked", as defined in [RFC-encoding] > > > > [Joe]Reword the Marking function to as: > > > > The "admission marking" is only applied to unmarked PCN packets. > > > > As note could state that "termination marked" packets MUST NOT be > > remarked, but I believe it is not needed as there may be networks that > > only do admission control and not flow termination. > > > > [phil] however, if the encoding chosen allows a pkt to be both 'adm > > marked' & 'termin marked' then your check is unnecessary. This is what > > the text tries to say. However, I don't think this section should be > > discussed too much at the moment, as hopefully we reach rapid > > convergence on the encoding option & then we know better what to write > > here. > > > > we could also add an example algorithm, such as that in > > http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt > > Fig 10.1 > > 00.txt%20Fig%2010.1> > > on page 21. > > > > Comments? > > > > phil > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > > > -- > 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 From pcn-bounces@ietf.org Wed Mar 5 05:51:25 2008 Return-Path: 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 A9FC73A6E3E; Wed, 5 Mar 2008 05:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.015 X-Spam-Level: * X-Spam-Status: No, score=1.015 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_24=0.6, J_CHICKENPOX_29=0.6, J_CHICKENPOX_72=0.6, 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 9HqciOkzh2Ek; Wed, 5 Mar 2008 05:51:24 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CB7E28C76E; Wed, 5 Mar 2008 05:51:24 -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 7712E28C76E for ; Wed, 5 Mar 2008 05:51:23 -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 nVkI+eBFgf7o for ; Wed, 5 Mar 2008 05:51:22 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id A5B9E28C74D for ; Wed, 5 Mar 2008 05:51:21 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 91B42A067B; Wed, 5 Mar 2008 14:51:09 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 85CC5A067A; Wed, 5 Mar 2008 14:51:09 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 511ACA066D; Wed, 5 Mar 2008 14:51:08 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m25Dp8V03620; Wed, 5 Mar 2008 14:51:08 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 1BDF3C8525; Wed, 5 Mar 2008 14:51:08 +0100 (CET) Message-ID: <47CEA50C.9060307@informatik.uni-wuerzburg.de> Date: Wed, 05 Mar 2008 14:50:04 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: philip.eardley@bt.com References: <75A199C5D243C741BF3D3F1EBCEF9BA503B3463F@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B3463F@E03MVZ1-UKDY.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] PCN admission marking algorithm - consensus? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi, philip.eardley@bt.com wrote: > >> -----Original Message----- >> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >> Sent: 05 March 2008 13:17 >> To: Eardley,PL,Philip,CXR9 R; pcn >> Subject: Re: [PCN] PCN admission marking algorithm - consensus? >> >> Hi, >> >> I would like to briefly comment some issues raised along this thread. >> Possibly there were also some misunderstandings. >> >> There was the debate concerning whether the metering and marking >> function has to be done at the head end or tail end of a link. This >> > has > >> actually no impact on the obtained markings. Therefore, I do not >> understand why this must be standardized and the configuration must be >> consistent. If we say the location must be the same for all links of a >> domain, this is not enough for inter-operability when vendor A >> implements all function for the head end and vendor B for the tail end >> of a link. Therefore, we should provide either more flexibility or >> specify exactly where to implement the functions. >> > > Yes, I think this is sensible. Does anyone have preferences (Joe has > said he prefers the former) > As far as I can remember the discussion was the following. If a processor cannot have several meters and markers per outgoing links, which may be implementation-specific, the marking functionality for admission may be implemented on the outgoing link and for termination on incoming links. It can also be done vice-versa. It was discussed as an implementation issue allowing more flexibility depending on existing code. Regards, Michael > >> The question whether packet metering and marking is done before or >> > after > >> packet loss occurs has more impact on the correctness of PCN than the >> above aspect. For the case of termination marking see 3.2 of >> >> > http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth07-PCN- > >> Eval.pdf >> > > I think I remember from 'corridor' discussions at last ietf that the > router needs to ensure that it first drops pkts (if necessary) and then > marks them. Then everything works as expected. If I got this right, then > this seems a good thing to add. > Thanks > phil > > >> Therefore, standardizing this issue could avoid different behavior of >> different equipment in challenging situations. However, this possibly >> reduces implementation options for vendors. >> >> Regards, >> >> Michael >> >> >> philip.eardley@bt.com wrote: >> >>> Here are some replies to some comments that Joe sent me (Joe replied >>> to a draft version I sent directly, but all the comments below still >>> apply to the version I sent to list) (hope that's ok joe). >>> >>> Thanks >>> >>> phil >>> >>> -----Original Message----- >>> *From:* pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] *On >>> > Behalf > >>> Of *philip.eardley@bt.com >>> *Sent:* 27 February 2008 11:02 >>> *To:* pcn@ietf.org >>> *Subject:* [PCN] PCN admission marking algorithm - consensus? >>> >>> I think we have consensus on the admission marking behaviour. This >>> > is > >>> a first attempt to capture that in Stds language, is it any use? >>> >>> If an interface of the PCN-domain performs PCN Admission Marking >>> > then it > >> performs three functions, which are outlined in draft-ietf-pcn- >> architecture as follows: >> >>> o Packet classify - decide whether an incoming packet is a PCN- >>> packet or not. Another PCN WG document will specify encoding, >>> using the DSCP and/or ECN fields. >>> >>> o PCN-meter - measure the 'amount of PCN-traffic'. The >>> > measurement > >>> is made as an aggregate of all PCN-packets, and not per flow. >>> >>> o PCN-mark - algorithms determine whether to PCN-mark >>> > PCN-packets > >>> and what packet encoding is used (as specified in another PCN >>> > WG > >>> document). >>> >>> These functions are now described in more detail. >>> >>> Note: The PCN-node MAY implement these three functions on either its >>> ingoing or outgoing interfaces. The same choice MUST be made for >>> > every > >>> PCN-node in one PCN-domain. >>> >>> [Joe] Suggest rewording "The same choice MUST be made for every >>> PCN-node in one PCN-domain" to something like "The PCN-domain SHOULD >>> be configured so that all links within the PCN-domain support the >>> > PCN > >>> function. >>> >>> The work MUST is to strong. I believe it is OK to have a node that >>> does not support the PCN function as long as other nodes provide the >>> PCN functions, i.e., a node may provide PCN-function on both ingoing >>> and outgoing interfaces to compensate for a node that does not >>> > provide > >>> PCN function. >>> >>> My other issue is really a chart issue, if inside the PCN-domain an >>> operator configures his network in such a way that there are links >>> that can not be congested why would he need PCN-function on those >>> > links? > >>> [phil] the architecture draft says "However if it's known >>> that an interface cannot become pre-congested then it's not >>> > strictly > >>> necessary for it to be capable of PCN-marking. But this must be >>> known even in unusual circumstances, eg after the failure of some >>> links. >>> >>> I suppose this makes it a SHOULD >>> >>> Classify function: >>> >>> If a packet's ECN/DSCP fields have the value PCN, as defined in >>> [RFC-encoding], then it MUST be classified as a PCN-packet. >>> >>> If a packet's ECN/DSCP fields do not have the value PCN, as defined >>> > in > >>> [RFC-encoding], then it MUST NOT be classified as a PCN-packet. >>> >>> [Joe] I would suggest that the second line be reword to say that >>> > "all > >>> other packets are not PCN-packets". >>> >>> [PHIL] Actually this needs to be updated, since we may need to take >>> account of [quoting arch draft]: >>> >>> There may be traffic that is more important than PCN, perhaps a >>> particular application or an operator's control messages. A >>> > PCN- > >>> node may dedicate capacity to such traffic or priority >>> > schedule it > >>> over PCN. In the latter case its traffic needs to contribute >>> > to > >>> the PCN meters. >>> >>> Meter function: >>> >>> Note: The meter is described as a 'token bucket with threshold', >>> however the implementation is not standardised. For example, it >>> > could > >>> equally well be implemented as a virtual queue (which operates with >>> negative tokens). >>> >>> A packet classified as a PCN-packet MUST be metered as follows. >>> >>> [Joe] change MUST to MAY in above as this is only an example. >>> >>> [phil] disagree. If we make this a MAY it means the PCN standard >>> doesn't require any particular marking behaviour!! >>> >>> The interface MUST have: >>> >>> [1] a configured bit rate, termed PCN-lower-rate >>> >>> [2] a meter for PCN-packets, which MUST have the following >>> > behaviour: > >>> [Joe] The above MUST can be changed to SHOULD. >>> >>> [phil] MUST seems right to me. >>> >>> a token bucket, which >>> >>> 1A tokens are added at the PCN-lower-rate, to a maximum TB.size >>> >>> 1B tokens are removed equal to the size of the PCN-packet, to a >>> minimum TB.size=0 >>> >>> 2 if TB.fill < TB.threshold, then the meter indicates "admission >>> > mark" > >>> to the Mark function >>> >>> [Joe] Need to add that TB.threshold MUST be configured to be less >>> > than > >>> maximum TB.size and grater than TB.size=0 >>> >>> [phil] ok, although I suppose 'equal to' is ok in both cases >>> >>> Note: Step 1A can be triggered by a packet and so can be done at the >>> same time as Step 1B. >>> >>> Note: Step 2 can be performed before or after step 1 >>> >>> [Joe] The two notes are not needed. >>> >>> [phil] they were meant to make it clear that numbering doesn't imply >>> must be done in this order (which the reader might otherwise >>> > assume)? > >>> If TB.fill < size of the PCN-packet, then the meter MAY: >>> >>> a. leave TB.fill unaltered and indicate "admission mark" to the Mark >>> function >>> >>> b. set TB.fill = 0 and indicate "admission mark" to the Mark >>> > function > >>> c. set TB.fill = 0 and check if TB.fill < TB.threshold and if it is, >>> then indicate "admission mark" to the Mark function >>> >>> Note: Option a is expected to be the simplest to implement. >>> >>> [Joe] The above points are not needed as "1B" states that minimum TB >>> size=0, it should not go negative. >>> >>> [phil] note, if the meter does choice a, then TB.fill is unaltered. >>> This needs to stated I think. >>> >>> Mark function: >>> >>> If the meter indicates to "admission mark" a PCN-packet, then: >>> >>> [1] this step is REQUIRED, unless [RFC-encoding] standardises an >>> encoding that allows a PCN-packet to be simultaneously "admission >>> marked" and "termination marked": >>> >>> If the PCN-packet's codepoint is already "termination mark" then it >>> MUST NOT be altered, ie the following step is not performed. >>> >>> [2] the PCN-packet's ECN/DSCP fields MUST be set to the codepoint >>> "admission marked", as defined in [RFC-encoding] >>> >>> [Joe]Reword the Marking function to as: >>> >>> The "admission marking" is only applied to unmarked PCN packets. >>> >>> As note could state that "termination marked" packets MUST NOT be >>> remarked, but I believe it is not needed as there may be networks >>> > that > >>> only do admission control and not flow termination. >>> >>> [phil] however, if the encoding chosen allows a pkt to be both 'adm >>> marked' & 'termin marked' then your check is unnecessary. This is >>> > what > >>> the text tries to say. However, I don't think this section should be >>> discussed too much at the moment, as hopefully we reach rapid >>> convergence on the encoding option & then we know better what to >>> > write > >>> here. >>> >>> we could also add an example algorithm, such as that in >>> >>> > http://www.ietf.org/internet-drafts/draft-charny-pcn-comparison-00.txt > >>> Fig 10.1 >>> >> >> 00.txt%20Fig%2010.1> >> >>> on page 21. >>> >>> Comments? >>> >>> phil >>> >>> >>> > ------------------------------------------------------------------------ > >>> _______________________________________________ >>> PCN mailing list >>> PCN@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcn >>> >>> >> -- >> 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 >> -- 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 From pcn-bounces@ietf.org Wed Mar 5 07:26:20 2008 Return-Path: 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 DC2EC28C71E; Wed, 5 Mar 2008 07:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.325 X-Spam-Level: X-Spam-Status: No, score=-0.325 tagged_above=-999 required=5 tests=[AWL=0.112, 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 0zV+WoQUeF2h; Wed, 5 Mar 2008 07:26:19 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA5CE28C799; Wed, 5 Mar 2008 07:26:19 -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 9CD1328C71E for ; Wed, 5 Mar 2008 07:26:18 -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 fSbF+rfvGZjZ for ; Wed, 5 Mar 2008 07:26:17 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 46C7828C5D1 for ; Wed, 5 Mar 2008 07:26:16 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Mar 2008 15:26:06 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 5 Mar 2008 15:26:05 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34641@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <52E7634C-8713-496C-BE3D-B13F04E0B0A7@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-architecture-03 Thread-Index: Ach5IatvK9xCrC+aQI2Mmkc6c8oG6wFpJ3Wg From: To: , X-OriginalArrivalTime: 05 Mar 2008 15:26:06.0545 (UTC) FILETIME=[3B24A410:01C87ED5] Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Lars > Eggert > Sent: 27 February 2008 09:17 > To: ext Geib, Ruediger > Cc: pcn@ietf.org > Subject: Re: [PCN] draft-ietf-pcn-architecture-03 > > Hi, > > On 2008-2-27, at 10:45, ext Geib, Ruediger wrote: > > [Lars] It is important to discuss somewhere that some choices here > > are less > > optimal than others. A good decision-making location is where PCN > > information naturally accumulates, e.g. at the egress. Any > > relocation > > of that decision-making requires additional communication, which > > increases the delay of the control loop and makes the system more > > brittle, because correct operation now requires dependable > > communication between the egress and the decision-making point. I'd > > like to suggest that we attempt to come to consensus on whether we > > can > > focus on a single decision point for PCN. > > > > [RG] The per flow signaling must reside at the ingress by our actual > > specification (see section 1, first bullet point) and to make > > admission > > control work, the egress must signal to the ingress anyway. It is > > (Sentence truncated?) > > I see your point. Thinking about this some more, I believe my comment > was based on a different understanding on something that the > architecture document currently doesn't discuss much, but probably > should: What information is signaled from the egress to the ingress? > > We agree that the egress looks at the volume of PCN marks compared to > the volume of total PCN traffic to determine the level of congestion > on an ingress-egress pair. The ingress then admits or terminates flows > in a way that is somehow based on that information. But what gets > signaled from egress to ingress? Is it some sort of load indication? > Or is it a desired behavior, i.e., "stop admit" or "start preempt"? Or > something else? > how about the following for admission ctrl: - the egress signals to the ingress "admit" or "block" on a per flow basis. - the egress bases this decision on the level of congestion on the ingress-egress-aggregate, using an EWMA or similar - the egress has been told what the "threshold" level of congestion is (ie threshold for admit vs block decision). This could be a signalling msg from the ingress of some configuration parameter. - if there's been no traffic from this ingress recently, then the "level of congestion" is based simply on whether this first pkt (which is the flow adm request msg) is marked or not. (those who believe that the marking of a single pkt contains as much info as the level of congestion (= markings of lots of pkts) simply set their EWMA weight to 1.) - the ingress abides by the egress signal to admit or block, unless it has to over-ride for some good reason eg perhaps instructed by management system to block all calls at the moment. - the above doesn't allow an approach where the egress signals to the ingress "admit (/block) for x secs, unless I tell you otherwise". (Michael has mentioned this approach, although for me it's rather difference in terms of performance implications on system reaction time, impact of lost msgs etc.) - there's an implication in the above that we indeed have a msg from the ingress to the egress. Is this reasonable assumption? for termination we have 2 quite different approaches (measuring rates vs EMFT), so convergence here is trickier. Thanks, phil > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 5 08:35:21 2008 Return-Path: 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 7634628C7BE; Wed, 5 Mar 2008 08:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.119 X-Spam-Level: X-Spam-Status: No, score=0.119 tagged_above=-999 required=5 tests=[AWL=0.556, 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 URMyii+yKvWy; Wed, 5 Mar 2008 08:35:20 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 554D428C77C; Wed, 5 Mar 2008 08:35:20 -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 76B2028C737 for ; Wed, 5 Mar 2008 08:35:18 -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 aNzbIrmOlpTV for ; Wed, 5 Mar 2008 08:35:17 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id CFF1A3A6B40 for ; Wed, 5 Mar 2008 08:35:16 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 855A9A0665; Wed, 5 Mar 2008 17:35:06 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 769CBA065B; Wed, 5 Mar 2008 17:35:06 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 0C50CA0664; Wed, 5 Mar 2008 17:35:02 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m25GZ2V05378; Wed, 5 Mar 2008 17:35:02 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id C4C2FC864C; Wed, 5 Mar 2008 17:35:02 +0100 (CET) Message-ID: <47CECB76.3060307@informatik.uni-wuerzburg.de> Date: Wed, 05 Mar 2008 17:33:58 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: philip.eardley@bt.com References: <75A199C5D243C741BF3D3F1EBCEF9BA503B34641@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34641@E03MVZ1-UKDY.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org, Ruediger.Geib@t-systems.com Subject: Re: [PCN] draft-ietf-pcn-architecture-03 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil and others, philip.eardley@bt.com wrote: > >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >> > Lars > >> Eggert >> Sent: 27 February 2008 09:17 >> To: ext Geib, Ruediger >> Cc: pcn@ietf.org >> Subject: Re: [PCN] draft-ietf-pcn-architecture-03 >> >> Hi, >> >> On 2008-2-27, at 10:45, ext Geib, Ruediger wrote: >> >>> [Lars] It is important to discuss somewhere that some choices here >>> are less >>> optimal than others. A good decision-making location is where PCN >>> information naturally accumulates, e.g. at the egress. Any >>> relocation >>> of that decision-making requires additional communication, which >>> increases the delay of the control loop and makes the system more >>> brittle, because correct operation now requires dependable >>> communication between the egress and the decision-making point. >>> > I'd > >>> like to suggest that we attempt to come to consensus on whether we >>> can >>> focus on a single decision point for PCN. >>> >>> [RG] The per flow signaling must reside at the ingress by our actual >>> specification (see section 1, first bullet point) and to make >>> admission >>> control work, the egress must signal to the ingress anyway. It is >>> >> (Sentence truncated?) >> >> I see your point. Thinking about this some more, I believe my comment >> was based on a different understanding on something that the >> architecture document currently doesn't discuss much, but probably >> should: What information is signaled from the egress to the ingress? >> >> We agree that the egress looks at the volume of PCN marks compared to >> the volume of total PCN traffic to determine the level of congestion >> on an ingress-egress pair. The ingress then admits or terminates flows >> in a way that is somehow based on that information. But what gets >> signaled from egress to ingress? Is it some sort of load indication? >> Or is it a desired behavior, i.e., "stop admit" or "start preempt"? Or >> something else? >> >> > > how about the following for admission ctrl: > - the egress signals to the ingress "admit" or "block" on a per flow > basis. > Yes, good idea as it decouples operation of ingress and egress nodes. > - the egress bases this decision on the level of congestion on the > ingress-egress-aggregate, using an EWMA or similar > For an architecture draft: " on the marking ". Details can be described by a different document. > - the egress has been told what the "threshold" level of congestion is > (ie threshold for admit vs block decision). This could be a signalling > msg from the ingress of some configuration parameter. > Yes, CLE-based Admission Control requires two thresholds: An admission-continue threshold and an admission-stop threshold such that appropriate messages can be triggered towards the PCN ingress. > - if there's been no traffic from this ingress recently, then the "level > of congestion" is based simply on whether this first pkt (which is the > flow adm request msg) is marked or not. (those who believe that the > marking of a single pkt contains as much info as the level of congestion > (= markings of lots of pkts) simply set their EWMA weight to 1.) > Well, this is already a kind of probing that reliably works only with exhaustive (threshold) marking. With excess marking this probably is equivalent to assuming the admit mode for empty aggregates. At least it's a safe option since the aggregate can admit another flow on which further CLE can be based. > - the ingress abides by the egress signal to admit or block, unless it > has to over-ride for some good reason eg perhaps instructed by > management system to block all calls at the moment. > - the above doesn't allow an approach where the egress signals to the > ingress "admit (/block) for x secs, unless I tell you otherwise". > (Michael has mentioned this approach, although for me it's rather > difference in terms of performance implications on system reaction time, > impact of lost msgs etc.) > You probably mean observation-based AC: egress sends admission-stop msg as soon as it sees first marked packet; it sends an admission-continue msg when it hasn't seen a marked packet for a minimum block interval. I don't think it's a contradiction. In general, refresh messages or other stuff can be sent without changing the general behavior of the AC method. > - there's an implication in the above that we indeed have a msg from the > ingress to the egress. Is this reasonable assumption? > We also need a mechanism for bootstrapping which is equivalent to an empty system. However, this can be simple such as empty = admit; This is problematic when we have lots of small edge-to-edge aggregates that contribute to a large aggregate in the core such that the aggregation condition is met. One important question is: should PCN work well for edge-to-edge aggregates of 1, 100, 10000 flows? I am talking here about edge-to-edge aggregation, not about the number of flows on a link which may be significantly higher. Regards, Michael > for termination we have 2 quite different approaches (measuring rates vs > EMFT), so convergence here is trickier. > Thanks, > phil > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > -- 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 From pcn-bounces@ietf.org Thu Mar 6 00:40:17 2008 Return-Path: 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 677363A6D7E; Thu, 6 Mar 2008 00:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.81 X-Spam-Level: X-Spam-Status: No, score=-98.81 tagged_above=-999 required=5 tests=[AWL=-1.569, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 ZK0ut5FAQSUb; Thu, 6 Mar 2008 00:40:16 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48B9428C806; Thu, 6 Mar 2008 00:40:16 -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 3FCE028C806 for ; Thu, 6 Mar 2008 00:40:15 -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 zXXhib0S3L3N for ; Thu, 6 Mar 2008 00:40:14 -0800 (PST) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 9429528C7F4 for ; Thu, 6 Mar 2008 00:40:13 -0800 (PST) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Thu, 6 Mar 2008 09:39:59 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Mar 2008 09:39:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Mar 2008 09:41:10 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CE87ABD@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <47CECB76.3060307@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-architecture-03 Thread-Index: Ach+3vXCQzv3NBdcSmeiruAqyYsy8AAgWSXQ References: <75A199C5D243C741BF3D3F1EBCEF9BA503B34641@E03MVZ1-UKDY.domain1.systemhost.net> <47CECB76.3060307@informatik.uni-wuerzburg.de> From: "Geib, Ruediger" To: , X-OriginalArrivalTime: 06 Mar 2008 08:39:59.0008 (UTC) FILETIME=[A95F5200:01C87F65] Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Phil, Michael, = | -----Original Message----- | From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] = | Sent: Wednesday, March 05, 2008 5:34 PM | To: philip.eardley@bt.com | Cc: lars.eggert@nokia.com; Geib, R=FCdiger; pcn@ietf.org | Subject: Re: [PCN] draft-ietf-pcn-architecture-03 | = | Hi Phil and others, | = | = | philip.eardley@bt.com wrote: | > = | >> -----Original Message----- | >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] = | On Behalf Of | >> = | > Lars | > = | >> Eggert | >> Sent: 27 February 2008 09:17 | >> To: ext Geib, Ruediger | >> Cc: pcn@ietf.org | >> Subject: Re: [PCN] draft-ietf-pcn-architecture-03 | >> | >> Hi, | >> | >> On 2008-2-27, at 10:45, ext Geib, Ruediger wrote: | >> = | >>> [Lars] It is important to discuss somewhere that some = | choices here = | >>> are less | >>> optimal than others. A good decision-making location is = | where PCN | >>> information naturally accumulates, e.g. at the egress. Any = | >>> relocation | >>> of that decision-making requires additional communication, which | >>> increases the delay of the control loop and makes the = | system more | >>> brittle, because correct operation now requires dependable | >>> communication between the egress and the decision-making point. | >>> = | > I'd | > = | >>> like to suggest that we attempt to come to consensus on = | whether we = | >>> can | >>> focus on a single decision point for PCN. | >>> | >>> [RG] The per flow signaling must reside at the ingress by = | our actual = | >>> specification (see section 1, first bullet point) and to make = | >>> admission control work, the egress must signal to the ingress = | >>> anyway. It is | >>> = | >> (Sentence truncated?) | >> | >> I see your point. Thinking about this some more, I believe my comment = | >> was based on a different understanding on something that the = | >> architecture document currently doesn't discuss much, but probably | >> should: What information is signaled from the egress to the ingress? | >> | >> We agree that the egress looks at the volume of PCN marks compared to = | >> the volume of total PCN traffic to determine the level of congestion = | >> on an ingress-egress pair. The ingress then admits or terminates = | >> flows in a way that is somehow based on that information. But what = | >> gets signaled from egress to ingress? Is it some sort of load indicati= on? | >> Or is it a desired behavior, i.e., "stop admit" or "start preempt"? = | >> Or something else? | >> | >> = | > P:> how about the following for admission ctrl: | > - the egress signals to the ingress "admit" or "block" on a per flow = | > basis. | > = M:Yes, good idea as it decouples operation of ingress and egress nodes. [RG]:This isn't in line with the current architecture as is (per flow state = just in the ingress node and only ingress/egress aggregate measurements in = the egress). Please clarify which new egress functionalities are required. | = | = P:> - the egress bases this decision on the level of congestion on the = | > ingress-egress-aggregate, using an EWMA or similar | > = M:For an architecture draft: " on the marking ". Details can be = | described by a different document. [RG] Yes. | = P:> - the egress has been told what the "threshold" level of congestion is = | > (ie threshold for admit vs block decision). This could be a signalling = | > msg from the ingress of some configuration parameter. | > = M:Yes, CLE-based Admission Control requires two thresholds: An = | admission-continue threshold and an admission-stop threshold = | such that appropriate messages can be triggered towards the = | PCN ingress. [RG] I'd favour configuration by management. Signaling from the ingress sou= nds a bit strange to me. What's trhe rational behind your idea, Phil? | = | = P:> - if there's been no traffic from this ingress recently, then the = | > "level of congestion" is based simply on whether this first pkt (which = | > is the flow adm request msg) is marked or not. (those who believe that = | > the marking of a single pkt contains as much info as the level of = | > congestion (=3D markings of lots of pkts) simply set their EWMA weight = | > to 1.) | > = M:Well, this is already a kind of probing that reliably works = | only with exhaustive (threshold) marking. With excess marking = | this probably is equivalent to assuming the admit mode for = | empty aggregates. At least it's a safe option since the = | aggregate can admit another flow on which further CLE can be based. [RG] For a flow with silence suppression or the like, it may not be a = request message. No probing, at least not if just admission control is = active. Just take the "safe option" just admit. I'm allright with limiting = the number of admitted new flows to empty aggregates based on a timer = or so however (see also below). | = P:> - the ingress abides by the egress signal to admit or block, unless it = | > has to over-ride for some good reason eg perhaps instructed by = | > management system to block all calls at the moment. | > - the above doesn't allow an approach where the egress signals to the = | > ingress "admit (/block) for x secs, unless I tell you otherwise". | > (Michael has mentioned this approach, although for me it's rather = | > difference in terms of performance implications on system reaction = | > time, impact of lost msgs etc.) | > = | You probably mean observation-based AC: egress sends = | admission-stop msg as soon as it sees first marked packet; it = | sends an admission-continue msg when it hasn't seen a marked = | packet for a minimum block interval. I don't think it's a = | contradiction. In general, refresh messages or other stuff = | can be sent without changing the general behavior of the AC method. [RG] I like Michaels idea. Maybe the number of new flows admitted should = be limited after the egress indicated the first received pre-congestion = marked packet from the egress. Unless the egress sends a second message = to keep up the pre-congestion status, there could be a time out in the = ingress after which the ingress continues admission as usual. | = | = P:> - there's an implication in the above that we indeed have a msg from = | > the ingress to the egress. Is this reasonable assumption? | > = M:We also need a mechanism for bootstrapping which is = | equivalent to an empty system. However, this can be simple = | such as empty =3D admit; This is problematic when we have lots = | of small edge-to-edge aggregates that contribute to a large = | aggregate in the core such that the aggregation condition is met. | = | One important question is: should PCN work well for = | edge-to-edge aggregates of 1, 100, 10000 flows? I am talking = | here about edge-to-edge aggregation, not about the number of = | flows on a link which may be significantly higher. [RG] It is a measurement based admission control mechanism and as such, = it requires traffic to work well. If the measurement interval is small like = 1 ms, you'll need a higher bit rate and a number of flows per aggregate to = see a packet with some probability. If the measurement interval is 10 s, = you have a fair chance to see a packet with fewer flows or lower bit rates. = We should consider whether we provide informational operational hints or = whether we say, engineering PCN is an operator issue. = Regards, Rudiger | = | Regards, | = | Michael | = | > for termination we have 2 quite different approaches = | (measuring rates = | > vs EMFT), so convergence here is trickier. | > Thanks, | > phil | > = | > _______________________________________________ | > PCN mailing list | > PCN@ietf.org | > https://www.ietf.org/mailman/listinfo/pcn | > = | = | -- | 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 From pcn-bounces@ietf.org Thu Mar 6 00:59:06 2008 Return-Path: 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 301143A6D2A; Thu, 6 Mar 2008 00:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.302 X-Spam-Level: X-Spam-Status: No, score=-98.302 tagged_above=-999 required=5 tests=[AWL=-1.061, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 eSlWHM13Kgnx; Thu, 6 Mar 2008 00:59:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D63063A6CEF; Thu, 6 Mar 2008 00:59:04 -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 CCE2D3A6954 for ; Thu, 6 Mar 2008 00:59:02 -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 AmKtin-ie2vk for ; Thu, 6 Mar 2008 00:58:58 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 7D5953A68D0 for ; Thu, 6 Mar 2008 00:58:34 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 5CEFCA06A0; Thu, 6 Mar 2008 09:58:24 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 4CA00A069F; Thu, 6 Mar 2008 09:58:24 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id E8E47A069C; Thu, 6 Mar 2008 09:58:21 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m268wLV13549; Thu, 6 Mar 2008 09:58:21 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id AA9FEC7F1A; Thu, 6 Mar 2008 09:58:21 +0100 (CET) Message-ID: <47CFB1EE.1080403@informatik.uni-wuerzburg.de> Date: Thu, 06 Mar 2008 09:57:18 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Geib, Ruediger" References: <75A199C5D243C741BF3D3F1EBCEF9BA503B34641@E03MVZ1-UKDY.domain1.systemhost.net> <47CECB76.3060307@informatik.uni-wuerzburg.de> <1B6169C658325341A3B8066E23919E1CE87ABD@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1B6169C658325341A3B8066E23919E1CE87ABD@S4DE8PSAANK.mitte.t-com.de> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi R=FCdiger, Geib, Ruediger wrote: > Phil, Michael, > > = > > | -----Original Message----- > | From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] = > | Sent: Wednesday, March 05, 2008 5:34 PM > | To: philip.eardley@bt.com > | Cc: lars.eggert@nokia.com; Geib, R=FCdiger; pcn@ietf.org > | Subject: Re: [PCN] draft-ietf-pcn-architecture-03 > | = > | Hi Phil and others, > | = > | = > | philip.eardley@bt.com wrote: > | > = > | >> -----Original Message----- > | >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] = > | On Behalf Of > | >> = > | > Lars > | > = > | >> Eggert > | >> Sent: 27 February 2008 09:17 > | >> To: ext Geib, Ruediger > | >> Cc: pcn@ietf.org > | >> Subject: Re: [PCN] draft-ietf-pcn-architecture-03 > | >> > | >> Hi, > | >> > | >> On 2008-2-27, at 10:45, ext Geib, Ruediger wrote: > | >> = > | >>> [Lars] It is important to discuss somewhere that some = > | choices here = > | >>> are less > | >>> optimal than others. A good decision-making location is = > | where PCN > | >>> information naturally accumulates, e.g. at the egress. Any = > | >>> relocation > | >>> of that decision-making requires additional communication, which > | >>> increases the delay of the control loop and makes the = > | system more > | >>> brittle, because correct operation now requires dependable > | >>> communication between the egress and the decision-making point. > | >>> = > | > I'd > | > = > | >>> like to suggest that we attempt to come to consensus on = > | whether we = > | >>> can > | >>> focus on a single decision point for PCN. > | >>> > | >>> [RG] The per flow signaling must reside at the ingress by = > | our actual = > | >>> specification (see section 1, first bullet point) and to make = > | >>> admission control work, the egress must signal to the ingress = > | >>> anyway. It is > | >>> = > | >> (Sentence truncated?) > | >> > | >> I see your point. Thinking about this some more, I believe my commen= t = > | >> was based on a different understanding on something that the = > | >> architecture document currently doesn't discuss much, but probably > | >> should: What information is signaled from the egress to the ingress? > | >> > | >> We agree that the egress looks at the volume of PCN marks compared t= o = > | >> the volume of total PCN traffic to determine the level of congestion = > | >> on an ingress-egress pair. The ingress then admits or terminates = > | >> flows in a way that is somehow based on that information. But what = > | >> gets signaled from egress to ingress? Is it some sort of load indica= tion? > | >> Or is it a desired behavior, i.e., "stop admit" or "start preempt"? = > | >> Or something else? > | >> > | >> = > | > > P:> how about the following for admission ctrl: > | > - the egress signals to the ingress "admit" or "block" on a per flow = > | > basis. > | > = > M:Yes, good idea as it decouples operation of ingress and egress nodes. > > [RG]:This isn't in line with the current architecture as is (per flow sta= te = > just in the ingress node and only ingress/egress aggregate measurements i= n = > the egress). Please clarify which new egress functionalities are required. > = Ooops, sorry! Yes, Ruediger, you are absolutely right. I mean that based = on per aggregate evaluation, the egress node signals to the ingress = "admit" or "block" such that the ingress node can update its state to = admit or block further flows. That's what I mean, anything else is of = course out of scope. Probably the same happened to Phil? > | = > | = > P:> - the egress bases this decision on the level of congestion on the = > | > ingress-egress-aggregate, using an EWMA or similar > | > = > M:For an architecture draft: " on the marking ". Details can be = > | described by a different document. > > [RG] Yes. > > | = > P:> - the egress has been told what the "threshold" level of congestion i= s = > | > (ie threshold for admit vs block decision). This could be a signallin= g = > | > msg from the ingress of some configuration parameter. > | > = > M:Yes, CLE-based Admission Control requires two thresholds: An = > | admission-continue threshold and an admission-stop threshold = > | such that appropriate messages can be triggered towards the = > | PCN ingress. > > [RG] I'd favour configuration by management. Signaling from the ingress s= ounds > a bit strange to me. What's trhe rational behind your idea, Phil? > = Yes, that's also my view. > | = > | = > P:> - if there's been no traffic from this ingress recently, then the = > | > "level of congestion" is based simply on whether this first pkt (whic= h = > | > is the flow adm request msg) is marked or not. (those who believe tha= t = > | > the marking of a single pkt contains as much info as the level of = > | > congestion (=3D markings of lots of pkts) simply set their EWMA weigh= t = > | > to 1.) > | > = > M:Well, this is already a kind of probing that reliably works = > | only with exhaustive (threshold) marking. With excess marking = > | this probably is equivalent to assuming the admit mode for = > | empty aggregates. At least it's a safe option since the = > | aggregate can admit another flow on which further CLE can be based. > > [RG] For a flow with silence suppression or the like, it may not be a = > request message. No probing, at least not if just admission control is = > active. Just take the "safe option" just admit. I'm allright with limitin= g = > the number of admitted new flows to empty aggregates based on a timer = > or so however (see also below). > > | = > P:> - the ingress abides by the egress signal to admit or block, unless i= t = > | > has to over-ride for some good reason eg perhaps instructed by = > | > management system to block all calls at the moment. > | > - the above doesn't allow an approach where the egress signals to the = > | > ingress "admit (/block) for x secs, unless I tell you otherwise". > | > (Michael has mentioned this approach, although for me it's rather = > | > difference in terms of performance implications on system reaction = > | > time, impact of lost msgs etc.) > | > = > | You probably mean observation-based AC: egress sends = > | admission-stop msg as soon as it sees first marked packet; it = > | sends an admission-continue msg when it hasn't seen a marked = > | packet for a minimum block interval. I don't think it's a = > | contradiction. In general, refresh messages or other stuff = > | can be sent without changing the general behavior of the AC method. > > [RG] I like Michaels idea. Maybe the number of new flows admitted should = > be limited after the egress indicated the first received pre-congestion = > marked packet from the egress. Unless the egress sends a second message = > to keep up the pre-congestion status, there could be a time out in the = > ingress after which the ingress continues admission as usual. > > | = > | = > P:> - there's an implication in the above that we indeed have a msg from = > | > the ingress to the egress. Is this reasonable assumption? > | > = > M:We also need a mechanism for bootstrapping which is = > | equivalent to an empty system. However, this can be simple = > | such as empty =3D admit; This is problematic when we have lots = > | of small edge-to-edge aggregates that contribute to a large = > | aggregate in the core such that the aggregation condition is met. > | = > | One important question is: should PCN work well for = > | edge-to-edge aggregates of 1, 100, 10000 flows? I am talking = > | here about edge-to-edge aggregation, not about the number of = > | flows on a link which may be significantly higher. > > [RG] It is a measurement based admission control mechanism and as such, = > it requires traffic to work well. If the measurement interval is small li= ke = > 1 ms, you'll need a higher bit rate and a number of flows per aggregate t= o = > see a packet with some probability. If the measurement interval is 10 s, = > you have a fair chance to see a packet with fewer flows or lower bit rate= s. The duration of the measurement interval is critical as it delays = potential blocking. This is not bad in a stationary scenario where only = a few flow request are above the admissible rate. AC is most important = and most likely to kick in in case of flash crowds. Therefore, it is = crucial that the reaction time is below 500 ms. Other opinions, also on = the parameter? > = > > We should consider whether we provide informational operational hints or = > whether we say, engineering PCN is an operator issue. = > = For further performance studies, statements from operators are helpful = for which aggregation level PCN AC should work. I remember a survey from = Phil, but I don't know the details anymore. I believe that there are = edge-to-edge aggregate with low aggregation we have to care for although = the aggregation on core links is high. Is that correct? What were the = numbers? Regards, Michael > Regards, Rudiger > > | = > | Regards, > | = > | Michael > | = > | > for termination we have 2 quite different approaches = > | (measuring rates = > | > vs EMFT), so convergence here is trickier. > | > Thanks, > | > phil > | > = > | > _______________________________________________ > | > PCN mailing list > | > PCN@ietf.org > | > https://www.ietf.org/mailman/listinfo/pcn > | > = > | = > | -- > | 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 > | = > | = > = -- = 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 From pcn-bounces@ietf.org Thu Mar 6 02:17:36 2008 Return-Path: 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 0E1C628C88F; Thu, 6 Mar 2008 02:17:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.181 X-Spam-Level: X-Spam-Status: No, score=-100.181 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 ZqvtNG7A5zZ4; Thu, 6 Mar 2008 02:17:35 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FBB728C879; Thu, 6 Mar 2008 02:17:35 -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 1125128C862 for ; Thu, 6 Mar 2008 02:17:34 -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 HQ7XqoohDJKT for ; Thu, 6 Mar 2008 02:17:33 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id D547328C885 for ; Thu, 6 Mar 2008 02:17:27 -0800 (PST) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail21.telekom.de with ESMTP; Thu, 6 Mar 2008 11:17:16 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Mar 2008 11:17:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Mar 2008 11:18:27 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CE87B6B@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <47CFB1EE.1080403@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-architecture-03 - topologies Thread-Index: Ach/aD1G5TCyS1XCQHm7ZcKGVYNKUQAAaQWg References: <75A199C5D243C741BF3D3F1EBCEF9BA503B34641@E03MVZ1-UKDY.domain1.systemhost.net> <47CECB76.3060307@informatik.uni-wuerzburg.de> <1B6169C658325341A3B8066E23919E1CE87ABD@S4DE8PSAANK.mitte.t-com.de> <47CFB1EE.1080403@informatik.uni-wuerzburg.de> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 06 Mar 2008 10:17:16.0304 (UTC) FILETIME=[40AC0100:01C87F73] Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 - topologies X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Michael, architecture plays a role here too. The information 10 000 loactions some bandwidths, some traffic matrix may be insufficient. If I look at telephony, there are systems like SBCs in our network and the other ingress/egress nodes are broadband access routers or interconnection routers, numbering say 400. Let's assume distributed video servers closer to the end user and connected similar as an SBC. Assume a fair share of the videos to be local/regional top down communication. Flows pass Access Router, SBC and Access Router. One of the routers could also be an interconnection router. There's no per flow state in routers. SBCs and Video Servers are flow aware. SBC's are fully meshed and some have links to interconnection points. Bandwidths for real time services are in the order of 500 Mbit/s for Voice and Video services per link. A voice call would be 100 kbit/s, a video stream no more than 10 Mbit/s. Let's assume each SBC and Video Server to be connected by 1 GE or bigger, full capacity available for PCN traffic. The SBC is a signaling and traffic relay for applications, the video server terminates signaling. Assume the video server to be part of the PCN domain, also in the case of a viewer downloading an exotic video from a remote site. The network is redundant in all sections (including interconnection). If you look for a network architecture, Deutsche Telekom publishes some information on that - but you can choose any other network for that too (eg Geant). I don't want to publish a link for one of our product servers here. I can't give you a traffic matrix. But there's more communication between economic centers for voice, I guess. For video streaming I have to pass. I don't know how many people are interested in the same movies at the same time. And the consumer preferences are different in different countries (languages, dubbing acceptance...). Regards, Rudiger [snipped all other stuff] [RG] We should consider whether we provide informational operational hints | > or whether we say, engineering PCN is an operator issue. | > | M:For further performance studies, statements from operators | are helpful for which aggregation level PCN AC should work. I | remember a survey from Phil, but I don't know the details | anymore. I believe that there are edge-to-edge aggregate with | low aggregation we have to care for although the aggregation | on core links is high. Is that correct? What were the numbers? | | Regards, | | Michael | | > Regards, Rudiger _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Mar 6 03:26:52 2008 Return-Path: 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 A284828C8CB; Thu, 6 Mar 2008 03:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.415 X-Spam-Level: X-Spam-Status: No, score=-99.415 tagged_above=-999 required=5 tests=[AWL=-0.778, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 YzaoUeLRVfSH; Thu, 6 Mar 2008 03:26:46 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3CF928C8B5; Thu, 6 Mar 2008 03:26:46 -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 EF8F528C8B5 for ; Thu, 6 Mar 2008 03:26:45 -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 nsx4oiYcbNen for ; Thu, 6 Mar 2008 03:26:44 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 288A228C8B0 for ; Thu, 6 Mar 2008 03:26:43 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Mar 2008 11:26:22 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Mar 2008 11:26:21 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B3464E@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <1B6169C658325341A3B8066E23919E1CE87ABD@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-architecture-03 Thread-Index: Ach+3vXCQzv3NBdcSmeiruAqyYsy8AAgWSXQAAYS/VA= From: To: , X-OriginalArrivalTime: 06 Mar 2008 11:26:22.0909 (UTC) FILETIME=[E83DB6D0:01C87F7C] Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org > P:> how about the following for admission ctrl: > | > - the egress signals to the ingress "admit" or "block" on a per flow > | > basis. > | > > M:Yes, good idea as it decouples operation of ingress and egress nodes. > > [RG]:This isn't in line with the current architecture as is (per flow > state > just in the ingress node and only ingress/egress aggregate measurements in > the egress). Please clarify which new egress functionalities are required. I think this is in-line with the current architecture. The egress doesn't need to remember the adm ctrl decision as it trusts the ingress to do what it tells it. if that's the state you were thinking of? > > | > P:> - if there's been no traffic from this ingress recently, then the > | > "level of congestion" is based simply on whether this first pkt (which > | > is the flow adm request msg) is marked or not. (those who believe that > | > the marking of a single pkt contains as much info as the level of > | > congestion (= markings of lots of pkts) simply set their EWMA weight > | > to 1.) > | > > M:Well, this is already a kind of probing that reliably works > | only with exhaustive (threshold) marking. With excess marking > | this probably is equivalent to assuming the admit mode for > | empty aggregates. At least it's a safe option since the > | aggregate can admit another flow on which further CLE can be based. True, the accuracy of the adm decision depends on what sort of marking the interior nodes use for adm ctrl (excess vs threshold) - although I think the egress actually does the same thing for both (use CLE if have it, otherwise look at marking on this flow adm request msg. In both cases, with excess marking (Single Marking) on interior nodes the reliability of the adm decision is worse - so the operator has to accept this [my view at the moment is that it's too inaccurate].) > > [RG] For a flow with silence suppression or the like, it may not be a > request message. Don't understand what silence suppression has to do with request msg. No probing, at least not if just admission control is > active. Just take the "safe option" just admit. I'm allright with limiting > the number of admitted new flows to empty aggregates based on a timer > or so however (see also below). > > | > P:> - the ingress abides by the egress signal to admit or block, unless it > | > has to over-ride for some good reason eg perhaps instructed by > | > management system to block all calls at the moment. > | > - the above doesn't allow an approach where the egress signals to the > | > ingress "admit (/block) for x secs, unless I tell you otherwise". > | > (Michael has mentioned this approach, although for me it's rather > | > difference in terms of performance implications on system reaction > | > time, impact of lost msgs etc.) > | > > | You probably mean observation-based AC: egress sends > | admission-stop msg as soon as it sees first marked packet; it > | sends an admission-continue msg when it hasn't seen a marked > | packet for a minimum block interval. I don't think it's a > | contradiction. In general, refresh messages or other stuff > | can be sent without changing the general behavior of the AC method. can we discuss this at ietf? I'm not against this approach in principle, I just worry whether we should focus more to at least get something done that has well understood performance, and add other bits later. > > [RG] I like Michaels idea. Maybe the number of new flows admitted should > be limited after the egress indicated the first received pre-congestion > marked packet from the egress. Unless the egress sends a second message > to keep up the pre-congestion status, there could be a time out in the > ingress after which the ingress continues admission as usual. This is true. Question is what are the risks for an operator, what advice is there (again: I think this is a reasonable approach, but it's a different one to get the IETF community to understand during pre-RFC review stages. Should discuss whether this is realistic (I'm open to being persuaded either way!) > > | > | > P:> - there's an implication in the above that we indeed have a msg from > | > the ingress to the egress. Is this reasonable assumption? > | > > M:We also need a mechanism for bootstrapping which is > | equivalent to an empty system. However, this can be simple > | such as empty = admit; This is problematic when we have lots > | of small edge-to-edge aggregates that contribute to a large > | aggregate in the core such that the aggregation condition is met. > | > | One important question is: should PCN work well for > | edge-to-edge aggregates of 1, 100, 10000 flows? I am talking > | here about edge-to-edge aggregation, not about the number of > | flows on a link which may be significantly higher. > > [RG] It is a measurement based admission control mechanism and as such, > it requires traffic to work well. If the measurement interval is small > like > 1 ms, you'll need a higher bit rate and a number of flows per aggregate to > see a packet with some probability. If the measurement interval is 10 s, > you have a fair chance to see a packet with fewer flows or lower bit > rates. Rudi - I don't quite agree. The most important thing is the number of pkts on the interior router that's in danger of being congested. My opinion is that it should work ok however many flows there are on the particular ingress-egress-aggregate (if one imagines a core network with say 100 PCN-boundary-nodes and a typical voice traffic matrix, then there'll be lots of ingress-egress pairs with no voice flows at any one instant). however, I don't think this implies we need to generate lots of "probe traffic" - reacting to a single pkt (ie the signalling msg) is ok (ben has convinced me of this, he's done analytical simulations, although I think talking about them at this ietf will probably just distract from the convergence Lars wants - hopefully he may be persuadable to come to Dublin!) > > We should consider whether we provide informational operational hints or > whether we say, engineering PCN is an operator issue. > > Regards, Rudiger > > | > | Regards, > | > | Michael > | > | > for termination we have 2 quite different approaches > | (measuring rates > | > vs EMFT), so convergence here is trickier. > | > Thanks, > | > phil > | > > | > _______________________________________________ > | > PCN mailing list > | > PCN@ietf.org > | > https://www.ietf.org/mailman/listinfo/pcn > | > > | > | -- > | 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 From pcn-bounces@ietf.org Thu Mar 6 03:56:55 2008 Return-Path: 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 C15593A6F04; Thu, 6 Mar 2008 03:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.172 X-Spam-Level: X-Spam-Status: No, score=-100.172 tagged_above=-999 required=5 tests=[AWL=-0.335, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 l-3uYqsyK74Z; Thu, 6 Mar 2008 03:56:54 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA6963A6DB5; Thu, 6 Mar 2008 03:56:54 -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 5C3E728C3AE for ; Thu, 6 Mar 2008 03:56:53 -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 Ub6poWl9BcSr for ; Thu, 6 Mar 2008 03:56:52 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 038623A6C41 for ; Thu, 6 Mar 2008 03:56:52 -0800 (PST) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail21.telekom.de with ESMTP; Thu, 6 Mar 2008 12:56:40 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 6 Mar 2008 12:56:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Mar 2008 12:57:51 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CE87C0B@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B3464E@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-architecture-03 - per flow signaling Thread-Index: Ach+3vXCQzv3NBdcSmeiruAqyYsy8AAgWSXQAAYS/VAAAb9ikA== References: <1B6169C658325341A3B8066E23919E1CE87ABD@S4DE8PSAANK.mitte.t-com.de> <75A199C5D243C741BF3D3F1EBCEF9BA503B3464E@E03MVZ1-UKDY.domain1.systemhost.net> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 06 Mar 2008 11:56:40.0288 (UTC) FILETIME=[237BBE00:01C87F81] Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 - per flow signaling X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, I decompose that a little. An appointment in 15 minutes leaves time for = one response (in line). Regards, Rudiger | -----Original Message----- | From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] = | Sent: Thursday, March 06, 2008 12:26 PM | To: Geib, R=FCdiger; menth@informatik.uni-wuerzburg.de | Cc: pcn@ietf.org | Subject: RE: [PCN] draft-ietf-pcn-architecture-03 | = | > P:> how about the following for admission ctrl: | > | > - the egress signals to the ingress "admit" or "block" on a per flow | > | > basis. | > | > | > M:Yes, good idea as it decouples operation of ingress and egress nodes. | > = | > [RG]:This isn't in line with the current architecture as is (per flow = | > state just in the ingress node and only ingress/egress aggregate measur= ements in | > the egress). Please clarify which new egress functionalities are requir= ed. | = P:I think this is in-line with the current architecture. The = | egress doesn't need to remember the adm ctrl decision as it = | trusts the ingress to do what it tells it. if that's the = | state you were thinking of? [RG] Your idea is that the egress measures active flows and the definition = of active = is "those for which packets were within the sliding window". That's ok in p= rinciple, = but still, the egress now measures per flow, not per aggregate. Or is your = suggestion = to measure per aggregate, then detect marked packets, identify the flows th= ey belong to and then signal decisions on them to the ingress? I don't understand how the per flow admission decision should work in the e= gress, = please describe this in more detail. _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Mar 6 05:08:22 2008 Return-Path: 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 A939328C8E6; Thu, 6 Mar 2008 05:08:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.319 X-Spam-Level: X-Spam-Status: No, score=-100.319 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 C4Bv6sM5VQaq; Thu, 6 Mar 2008 05:08:21 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14A3928C830; Thu, 6 Mar 2008 05:08:16 -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 F077C28C8E4 for ; Thu, 6 Mar 2008 05:08:14 -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 49wNBs5i9BMO for ; Thu, 6 Mar 2008 05:08:09 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id A5F9928C49D for ; Thu, 6 Mar 2008 05:08:03 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Mar 2008 13:07:52 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Mar 2008 13:07:51 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34652@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <1B6169C658325341A3B8066E23919E1CE87C0B@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-architecture-03 - per flow signaling Thread-Index: Ach+3vXCQzv3NBdcSmeiruAqyYsy8AAgWSXQAAYS/VAAAb9ikAAChEMg From: To: X-OriginalArrivalTime: 06 Mar 2008 13:07:52.0379 (UTC) FILETIME=[15D918B0:01C87F8B] Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 - per flow signaling X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org > > [RG] Your idea is that the egress measures active flows and the definition > of active > is "those for which packets were within the sliding window". That's ok in > principle, > but still, the egress now measures per flow, not per aggregate. Or is your > suggestion > to measure per aggregate, then detect marked packets, identify the flows > they belong to > and then signal decisions on them to the ingress? > > I don't understand how the per flow admission decision should work in the > egress, > please describe this in more detail. > egress gets an adm request msg (as per normal). Looks up what the ingress is (eg if it's rsvp this is the PHOP). Egress then looks what congestion info it has for this ingress: If it has a CLE (because there's already data flowing from this ingress on other sessions), base adm decision on what the CLE is. If it doesn't have a CLE, see whether this pkt (adm request msg) is marked. If it's marked adm decision is Reject. If it isnt, adm decision is Accept. Inform ingress of adm decision. This is the same as CL documentation, except that: - the egress reported the CLE to the ingress, which then made the decision. No longer necessary as egress makes decision. Implication of new proposal is that egress has to know what "threshold CLE" is (above/below => block/admit); you suggest this is a configured parameter, which seems ok to me. - if there wasn't a CLE (no data flowing from this ingress) then it asked the ingress to send "probes" ie send dummy data in order to generate CLE. Implication is that egress bases decision on whether a single pkt is marked (the adm request msg). _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Mar 7 00:04:39 2008 Return-Path: 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 1D3493A6F49; Fri, 7 Mar 2008 00:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.321 X-Spam-Level: X-Spam-Status: No, score=-100.321 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 VEsaSqQjt2Ak; Fri, 7 Mar 2008 00:04:38 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31F7A3A6E61; Fri, 7 Mar 2008 00:04:38 -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 1E6733A69BF for ; Fri, 7 Mar 2008 00:04:37 -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 8+kUXiOFyxLB for ; Fri, 7 Mar 2008 00:04:35 -0800 (PST) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id EC68728C449 for ; Fri, 7 Mar 2008 00:04:07 -0800 (PST) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Fri, 7 Mar 2008 09:03:56 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 7 Mar 2008 09:03:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 Mar 2008 09:05:08 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CE87E6E@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34652@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-architecture-03 - per flow signaling Thread-Index: Ach+3vXCQzv3NBdcSmeiruAqyYsy8AAgWSXQAAYS/VAAAb9ikAAChEMgACeax4A= References: <1B6169C658325341A3B8066E23919E1CE87C0B@S4DE8PSAANK.mitte.t-com.de> <75A199C5D243C741BF3D3F1EBCEF9BA503B34652@E03MVZ1-UKDY.domain1.systemhost.net> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 07 Mar 2008 08:03:56.0205 (UTC) FILETIME=[CAA785D0:01C88029] Cc: pcn@ietf.org Subject: Re: [PCN] draft-ietf-pcn-architecture-03 - per flow signaling X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Phil, | > [RG] Your idea is that the egress measures active flows and the definition | > of active is "those for which packets were within the sliding window". | > That's ok in principle, but still, the egress now measures per flow, | > not per aggregate. Or is your suggestion to measure per aggregate, | > then detect marked packets, identify the flows they belong to | > and then signal decisions on them to the ingress? | > | > I don't understand how the per flow admission decision should work in | > the egress, please describe this in more detail. | > [Phil] | egress gets an adm request msg (as per normal). Looks up what | the ingress is (eg if it's rsvp this is the PHOP). [RG] Umm maybe I'm slow here but putting this all together means: - the egress node supports RSVP signaling to the extent that it is a PHOP, supports signaling and reads the flow identifiers. - the egress node does however not support any of the per flow conditioning features required by RSVP. Is that it? If yes, it may be useful to emphasize the concept a little more in the architecture. I don't object to the idea. Regards, Rudiger | Egress then looks what congestion info it has for this ingress: | If it has a CLE (because there's already data flowing from | this ingress on other sessions), base adm decision on what | the CLE is. | If it doesn't have a CLE, see whether this pkt (adm request | msg) is marked. If it's marked adm decision is Reject. If it | isnt, adm decision is Accept. | Inform ingress of adm decision. | | This is the same as CL documentation, except that: | - the egress reported the CLE to the ingress, which then made | the decision. No longer necessary as egress makes decision. | Implication of new proposal is that egress has to know what | "threshold CLE" is (above/below => block/admit); you suggest | this is a configured parameter, which seems ok to me. | - if there wasn't a CLE (no data flowing from this ingress) | then it asked the ingress to send "probes" ie send dummy data | in order to generate CLE. Implication is that egress bases | decision on whether a single pkt is marked (the adm request msg). | _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sat Mar 8 14:18:05 2008 Return-Path: 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 679BC3A6C75; Sat, 8 Mar 2008 14:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.619 X-Spam-Level: X-Spam-Status: No, score=-99.619 tagged_above=-999 required=5 tests=[AWL=0.818, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 pGH-Th84FfmK; Sat, 8 Mar 2008 14:18:04 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6ECB53A6C07; Sat, 8 Mar 2008 14:18:04 -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 D702028CCEA for ; Sat, 8 Mar 2008 07:25:51 -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 8hQzK0ea7V2W for ; Sat, 8 Mar 2008 07:25:49 -0800 (PST) Received: from smtp110.sbc.mail.mud.yahoo.com (smtp110.sbc.mail.mud.yahoo.com [68.142.198.209]) by core3.amsl.com (Postfix) with SMTP id 151B63A702F for ; Sat, 8 Mar 2008 07:06:42 -0800 (PST) Received: (qmail 48370 invoked from network); 8 Mar 2008 15:04:20 -0000 Received: from unknown (HELO JAINX61) (rajain@sbcglobal.net@12.10.125.134 with login) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 8 Mar 2008 15:04:19 -0000 X-YMail-OSG: W5tRstgVM1mu6DLUJjM6XPocZ52jpkquaM8ccVVNIbeZk37iuJJ7hay4e11AWaa6yTuC1xcybNdiQRRXWdLArA1czbPaTRndGzecPHsRI64SQufRWeAVs09_YkGXFg-- X-Yahoo-Newman-Property: ymail-3 From: "Raj Jain" To: Date: Sat, 8 Mar 2008 09:04:18 -0600 Organization: Washington University in St. Louis Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciBLa5OnyPP+J9USYCBPUk9/IkSfQ== X-Mailman-Approved-At: Sat, 08 Mar 2008 14:18:03 -0800 Cc: 'Jinjing Jiang' , 'Jinjing Jiang' Subject: [PCN] A Simple Analytical Model of PCN X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: jain@cse.wustl.edu List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Analytical models often require simplifications but they provide good insights in to the effects of various parameters. With this view point, we have developed a simple model of PCN. We model n flows going through a single bottleneck where the packets are marked using a token bucket. The egress measures the rate of marked packets and sends it to the ingress point which makes a decision to reject new flows or to terminate existing flows. Currently the model assumes instantaneous feedback and infinite buffering (therefore no loss). The sources are modeled with exponentially distributed on/off period. We are able to get close form expressions for the rejection and termination probabilities for single marking case. An inital set of slides presenting the model are available at: http://www.cse.wustl.edu/~jain/ietf/pcn0803.htm We are still working on the presentation and, in the next few days, hope to add sensitivity analysis and the effect of various parameters on thrashing (when some flows are accepted while other flows are terminated). Comments are welcome. Thanks. -Jinjing Jiang and Raj Jain ----------------------------------------------------- Raj Jain, Ph.D., Fellow of IEEE, Fellow of ACM Professor of Computer Science and Engineering Washington University in St. Louis Campus Box 1045, One Brookings Drive St. Louis, MO 63130 Phone: +1 314 322 8092 Email: Jain@cse.wustl.edu URL: http://www.cse.wustl.edu/~jain Author of: "High Performance TCP/IP Networking" and "The Art of Computer Systems Performance Analysis" ------------------------------------------------------ _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sat Mar 8 18:38:57 2008 Return-Path: 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 EE63D3A6780; Sat, 8 Mar 2008 18:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.839 X-Spam-Level: X-Spam-Status: No, score=-98.839 tagged_above=-999 required=5 tests=[AWL=-0.479, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, SUBJ_ALL_CAPS=2.077, USER_IN_WHITELIST=-100] 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 X6hb9nNAex7w; Sat, 8 Mar 2008 18:38:57 -0800 (PST) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7683A67B1; Sat, 8 Mar 2008 18:38:57 -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 9AAB23A6780 for ; Sat, 8 Mar 2008 18:38:55 -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 v7PzljAxdyyM for ; Sat, 8 Mar 2008 18:38:54 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 6BB143A67B1 for ; Sat, 8 Mar 2008 18:38:54 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 6D22BA0648 for ; Sun, 9 Mar 2008 03:36:31 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 613F1A0640 for ; Sun, 9 Mar 2008 03:36:31 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 4C408A063F for ; Sun, 9 Mar 2008 03:36:16 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m292aGV07915 for ; Sun, 9 Mar 2008 03:36:16 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 56E3CC85AC for ; Sun, 9 Mar 2008 03:36:16 +0100 (CET) Message-ID: <47D34CE4.4070501@informatik.uni-wuerzburg.de> Date: Sun, 09 Mar 2008 03:35:16 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: pcn X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Subject: [PCN] LC-PCN X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Lars, Anurag, Attila, and Georgios! I read your new version of LC-PCN on the airplane, at least the high-level description of Section 1-3. http://tools.ietf.org/id/draft-westberg-pcn-load-control-03.txt The readability of the document has largely improved compared to the last version and I think that I have understood your concept now. To make sure I've fully understood it, I briefly summarized my understanding of LC-PCN in my own words and in an approximative way in a short PPT and added 3 questions. http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/LC-PCN.ppt I would appreciate your comments on my summary and answers to my 3 questions. Hope to see you in Philly. Are you there? Regards, Michael -- 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 From pcn-bounces@ietf.org Sun Mar 9 05:43:15 2008 Return-Path: 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 85AE428C1D1; Sun, 9 Mar 2008 05:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.873 X-Spam-Level: X-Spam-Status: No, score=-99.873 tagged_above=-999 required=5 tests=[AWL=0.564, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 TXApeZ1W8fS5; Sun, 9 Mar 2008 05:43:14 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9699F3A6CE7; Sun, 9 Mar 2008 05:43:14 -0700 (PDT) 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 5ABB13A6CE7 for ; Sun, 9 Mar 2008 05:43:13 -0700 (PDT) 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 DQ1LAk3Rd9Em for ; Sun, 9 Mar 2008 05:43:12 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 117493A6984 for ; Sun, 9 Mar 2008 05:43:11 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id DB060A05C9; Sun, 9 Mar 2008 13:40:49 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id CDDCCA05BE; Sun, 9 Mar 2008 13:40:49 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 9AB6EA05BA; Sun, 9 Mar 2008 13:40:48 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m29CemV11358; Sun, 9 Mar 2008 13:40:48 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id CB755C85AC; Sun, 9 Mar 2008 13:40:47 +0100 (CET) Message-ID: <47D3DA95.7020504@informatik.uni-wuerzburg.de> Date: Sun, 09 Mar 2008 13:39:49 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Philip Eardley X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn Subject: [PCN] Terminology X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil and others, I have some improvements for the high level description of PCN including some nomenclature. I suggest to rename the expressions o PCN-lower-rate: a reference rate configured for each link in the PCN-domain, which is lower than the PCN-upper-rate. It is used by a marking behaviour that determines whether a packet should be PCN-marked with a first encoding. o PCN-upper-rate: a reference rate configured for each link in the PCN-domain, which is higher than the PCN-lower-rate. It is used by a marking behaviour that determines whether a packet should be PCN-marked with a second encoding. o Admissible Rate (AR): a reference rate configured for each link in the PCN-domain. It's the rate up to which admission control should accept new flows. o Supportable Rate (SR): a reference rate configured for each link in the PCN-domain. It's the rate down to which flow termination should terminate already admitted flows if they cause overload. SR does not need to be given explicitly but also implicitly by SR=u*AR with the same value u for all links in the network. The new naming is very general and applicable to any existing proposal. It helps to make text more readable. The new expressions also help to qualify the types of pre-congestion and overload on a link in an intuitive way which is also easy to remember. Types of pre-congestion on a link: * No pre-congestion (NPC): PCN rate <= AR * AR-pre-congestion (ARPC): AR < PCN rate <= SR * SR-pre-congestion (SRPC): SR < PCN rate Types of overload on a link: * no overload (PCN rate <= AR) * AR-overload = PCN rate - AR (per link) * SR-overload = PCN rate - SR (per link) I have summarized the general PCN idea using this nomenclature on two PPT slides: http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/PCN-Description.ppt In contrast, the naming of the packet marking depends on the specific proposals and cannot be streamlined similarly as the semantics of the markings depends both on the metering and marking method connected with the AR and SR thresholds. * CL: unmarked, admission-marked (AM), termination-marked (TM) * 3sm: no-pre-congestion (NP), admission-stop (AS), excess-traffic (ET) * SM: unmarked, admission marked (AM) * LC-PCN: unmarked, "PCN_Marked", "Affected_Marked" From my point of view, it makes sense to adopt the new nomenclature concerning the general PCN idea in the architecture draft, but it currently does not make sense to harmonize the naming of the marking. I am already in Philadelphia and look forward to see you guys again at the welcome reception tonight. Regards, Michael -- 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 From pcn-bounces@ietf.org Mon Mar 10 07:51:50 2008 Return-Path: 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 300A328E3A9; Mon, 10 Mar 2008 07:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.489 X-Spam-Level: X-Spam-Status: No, score=-100.489 tagged_above=-999 required=5 tests=[AWL=-0.651, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 gYjjN2xiT7PO; Mon, 10 Mar 2008 07:51:50 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A149228CDE1; Mon, 10 Mar 2008 07:24:07 -0700 (PDT) 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 DF1ED28C546 for ; Mon, 10 Mar 2008 07:24:05 -0700 (PDT) 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 8rWLYuWQObBE for ; Mon, 10 Mar 2008 07:24:00 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 24C7C293DBD for ; Mon, 10 Mar 2008 06:47:19 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 13:44:58 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 13:44:58 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1205156697475; Mon, 10 Mar 2008 13:44:57 +0000 Received: from mut.jungle.bt.co.uk ([10.73.145.122]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m2ADinHs010092; Mon, 10 Mar 2008 13:44:54 GMT Message-Id: <200803101344.m2ADinHs010092@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Mar 2008 13:44:47 +0000 To: Georgios Karagiannis From: Bob Briscoe Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 10 Mar 2008 13:44:58.0096 (UTC) FILETIME=[EE218F00:01C882B4] Cc: PCN IETF list Subject: [PCN] Fwd: How necessary is affected marking? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Georgios, [Following up my own post (please ignore the original), since talking to you just now has simplified this to one outstanding question:] >Have you tried to quantify how likely it will be that AfM will be useful? A 'good enough' alternative to AfM would be to use AM as a reasonably good approximator for AfM. The egress would only terminate flows marked TM and it would calculate how much to terminate from the proportion of TM to AM. This 'good enough' approach would never terminate flows not passing through a termination marking router. But, if other path(s) were coincidentally admission marking but not termination marking, termination on the first path would be slowed down but still completely terminate sufficient flows. I imagine termination would rarely be prolonged by more than a few percent. There could be cases where termination would be prolonged by hundreds of percent, when many other paths were heavily admission marking but not termination marking at all. However, I think network operators should be given the probability that these cases will happen, so they can decide whether AfM is worth deploying. Bob >Date: Mon, 10 Mar 2008 12:18:54 +0000 >To: Georgios Karagiannis >From: Bob Briscoe >Subject: How necessary is affected marking? >Cc: "PCN IETF list" > >Georgios, > >Do you propose using Affected Marking (AfM) in ECMP cases to >calculate the Admission Marking level or just the Termination Marking level? I understand now, that the same AfM can't be used for admission marking as for termination marking (because then AfM on paths with admission marking would be confusable with AfM from paths doing termination marking. >If both, I can see it seems to help in ECMP cases {but see Note 1}. > >But if AfM is only used for Termination, the case for Affected >Marking (AfM) seems marginal. Because all packets that aren't >Termination Marked (TM) will typically be Admission Marked (AM), so >AM can serve the function of AfM. > >Of course, there may be one queue sending TM & AM to an egress and >another sending only AM. So AfM would help in such cases. But that's >a bit of a corner case to justify another codepoint. Without AfM, >this would slow down flow termination, but it would still terminate >the right amount of flows eventually. > >My question: Have you tried to quantify how likely it will be that >AfM will be useful? > >I'm just wondering whether it is worth complicating the core PCN >algorithm and encoding specs with AfM, or whether we should have a >separate spec just about AfM. Then the main PCN specs can refer to >AfM as an optional extra for any vendor who wants to do it. > >Cheers > > >Bob > >--------- >{Note 1}: However, the admission marking behaviour we are likely to >standardise doesn't have a clear point where AM is on or off. It >gets gradually greater. The egress can decide when the fraction of >AM has passed a threshold for sufficient time (e.g. with an >exponentially weighted moving average EWMA). But that seems quite >complicated (but not impossible) for an interior node. > >I guess though that excess rate marking would also have to be able >to detect when it had been marking sufficiently for sufficiently >long to turn on AfM, and when to turn it off again. Have you >documented a possible algorithm for these state change triggers anywhere? > > >____________________________________________________________________________ >Bob Briscoe, Networks Research Centre, BT Research >B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 10 08:01:09 2008 Return-Path: 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 F123B28D6A2; Mon, 10 Mar 2008 08:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.975 X-Spam-Level: X-Spam-Status: No, score=-100.975 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 EbfzPljkSN8B; Mon, 10 Mar 2008 08:01:03 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A31328CBA9; Mon, 10 Mar 2008 07:29:40 -0700 (PDT) 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 B3F3A28CE0F for ; Mon, 10 Mar 2008 07:29:38 -0700 (PDT) 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 oP7PFxq7G-TD for ; Mon, 10 Mar 2008 07:29:35 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 19F7A293AC6 for ; Mon, 10 Mar 2008 06:17:29 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m2ADF8r4013898 for ; Mon, 10 Mar 2008 08:15:08 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 08:15:08 -0500 Received: from [127.0.0.1] ([147.117.168.117]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 08:15:07 -0500 From: Steven Blake To: pcn Organization: Ericsson IP Infrastructure Date: Mon, 10 Mar 2008 09:15:06 -0400 Message-Id: <1205154906.4570.0.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) X-OriginalArrivalTime: 10 Mar 2008 13:15:07.0885 (UTC) FILETIME=[C31509D0:01C882B0] Subject: [PCN] IETF71 presentations X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org If you are presenting either Tuesday or Thursday, please send me your slides (preferably in pdf format) so that I can upload them. Thanks, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 10 08:13:38 2008 Return-Path: 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 BD6B628E338; Mon, 10 Mar 2008 08:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.428 X-Spam-Level: X-Spam-Status: No, score=-98.428 tagged_above=-999 required=5 tests=[AWL=-0.891, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, MANGLED_TOOL=2.3, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 dId6Bn7-wxfW; Mon, 10 Mar 2008 08:13:37 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07BD328E3D1; Mon, 10 Mar 2008 07:52:05 -0700 (PDT) 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 3154328C7A1 for ; Mon, 10 Mar 2008 07:52:04 -0700 (PDT) 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 EqiiOUtTEvAr for ; Mon, 10 Mar 2008 07:52:02 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 6B7D4293907 for ; Mon, 10 Mar 2008 05:59:30 -0700 (PDT) Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2ACukP21561; Mon, 10 Mar 2008 12:56:46 GMT Received: from KCHAN-2K3.nortel.com ([47.16.102.92] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 08:56:38 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Mar 2008 08:56:37 -0400 To: Bob Briscoe From: "Kwok-Ho Chan" In-Reply-To: <200803101153.m2ABrpBW004972@bagheera.jungle.bt.co.uk> References: <200803101153.m2ABrpBW004972@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 10 Mar 2008 12:56:38.0908 (UTC) FILETIME=[2E1493C0:01C882AE] Cc: PCN IETF list Subject: Re: [PCN] PCN encoding options and tunnelling X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Bob, all: Why can't we consider the use of PCN as establishing a PCN VPN? This view goes well with the use of DSCP to differentiate PCN packets/traffic from all other packets/traffic. With the definition of the PCN PHB as the behavior for such a PCN VPN. In essences, the PCN packets/traffic travels in a VPN "tunnel" defined for it. This view allows clear definitions of: 1. PCN VPN support on a per domain basis. 2. SLAs for interfacing the PCN VPN between different domains. 3. How such a PCN VPN may be extended through multiple domains, possibly end to end. With the PCN VPN thinking, the other non PCN packets/traffic can be viewed as being packets in VPNs/tunnels different from the PCN VPN/tunnel. Then the PCN domain is the world inside the PCN VPN. With such a PCN VPN in mind, I would like to ask: 1. How does the VPNs in use today need to consider the ECN bits? 2. How does the VPNs in use today need to worry about mixing of each VPNs' packets/traffic together and separating them? 3. Does the VPNs in use today have to worry about other VPNs/tunnels: a. Starting the ingress end of one (or more) of the other VPN/tunnel inside its VPN? b. Endng the egress end of one (or more) of the other VPN/tunnel inside its VPN? c. Have both the ingress and egress endw of one (or more) of the other VPN/tunnel inside its VPN? If yes to any of the above, how are they being solved and can PCN adopt the same solution? 4. Can SLAs be written to handle both the DSCP and ECN bits so they are clearly defined in the PCN VPN ingress and egress points (PCN domain edges)? I have the PCN VPN thinking in mind from the beginning and this is the reason I support the use of DiffServ and DSCP to separate the PCN packets/traffic from the other packets/traffic. Hopefully allowing many of the problems to be understood, solved, or worked arounded. Section 2.2.7 on page 11 of http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison-03.txt have that thinking in mind and started putting some of the packet "leakage" issues as exceptions rather then the norm. Thanks! -- Kwok -- At 07:53 AM 3/10/2008, Bob Briscoe wrote: >Kwok, George, Toby, Michael, > >I believe tunneling represents the greatest constraint on the choice >of codepoints in the ECN field, so it nearly decides this issue for us... > >First I believe we have to allow for the likely possibility of a >tunnel starting and ending within a PCN region (as in S.5.7 of the >PCN arch I-D). For example, a multi-site VPN that is one big PCN >region under one operator's control joined together over the public >Internet by IPSec VPNs. If the customer-sites are part of the PCN >region they could have typical paths across the VPN like this: >Sender > PCN_ingress > IPSec_encap > IPSec_decap > PCN_egress > Receiver > >Then I suggest the following requirement sentence in S.2.2.7 of PCN >encoding Comparision about tunnels: >============================================================================= >"Tunnel endpoints, whether encapsulators or decapsulators, should >not require any new behaviour to handle PCN-capable packets. >Expecting vendors of all IPSec and all IP in IP tunnel endpoints to >cater specifically for PCN would be unrealistic, and require complex >backward compatibility rules for tunnels prior to PCN. If tunnels >did require PCN-specific behaviour, the resulting patchy and >error-prone deployment would probably cause PCN to suffer byzantine >feature interactions with poorly implemented tunnels. > >Tunnel endpoints should not have to detect that a packet's DSCP is >PCN and implement special PCN-specific encapsulating or >decapsulating behaviour. The rules that already exist for tunnel >endpoints to handle both the Diffserv field and the ECN field should >'just work' when handling packets with a PCN Diffserv codepoint." >============================================================================= > >That sounds reasonable, but it puts strong further constraints on >our PCN encoding options. Decapsulation in both RFC3168 'full >functionality [tunnelling] mode' and the old and new RFC4301 IPSec >architecture discards all ECN codepoints in the outer header except >11, forwarding the inner header unchanged. > >If we find this leaves us with no PCN encoding options, we might >have to require all tunnel decapsulators within a PCN region to be >changed (as currently implied in S.5.7 of the PCN architecture), but >let's see whether we have to first... > >With this constraint, it seems that none of 00, 01 or 10 of the ECN >field can be used for encoding AM (admission marked) or TM >(termination marked), without risking losing markings on >decapsulation that were added to the outer header due to congestion >in the middle of the tunnel. > >Further, 00 cannot be used for the unmarked (UM) state, because a >tunnel decapsulator will drop a packet if the inner header is marked >00 and the outer anything but 11. That leaves only 01 or 10 for UM. > >So far, if we use the ECN field at all, we're left with 01 or 10 for >the unmarked state and only 11 for anything else. > >Further, if either of 01 or 10 were used for UM, there would be a >risk of losing the UM meaning if a tunnel straddled the PCN ingress >but not the PCN egress, because the inner header is forwarded and >the outer header discarded if the outer is 01 or 10. I think it >would be reasonable for PCN standards to mandate that tunnel >decapsulators take special account of PCN encodings if the >encapsulator is not also in the region. > >We also now have to work around RFC5129 recently standardising ECN >in MPLS (with discussion of PCN in an appendix). I don't think that >constrains us further, but I'll check. I'll also check I can still >do the anti-cheating trick I'm proposing if we re-charter for >multiple domains (I suspect this will be hard now). > >Diffserv code points >-------------------- >For PCN to work at all, we would have to mandate that all tunnel >decapsulators within a PCN region used the uniform model of RFC2983 >(copying outer DSCP to inner). > >The disadvantage of using /only/ DSCPs to encode PCN are as follows: > >a) If an operator wants to have multiple PCN PHBs (e.g. for data >plane as well as signalled precedence for emergency traffic), it has >to use 1 more DSCP to /each/ PHB in order to add termination and 1 >more /each/ to add admission marking. Whereas using 11 in the ECN >field for AM or TM requires only 1 DSCP per PHB. If an operator >wants AM and TM, and data plane precedence it seems to have no >choice but to use up multiple DSCPs, but at least it can use 11 in >the ECN field for one of the markings. > >b) If the operator uses equal cost multipath (ECMP) routing within >the PCN region, and the vendor's ECMP algorithm depends on the DSCP >in each packet, ideally we don't want to admission mark by changing >DSCPs because this will throw some packets of each flow onto >different routes, causing re-ordering. Ideally we don't want >termination marking to change DSCPs either, but given all the >constraints we might have to live with some packet re-ordering in >all flows until some have been terminated, as this is becoming a bit >of a corner case. > >In summary >---------- >It looks like we have two main option families left: >1/ use only the DSCP field for all PCN marking and the PCN ingress >would have to set the ECN field to 01 or 10. No PCN interior nodes >would change the ECN field. >2/ Use 01 or 10 in the ECN field for UM. Use 11 in the ECN field for >AM. Use an extra DSCP for TM. > >Option 2/ seems a slightly better compromise because of a) & b) above. > >In either case, use another DSCP for affected marking if it is >required at all (but see next email). > >If there's one lesson from this,... >-------------------------------- >...it's that encoding into a tightly constrained field should be >standardised very very carefully. Most of our problems come from all >the changes of mind concerning ECN that have happened over the >years, leaving us no space to manoeuvre between all the backward >compatibility constraints. > >That doesn't mean we should standardise slowly. But it does mean we >should get a design team of experts to focus on this one issue, all >locked in a room until they are all happy. That means now. On this issue. > >For instance, I believe Option 1/ would be better if we want to >allow for end-to-end ECN as well. But I haven't thought that all >through. And I also strongly believe that we shouldn't allow >adaptive codecs to use PCN unless they explicitly signal that they >are going to. Otherwise all PCN's admission control assurances >break. If endpoints explicitly signal they want to be adaptive, I >think we can manage forwarding ECN markings properly. > >Further reading? >---------------- >All the background to why ECN tunneling is like it is, and how it >will need to change in the future, is explained in the draft I did >for tsvwg on tunneling congestion notification, which I highlighted >to the PCN list at the time. Bruce Davie & David Black have been >helping with it and may become co-authors. > >TSVWG and the area directors agreed to put that I-D on hold until >the PCN w-g had got closer to a decision on encodings, but it was >written to help PCN in that task. It recently expired, because we >didn't think PCN encodings would take this long! You can still >access an archived copy from my publications page: > > >To save time you can cut to S.5 and onwards, if you just want to >know the encap/decap behaviours and the variants that you have to be >backward compatible with. Earlier sections explain why. Appendix A >specifically discusses PCN tunneling, but I hadn't thought the >encoding constrints through like I just did above. > >Essentially, discarding 00, 01 & 10 from the outer header was >unfortunately necessary in RFC3168 and RFC4301 for backward >compatibility with the first experimental RFC2481 ECN, which >satisfied possible concerns at the time about the ECN field being >abused as a covert channel from the public Internet into an IPSec >tunnel. Since then the security area has decided these concerns were >unwarranted and the risk can be managed. > >In the PCN sessions this week, I can repeat some of the slides from >the summary presentation of this I gave to the tsvwg last Jun: > >but I believe Toby will now be covering this in his slides anyway. > > >Bob > > >____________________________________________________________________________ >Bob Briscoe, Networks Research Centre, BT Research >B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 10 08:14:06 2008 Return-Path: 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 CF1C23A71EB; Mon, 10 Mar 2008 08:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.503 X-Spam-Level: X-Spam-Status: No, score=-100.503 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 tA6tGYorBE+V; Mon, 10 Mar 2008 08:14:06 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D955C28CF55; Mon, 10 Mar 2008 07:52:31 -0700 (PDT) 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 09EA43A6F2C for ; Mon, 10 Mar 2008 07:52:31 -0700 (PDT) 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 RkFgVrXiiCLi for ; Mon, 10 Mar 2008 07:52:25 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 9121529354E for ; Mon, 10 Mar 2008 05:21:25 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 12:19:04 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 12:19:04 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1205151543110; Mon, 10 Mar 2008 12:19:03 +0000 Received: from mut.jungle.bt.co.uk ([10.73.145.122]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m2ACItK3005864; Mon, 10 Mar 2008 12:19:00 GMT Message-Id: <200803101219.m2ACItK3005864@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Mar 2008 12:18:54 +0000 To: Georgios Karagiannis From: Bob Briscoe Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 10 Mar 2008 12:19:04.0094 (UTC) FILETIME=[EE1B43E0:01C882A8] Cc: PCN IETF list Subject: [PCN] How necessary is affected marking? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Georgios, Do you propose using Affected Marking (AfM) in ECMP cases to calculate the Admission Marking level or just the Termination Marking level? If both, I can see it seems to help in ECMP cases {but see Note 1}. But if AfM is only used for Termination, the case for Affected Marking (AfM) seems marginal. Because all packets that aren't Termination Marked (TM) will typically be Admission Marked (AM), so AM can serve the function of AfM. Of course, there may be one queue sending TM & AM to an egress and another sending only AM. So AfM would help in such cases. But that's a bit of a corner case to justify another codepoint. Without AfM, this would slow down flow termination, but it would still terminate the right amount of flows eventually. My question: Have you tried to quantify how likely it will be that AfM will be useful? I'm just wondering whether it is worth complicating the core PCN algorithm and encoding specs with AfM, or whether we should have a separate spec just about AfM. Then the main PCN specs can refer to AfM as an optional extra for any vendor who wants to do it. Cheers Bob --------- {Note 1}: However, the admission marking behaviour we are likely to standardise doesn't have a clear point where AM is on or off. It gets gradually greater. The egress can decide when the fraction of AM has passed a threshold for sufficient time (e.g. with an exponentially weighted moving average EWMA). But that seems quite complicated (but not impossible) for an interior node. I guess though that excess rate marking would also have to be able to detect when it had been marking sufficiently for sufficiently long to turn on AfM, and when to turn it off again. Have you documented a possible algorithm for these state change triggers anywhere? ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 10 08:16:59 2008 Return-Path: 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 3E84328D0BE; Mon, 10 Mar 2008 08:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.939 X-Spam-Level: X-Spam-Status: No, score=-98.939 tagged_above=-999 required=5 tests=[AWL=-1.402, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, MANGLED_TOOL=2.3, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 qRE0YzWqxc1p; Mon, 10 Mar 2008 08:16:56 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC00528DB39; Mon, 10 Mar 2008 07:56:21 -0700 (PDT) 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 A040028D140 for ; Mon, 10 Mar 2008 07:56:20 -0700 (PDT) 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 9DC+TualEUtt for ; Mon, 10 Mar 2008 07:56:14 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id BDC4F2932EC for ; Mon, 10 Mar 2008 04:56:22 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 11:54:00 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 11:54:01 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 120515003976; Mon, 10 Mar 2008 11:53:59 +0000 Received: from mut.jungle.bt.co.uk ([10.73.145.122]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m2ABrpBW004972; Mon, 10 Mar 2008 11:53:55 GMT Message-Id: <200803101153.m2ABrpBW004972@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Mar 2008 11:53:42 +0000 To: "CHAN, Kwok Ho" , "Georgios Karagiannis" , "MONCASTER, Toby" , Michael Menth From: Bob Briscoe Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 10 Mar 2008 11:54:01.0078 (UTC) FILETIME=[6E3D3960:01C882A5] Cc: PCN IETF list Subject: [PCN] PCN encoding options and tunnelling X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Kwok, George, Toby, Michael, I believe tunneling represents the greatest constraint on the choice of codepoints in the ECN field, so it nearly decides this issue for us... First I believe we have to allow for the likely possibility of a tunnel starting and ending within a PCN region (as in S.5.7 of the PCN arch I-D). For example, a multi-site VPN that is one big PCN region under one operator's control joined together over the public Internet by IPSec VPNs. If the customer-sites are part of the PCN region they could have typical paths across the VPN like this: Sender > PCN_ingress > IPSec_encap > IPSec_decap > PCN_egress > Receiver Then I suggest the following requirement sentence in S.2.2.7 of PCN encoding Comparision about tunnels: ============================================================================= "Tunnel endpoints, whether encapsulators or decapsulators, should not require any new behaviour to handle PCN-capable packets. Expecting vendors of all IPSec and all IP in IP tunnel endpoints to cater specifically for PCN would be unrealistic, and require complex backward compatibility rules for tunnels prior to PCN. If tunnels did require PCN-specific behaviour, the resulting patchy and error-prone deployment would probably cause PCN to suffer byzantine feature interactions with poorly implemented tunnels. Tunnel endpoints should not have to detect that a packet's DSCP is PCN and implement special PCN-specific encapsulating or decapsulating behaviour. The rules that already exist for tunnel endpoints to handle both the Diffserv field and the ECN field should 'just work' when handling packets with a PCN Diffserv codepoint." ============================================================================= That sounds reasonable, but it puts strong further constraints on our PCN encoding options. Decapsulation in both RFC3168 'full functionality [tunnelling] mode' and the old and new RFC4301 IPSec architecture discards all ECN codepoints in the outer header except 11, forwarding the inner header unchanged. If we find this leaves us with no PCN encoding options, we might have to require all tunnel decapsulators within a PCN region to be changed (as currently implied in S.5.7 of the PCN architecture), but let's see whether we have to first... With this constraint, it seems that none of 00, 01 or 10 of the ECN field can be used for encoding AM (admission marked) or TM (termination marked), without risking losing markings on decapsulation that were added to the outer header due to congestion in the middle of the tunnel. Further, 00 cannot be used for the unmarked (UM) state, because a tunnel decapsulator will drop a packet if the inner header is marked 00 and the outer anything but 11. That leaves only 01 or 10 for UM. So far, if we use the ECN field at all, we're left with 01 or 10 for the unmarked state and only 11 for anything else. Further, if either of 01 or 10 were used for UM, there would be a risk of losing the UM meaning if a tunnel straddled the PCN ingress but not the PCN egress, because the inner header is forwarded and the outer header discarded if the outer is 01 or 10. I think it would be reasonable for PCN standards to mandate that tunnel decapsulators take special account of PCN encodings if the encapsulator is not also in the region. We also now have to work around RFC5129 recently standardising ECN in MPLS (with discussion of PCN in an appendix). I don't think that constrains us further, but I'll check. I'll also check I can still do the anti-cheating trick I'm proposing if we re-charter for multiple domains (I suspect this will be hard now). Diffserv code points -------------------- For PCN to work at all, we would have to mandate that all tunnel decapsulators within a PCN region used the uniform model of RFC2983 (copying outer DSCP to inner). The disadvantage of using /only/ DSCPs to encode PCN are as follows: a) If an operator wants to have multiple PCN PHBs (e.g. for data plane as well as signalled precedence for emergency traffic), it has to use 1 more DSCP to /each/ PHB in order to add termination and 1 more /each/ to add admission marking. Whereas using 11 in the ECN field for AM or TM requires only 1 DSCP per PHB. If an operator wants AM and TM, and data plane precedence it seems to have no choice but to use up multiple DSCPs, but at least it can use 11 in the ECN field for one of the markings. b) If the operator uses equal cost multipath (ECMP) routing within the PCN region, and the vendor's ECMP algorithm depends on the DSCP in each packet, ideally we don't want to admission mark by changing DSCPs because this will throw some packets of each flow onto different routes, causing re-ordering. Ideally we don't want termination marking to change DSCPs either, but given all the constraints we might have to live with some packet re-ordering in all flows until some have been terminated, as this is becoming a bit of a corner case. In summary ---------- It looks like we have two main option families left: 1/ use only the DSCP field for all PCN marking and the PCN ingress would have to set the ECN field to 01 or 10. No PCN interior nodes would change the ECN field. 2/ Use 01 or 10 in the ECN field for UM. Use 11 in the ECN field for AM. Use an extra DSCP for TM. Option 2/ seems a slightly better compromise because of a) & b) above. In either case, use another DSCP for affected marking if it is required at all (but see next email). If there's one lesson from this,... -------------------------------- ...it's that encoding into a tightly constrained field should be standardised very very carefully. Most of our problems come from all the changes of mind concerning ECN that have happened over the years, leaving us no space to manoeuvre between all the backward compatibility constraints. That doesn't mean we should standardise slowly. But it does mean we should get a design team of experts to focus on this one issue, all locked in a room until they are all happy. That means now. On this issue. For instance, I believe Option 1/ would be better if we want to allow for end-to-end ECN as well. But I haven't thought that all through. And I also strongly believe that we shouldn't allow adaptive codecs to use PCN unless they explicitly signal that they are going to. Otherwise all PCN's admission control assurances break. If endpoints explicitly signal they want to be adaptive, I think we can manage forwarding ECN markings properly. Further reading? ---------------- All the background to why ECN tunneling is like it is, and how it will need to change in the future, is explained in the draft I did for tsvwg on tunneling congestion notification, which I highlighted to the PCN list at the time. Bruce Davie & David Black have been helping with it and may become co-authors. TSVWG and the area directors agreed to put that I-D on hold until the PCN w-g had got closer to a decision on encodings, but it was written to help PCN in that task. It recently expired, because we didn't think PCN encodings would take this long! You can still access an archived copy from my publications page: To save time you can cut to S.5 and onwards, if you just want to know the encap/decap behaviours and the variants that you have to be backward compatible with. Earlier sections explain why. Appendix A specifically discusses PCN tunneling, but I hadn't thought the encoding constrints through like I just did above. Essentially, discarding 00, 01 & 10 from the outer header was unfortunately necessary in RFC3168 and RFC4301 for backward compatibility with the first experimental RFC2481 ECN, which satisfied possible concerns at the time about the ECN field being abused as a covert channel from the public Internet into an IPSec tunnel. Since then the security area has decided these concerns were unwarranted and the risk can be managed. In the PCN sessions this week, I can repeat some of the slides from the summary presentation of this I gave to the tsvwg last Jun: but I believe Toby will now be covering this in his slides anyway. Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 10 08:46:03 2008 Return-Path: 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 A828A28D09B; Mon, 10 Mar 2008 08:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.671 X-Spam-Level: X-Spam-Status: No, score=-99.671 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 c5ImrnlQ+Igf; Mon, 10 Mar 2008 08:45:59 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60BAB28C8B1; Mon, 10 Mar 2008 08:20:16 -0700 (PDT) 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 8D4D228CFD3 for ; Mon, 10 Mar 2008 08:20:12 -0700 (PDT) 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 GdpE+P8KK8ei for ; Mon, 10 Mar 2008 08:20:10 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 8DA2528C63C for ; Mon, 10 Mar 2008 08:01:10 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id m2AEwcmB011096; Mon, 10 Mar 2008 15:58:48 +0100 (MET) Received: from 130.129.18.139 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Mon, 10 Mar 2008 14:58:37 +0000 To: "Bob Briscoe" Date: Mon, 10 Mar 2008 14:58:37 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <200803101219.m2ACItK3005864@bagheera.jungle.bt.co.uk> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 10 Mar 2008 15:58:49 +0100 (MET) Cc: PCN IETF list Subject: Re: [PCN] How necessary is affected marking? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Bob Please see in line! Best regards, Georgios On 3/10/2008, "Bob Briscoe" wrote: >Georgios, > >Do you propose using Affected Marking (AfM) in ECMP cases to >calculate the Admission Marking level or just the Termination Marking level? Georgios: I propose to use Affected Marking to solve the ECMP routing issues that occur during the flow termination process. >If both, I can see it seems to help in ECMP cases {but see Note 1}. > >But if AfM is only used for Termination, the case for Affected >Marking (AfM) seems marginal. Because all packets that aren't >Termination Marked (TM) will typically be Admission Marked (AM), so >AM can serve the function of AfM. Georgios: I do not think so, because, there might be situations where some nodes might operate in admission control state and others in termination state. Now consider that many flows belong to the same ingress-egress-aggregate. However, due to the ECMP routing problem, some of the flows can pass only through nodes operating in admission control state and other flows that belong to the same ingress-egress-aggregate can pass through nodes operating in termination state. If you use AM marking to solve the ECMp routing problem, then the egress will also terminate flows that just passed through nodes operating in admission control state, (and not operating in flow termination state). This will mean that flows that do not contribute to termination, will be terminated. This will not contribute on solving the severe congestion situatin. > >Of course, there may be one queue sending TM & AM to an egress and >another sending only AM. So AfM would help in such cases. But that's >a bit of a corner case to justify another codepoint. Without AfM, >this would slow down flow termination, but it would still terminate >the right amount of flows eventually. georgios: i do not think so! > >My question: Have you tried to quantify how likely it will be that >AfM will be useful? georgios: I have tried to do it, but the prblems that I have are related on etting reliable ECMP routing information. It will be great if we can get more accurate insight in the operation and performance related information of the ECMP routing. Can we get this information from operators that are using ECMp routing in their domains? if we do not have this information, to use it in simulations and/or performance analysis techniques, then the produced results from simulations and performance analysis could be useless. > >I'm just wondering whether it is worth complicating the core PCN >algorithm and encoding specs with AfM, or whether we should have a >separate spec just about AfM. Then the main PCN specs can refer to >AfM as an optional extra for any vendor who wants to do it. Georgios: I am in favour of separating the PCN base protocol from the ECMP solutions. Thus I am in favour of your proposed solution! Best regards, Georgios > >Cheers > > >Bob > >--------- >{Note 1}: However, the admission marking behaviour we are likely to >standardise doesn't have a clear point where AM is on or off. It gets >gradually greater. The egress can decide when the fraction of AM has >passed a threshold for sufficient time (e.g. with an exponentially >weighted moving average EWMA). But that seems quite complicated (but >not impossible) for an interior node. > >I guess though that excess rate marking would also have to be able to >detect when it had been marking sufficiently for sufficiently long to >turn on AfM, and when to turn it off again. Have you documented a >possible algorithm for these state change triggers anywhere? > > > >____________________________________________________________________________ >Bob Briscoe, Networks Research Centre, BT Research >B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 10 09:17:49 2008 Return-Path: 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 666F128C5F8; Mon, 10 Mar 2008 09:17:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.605 X-Spam-Level: X-Spam-Status: No, score=-100.605 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 lC86O2Nx1dZU; Mon, 10 Mar 2008 09:17:48 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BECD3A7025; Mon, 10 Mar 2008 08:51:02 -0700 (PDT) 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 5C69E3A7020 for ; Mon, 10 Mar 2008 08:51:01 -0700 (PDT) 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 DwDOVEjB2P30 for ; Mon, 10 Mar 2008 08:50:55 -0700 (PDT) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by core3.amsl.com (Postfix) with SMTP id 0717428CAF8 for ; Mon, 10 Mar 2008 08:28:45 -0700 (PDT) Received: (qmail 86961 invoked from network); 10 Mar 2008 15:26:25 -0000 Received: from unknown (HELO JAINX61) (rajain@sbcglobal.net@128.252.160.222 with login) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 10 Mar 2008 15:26:24 -0000 X-YMail-OSG: 2E2tONIVM1nf89VQbB8XEzNShuHFppq7bY9BPwFYfouYO55gzjLhpwv5oS6M49cJ2yIu737tFFs3zMYVCHU8.gNP8Qhx1df3ejpVItr2hpmrPG2BRYgaV.zPpQ4VpS3Hme8cDRxbYSVFN8OS X-Yahoo-Newman-Property: ymail-3 From: "Raj Jain" To: References: Date: Mon, 10 Mar 2008 10:26:23 -0500 Organization: Washington University in St. Louis Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AciBLa5OnyPP+J9USYCBPUk9/IkSfQBlChxQ In-Reply-To: Cc: 'Jinjing Jiang' , 'Jinjing Jiang' Subject: Re: [PCN] A Simple Analytical Model of PCN - Revised version X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: jain@cse.wustl.edu List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org We have now posted a revised version of our presentation on "A Simple Analytical Model of PCN" at: http://www.cse.wustl.edu/~jain/ietf/pcn0803.htm As indicated earlier, this version examines the issue of thrashing - when some flows are terminated while new ones are also accepted. We define a thrasing index and show how to minimize thrasing. Sensitivity of thrashing to termination threshold, probability of a flow being on (or off), and the link speed (which effects total number of flows) is examined. The results indicate that for small number of flows, the termination threshold should be significantly higher than the rejection threshold. For large number of flows (very high speed links), the two thresholds can be closer together. Thanks. -Raj Jain -----Original Message----- From: Raj Jain [mailto:jain@cse.wustl.edu] Sent: Saturday, March 08, 2008 9:04 AM To: 'pcn@ietf.org' Cc: 'Jinjing Jiang'; 'Jinjing Jiang' Subject: A Simple Analytical Model of PCN Analytical models often require simplifications but they provide good insights in to the effects of various parameters. With this view point, we have developed a simple model of PCN. We model n flows going through a single bottleneck where the packets are marked using a token bucket. The egress measures the rate of marked packets and sends it to the ingress point which makes a decision to reject new flows or to terminate existing flows. Currently the model assumes instantaneous feedback and infinite buffering (therefore no loss). The sources are modeled with exponentially distributed on/off period. We are able to get close form expressions for the rejection and termination probabilities for single marking case. An inital set of slides presenting the model are available at: http://www.cse.wustl.edu/~jain/ietf/pcn0803.htm We are still working on the presentation and, in the next few days, hope to add sensitivity analysis and the effect of various parameters on thrashing (when some flows are accepted while other flows are terminated). Comments are welcome. Thanks. -Jinjing Jiang and Raj Jain ----------------------------------------------------- Raj Jain, Ph.D., Fellow of IEEE, Fellow of ACM Professor of Computer Science and Engineering Washington University in St. Louis Campus Box 1045, One Brookings Drive St. Louis, MO 63130 Phone: +1 314 322 8092 Email: Jain@cse.wustl.edu URL: http://www.cse.wustl.edu/~jain Author of: "High Performance TCP/IP Networking" and "The Art of Computer Systems Performance Analysis" ------------------------------------------------------ _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 10 10:11:22 2008 Return-Path: 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 8AA7D28C3CB; Mon, 10 Mar 2008 10:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.699 X-Spam-Level: X-Spam-Status: No, score=-100.699 tagged_above=-999 required=5 tests=[AWL=1.138, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 PhaachvTtIsm; Mon, 10 Mar 2008 10:11:19 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A55F28C370; Mon, 10 Mar 2008 10:07:54 -0700 (PDT) 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 D4C7428C0DE for ; Mon, 10 Mar 2008 10:07:52 -0700 (PDT) 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 OAuVwLlmrsrg for ; Mon, 10 Mar 2008 10:07:51 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id D8EF63A6994 for ; Mon, 10 Mar 2008 09:58:06 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 16:55:39 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 16:55:32 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1205168132192; Mon, 10 Mar 2008 16:55:32 +0000 Received: from mut.jungle.bt.co.uk ([10.73.1.157]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m2AGtOUY019124; Mon, 10 Mar 2008 16:55:28 GMT Message-Id: <200803101655.m2AGtOUY019124@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Mar 2008 16:55:25 +0000 To: jain@cse.wustl.edu From: Bob Briscoe In-Reply-To: References: Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 10 Mar 2008 16:55:32.0939 (UTC) FILETIME=[8DD421B0:01C882CF] Cc: 'Jinjing Jiang' , pcn@ietf.org, 'Jinjing Jiang' Subject: Re: [PCN] A Simple Analytical Model of PCN - Revised version X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Raj, At 15:26 10/03/2008, Raj Jain wrote: >We have now posted a revised version of our presentation on "A Simple >Analytical Model of PCN" at: > >http://www.cse.wustl.edu/~jain/ietf/pcn0803.htm > >As indicated earlier, this version examines the issue of thrashing - when >some flows are terminated while new ones are also accepted. We define a >thrasing index and show how to minimize thrasing. Sensitivity of thrashing >to termination threshold, probability of a flow being on (or off), and the >link speed (which effects total number of flows) is examined. > >The results indicate that for small number of flows, the termination >threshold should be significantly higher than the rejection threshold. For >large number of flows (very high speed links), the two thresholds can be >closer together. I've had a quick scan - but in my acrobat reader a lot of the maths symbols come out rendered oddly - big greek letters and new paragraph symbols out of place in the middle of the slide. Do others get the same? I understand you'll be presenting this on Thur, so I'll defer comment until I understand better. Just a quick question: is the "no of flows" per edge-edge aggregate or per link? I think you are talking per aggregate, but just to be sure. Cheers Bob >Thanks. > >-Raj Jain > > >-----Original Message----- >From: Raj Jain [mailto:jain@cse.wustl.edu] >Sent: Saturday, March 08, 2008 9:04 AM >To: 'pcn@ietf.org' >Cc: 'Jinjing Jiang'; 'Jinjing Jiang' >Subject: A Simple Analytical Model of PCN > >Analytical models often require simplifications but they provide good >insights in to the effects of various parameters. With this view point, we >have developed a simple model of PCN. We model n flows going through a >single bottleneck where the packets are marked using a token bucket. The >egress measures the rate of marked packets and sends it to the ingress point >which makes a decision to reject new flows or to terminate existing flows. > >Currently the model assumes instantaneous feedback and infinite buffering >(therefore no loss). The sources are modeled with exponentially distributed >on/off period. We are able to get close form expressions for the rejection >and termination probabilities for single marking case. > >An inital set of slides presenting the model are available at: > >http://www.cse.wustl.edu/~jain/ietf/pcn0803.htm > >We are still working on the presentation and, in the next few days, hope to >add sensitivity analysis and the effect of various parameters on thrashing >(when some flows are accepted while other flows are terminated). > >Comments are welcome. > >Thanks. > >-Jinjing Jiang and Raj Jain >----------------------------------------------------- >Raj Jain, Ph.D., Fellow of IEEE, Fellow of ACM >Professor of Computer Science and Engineering >Washington University in St. Louis >Campus Box 1045, One Brookings Drive >St. Louis, MO 63130 >Phone: +1 314 322 8092 >Email: Jain@cse.wustl.edu >URL: http://www.cse.wustl.edu/~jain >Author of: "High Performance TCP/IP Networking" and "The Art of Computer >Systems Performance Analysis" >------------------------------------------------------ > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 10 10:21:56 2008 Return-Path: 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 CA01E3A6AEB; Mon, 10 Mar 2008 10:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.617 X-Spam-Level: X-Spam-Status: No, score=-102.617 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 AxMpXumfxWHr; Mon, 10 Mar 2008 10:21:51 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA90A3A69E8; Mon, 10 Mar 2008 10:21:30 -0700 (PDT) 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 56F093A6869 for ; Mon, 10 Mar 2008 10:21:29 -0700 (PDT) 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 CUGw-fmGj0HL for ; Mon, 10 Mar 2008 10:21:23 -0700 (PDT) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.179]) by core3.amsl.com (Postfix) with ESMTP id 1FD1C28C253 for ; Mon, 10 Mar 2008 10:19:29 -0700 (PDT) Received: by py-out-1112.google.com with SMTP id x19so2736710pyg.24 for ; Mon, 10 Mar 2008 10:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=BOTfHXeaxqDfy138j1Fz3ENyd8FqioBkRjZcA96AFuQ=; b=ArauDK9HRkNiv3NcHPVkHpd0FPqlfuNQEHoenjK16JZILxufywkRDiCb1DBBDptZP5k/MBY0ldwXvENm0APG/4yG8Q9fRD1kSH6oss44m+cL1GcZ9IaG0a6MXUOFQAq0y/f0AZBcOnSTZDQ2JS7tM9h1GXQGKXFZeFVrkiKOyvs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OW9WrOwozXDjkgvUQPsK3ln6v8qAyMpx2OMvYwvXVzJUUtEF9ugpwY9FSjxR1/N8mZpebpZZUtVFOkzUMKDNwRibUBPpNqlYac886QAhcjD/Io0f//9DpR17B8u/JDaY4gplNGWt0Ym0dGr+D5LRkd37e+wXZV2OIQJfugH4B7I= Received: by 10.65.252.13 with SMTP id e13mr10059813qbs.26.1205169425597; Mon, 10 Mar 2008 10:17:05 -0700 (PDT) Received: by 10.65.239.4 with HTTP; Mon, 10 Mar 2008 10:17:05 -0700 (PDT) Message-ID: Date: Mon, 10 Mar 2008 10:17:05 -0700 From: "Lachlan Andrew" To: "Bob Briscoe" In-Reply-To: <200803101655.m2AGtOUY019124@bagheera.jungle.bt.co.uk> MIME-Version: 1.0 Content-Disposition: inline References: <200803101655.m2AGtOUY019124@bagheera.jungle.bt.co.uk> Cc: Jinjing Jiang , pcn@ietf.org, jain@cse.wustl.edu, Jinjing Jiang Subject: Re: [PCN] A Simple Analytical Model of PCN - Revised version X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org On 10/03/2008, Bob Briscoe wrote: > > In my acrobat reader a lot of the maths > symbols come out rendered oddly - big greek letters and new paragraph > symbols out of place in the middle of the slide. Do others get the same? Yes. Lachlan -- Lachlan Andrew Dept of Computer Science, Caltech 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA Ph: +1 (626) 395-8820 Fax: +1 (626) 568-3603 http://netlab.caltech.edu/lachlan _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 10 10:33:07 2008 Return-Path: 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 8EB9228C0DE; Mon, 10 Mar 2008 10:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.185 X-Spam-Level: X-Spam-Status: No, score=-101.185 tagged_above=-999 required=5 tests=[AWL=-0.747, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 oTqfMsfmx+V4; Mon, 10 Mar 2008 10:33:06 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6B973A690C; Mon, 10 Mar 2008 10:33:04 -0700 (PDT) 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 A67683A6857 for ; Mon, 10 Mar 2008 10:33:02 -0700 (PDT) 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 1qFhcDGkBBMl for ; Mon, 10 Mar 2008 10:32:57 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id A4F3E3A68F3 for ; Mon, 10 Mar 2008 10:31:49 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m2AHTSS3025902; Mon, 10 Mar 2008 12:29:28 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 12:29:27 -0500 Received: from [127.0.0.1] ([147.117.168.117]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 12:29:27 -0500 From: Steven Blake To: Bob Briscoe In-Reply-To: <200803101153.m2ABrpBW004972@bagheera.jungle.bt.co.uk> References: <200803101153.m2ABrpBW004972@bagheera.jungle.bt.co.uk> Organization: Ericsson IP Infrastructure Date: Mon, 10 Mar 2008 13:29:26 -0400 Message-Id: <1205170166.2974.7.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) X-OriginalArrivalTime: 10 Mar 2008 17:29:27.0827 (UTC) FILETIME=[4AB76630:01C882D4] Cc: PCN IETF list Subject: Re: [PCN] PCN encoding options and tunnelling X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org A few comments on this note: On Mon, 2008-03-10 at 11:53 +0000, Bob Briscoe wrote: > Diffserv code points > -------------------- > For PCN to work at all, we would have to mandate that all tunnel > decapsulators within a PCN region used the uniform model of RFC2983 > (copying outer DSCP to inner). > > The disadvantage of using /only/ DSCPs to encode PCN are as follows: > > a) If an operator wants to have multiple PCN PHBs (e.g. for data > plane as well as signalled precedence for emergency traffic), it has > to use 1 more DSCP to /each/ PHB in order to add termination and 1 > more /each/ to add admission marking. Whereas using 11 in the ECN > field for AM or TM requires only 1 DSCP per PHB. If an operator wants > AM and TM, and data plane precedence it seems to have no choice but > to use up multiple DSCPs, but at least it can use 11 in the ECN field > for one of the markings. Dealing with emergency traffic is strictly out of scope for PCN at this time. With that said, wouldn't the flow precedence be included in the flow signaling? I confess to being really ignorant on all of the work that went on in IEPREP. In general, excluding the possibility of conveying flow admission/termination precedence in the DSCP bits, there are only so many managed-to-almost-never-be-congested BAs that are needed in a network. > b) If the operator uses equal cost multipath (ECMP) routing within > the PCN region, and the vendor's ECMP algorithm depends on the DSCP > in each packet, ideally we don't want to admission mark by changing > DSCPs because this will throw some packets of each flow onto > different routes, causing re-ordering. Ideally we don't want > termination marking to change DSCPs either, but given all the > constraints we might have to live with some packet re-ordering in all > flows until some have been terminated, as this is becoming a bit of a > corner case. Using DSCP (or any other router-mutable field) for ECMP hashing is broken on so many levels. Do we have evidence that any vendor has actually implemented this? Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 10 10:36:16 2008 Return-Path: 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 C47F83A6B57; Mon, 10 Mar 2008 10:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.161 X-Spam-Level: X-Spam-Status: No, score=-102.161 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 y3ZhSM8ZhiBc; Mon, 10 Mar 2008 10:36:12 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F016D3A68F3; Mon, 10 Mar 2008 10:36:12 -0700 (PDT) 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 3A2263A68F3 for ; Mon, 10 Mar 2008 10:36:12 -0700 (PDT) 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 Vq8FYiIH98Nh for ; Mon, 10 Mar 2008 10:36:08 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 445D23A67F8 for ; Mon, 10 Mar 2008 10:36:08 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m2AHXkSt028813; Mon, 10 Mar 2008 12:33:47 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 12:33:46 -0500 Received: from [127.0.0.1] ([147.117.168.117]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 12:33:45 -0500 From: Steven Blake To: Lachlan Andrew In-Reply-To: References: <200803101655.m2AGtOUY019124@bagheera.jungle.bt.co.uk> Organization: Ericsson IP Infrastructure Date: Mon, 10 Mar 2008 13:33:44 -0400 Message-Id: <1205170424.2974.11.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) X-OriginalArrivalTime: 10 Mar 2008 17:33:46.0150 (UTC) FILETIME=[E4B05C60:01C882D4] Cc: pcn Subject: Re: [PCN] A Simple Analytical Model of PCN - Revised version X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org On Mon, 2008-03-10 at 10:17 -0700, Lachlan Andrew wrote: > On 10/03/2008, Bob Briscoe wrote: > > > > In my acrobat reader a lot of the maths > > symbols come out rendered oddly - big greek letters and new paragraph > > symbols out of place in the middle of the slide. Do others get the same? > > Yes. It looks fine to me, using both acrobat and evince on Linux. For the purposes of an IETF meeting, having the math look like garbage might be better. :) Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 10 10:43:30 2008 Return-Path: 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 5932F3A6A12; Mon, 10 Mar 2008 10:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.228 X-Spam-Level: X-Spam-Status: No, score=-101.228 tagged_above=-999 required=5 tests=[AWL=-0.790, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 5FDoK+yFuoAp; Mon, 10 Mar 2008 10:43:29 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B92303A6B5A; Mon, 10 Mar 2008 10:43:25 -0700 (PDT) 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 DC4D93A6C51 for ; Mon, 10 Mar 2008 10:43:23 -0700 (PDT) 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 VYDle-KHvWbC for ; Mon, 10 Mar 2008 10:43:23 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id EE2A13A6B51 for ; Mon, 10 Mar 2008 10:42:23 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 17:40:02 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 10 Mar 2008 17:37:10 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA50332F82B@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN encoding options and tunnelling Thread-Index: AciCxLGBYJqJ/1yiTsG5BrY/HjJ98wAEK0BR References: <200803101153.m2ABrpBW004972@bagheera.jungle.bt.co.uk> From: To: , , , , X-OriginalArrivalTime: 10 Mar 2008 17:40:02.0976 (UTC) FILETIME=[C54B7200:01C882D5] Cc: pcn@ietf.org Subject: Re: [PCN] PCN encoding options and tunnelling X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org The disadvantage of using /only/ DSCPs to encode PCN are as follows: b) If the operator uses equal cost multipath (ECMP) routing within the PCN region, and the vendor's ECMP algorithm depends on the DSCP in each packet, ideally we don't want to admission mark by changing DSCPs because this will throw some packets of each flow onto different routes, causing re-ordering. [phil] to me this is not an "ideally" but a "critical". question is whether any ecmp algos actually do this, or prepared to run the risk that they might do in the future. Ideally we don't want termination marking to change DSCPs either, but given all the constraints we might have to live with some packet re-ordering in all flows until some have been terminated, as this is becoming a bit of a corner case. [phil] happy to call this "ideally". termination marking means things have gone wrong, so a penalty like re-ordering is less unacceptable. _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 10 10:54:36 2008 Return-Path: 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 585DD3A6CB4; Mon, 10 Mar 2008 10:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.978 X-Spam-Level: X-Spam-Status: No, score=-100.978 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 8un7Zh9d4P-M; Mon, 10 Mar 2008 10:54:35 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18BAE28C2E3; Mon, 10 Mar 2008 10:51:47 -0700 (PDT) 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 A320D3A69D7 for ; Mon, 10 Mar 2008 10:51:43 -0700 (PDT) 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 l8lS20mRugHe for ; Mon, 10 Mar 2008 10:51:38 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id F423228C370 for ; Mon, 10 Mar 2008 10:49:38 -0700 (PDT) Received: from OMTA04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA03.westchester.pa.mail.comcast.net with comcast id zNhq1Y0080ldTLk530Sz00; Mon, 10 Mar 2008 17:46:27 +0000 Received: from [192.168.1.120] ([69.250.217.163]) by OMTA04.westchester.pa.mail.comcast.net with comcast id zVnH1Y0053Y6jD93Q00000; Mon, 10 Mar 2008 17:47:18 +0000 X-Authority-Analysis: v=1.0 c=1 a=4JEPA5vNlEgA:10 a=75Xn_jvl1hQAJZ2pFfoA:9 a=1NBcD3-ltEynjkNVCF4lOoqaCiAA:4 a=WuK_CZDBSqoA:10 Message-Id: From: ken carlberg To: Steven Blake In-Reply-To: <1205170166.2974.7.camel@neutrino> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 10 Mar 2008 13:47:17 -0400 References: <200803101153.m2ABrpBW004972@bagheera.jungle.bt.co.uk> <1205170166.2974.7.camel@neutrino> X-Mailer: Apple Mail (2.919.2) Cc: PCN IETF list Subject: Re: [PCN] PCN encoding options and tunnelling X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org On Mar 10, 2008, at 1:29 PM, Steven Blake wrote: >> a) If an operator wants to have multiple PCN PHBs (e.g. for data >> plane as well as signalled precedence for emergency traffic), it has perhaps it would be a bit more agnostic to swap the above phrase "signalled precedence for emergency traffic" with "signaled priority traffic". Emergency is really just a motivation loosely associated with target level(s) of precedence, so I've always been a bit perplexed as to why it gets explicitly singled out in this group. On the other hand, prioritization is something more tangible that can be play a complementary role, imho, to what PCN is trying to achieve. -ken _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 10 11:04:19 2008 Return-Path: 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 0D4703A686C; Mon, 10 Mar 2008 11:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.023 X-Spam-Level: X-Spam-Status: No, score=-98.023 tagged_above=-999 required=5 tests=[AWL=-0.486, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, MANGLED_TOOL=2.3, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 pFJ6fFqWDa0k; Mon, 10 Mar 2008 11:04:15 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89F5D3A68B0; Mon, 10 Mar 2008 11:04:15 -0700 (PDT) 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 C9D683A684A for ; Mon, 10 Mar 2008 11:04:13 -0700 (PDT) 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 fxF1oG8Qg2B9 for ; Mon, 10 Mar 2008 11:04:11 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id AF4533A684E for ; Mon, 10 Mar 2008 11:04:10 -0700 (PDT) Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2AI1YP04645; Mon, 10 Mar 2008 18:01:34 GMT Received: from KCHAN-2K3.nortel.com ([47.16.102.92] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 14:01:29 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Mar 2008 14:01:28 -0400 To: "Kwok-Ho Chan" From: "Kwok-Ho Chan" In-Reply-To: References: <200803101153.m2ABrpBW004972@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 10 Mar 2008 18:01:29.0635 (UTC) FILETIME=[C4340730:01C882D8] Cc: PCN IETF list Subject: Re: [PCN] PCN encoding options and tunnelling X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi all: With the thinking indicated below, the notion of DiffServ tunnels indicated by RFC 2983 comes into play. As the encoding proposals we have uses DiffServ (with different numbers of DSCPs). IMHO, we should start with the simple case, the use of the "uniform model" indicated by section 3.1 on page 3 of RFC 2983, where the DSCP value of the inner header is copied to the outer header at the tunnel ingress, and the DSCP value of the outer header is copied to the inner header at the tunnel egress. Taking this simple view means the tunnel we are working with are Not PCN capable, the outer header does not receive any PCN modification. I think most tunnels we first encounter will not be PCN capable. Can we also indicate the tunnels we encounter be Not ECN capable? Will this be a show stopper? With PCN requiring DiffServ (as part of the charter and architecture). Can we safely say the complex case of either tunnel ingress or tunnel egress not supporting DiffServ not an issue with PCN and tunneling? I am just thinking we are adding too much complexity into the problem and want to bring it down to a more simple view. -- Kwok -- At 08:56 AM 3/10/2008, Kwok Ho Chan wrote: >Bob, all: >Why can't we consider the use of PCN as establishing a PCN VPN? >This view goes well with the use of DSCP to differentiate PCN >packets/traffic from all other >packets/traffic. With the definition of the PCN PHB as the behavior >for such a PCN VPN. >In essences, the PCN packets/traffic travels in a VPN "tunnel" defined for it. >This view allows clear definitions of: >1. PCN VPN support on a per domain basis. >2. SLAs for interfacing the PCN VPN between different domains. >3. How such a PCN VPN may be extended through multiple domains, >possibly end to end. > >With the PCN VPN thinking, the other non PCN packets/traffic can be >viewed as being packets >in VPNs/tunnels different from the PCN VPN/tunnel. Then the PCN >domain is the world inside >the PCN VPN. > >With such a PCN VPN in mind, I would like to ask: >1. How does the VPNs in use today need to consider the ECN bits? >2. How does the VPNs in use today need to worry about mixing of each >VPNs' packets/traffic > together and separating them? >3. Does the VPNs in use today have to worry about other VPNs/tunnels: > a. Starting the ingress end of one (or more) of the other > VPN/tunnel inside its VPN? > b. Endng the egress end of one (or more) of the other > VPN/tunnel inside its VPN? > c. Have both the ingress and egress endw of one (or more) of > the other VPN/tunnel inside its VPN? > If yes to any of the above, how are they being solved and can > PCN adopt the same solution? >4. Can SLAs be written to handle both the DSCP and ECN bits so they >are clearly defined > in the PCN VPN ingress and egress points (PCN domain edges)? > >I have the PCN VPN thinking in mind from the beginning and this is >the reason I support the >use of DiffServ and DSCP to separate the PCN packets/traffic from >the other packets/traffic. >Hopefully allowing many of the problems to be understood, solved, or >worked arounded. > >Section 2.2.7 on page 11 of >http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison-03.txt >have that thinking in mind and started putting some of the packet >"leakage" issues >as exceptions rather then the norm. > >Thanks! >-- Kwok -- > > >At 07:53 AM 3/10/2008, Bob Briscoe wrote: >>Kwok, George, Toby, Michael, >> >>I believe tunneling represents the greatest constraint on the >>choice of codepoints in the ECN field, so it nearly decides this >>issue for us... >> >>First I believe we have to allow for the likely possibility of a >>tunnel starting and ending within a PCN region (as in S.5.7 of the >>PCN arch I-D). For example, a multi-site VPN that is one big PCN >>region under one operator's control joined together over the public >>Internet by IPSec VPNs. If the customer-sites are part of the PCN >>region they could have typical paths across the VPN like this: >>Sender > PCN_ingress > IPSec_encap > IPSec_decap > PCN_egress > Receiver >> >>Then I suggest the following requirement sentence in S.2.2.7 of PCN >>encoding Comparision about tunnels: >>============================================================================= >>"Tunnel endpoints, whether encapsulators or decapsulators, should >>not require any new behaviour to handle PCN-capable packets. >>Expecting vendors of all IPSec and all IP in IP tunnel endpoints to >>cater specifically for PCN would be unrealistic, and require >>complex backward compatibility rules for tunnels prior to PCN. If >>tunnels did require PCN-specific behaviour, the resulting patchy >>and error-prone deployment would probably cause PCN to suffer >>byzantine feature interactions with poorly implemented tunnels. >> >>Tunnel endpoints should not have to detect that a packet's DSCP is >>PCN and implement special PCN-specific encapsulating or >>decapsulating behaviour. The rules that already exist for tunnel >>endpoints to handle both the Diffserv field and the ECN field >>should 'just work' when handling packets with a PCN Diffserv codepoint." >>============================================================================= >> >>That sounds reasonable, but it puts strong further constraints on >>our PCN encoding options. Decapsulation in both RFC3168 'full >>functionality [tunnelling] mode' and the old and new RFC4301 IPSec >>architecture discards all ECN codepoints in the outer header except >>11, forwarding the inner header unchanged. >> >>If we find this leaves us with no PCN encoding options, we might >>have to require all tunnel decapsulators within a PCN region to be >>changed (as currently implied in S.5.7 of the PCN architecture), >>but let's see whether we have to first... >> >>With this constraint, it seems that none of 00, 01 or 10 of the ECN >>field can be used for encoding AM (admission marked) or TM >>(termination marked), without risking losing markings on >>decapsulation that were added to the outer header due to congestion >>in the middle of the tunnel. >> >>Further, 00 cannot be used for the unmarked (UM) state, because a >>tunnel decapsulator will drop a packet if the inner header is >>marked 00 and the outer anything but 11. That leaves only 01 or 10 for UM. >> >>So far, if we use the ECN field at all, we're left with 01 or 10 >>for the unmarked state and only 11 for anything else. >> >>Further, if either of 01 or 10 were used for UM, there would be a >>risk of losing the UM meaning if a tunnel straddled the PCN ingress >>but not the PCN egress, because the inner header is forwarded and >>the outer header discarded if the outer is 01 or 10. I think it >>would be reasonable for PCN standards to mandate that tunnel >>decapsulators take special account of PCN encodings if the >>encapsulator is not also in the region. >> >>We also now have to work around RFC5129 recently standardising ECN >>in MPLS (with discussion of PCN in an appendix). I don't think that >>constrains us further, but I'll check. I'll also check I can still >>do the anti-cheating trick I'm proposing if we re-charter for >>multiple domains (I suspect this will be hard now). >> >>Diffserv code points >>-------------------- >>For PCN to work at all, we would have to mandate that all tunnel >>decapsulators within a PCN region used the uniform model of RFC2983 >>(copying outer DSCP to inner). >> >>The disadvantage of using /only/ DSCPs to encode PCN are as follows: >> >>a) If an operator wants to have multiple PCN PHBs (e.g. for data >>plane as well as signalled precedence for emergency traffic), it >>has to use 1 more DSCP to /each/ PHB in order to add termination >>and 1 more /each/ to add admission marking. Whereas using 11 in the >>ECN field for AM or TM requires only 1 DSCP per PHB. If an operator >>wants AM and TM, and data plane precedence it seems to have no >>choice but to use up multiple DSCPs, but at least it can use 11 in >>the ECN field for one of the markings. >> >>b) If the operator uses equal cost multipath (ECMP) routing within >>the PCN region, and the vendor's ECMP algorithm depends on the DSCP >>in each packet, ideally we don't want to admission mark by changing >>DSCPs because this will throw some packets of each flow onto >>different routes, causing re-ordering. Ideally we don't want >>termination marking to change DSCPs either, but given all the >>constraints we might have to live with some packet re-ordering in >>all flows until some have been terminated, as this is becoming a >>bit of a corner case. >> >>In summary >>---------- >>It looks like we have two main option families left: >>1/ use only the DSCP field for all PCN marking and the PCN ingress >>would have to set the ECN field to 01 or 10. No PCN interior nodes >>would change the ECN field. >>2/ Use 01 or 10 in the ECN field for UM. Use 11 in the ECN field >>for AM. Use an extra DSCP for TM. >> >>Option 2/ seems a slightly better compromise because of a) & b) above. >> >>In either case, use another DSCP for affected marking if it is >>required at all (but see next email). >> >>If there's one lesson from this,... >>-------------------------------- >>...it's that encoding into a tightly constrained field should be >>standardised very very carefully. Most of our problems come from >>all the changes of mind concerning ECN that have happened over the >>years, leaving us no space to manoeuvre between all the backward >>compatibility constraints. >> >>That doesn't mean we should standardise slowly. But it does mean we >>should get a design team of experts to focus on this one issue, all >>locked in a room until they are all happy. That means now. On this issue. >> >>For instance, I believe Option 1/ would be better if we want to >>allow for end-to-end ECN as well. But I haven't thought that all >>through. And I also strongly believe that we shouldn't allow >>adaptive codecs to use PCN unless they explicitly signal that they >>are going to. Otherwise all PCN's admission control assurances >>break. If endpoints explicitly signal they want to be adaptive, I >>think we can manage forwarding ECN markings properly. >> >>Further reading? >>---------------- >>All the background to why ECN tunneling is like it is, and how it >>will need to change in the future, is explained in the draft I did >>for tsvwg on tunneling congestion notification, which I highlighted >>to the PCN list at the time. Bruce Davie & David Black have been >>helping with it and may become co-authors. >> >>TSVWG and the area directors agreed to put that I-D on hold until >>the PCN w-g had got closer to a decision on encodings, but it was >>written to help PCN in that task. It recently expired, because we >>didn't think PCN encodings would take this long! You can still >>access an archived copy from my publications page: >> >> >>To save time you can cut to S.5 and onwards, if you just want to >>know the encap/decap behaviours and the variants that you have to >>be backward compatible with. Earlier sections explain why. Appendix >>A specifically discusses PCN tunneling, but I hadn't thought the >>encoding constrints through like I just did above. >> >>Essentially, discarding 00, 01 & 10 from the outer header was >>unfortunately necessary in RFC3168 and RFC4301 for backward >>compatibility with the first experimental RFC2481 ECN, which >>satisfied possible concerns at the time about the ECN field being >>abused as a covert channel from the public Internet into an IPSec >>tunnel. Since then the security area has decided these concerns >>were unwarranted and the risk can be managed. >> >>In the PCN sessions this week, I can repeat some of the slides from >>the summary presentation of this I gave to the tsvwg last Jun: >> >>but I believe Toby will now be covering this in his slides anyway. >> >> >>Bob >> >> >>____________________________________________________________________________ >>Bob Briscoe, Networks Research Centre, BT Research >>B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 10 12:09:55 2008 Return-Path: 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 9826D3A6DD4; Mon, 10 Mar 2008 12:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.211 X-Spam-Level: X-Spam-Status: No, score=-100.211 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 4ko60JpUx47M; Mon, 10 Mar 2008 12:09:54 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54FD93A6E53; Mon, 10 Mar 2008 12:09:34 -0700 (PDT) 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 EC3F53A6E52 for ; Mon, 10 Mar 2008 12:09:31 -0700 (PDT) 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 Yxeg8nR4Dr-d for ; Mon, 10 Mar 2008 12:09:30 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 7DA0F28C402 for ; Mon, 10 Mar 2008 12:07:11 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id m2AJ4bxY029612; Mon, 10 Mar 2008 20:04:37 +0100 (MET) Received: from 130.129.16.162 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Mon, 10 Mar 2008 19:04:36 +0000 To: "Steven Blake" , "Bob Briscoe" Date: Mon, 10 Mar 2008 19:04:35 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <1205170166.2974.7.camel@neutrino> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 10 Mar 2008 20:04:49 +0100 (MET) Cc: PCN IETF list Subject: Re: [PCN] PCN encoding options and tunnelling X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi all Regarding the second issue on this point, i.e., when the PCN-domain is operating ECMP that uses DSCP to select the routes, a risk of mis-ordering of packets within a flow might occur. As mentioned already in the 03 version of the encoding draft, the impact of this drawback depends on the following: 1. the level of deployment of ECMP algorithms that use DSCP for route selection; 2. mis-ordering of packets within a flow when there is termination marking may be acceptable; 3. the possibility of configuring the ECMP algorithms that use DSCP for route selection in the PCN-domain, that the used PCN aware DSCPs are belonging to the same PHB and therefore, all these DSCP values should be converted to one preconfigured DSCP value before applying it in the ECMP routing algorithm. Note that all the additional experimental DSCPs that are used within PCN are belonging to the same PHB. In other words, if the DSCp based ECMP routing algorithm uses one DSCP hash value for all DSCPs that are belonging to the same PHB, then no misordering of packets will occur. Best regards, Georgios On 3/10/2008, "Steven Blake" wrote: >A few comments on this note: > >On Mon, 2008-03-10 at 11:53 +0000, Bob Briscoe wrote: > > >> Diffserv code points >> -------------------- >> For PCN to work at all, we would have to mandate that all tunnel >> decapsulators within a PCN region used the uniform model of RFC2983 >> (copying outer DSCP to inner). >> >> The disadvantage of using /only/ DSCPs to encode PCN are as follows: >> >> a) If an operator wants to have multiple PCN PHBs (e.g. for data >> plane as well as signalled precedence for emergency traffic), it has >> to use 1 more DSCP to /each/ PHB in order to add termination and 1 >> more /each/ to add admission marking. Whereas using 11 in the ECN >> field for AM or TM requires only 1 DSCP per PHB. If an operator wants >> AM and TM, and data plane precedence it seems to have no choice but >> to use up multiple DSCPs, but at least it can use 11 in the ECN field >> for one of the markings. > >Dealing with emergency traffic is strictly out of scope for PCN at this >time. With that said, wouldn't the flow precedence be included in the >flow signaling? I confess to being really ignorant on all of the work >that went on in IEPREP. > >In general, excluding the possibility of conveying flow >admission/termination precedence in the DSCP bits, there are only so >many managed-to-almost-never-be-congested BAs that are needed in a >network. > >> b) If the operator uses equal cost multipath (ECMP) routing within >> the PCN region, and the vendor's ECMP algorithm depends on the DSCP >> in each packet, ideally we don't want to admission mark by changing >> DSCPs because this will throw some packets of each flow onto >> different routes, causing re-ordering. Ideally we don't want >> termination marking to change DSCPs either, but given all the >> constraints we might have to live with some packet re-ordering in all >> flows until some have been terminated, as this is becoming a bit of a >> corner case. > >Using DSCP (or any other router-mutable field) for ECMP hashing is >broken on so many levels. Do we have evidence that any vendor has >actually implemented this? > > >Regards, > >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >Steven Blake >Ericsson/Redback Networks +1 919-472-9913 > >_______________________________________________ >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 From pcn-bounces@ietf.org Mon Mar 10 13:54:30 2008 Return-Path: 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 7828F3A6DD2; Mon, 10 Mar 2008 13:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.02 X-Spam-Level: X-Spam-Status: No, score=-100.02 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 O0sOwO9ClURj; Mon, 10 Mar 2008 13:54:29 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48C7A3A6D0F; Mon, 10 Mar 2008 13:54:24 -0700 (PDT) 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 505073A6A12 for ; Mon, 10 Mar 2008 13:54:23 -0700 (PDT) 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 ypq+Qlj34AEU for ; Mon, 10 Mar 2008 13:54:17 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 11EC83A6A78 for ; Mon, 10 Mar 2008 13:54:06 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 20:51:46 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 20:51:44 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1205182303858; Mon, 10 Mar 2008 20:51:43 +0000 Received: from mut.jungle.bt.co.uk ([10.73.80.15]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m2AKpCU9030984; Mon, 10 Mar 2008 20:51:42 GMT Message-Id: <200803102051.m2AKpCU9030984@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Mar 2008 18:30:14 +0000 To: Steven Blake From: Bob Briscoe In-Reply-To: <1205170166.2974.7.camel@neutrino> References: <200803101153.m2ABrpBW004972@bagheera.jungle.bt.co.uk> <1205170166.2974.7.camel@neutrino> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 10 Mar 2008 20:51:44.0576 (UTC) FILETIME=[8CC85400:01C882F0] Cc: PCN IETF list Subject: Re: [PCN] PCN encoding options and tunnelling X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Steven At 17:29 10/03/2008, Steven Blake wrote: >A few comments on this note: > >On Mon, 2008-03-10 at 11:53 +0000, Bob Briscoe wrote: > > > > Diffserv code points > > -------------------- > > For PCN to work at all, we would have to mandate that all tunnel > > decapsulators within a PCN region used the uniform model of RFC2983 > > (copying outer DSCP to inner). > > > > The disadvantage of using /only/ DSCPs to encode PCN are as follows: > > > > a) If an operator wants to have multiple PCN PHBs (e.g. for data > > plane as well as signalled precedence for emergency traffic), it has > > to use 1 more DSCP to /each/ PHB in order to add termination and 1 > > more /each/ to add admission marking. Whereas using 11 in the ECN > > field for AM or TM requires only 1 DSCP per PHB. If an operator wants > > AM and TM, and data plane precedence it seems to have no choice but > > to use up multiple DSCPs, but at least it can use 11 in the ECN field > > for one of the markings. > >Dealing with emergency traffic is strictly out of scope for PCN at this >time. I know - I should have said that - but we should also take into account what we might prevent by making choices. >With that said, wouldn't the flow precedence be included in the >flow signaling? I confess to being really ignorant on all of the work >that went on in IEPREP. Me too. We have (informally) spoken to an emergency calls agency that wants data plane precedence as well as signalling plane, but I don't know whether that would turn into a formal requirement. The issue is where a disaster is causing continuous disruptions, so that signalling precedence doesn't do enough to protect the data from continual changes in capacity as routes flap around. I take this requirement as one of those things it would be nice to enable, but if we can't do it, I suspect operators and agencies will live without it. >In general, excluding the possibility of conveying flow >admission/termination precedence in the DSCP bits, there are only so >many managed-to-almost-never-be-congested BAs that are needed in a >network. > > > b) If the operator uses equal cost multipath (ECMP) routing within > > the PCN region, and the vendor's ECMP algorithm depends on the DSCP > > in each packet, ideally we don't want to admission mark by changing > > DSCPs because this will throw some packets of each flow onto > > different routes, causing re-ordering. Ideally we don't want > > termination marking to change DSCPs either, but given all the > > constraints we might have to live with some packet re-ordering in all > > flows until some have been terminated, as this is becoming a bit of a > > corner case. > >Using DSCP (or any other router-mutable field) for ECMP hashing is >broken on so many levels. Do we have evidence that any vendor has >actually implemented this? Nope - I'll check around. Anyone on the list know? Bob >Regards, > >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >Steven Blake >Ericsson/Redback Networks +1 919-472-9913 ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 10 15:25:57 2008 Return-Path: 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 BEE3628C2C6; Mon, 10 Mar 2008 15:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.422 X-Spam-Level: X-Spam-Status: No, score=-100.422 tagged_above=-999 required=5 tests=[AWL=-0.585, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 ip6YnSMF2UDw; Mon, 10 Mar 2008 15:25:56 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6D2A28C104; Mon, 10 Mar 2008 15:25:56 -0700 (PDT) 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 7486C28C0F8 for ; Mon, 10 Mar 2008 15:25:55 -0700 (PDT) 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 GCusWDVftnaR for ; Mon, 10 Mar 2008 15:25:54 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 47EB428C104 for ; Mon, 10 Mar 2008 15:25:54 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Mar 2008 18:05:37 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 10 Mar 2008 18:00:36 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA50332F82E@E03MVZ1-UKDY.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Terminology Thread-Index: AciCHQi8ckkKAlUYTpa8QAFa8Yw2VgAu5wA8 References: <47D3DA95.7020504@informatik.uni-wuerzburg.de> From: To: X-OriginalArrivalTime: 10 Mar 2008 18:05:37.0413 (UTC) FILETIME=[57E3F350:01C882D9] Cc: pcn@ietf.org Subject: Re: [PCN] Terminology X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org michael i'll think about this, thanks - but quite reulctant to re-open discussion about terminology unless we really really need to, as we've already proven that it rat-holes. lars made a comment in his review about one section needing some re-phrasing in order to elegantly talk about single marking, so will think about that at the same time. phil ________________________________ From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] Sent: Sun 09/03/2008 12:39 To: Eardley,PL,Philip,CXR9 R Cc: pcn Subject: Terminology Hi Phil and others, I have some improvements for the high level description of PCN including some nomenclature. I suggest to rename the expressions o PCN-lower-rate: a reference rate configured for each link in the PCN-domain, which is lower than the PCN-upper-rate. It is used by a marking behaviour that determines whether a packet should be PCN-marked with a first encoding. o PCN-upper-rate: a reference rate configured for each link in the PCN-domain, which is higher than the PCN-lower-rate. It is used by a marking behaviour that determines whether a packet should be PCN-marked with a second encoding. o Admissible Rate (AR): a reference rate configured for each link in the PCN-domain. It's the rate up to which admission control should accept new flows. o Supportable Rate (SR): a reference rate configured for each link in the PCN-domain. It's the rate down to which flow termination should terminate already admitted flows if they cause overload. SR does not need to be given explicitly but also implicitly by SR=u*AR with the same value u for all links in the network. The new naming is very general and applicable to any existing proposal. It helps to make text more readable. The new expressions also help to qualify the types of pre-congestion and overload on a link in an intuitive way which is also easy to remember. Types of pre-congestion on a link: * No pre-congestion (NPC): PCN rate <= AR * AR-pre-congestion (ARPC): AR < PCN rate <= SR * SR-pre-congestion (SRPC): SR < PCN rate Types of overload on a link: * no overload (PCN rate <= AR) * AR-overload = PCN rate - AR (per link) * SR-overload = PCN rate - SR (per link) I have summarized the general PCN idea using this nomenclature on two PPT slides: http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/PCN-Description.ppt In contrast, the naming of the packet marking depends on the specific proposals and cannot be streamlined similarly as the semantics of the markings depends both on the metering and marking method connected with the AR and SR thresholds. * CL: unmarked, admission-marked (AM), termination-marked (TM) * 3sm: no-pre-congestion (NP), admission-stop (AS), excess-traffic (ET) * SM: unmarked, admission marked (AM) * LC-PCN: unmarked, "PCN_Marked", "Affected_Marked" From my point of view, it makes sense to adopt the new nomenclature concerning the general PCN idea in the architecture draft, but it currently does not make sense to harmonize the naming of the marking. I am already in Philadelphia and look forward to see you guys again at the welcome reception tonight. Regards, Michael -- 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 From pcn-bounces@ietf.org Mon Mar 10 18:09:31 2008 Return-Path: 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 40CFD3A6A92; Mon, 10 Mar 2008 18:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.007 X-Spam-Level: X-Spam-Status: No, score=-102.007 tagged_above=-999 required=5 tests=[AWL=0.430, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 e+6cjOFQVs37; Mon, 10 Mar 2008 18:09:29 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52D063A68EC; Mon, 10 Mar 2008 18:09:29 -0700 (PDT) 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 AF9CA3A68D9 for ; Mon, 10 Mar 2008 18:09:26 -0700 (PDT) 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 tAZjXY36MCV1 for ; Mon, 10 Mar 2008 18:09:25 -0700 (PDT) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.207]) by core3.amsl.com (Postfix) with SMTP id E137E3A6851 for ; Mon, 10 Mar 2008 18:09:24 -0700 (PDT) Received: (qmail 4806 invoked from network); 11 Mar 2008 01:07:04 -0000 Received: from unknown (HELO JAINX61) (rajain@sbcglobal.net@128.252.160.222 with login) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 11 Mar 2008 01:07:04 -0000 X-YMail-OSG: 45tQRKwVM1kNtJJq6BaDy_q5VPyCMmDvVCFaK9ji4Ate8wRELSvowP2QLBHObZAGpoaH87lG.0_yA2Bcs_MzhF2tKx3yfNpkFRbmhPcEzXQwkid_Zvv8Ms_w1S98gA-- X-Yahoo-Newman-Property: ymail-3 From: "Raj Jain" To: "'Lachlan Andrew'" , "'Bob Briscoe'" References: <200803101655.m2AGtOUY019124@bagheera.jungle.bt.co.uk> Date: Mon, 10 Mar 2008 20:06:49 -0500 Organization: Washington University in St. Louis Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-index: AciC0pJXdNqBt8qmSDmHzyzxlNj+UgAPsEXg In-Reply-To: Cc: 'Jinjing Jiang' , pcn@ietf.org Subject: Re: [PCN] A Simple Analytical Model of PCN - Revised version X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: jain@cse.wustl.edu List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Lachlan and Bob, Thanks for pointing out the issues with pdf. I have now replaced the pdfs with a different version. Same URL: http://www.cse.wustl.edu/~jain/ietf/pcn0803.htm No change in contents. If anyone finds problems with the symbols and equations in this version, please do let me know. Thanks. -Raj Jain -----Original Message----- From: Lachlan Andrew [mailto:lachlan.andrew@gmail.com] Sent: Monday, March 10, 2008 12:17 PM To: Bob Briscoe Cc: jain@cse.wustl.edu; Jinjing Jiang; pcn@ietf.org; Jinjing Jiang Subject: Re: [PCN] A Simple Analytical Model of PCN - Revised version On 10/03/2008, Bob Briscoe wrote: > > In my acrobat reader a lot of the maths symbols come out rendered > oddly - big greek letters and new paragraph symbols out of place in > the middle of the slide. Do others get the same? Yes. Lachlan -- Lachlan Andrew Dept of Computer Science, Caltech 1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA Ph: +1 (626) 395-8820 Fax: +1 (626) 568-3603 http://netlab.caltech.edu/lachlan _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 11 00:48:57 2008 Return-Path: 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 0BD8C3A6CA6; Tue, 11 Mar 2008 00:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.789 X-Spam-Level: X-Spam-Status: No, score=-102.789 tagged_above=-999 required=5 tests=[AWL=-0.352, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 n74QAmlHh8PK; Tue, 11 Mar 2008 00:48:56 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17B0428C0F4; Tue, 11 Mar 2008 00:48:56 -0700 (PDT) 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 724CE3A6834 for ; Tue, 11 Mar 2008 00:48:54 -0700 (PDT) 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 Pla9S2-qInmp for ; Tue, 11 Mar 2008 00:48:53 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id EEC383A6CA3 for ; Tue, 11 Mar 2008 00:48:52 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail21.telekom.de with ESMTP; Tue, 11 Mar 2008 08:46:30 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Mar 2008 08:46:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 11 Mar 2008 08:47:46 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CEF5461@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] A Simple Analytical Model of PCN - Revised version Thread-Index: AciC0pJXdNqBt8qmSDmHzyzxlNj+UgAPsEXgAA566+A= References: <200803101655.m2AGtOUY019124@bagheera.jungle.bt.co.uk> From: "Geib, Ruediger" To: , X-OriginalArrivalTime: 11 Mar 2008 07:46:30.0390 (UTC) FILETIME=[04F3D160:01C8834C] Cc: pcn@ietf.org Subject: Re: [PCN] A Simple Analytical Model of PCN - Revised version X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Raj, hi Lachlan, if I understood the presentation right, you propose single codepoint marking combined with excess marking. The admission stop and termination decisions are based on rate measurements. The PCN architecture document suggests to smooth rate counts in egress nodes by working with an exponentially weighted moving average. Did you apply EWMA? Regards, Rudiger | -----Original Message----- | From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On | Behalf Of Raj Jain | Sent: Tuesday, March 11, 2008 2:07 AM | To: 'Lachlan Andrew'; 'Bob Briscoe' | Cc: 'Jinjing Jiang'; pcn@ietf.org | Subject: Re: [PCN] A Simple Analytical Model of PCN - Revised version | | Lachlan and Bob, | | Thanks for pointing out the issues with pdf. | | I have now replaced the pdfs with a different version. | | Same URL: | http://www.cse.wustl.edu/~jain/ietf/pcn0803.htm | | No change in contents. | | If anyone finds problems with the symbols and equations in | this version, please do let me know. | | Thanks. | | -Raj Jain | | | | -----Original Message----- | From: Lachlan Andrew [mailto:lachlan.andrew@gmail.com] | Sent: Monday, March 10, 2008 12:17 PM | To: Bob Briscoe | Cc: jain@cse.wustl.edu; Jinjing Jiang; pcn@ietf.org; Jinjing Jiang | Subject: Re: [PCN] A Simple Analytical Model of PCN - Revised version | | On 10/03/2008, Bob Briscoe wrote: | > | > In my acrobat reader a lot of the maths symbols come out rendered | > oddly - big greek letters and new paragraph symbols out of | place in | > the middle of the slide. Do others get the same? | | Yes. | | Lachlan | | | -- | Lachlan Andrew Dept of Computer Science, Caltech 1200 E | California Blvd, Mail Code 256-80, Pasadena CA 91125, USA | Ph: +1 (626) 395-8820 Fax: +1 (626) 568-3603 | http://netlab.caltech.edu/lachlan | | _______________________________________________ | 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 From pcn-bounces@ietf.org Tue Mar 11 01:33:39 2008 Return-Path: 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 A2A7B3A6B66; Tue, 11 Mar 2008 01:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.14 X-Spam-Level: X-Spam-Status: No, score=-101.14 tagged_above=-999 required=5 tests=[AWL=-0.703, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 t2A8HIEwcfQN; Tue, 11 Mar 2008 01:33:38 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8981E3A6925; Tue, 11 Mar 2008 01:33:38 -0700 (PDT) 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 C10933A69AE for ; Tue, 11 Mar 2008 01:33:37 -0700 (PDT) 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 JEJJVSBcAeiW for ; Tue, 11 Mar 2008 01:33:36 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 1D5353A6925 for ; Tue, 11 Mar 2008 01:33:35 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Tue, 11 Mar 2008 09:31:13 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Mar 2008 09:31:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 11 Mar 2008 09:32:28 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CEF54A8@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN encoding options and tunnelling Thread-Index: AciC4k9kbRj+B8k8S2Snarv8avPWZgAbS5DQ References: <1205170166.2974.7.camel@neutrino> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 11 Mar 2008 08:31:12.0221 (UTC) FILETIME=[4372C0D0:01C88352] Cc: pcn@ietf.org Subject: Re: [PCN] PCN encoding options and tunnelling X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Georgios, all just to repeat: To the best of my knowledge, the configuration options on ECMP are - To activate it. - To define a balance other that "the same load to all links". As far as I'm aware of it - Nothing else is configurable. - Nothing else is documented. - Every implementation may differ with other hardware or operating system. - Different protocol and tunnel stacks may use different fields. Now PCN isn't the only WG noticing that ECMP is an important feature to many carriers and that these carriers may regard the implementation and documentation of ECMP as it is now as a show stopper for advanced innovative service deployments, network optimisation and so on. Rather then having the PCN WG just to construct another fragile but complex (or costly) workaround to deal with ECMP, it may be worth thinking about IETF to take up the issue and come to a more general solution to the problem. Make ECMP functionality a standard feature with standard documentation (where possible). There are limits to that, the hashing function will stay vendor specific. The fields across which to hash should however be standardised. Do the IETF officials on our list have a point of view on this? Regards, Rudiger | -----Original Message----- | From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On | Behalf Of Georgios Karagiannis | Sent: Monday, March 10, 2008 8:05 PM | To: Steven Blake; Bob Briscoe | Cc: PCN IETF list | Subject: Re: [PCN] PCN encoding options and tunnelling | | Hi all | | Regarding the second issue on this point, i.e., when the | PCN-domain is operating ECMP that uses DSCP to select the | routes, a risk of mis-ordering of packets within a flow might | occur. As mentioned already in the 03 version of the | encoding draft, the impact of this drawback depends on the following: | | 1. the level of deployment of ECMP algorithms that use DSCP for | route selection; | | | 2. mis-ordering of packets within a flow when there is | termination marking may be acceptable; | | 3. the possibility of configuring the ECMP algorithms that use | DSCP for route selection in the PCN-domain, that | the used PCN | aware DSCPs are belonging to the same PHB and therefore, all | these DSCP values should be converted to one preconfigured | DSCP value before applying it in the ECMP routing algorithm. | Note that all the additional experimental DSCPs | that are used | within PCN are belonging to the same PHB. | | In other words, if the DSCp based ECMP routing algorithm uses | one DSCP hash value for all DSCPs that are belonging to the | same PHB, then no misordering of packets will occur. | | Best regards, | Georgios | | On 3/10/2008, "Steven Blake" wrote: | | >A few comments on this note: | > | >On Mon, 2008-03-10 at 11:53 +0000, Bob Briscoe wrote: | > | > | >> Diffserv code points | >> -------------------- | >> For PCN to work at all, we would have to mandate that all tunnel | >> decapsulators within a PCN region used the uniform model | of RFC2983 | >> (copying outer DSCP to inner). | >> | >> The disadvantage of using /only/ DSCPs to encode PCN are | as follows: | >> | >> a) If an operator wants to have multiple PCN PHBs (e.g. for data | >> plane as well as signalled precedence for emergency | traffic), it has | >> to use 1 more DSCP to /each/ PHB in order to add termination and 1 | >> more /each/ to add admission marking. Whereas using 11 in the ECN | >> field for AM or TM requires only 1 DSCP per PHB. If an | operator wants | >> AM and TM, and data plane precedence it seems to have no | choice but | >> to use up multiple DSCPs, but at least it can use 11 in | the ECN field | >> for one of the markings. | > | >Dealing with emergency traffic is strictly out of scope for | PCN at this | >time. With that said, wouldn't the flow precedence be | included in the | >flow signaling? I confess to being really ignorant on all | of the work | >that went on in IEPREP. | > | >In general, excluding the possibility of conveying flow | >admission/termination precedence in the DSCP bits, there are only so | >many managed-to-almost-never-be-congested BAs that are needed in a | >network. | > | >> b) If the operator uses equal cost multipath (ECMP) routing within | >> the PCN region, and the vendor's ECMP algorithm depends on | the DSCP | >> in each packet, ideally we don't want to admission mark by | changing | >> DSCPs because this will throw some packets of each flow onto | >> different routes, causing re-ordering. Ideally we don't want | >> termination marking to change DSCPs either, but given all the | >> constraints we might have to live with some packet | re-ordering in all | >> flows until some have been terminated, as this is becoming | a bit of a | >> corner case. | > | >Using DSCP (or any other router-mutable field) for ECMP hashing is | >broken on so many levels. Do we have evidence that any vendor has | >actually implemented this? | > | > | >Regards, | > | >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | >Steven Blake | >Ericsson/Redback Networks +1 919-472-9913 | > | >_______________________________________________ | >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 | _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 11 04:34:25 2008 Return-Path: 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 56EAC3A69BF; Tue, 11 Mar 2008 04:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.696 X-Spam-Level: X-Spam-Status: No, score=-100.696 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 zH29ZY2AKRJs; Tue, 11 Mar 2008 04:34:21 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 413EC3A6AD3; Tue, 11 Mar 2008 04:34:21 -0700 (PDT) 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 874C63A6936 for ; Tue, 11 Mar 2008 04:34:19 -0700 (PDT) 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 a6PHSkk8soHp for ; Tue, 11 Mar 2008 04:34:13 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 4B01828C20C for ; Tue, 11 Mar 2008 04:34:13 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 511A5A0651; Tue, 11 Mar 2008 12:31:53 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 45022A0646; Tue, 11 Mar 2008 12:31:53 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id F1C9EA05FD; Tue, 11 Mar 2008 12:31:50 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m2BBVoV31128; Tue, 11 Mar 2008 12:31:50 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id E1697C8709; Tue, 11 Mar 2008 12:31:49 +0100 (CET) Message-ID: <47D66D6D.3030309@informatik.uni-wuerzburg.de> Date: Tue, 11 Mar 2008 12:30:53 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Geib, Ruediger" References: <1205170166.2974.7.camel@neutrino> <1B6169C658325341A3B8066E23919E1CEF54A8@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1B6169C658325341A3B8066E23919E1CEF54A8@S4DE8PSAANK.mitte.t-com.de> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] PCN encoding options and tunnelling X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi R=FCdiger, thanks again R=FCdiger for this input, it'll go right away in today's = session. We give very high priority to the problem that ECMP might = perform unintentioally rerouting as soon as the DSCP of a packet is = changed. Therefore, we pursue a solution that minimizes changing DSCPs. Regards, Michael Geib, Ruediger wrote: > Hi Georgios, all > > just to repeat: > > To the best of my knowledge, the configuration options on ECMP are > - To activate it. > - To define a balance other that "the same load to all links". > > As far as I'm aware of it > - Nothing else is configurable. > - Nothing else is documented. > - Every implementation may differ with other hardware = > or operating system. > - Different protocol and tunnel stacks may use = > different fields. > > Now PCN isn't the only WG noticing that ECMP is an important feature = > to many carriers and that these carriers may regard the implementation = > and documentation of ECMP as it is now as a show stopper for advanced = > innovative service deployments, network optimisation and so on. > > Rather then having the PCN WG just to construct another fragile but = > complex (or costly) workaround to deal with ECMP, it may be worth = > thinking about IETF to take up the issue and come to a more general > solution to the problem. Make ECMP functionality a standard feature = > with standard documentation (where possible). There are limits to = > that, the hashing function will stay vendor specific. The fields = > across which to hash should however be standardised. > > Do the IETF officials on our list have a point of view on this? > > Regards, > > Rudiger > > > | -----Original Message----- > | From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On = > | Behalf Of Georgios Karagiannis > | Sent: Monday, March 10, 2008 8:05 PM > | To: Steven Blake; Bob Briscoe > | Cc: PCN IETF list > | Subject: Re: [PCN] PCN encoding options and tunnelling > | = > | Hi all > | = > | Regarding the second issue on this point, i.e., when the = > | PCN-domain is operating ECMP that uses DSCP to select the = > | routes, a risk of mis-ordering of packets within a flow might = > | occur. As mentioned already in the 03 version of the = > | encoding draft, the impact of this drawback depends on the following: > | = > | 1. the level of deployment of ECMP algorithms that use DSCP for > | route selection; > | = > | = > | 2. mis-ordering of packets within a flow when there is > | termination marking may be acceptable; > | = > | 3. the possibility of configuring the ECMP algorithms that use > | DSCP for route selection in the PCN-domain, that = > | the used PCN > | aware DSCPs are belonging to the same PHB and therefore, all > | these DSCP values should be converted to one preconfigured > | DSCP value before applying it in the ECMP routing algorithm. > | Note that all the additional experimental DSCPs = > | that are used > | within PCN are belonging to the same PHB. > | = > | In other words, if the DSCp based ECMP routing algorithm uses = > | one DSCP hash value for all DSCPs that are belonging to the = > | same PHB, then no misordering of packets will occur. > | = > | Best regards, > | Georgios > | = > | On 3/10/2008, "Steven Blake" wrote: > | = > | >A few comments on this note: > | > > | >On Mon, 2008-03-10 at 11:53 +0000, Bob Briscoe wrote: > | > > | > > | >> Diffserv code points > | >> -------------------- > | >> For PCN to work at all, we would have to mandate that all tunnel = > | >> decapsulators within a PCN region used the uniform model = > | of RFC2983 = > | >> (copying outer DSCP to inner). > | >> > | >> The disadvantage of using /only/ DSCPs to encode PCN are = > | as follows: > | >> > | >> a) If an operator wants to have multiple PCN PHBs (e.g. for data = > | >> plane as well as signalled precedence for emergency = > | traffic), it has = > | >> to use 1 more DSCP to /each/ PHB in order to add termination and 1 = > | >> more /each/ to add admission marking. Whereas using 11 in the ECN = > | >> field for AM or TM requires only 1 DSCP per PHB. If an = > | operator wants = > | >> AM and TM, and data plane precedence it seems to have no = > | choice but = > | >> to use up multiple DSCPs, but at least it can use 11 in = > | the ECN field = > | >> for one of the markings. > | > > | >Dealing with emergency traffic is strictly out of scope for = > | PCN at this = > | >time. With that said, wouldn't the flow precedence be = > | included in the = > | >flow signaling? I confess to being really ignorant on all = > | of the work = > | >that went on in IEPREP. > | > > | >In general, excluding the possibility of conveying flow = > | >admission/termination precedence in the DSCP bits, there are only so = > | >many managed-to-almost-never-be-congested BAs that are needed in a = > | >network. > | > > | >> b) If the operator uses equal cost multipath (ECMP) routing within = > | >> the PCN region, and the vendor's ECMP algorithm depends on = > | the DSCP = > | >> in each packet, ideally we don't want to admission mark by = > | changing = > | >> DSCPs because this will throw some packets of each flow onto = > | >> different routes, causing re-ordering. Ideally we don't want = > | >> termination marking to change DSCPs either, but given all the = > | >> constraints we might have to live with some packet = > | re-ordering in all = > | >> flows until some have been terminated, as this is becoming = > | a bit of a = > | >> corner case. > | > > | >Using DSCP (or any other router-mutable field) for ECMP hashing is = > | >broken on so many levels. Do we have evidence that any vendor has = > | >actually implemented this? > | > > | > > | >Regards, > | > > | >=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D > | >Steven Blake > | >Ericsson/Redback Networks +1 919-472-9913 > | > > | >_______________________________________________ > | >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 > | = > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > = -- = 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 From pcn-bounces@ietf.org Tue Mar 11 05:59:33 2008 Return-Path: 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 CC9EC28C3A3; Tue, 11 Mar 2008 05:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.262 X-Spam-Level: X-Spam-Status: No, score=-100.262 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 5Z9DILUW35P6; Tue, 11 Mar 2008 05:59:32 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8942F28C38D; Tue, 11 Mar 2008 05:59:32 -0700 (PDT) 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 557C028C334 for ; Tue, 11 Mar 2008 05:59:31 -0700 (PDT) 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 GgOuC5w0FUcL for ; Tue, 11 Mar 2008 05:59:29 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 35EF528C29F for ; Tue, 11 Mar 2008 05:59:29 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id m2BCv8w1018671; Tue, 11 Mar 2008 13:57:08 +0100 (MET) Received: from 130.129.16.162 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Tue, 11 Mar 2008 12:57:08 +0000 To: "menth@informatik.uni-wuerzburg.de" , "Geib, Ruediger" Date: Tue, 11 Mar 2008 12:57:07 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <47D66D6D.3030309@informatik.uni-wuerzburg.de> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Tue, 11 Mar 2008 13:57:09 +0100 (MET) Cc: "pcn@ietf.org" Subject: Re: [PCN] PCN encoding options and tunnelling X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ruediger, Hi Michael As I mentioned in the email of yesterday, I think that the DSCP based ECMP routing problem can be solved very easily. if the DSCp based ECMP routing algorithm uses one DSCP hash value for all DSCPs that are belonging to the same PHB, then no misordering of packets will occur. See text sent yesterday: Regarding the second issue on this point, i.e., when the PCN-domain is operating ECMP that uses DSCP to select the routes, a risk of mis-ordering of packets within a flow might occur. As mentioned already in the 03 version of the encoding draft, the impact of this drawback depends on the following: 1. the level of deployment of ECMP algorithms that use DSCP for route selection; 2. mis-ordering of packets within a flow when there is termination marking may be acceptable; 3. the possibility of configuring the ECMP algorithms that use DSCP for route selection in the PCN-domain, that the used PCN aware DSCPs are belonging to the same PHB and therefore, all these DSCP values should be converted to one preconfigured DSCP value before applying it in the ECMP routing algorithm. Note that all the additional experimental DSCPs that are used within PCN are belonging to the same PHB. In other words, if the DSCp based ECMP routing algorithm uses one DSCP hash value for all DSCPs that are belonging to the same PHB, then no misordering of packets will occur. Best regards, Georgios On 3/11/2008, "Michael Menth" wrote: >Hi R=FCdiger, > >thanks again R=FCdiger for this input, it'll go right away in today's >session. We give very high priority to the problem that ECMP might >perform unintentioally rerouting as soon as the DSCP of a packet is >changed. Therefore, we pursue a solution that minimizes changing DSCPs. > >Regards, > > Michael > >Geib, Ruediger wrote: >> Hi Georgios, all >> >> just to repeat: >> >> To the best of my knowledge, the configuration options on ECMP are >> - To activate it. >> - To define a balance other that "the same load to all links". >> >> As far as I'm aware of it >> - Nothing else is configurable. >> - Nothing else is documented. >> - Every implementation may differ with other hardware >> or operating system. >> - Different protocol and tunnel stacks may use >> different fields. >> >> Now PCN isn't the only WG noticing that ECMP is an important feature >> to many carriers and that these carriers may regard the implementation >> and documentation of ECMP as it is now as a show stopper for advanced >> innovative service deployments, network optimisation and so on. >> >> Rather then having the PCN WG just to construct another fragile but >> complex (or costly) workaround to deal with ECMP, it may be worth >> thinking about IETF to take up the issue and come to a more general >> solution to the problem. Make ECMP functionality a standard feature >> with standard documentation (where possible). There are limits to >> that, the hashing function will stay vendor specific. The fields >> across which to hash should however be standardised. >> >> Do the IETF officials on our list have a point of view on this? >> >> Regards, >> >> Rudiger >> >> >> | -----Original Message----- >> | From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On >> | Behalf Of Georgios Karagiannis >> | Sent: Monday, March 10, 2008 8:05 PM >> | To: Steven Blake; Bob Briscoe >> | Cc: PCN IETF list >> | Subject: Re: [PCN] PCN encoding options and tunnelling >> | >> | Hi all >> | >> | Regarding the second issue on this point, i.e., when the >> | PCN-domain is operating ECMP that uses DSCP to select the >> | routes, a risk of mis-ordering of packets within a flow might >> | occur. As mentioned already in the 03 version of the >> | encoding draft, the impact of this drawback depends on the following: >> | >> | 1. the level of deployment of ECMP algorithms that use DSCP for >> | route selection; >> | >> | >> | 2. mis-ordering of packets within a flow when there is >> | termination marking may be acceptable; >> | >> | 3. the possibility of configuring the ECMP algorithms that use >> | DSCP for route selection in the PCN-domain, that >> | the used PCN >> | aware DSCPs are belonging to the same PHB and therefore, all >> | these DSCP values should be converted to one preconfigured >> | DSCP value before applying it in the ECMP routing algorithm. >> | Note that all the additional experimental DSCPs >> | that are used >> | within PCN are belonging to the same PHB. >> | >> | In other words, if the DSCp based ECMP routing algorithm uses >> | one DSCP hash value for all DSCPs that are belonging to the >> | same PHB, then no misordering of packets will occur. >> | >> | Best regards, >> | Georgios >> | >> | On 3/10/2008, "Steven Blake" wrote: >> | >> | >A few comments on this note: >> | > >> | >On Mon, 2008-03-10 at 11:53 +0000, Bob Briscoe wrote: >> | > >> | > >> | >> Diffserv code points >> | >> -------------------- >> | >> For PCN to work at all, we would have to mandate that all tunnel >> | >> decapsulators within a PCN region used the uniform model >> | of RFC2983 >> | >> (copying outer DSCP to inner). >> | >> >> | >> The disadvantage of using /only/ DSCPs to encode PCN are >> | as follows: >> | >> >> | >> a) If an operator wants to have multiple PCN PHBs (e.g. for data >> | >> plane as well as signalled precedence for emergency >> | traffic), it has >> | >> to use 1 more DSCP to /each/ PHB in order to add termination and 1 >> | >> more /each/ to add admission marking. Whereas using 11 in the ECN >> | >> field for AM or TM requires only 1 DSCP per PHB. If an >> | operator wants >> | >> AM and TM, and data plane precedence it seems to have no >> | choice but >> | >> to use up multiple DSCPs, but at least it can use 11 in >> | the ECN field >> | >> for one of the markings. >> | > >> | >Dealing with emergency traffic is strictly out of scope for >> | PCN at this >> | >time. With that said, wouldn't the flow precedence be >> | included in the >> | >flow signaling? I confess to being really ignorant on all >> | of the work >> | >that went on in IEPREP. >> | > >> | >In general, excluding the possibility of conveying flow >> | >admission/termination precedence in the DSCP bits, there are only so >> | >many managed-to-almost-never-be-congested BAs that are needed in a >> | >network. >> | > >> | >> b) If the operator uses equal cost multipath (ECMP) routing within >> | >> the PCN region, and the vendor's ECMP algorithm depends on >> | the DSCP >> | >> in each packet, ideally we don't want to admission mark by >> | changing >> | >> DSCPs because this will throw some packets of each flow onto >> | >> different routes, causing re-ordering. Ideally we don't want >> | >> termination marking to change DSCPs either, but given all the >> | >> constraints we might have to live with some packet >> | re-ordering in all >> | >> flows until some have been terminated, as this is becoming >> | a bit of a >> | >> corner case. >> | > >> | >Using DSCP (or any other router-mutable field) for ECMP hashing is >> | >broken on so many levels. Do we have evidence that any vendor has >> | >actually implemented this? >> | > >> | > >> | >Regards, >> | > >> | >=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D >> | >Steven Blake >> | >Ericsson/Redback Networks +1 919-472-9913 >> | > >> | >_______________________________________________ >> | >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 >> | >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn >> > >-- >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 From pcn-bounces@ietf.org Tue Mar 11 06:31:27 2008 Return-Path: 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 2002528C3E3; Tue, 11 Mar 2008 06:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.052 X-Spam-Level: X-Spam-Status: No, score=-100.052 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 1wf8M8o6O+LI; Tue, 11 Mar 2008 06:31:26 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18E2528C1E6; Tue, 11 Mar 2008 06:31:26 -0700 (PDT) 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 0555A3A6DBF for ; Tue, 11 Mar 2008 06:31:25 -0700 (PDT) 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 iAFQDP09TOPN for ; Tue, 11 Mar 2008 06:31:18 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 92D003A6920 for ; Tue, 11 Mar 2008 06:31:17 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Mar 2008 13:28:57 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Mar 2008 13:28:57 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1205242136134; Tue, 11 Mar 2008 13:28:56 +0000 Received: from mut.jungle.bt.co.uk ([10.73.145.127]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m2BDSovK031235; Tue, 11 Mar 2008 13:28:53 GMT Message-Id: <200803111328.m2BDSovK031235@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 11 Mar 2008 13:28:50 +0000 To: "Georgios Karagiannis" From: Bob Briscoe In-Reply-To: References: <1205170166.2974.7.camel@neutrino> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 11 Mar 2008 13:28:57.0393 (UTC) FILETIME=[DBEBAA10:01C8837B] Cc: PCN IETF list Subject: Re: [PCN] PCN encoding options and tunnelling X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Georgios, On point 1, after speaking with vendor friends I'm inclined to agree with Steve Blake that it is unlikely any vendors do ECMP by hashing based on the (mutable) Diffserv field. On 2, misordering because of termination marking may be acceptable, but it's not ideal - it could break up the QoS of flows that are not going going to be terminated, which wouldn't be a good result. But if no-one does ECMP on the DS field, we're OK anyway. On 3, I can't imagine any vendor altering their ECMP algo just for PCN - again they're more likely not to do ECMP on the DS field in the first place. Bob At 19:04 10/03/2008, Georgios Karagiannis wrote: >Hi all > >Regarding the second issue on this point, i.e., when the PCN-domain is >operating ECMP that uses DSCP to select the routes, a risk of >mis-ordering of packets within a flow might occur. As mentioned already >in the 03 version of the encoding draft, the impact of this drawback >depends on the following: > > 1. the level of deployment of ECMP algorithms that use DSCP for > route selection; > > > 2. mis-ordering of packets within a flow when there is > termination marking may be acceptable; > > 3. the possibility of configuring the ECMP algorithms that use > DSCP for route selection in the PCN-domain, that the used PCN > aware DSCPs are belonging to the same PHB and therefore, all > these DSCP values should be converted to one preconfigured > DSCP value before applying it in the ECMP routing algorithm. > Note that all the additional experimental DSCPs that are used > within PCN are belonging to the same PHB. > >In other words, if the DSCp based ECMP routing algorithm uses one DSCP >hash value for all DSCPs that are belonging to the same PHB, then no >misordering of packets will occur. > >Best regards, >Georgios > >On 3/10/2008, "Steven Blake" wrote: > > >A few comments on this note: > > > >On Mon, 2008-03-10 at 11:53 +0000, Bob Briscoe wrote: > > > > > >> Diffserv code points > >> -------------------- > >> For PCN to work at all, we would have to mandate that all tunnel > >> decapsulators within a PCN region used the uniform model of RFC2983 > >> (copying outer DSCP to inner). > >> > >> The disadvantage of using /only/ DSCPs to encode PCN are as follows: > >> > >> a) If an operator wants to have multiple PCN PHBs (e.g. for data > >> plane as well as signalled precedence for emergency traffic), it has > >> to use 1 more DSCP to /each/ PHB in order to add termination and 1 > >> more /each/ to add admission marking. Whereas using 11 in the ECN > >> field for AM or TM requires only 1 DSCP per PHB. If an operator wants > >> AM and TM, and data plane precedence it seems to have no choice but > >> to use up multiple DSCPs, but at least it can use 11 in the ECN field > >> for one of the markings. > > > >Dealing with emergency traffic is strictly out of scope for PCN at this > >time. With that said, wouldn't the flow precedence be included in the > >flow signaling? I confess to being really ignorant on all of the work > >that went on in IEPREP. > > > >In general, excluding the possibility of conveying flow > >admission/termination precedence in the DSCP bits, there are only so > >many managed-to-almost-never-be-congested BAs that are needed in a > >network. > > > >> b) If the operator uses equal cost multipath (ECMP) routing within > >> the PCN region, and the vendor's ECMP algorithm depends on the DSCP > >> in each packet, ideally we don't want to admission mark by changing > >> DSCPs because this will throw some packets of each flow onto > >> different routes, causing re-ordering. Ideally we don't want > >> termination marking to change DSCPs either, but given all the > >> constraints we might have to live with some packet re-ordering in all > >> flows until some have been terminated, as this is becoming a bit of a > >> corner case. > > > >Using DSCP (or any other router-mutable field) for ECMP hashing is > >broken on so many levels. Do we have evidence that any vendor has > >actually implemented this? > > > > > >Regards, > > > >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > >Steven Blake > >Ericsson/Redback Networks +1 919-472-9913 > > > >_______________________________________________ > >PCN mailing list > >PCN@ietf.org > >https://www.ietf.org/mailman/listinfo/pcn ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 11 06:43:55 2008 Return-Path: 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 C9C3A3A69BF; Tue, 11 Mar 2008 06:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.881 X-Spam-Level: X-Spam-Status: No, score=-99.881 tagged_above=-999 required=5 tests=[AWL=-0.840, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 r3zkQBKS1qBQ; Tue, 11 Mar 2008 06:43:49 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9B3F3A6A75; Tue, 11 Mar 2008 06:43:49 -0700 (PDT) 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 6738C3A6A75 for ; Tue, 11 Mar 2008 06:43:49 -0700 (PDT) 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 RtzPaMzkc4w6 for ; Tue, 11 Mar 2008 06:43:48 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 836CA3A6903 for ; Tue, 11 Mar 2008 06:43:47 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Tue, 11 Mar 2008 14:41:07 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 11 Mar 2008 14:41:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 11 Mar 2008 14:42:23 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CEF5707@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN encoding options and tunnelling Thread-Index: AciDd3Qd0qIPg4zhSq2jW9hJ9AdskQABDc7Q References: <47D66D6D.3030309@informatik.uni-wuerzburg.de> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 11 Mar 2008 13:41:07.0191 (UTC) FILETIME=[8EEA0070:01C8837D] Cc: pcn@ietf.org Subject: Re: [PCN] PCN encoding options and tunnelling X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Georgios, I'm not sure, whether any of Deutsche Telekom's vendors uses the DSCP field = for ECMP. If one of these vendor did so, the easy solution proposed by you = is, that once Deutsche Telekom figured out which DSCP scheme we are going = to operate for PCN, we talk to this vendor, which will then adapt his = ECMP implementation. I'm not an expert on fast forwarding, so I can't judge = whether ECMP is implemented in hard- or software. "Easy" means, you are = sure it is software? Did I understand you right? Please also keep in mind, that larger carriers may have hierachical network = architectures. ECMP hops may be concatenated and the ECMP hashes need to = be different per router to make ECMP work correctly. To the best of my = knowledge, there's no signaling protocol and no ECMP management set up = exchanging or steering ECMP hashing within backbone routers. Regards, Rudiger | -----Original Message----- | From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On = | Behalf Of Georgios Karagiannis | Sent: Tuesday, March 11, 2008 1:57 PM | To: menth@informatik.uni-wuerzburg.de; Geib, R=FCdiger | Cc: pcn@ietf.org | Subject: Re: [PCN] PCN encoding options and tunnelling | = | Hi Ruediger, Hi Michael | = | As I mentioned in the email of yesterday, I think that the = | DSCP based ECMP routing problem can be solved very easily. | = | if the DSCp based ECMP routing algorithm uses one DSCP hash = | value for all DSCPs that are belonging to the same PHB, then = | no misordering of packets will occur. | = | See text sent yesterday: | = | Regarding the second issue on this point, i.e., when the = | PCN-domain is operating ECMP that uses DSCP to select the = | routes, a risk of mis-ordering of packets within a flow might = | occur. As mentioned already in the 03 version of the encoding = | draft, the impact of this drawback depends on the following: | = | 1. the level of deployment of ECMP algorithms that use DSCP for | route selection; | = | = | 2. mis-ordering of packets within a flow when there is | termination marking may be acceptable; | = | 3. the possibility of configuring the ECMP algorithms that use | DSCP for route selection in the PCN-domain, that the used PCN | aware DSCPs are belonging to the same PHB and therefore, all | these DSCP values should be converted to one preconfigured | DSCP value before applying it in the ECMP routing algorithm. | Note that all the additional experimental DSCPs that are used | within PCN are belonging to the same PHB. | = | In other words, if the DSCp based ECMP routing algorithm uses = | one DSCP hash value for all DSCPs that are belonging to the = | same PHB, then no misordering of packets will occur. | = | Best regards, | Georgios | = | = | = | On 3/11/2008, "Michael Menth" = | wrote: | = | >Hi R=FCdiger, | > | >thanks again R=FCdiger for this input, it'll go right away in today's = | >session. We give very high priority to the problem that ECMP might = | >perform unintentioally rerouting as soon as the DSCP of a packet is = | >changed. Therefore, we pursue a solution that minimizes = | changing DSCPs. | > | >Regards, | > | > Michael | > | >Geib, Ruediger wrote: | >> Hi Georgios, all | >> | >> just to repeat: | >> | >> To the best of my knowledge, the configuration options on ECMP are | >> - To activate it. | >> - To define a balance other that "the same load to all links". | >> | >> As far as I'm aware of it | >> - Nothing else is configurable. | >> - Nothing else is documented. | >> - Every implementation may differ with other hardware | >> or operating system. | >> - Different protocol and tunnel stacks may use | >> different fields. | >> | >> Now PCN isn't the only WG noticing that ECMP is an = | important feature = | >> to many carriers and that these carriers may regard the = | >> implementation and documentation of ECMP as it is now as a show = | >> stopper for advanced innovative service deployments, = | network optimisation and so on. | >> | >> Rather then having the PCN WG just to construct another = | fragile but = | >> complex (or costly) workaround to deal with ECMP, it may be worth = | >> thinking about IETF to take up the issue and come to a = | more general = | >> solution to the problem. Make ECMP functionality a = | standard feature = | >> with standard documentation (where possible). There are limits to = | >> that, the hashing function will stay vendor specific. The fields = | >> across which to hash should however be standardised. | >> | >> Do the IETF officials on our list have a point of view on this? | >> | >> Regards, | >> | >> Rudiger | >> | >> | >> | -----Original Message----- | >> | From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] = | On Behalf = | >> | Of Georgios Karagiannis | >> | Sent: Monday, March 10, 2008 8:05 PM | >> | To: Steven Blake; Bob Briscoe | >> | Cc: PCN IETF list | >> | Subject: Re: [PCN] PCN encoding options and tunnelling | >> | | >> | Hi all | >> | | >> | Regarding the second issue on this point, i.e., when the = | PCN-domain = | >> | is operating ECMP that uses DSCP to select the routes, a risk of = | >> | mis-ordering of packets within a flow might occur. As mentioned = | >> | already in the 03 version of the encoding draft, the = | impact of this = | >> | drawback depends on the following: | >> | | >> | 1. the level of deployment of ECMP algorithms = | that use DSCP for | >> | route selection; | >> | | >> | | >> | 2. mis-ordering of packets within a flow when there is | >> | termination marking may be acceptable; | >> | | >> | 3. the possibility of configuring the ECMP = | algorithms that use | >> | DSCP for route selection in the PCN-domain, = | that the used = | >> | PCN | >> | aware DSCPs are belonging to the same PHB and = | therefore, all | >> | these DSCP values should be converted to one = | preconfigured | >> | DSCP value before applying it in the ECMP = | routing algorithm. | >> | Note that all the additional experimental = | DSCPs that are = | >> | used | >> | within PCN are belonging to the same PHB. | >> | | >> | In other words, if the DSCp based ECMP routing algorithm = | uses one = | >> | DSCP hash value for all DSCPs that are belonging to the = | same PHB, = | >> | then no misordering of packets will occur. | >> | | >> | Best regards, | >> | Georgios | >> | | >> | On 3/10/2008, "Steven Blake" wrote: | >> | | >> | >A few comments on this note: | >> | > | >> | >On Mon, 2008-03-10 at 11:53 +0000, Bob Briscoe wrote: | >> | > | >> | > | >> | >> Diffserv code points | >> | >> -------------------- | >> | >> For PCN to work at all, we would have to mandate that = | all tunnel = | >> | >> decapsulators within a PCN region used the uniform model | >> | of RFC2983 | >> | >> (copying outer DSCP to inner). | >> | >> | >> | >> The disadvantage of using /only/ DSCPs to encode PCN are | >> | as follows: | >> | >> | >> | >> a) If an operator wants to have multiple PCN PHBs = | (e.g. for data = | >> | >> plane as well as signalled precedence for emergency | >> | traffic), it has | >> | >> to use 1 more DSCP to /each/ PHB in order to add = | termination and = | >> | >> 1 more /each/ to add admission marking. Whereas using = | 11 in the = | >> | >> ECN field for AM or TM requires only 1 DSCP per PHB. If an | >> | operator wants | >> | >> AM and TM, and data plane precedence it seems to have no | >> | choice but | >> | >> to use up multiple DSCPs, but at least it can use 11 in | >> | the ECN field | >> | >> for one of the markings. | >> | > | >> | >Dealing with emergency traffic is strictly out of scope for | >> | PCN at this | >> | >time. With that said, wouldn't the flow precedence be | >> | included in the | >> | >flow signaling? I confess to being really ignorant on all | >> | of the work | >> | >that went on in IEPREP. | >> | > | >> | >In general, excluding the possibility of conveying flow = | >> | >admission/termination precedence in the DSCP bits, = | there are only = | >> | >so many managed-to-almost-never-be-congested BAs that = | are needed = | >> | >in a network. | >> | > | >> | >> b) If the operator uses equal cost multipath (ECMP) routing = | >> | >> within the PCN region, and the vendor's ECMP = | algorithm depends = | >> | >> on | >> | the DSCP | >> | >> in each packet, ideally we don't want to admission mark by | >> | changing | >> | >> DSCPs because this will throw some packets of each flow onto = | >> | >> different routes, causing re-ordering. Ideally we don't want = | >> | >> termination marking to change DSCPs either, but given all the = | >> | >> constraints we might have to live with some packet | >> | re-ordering in all | >> | >> flows until some have been terminated, as this is becoming | >> | a bit of a | >> | >> corner case. | >> | > | >> | >Using DSCP (or any other router-mutable field) for ECMP = | hashing is = | >> | >broken on so many levels. Do we have evidence that any = | vendor has = | >> | >actually implemented this? | >> | > | >> | > | >> | >Regards, | >> | > | >> | >=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D | >> | >Steven Blake | >> | >Ericsson/Redback Networks +1 919-472-9913 | >> | > | >> | >_______________________________________________ | >> | >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 | >> | | >> _______________________________________________ | >> PCN mailing list | >> PCN@ietf.org | >> https://www.ietf.org/mailman/listinfo/pcn | >> | > | >-- | >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 From pcn-bounces@ietf.org Tue Mar 11 11:06:36 2008 Return-Path: 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 974DE28C250; Tue, 11 Mar 2008 11:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.517 X-Spam-Level: X-Spam-Status: No, score=-103.517 tagged_above=-999 required=5 tests=[AWL=-3.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 pM2z5MpC-L51; Tue, 11 Mar 2008 11:06:35 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DB8528C23C; Tue, 11 Mar 2008 11:06:35 -0700 (PDT) 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 B23183A6974 for ; Tue, 11 Mar 2008 11:06:33 -0700 (PDT) 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 EgH4zPKfEa4K for ; Tue, 11 Mar 2008 11:06:32 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 971933A69E6 for ; Tue, 11 Mar 2008 11:06:32 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m2BI49ZS031038 for ; Tue, 11 Mar 2008 13:04:12 -0500 Received: from eusrcmw720.eamcs.ericsson.se ([138.85.77.20]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Mar 2008 13:04:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 11 Mar 2008 13:04:10 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Scribes for PCN meetings Thread-Index: AciDok7590IH7ereS5SHRXoiLYNaww== From: "Steve Blake" To: X-OriginalArrivalTime: 11 Mar 2008 18:04:11.0903 (UTC) FILETIME=[4F55E8F0:01C883A2] Subject: [PCN] Scribes for PCN meetings X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0695716963==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0695716963== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C883A2.4EBD3638" This is a multi-part message in MIME format. ------_=_NextPart_001_01C883A2.4EBD3638 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Would somebody(s) please volunteer to take meeting minutes today and Thursday? We also need Jabber scribes. Thanks, =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D Steven Blake Ericsson/Redback Networks +1 919-472-9913 ------_=_NextPart_001_01C883A2.4EBD3638 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Scribes for PCN meetings

Would somebody(s) please volunteer to = take meeting minutes today and Thursday?
We also need Jabber scribes.


Thanks,

=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D
Steven = Blake           &n= bsp;    <steven.blake@ericsson.com>
Ericsson/Redback = Networks           = ;    +1 919-472-9913

------_=_NextPart_001_01C883A2.4EBD3638-- --===============0695716963== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0695716963==-- From pcn-bounces@ietf.org Tue Mar 11 11:48:37 2008 Return-Path: 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 1B7493A6DF4; Tue, 11 Mar 2008 11:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.664 X-Spam-Level: X-Spam-Status: No, score=-100.664 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 oSWDyNOa2HHx; Tue, 11 Mar 2008 11:48:33 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 291733A6E06; Tue, 11 Mar 2008 11:48:33 -0700 (PDT) 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 B9F4D3A6877 for ; Tue, 11 Mar 2008 11:48:31 -0700 (PDT) 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 zjkVzYU7lgvC for ; Tue, 11 Mar 2008 11:48:30 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 746843A6946 for ; Tue, 11 Mar 2008 11:48:20 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id B0B75A06AD; Tue, 11 Mar 2008 19:46:00 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id A4647A06A4; Tue, 11 Mar 2008 19:46:00 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 5DF59A068B; Tue, 11 Mar 2008 19:45:58 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m2BIjwV03015; Tue, 11 Mar 2008 19:45:58 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 280C8C837A; Tue, 11 Mar 2008 19:45:58 +0100 (CET) Message-ID: <47D6D32C.6050008@informatik.uni-wuerzburg.de> Date: Tue, 11 Mar 2008 19:45:00 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: pcn X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Subject: [PCN] Encoding options with 2 DSCPs and limited ECN X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi, I had a short brainstorming with Bob and Toby discussing the few remaining encoding options when we go with an encoding using 2 DSCPs and reusing ECN bits. Here is the result: http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/PCN-Encoding.pdf Regards, Michael -- 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 From pcn-bounces@ietf.org Tue Mar 11 12:51:08 2008 Return-Path: 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 1E0BF28C2A6; Tue, 11 Mar 2008 12:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.513 X-Spam-Level: X-Spam-Status: No, score=-100.513 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 LXfp7Dp4aDIM; Tue, 11 Mar 2008 12:51:07 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A46228C42C; Tue, 11 Mar 2008 12:51:07 -0700 (PDT) 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 CAE313A6C85 for ; Tue, 11 Mar 2008 12:51:05 -0700 (PDT) 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 ahaoAGH158Ns for ; Tue, 11 Mar 2008 12:51:01 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 57D213A6C4B for ; Tue, 11 Mar 2008 12:51:01 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 86AB4205EC; Tue, 11 Mar 2008 20:48:40 +0100 (CET) X-AuditID: c1b4fb3c-ac097bb00000193b-df-47d6e2186db2 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 6A8BB204C3; Tue, 11 Mar 2008 20:48:40 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Mar 2008 20:48:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 11 Mar 2008 20:48:39 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC050260E22B@esealmw109.eemea.ericsson.se> In-Reply-To: <47D6D32C.6050008@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Encoding options with 2 DSCPs and limited ECN thread-index: AciDqDWY/C6P1pzDQbC6Qahp0fV8HQABv1FQ References: <47D6D32C.6050008@informatik.uni-wuerzburg.de> From: "Ingemar Johansson S" To: , "pcn" X-OriginalArrivalTime: 11 Mar 2008 19:48:40.0231 (UTC) FILETIME=[E78CDB70:01C883B0] X-Brightmail-Tracker: AAAAAA== Subject: Re: [PCN] Encoding options with 2 DSCPs and limited ECN X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org A short question. If I understand this approach correctly the ECT is broken at PCN ingress. Is this correct ? /Ingemar > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Michael Menth > Sent: den 11 mars 2008 14:45 > To: pcn > Subject: [PCN] Encoding options with 2 DSCPs and limited ECN > > Hi, > > I had a short brainstorming with Bob and Toby discussing the > few remaining encoding options when we go with an encoding > using 2 DSCPs and reusing ECN bits. > > Here is the result: > http://www3.informatik.uni-wuerzburg.de/staff/menth/Publicatio ns/PCN-Encoding.pdf > > Regards, > > Michael > > -- > 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 From pcn-bounces@ietf.org Tue Mar 11 16:11:27 2008 Return-Path: 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 0351B3A696F; Tue, 11 Mar 2008 16:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.518 X-Spam-Level: X-Spam-Status: No, score=-103.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 dJJk4R8FVrKY; Tue, 11 Mar 2008 16:11:26 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AFBB3A6810; Tue, 11 Mar 2008 16:11:26 -0700 (PDT) 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 7C4793A6810 for ; Tue, 11 Mar 2008 16:11:24 -0700 (PDT) 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 mxIF1q5JP7QT for ; Tue, 11 Mar 2008 16:11:23 -0700 (PDT) Received: from smtp106.sbc.mail.mud.yahoo.com (smtp106.sbc.mail.mud.yahoo.com [68.142.198.205]) by core3.amsl.com (Postfix) with SMTP id 464213A6784 for ; Tue, 11 Mar 2008 16:11:23 -0700 (PDT) Received: (qmail 37708 invoked from network); 11 Mar 2008 23:09:03 -0000 Received: from unknown (HELO JAINX61) (rajain@sbcglobal.net@12.10.125.134 with login) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 11 Mar 2008 23:09:03 -0000 X-YMail-OSG: UQ69MmcVM1lfrEKpB_EgkkIGXu8P6oksHFLMlbwtHc7R80zMuRb.vKSlMBQd0PW2VWM1MPr_sHOjEWdqlWw_wGxEYXpaOTlOhr.u3gfV0R9oEfbxG9TQ3SZLmT2cKw-- X-Yahoo-Newman-Property: ymail-3 From: "Raj Jain" To: "'Geib, Ruediger'" , References: <200803101655.m2AGtOUY019124@bagheera.jungle.bt.co.uk> <1B6169C658325341A3B8066E23919E1CEF5461@S4DE8PSAANK.mitte.t-com.de> Date: Tue, 11 Mar 2008 18:09:00 -0500 Organization: Washington University in St. Louis Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <1B6169C658325341A3B8066E23919E1CEF5461@S4DE8PSAANK.mitte.t-com.de> Thread-Index: AciC0pJXdNqBt8qmSDmHzyzxlNj+UgAPsEXgAA566+AAIEp/oA== Cc: pcn@ietf.org Subject: Re: [PCN] A Simple Analytical Model of PCN - Revised version X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: jain@cse.wustl.edu List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ruediger, We use the mean rate, which is what exponentially weighted moving average is trying to estimate and so the answer would be "yes." Thanks. -Raj -----Original Message----- From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] Sent: Tuesday, March 11, 2008 2:48 AM To: jain@cse.wustl.edu; lachlan.andrew@gmail.com Cc: pcn@ietf.org Subject: RE: [PCN] A Simple Analytical Model of PCN - Revised version Hi Raj, hi Lachlan, if I understood the presentation right, you propose single codepoint marking combined with excess marking. The admission stop and termination decisions are based on rate measurements. The PCN architecture document suggests to smooth rate counts in egress nodes by working with an exponentially weighted moving average. Did you apply EWMA? Regards, Rudiger | -----Original Message----- | From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of | Raj Jain | Sent: Tuesday, March 11, 2008 2:07 AM | To: 'Lachlan Andrew'; 'Bob Briscoe' | Cc: 'Jinjing Jiang'; pcn@ietf.org | Subject: Re: [PCN] A Simple Analytical Model of PCN - Revised version | | Lachlan and Bob, | | Thanks for pointing out the issues with pdf. | | I have now replaced the pdfs with a different version. | | Same URL: | http://www.cse.wustl.edu/~jain/ietf/pcn0803.htm | | No change in contents. | | If anyone finds problems with the symbols and equations in this | version, please do let me know. | | Thanks. | | -Raj Jain | | | | -----Original Message----- | From: Lachlan Andrew [mailto:lachlan.andrew@gmail.com] | Sent: Monday, March 10, 2008 12:17 PM | To: Bob Briscoe | Cc: jain@cse.wustl.edu; Jinjing Jiang; pcn@ietf.org; Jinjing Jiang | Subject: Re: [PCN] A Simple Analytical Model of PCN - Revised version | | On 10/03/2008, Bob Briscoe wrote: | > | > In my acrobat reader a lot of the maths symbols come out rendered | > oddly - big greek letters and new paragraph symbols out of | place in | > the middle of the slide. Do others get the same? | | Yes. | | Lachlan | | | -- | Lachlan Andrew Dept of Computer Science, Caltech 1200 E California | Blvd, Mail Code 256-80, Pasadena CA 91125, USA | Ph: +1 (626) 395-8820 Fax: +1 (626) 568-3603 | http://netlab.caltech.edu/lachlan | | _______________________________________________ | 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 From pcn-bounces@ietf.org Wed Mar 12 02:01:45 2008 Return-Path: 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 3AA9D28C5DA; Wed, 12 Mar 2008 02:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.416 X-Spam-Level: X-Spam-Status: No, score=-101.416 tagged_above=-999 required=5 tests=[AWL=-0.979, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 xNpbuGR5ZczP; Wed, 12 Mar 2008 02:01:44 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23A5F28C5D0; Wed, 12 Mar 2008 02:01:44 -0700 (PDT) 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 E936728C5C9 for ; Wed, 12 Mar 2008 02:01:42 -0700 (PDT) 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 stmDidrPYqkH for ; Wed, 12 Mar 2008 02:01:42 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 7D02828C5D0 for ; Wed, 12 Mar 2008 02:01:40 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail21.telekom.de with ESMTP; Wed, 12 Mar 2008 09:59:21 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 12 Mar 2008 09:59:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 12 Mar 2008 10:00:37 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CEF5987@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <47D6D32C.6050008@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Encoding options with 2 DSCPs and limited ECN Thread-Index: AciDqDVAlD3KGNFIQMmQYMnVTJyolwAcoszQ References: <47D6D32C.6050008@informatik.uni-wuerzburg.de> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 12 Mar 2008 08:59:20.0838 (UTC) FILETIME=[5C5B0260:01C8841F] Cc: pcn@ietf.org Subject: Re: [PCN] Encoding options with 2 DSCPs and limited ECN X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Michael, I'm a bit lost here. You only discuss tunneling or is this a general proposal? The tunnel is PCN and it carries packets which are non PCN (i.e. ECN or ECN and other traffic)? Is the interpretation of DSCP1 + 00 = PCN aware? In the case of the example on slide with page number 10 (the forth page), How can an a node tell when it should transition from NP to AM and when from NP to CE? This requires flow awareness, doesn't it? Finally, in your last slide, first arrow, first and second bullet point: First you say, that Non-PCN traffic backs off, then you claim that Non-PCN traffic grabs bandwidth from PCN traffic. This seems to be contradicting. In termination state, non new flows are admitted. The idea is, to reduce traffic. Some flows do so by reducing bandwidth, others can't and therefore a few of them are terminated. If the end to end type of traffic reduces bandwidth consumption by 40% as a reaction on "11" and the PCN flows reduce bandwidth by 30% due to TM indications (the flows not terminated don't reduce bandwidth), then the non PCN flows don't seem to grab bandwidth from PCN flows. Further, I'd like to know which of the following scenarios you have considered during your discussion: The PCN PHB is assumed to be acessible by - an ECN aware application not using a PCN aware control plane. - a non ECN aware application not using a PCN aware control plane. - an ECN aware application using a PCN aware control plane. - a non ECN aware application using a PCN aware control plane. Regards, Rudiger | -----Original Message----- | From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On | Behalf Of Michael Menth | Sent: Tuesday, March 11, 2008 7:45 PM | To: pcn | Subject: [PCN] Encoding options with 2 DSCPs and limited ECN | | Hi, | | I had a short brainstorming with Bob and Toby discussing the | few remaining encoding options when we go with an encoding | using 2 DSCPs and reusing ECN bits. | | Here is the result: | http://www3.informatik.uni-wuerzburg.de/staff/menth/Publicatio | ns/PCN-Encoding.pdf | | Regards, | | Michael | | -- | 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 From pcn-bounces@ietf.org Wed Mar 12 03:08:26 2008 Return-Path: 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 D860D28C607; Wed, 12 Mar 2008 03:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.964 X-Spam-Level: X-Spam-Status: No, score=-102.964 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 AkMj0hdTkzAY; Wed, 12 Mar 2008 03:08:22 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCDE228C5F9; Wed, 12 Mar 2008 03:08:22 -0700 (PDT) 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 BA82128C2EC for ; Wed, 12 Mar 2008 03:08:21 -0700 (PDT) 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 7l+9ivAtg3Xt for ; Wed, 12 Mar 2008 03:08:17 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 412EE28C5FB for ; Wed, 12 Mar 2008 03:08:15 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Mar 2008 10:05:56 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 12 Mar 2008 10:05:55 -0000 Message-ID: <66C55C26FA491C42A9C9BB62A376DAFF0212222E@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] A Simple Analytical Model of PCN - Revised version Thread-Index: AciC0pJXdNqBt8qmSDmHzyzxlNj+UgAPsEXgAA566+AAIEp/oAAWtcuQ From: To: , , X-OriginalArrivalTime: 12 Mar 2008 10:05:56.0411 (UTC) FILETIME=[A9E710B0:01C88428] Cc: pcn@ietf.org Subject: Re: [PCN] A Simple Analytical Model of PCN - Revised version X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Rudiger, Raj To be pedantic, Raj's model is a sort of "infinite" EWMA limit. He assumes that the EWMA can produce a good estimate of rate on the time scale over which rate is (in his model) roughly constant. This depends on the level of aggregation at the bottleneck but also on the edge-edge aggregates through that bottleneck: an egress seeing only a few packets through a bottleneck may have trouble making a good estimation of rate. Modelling how a real EWMA behaves probabilistically is quite hard. Ben > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Raj Jain > Sent: 11 March 2008 23:09 > To: 'Geib, Ruediger'; lachlan.andrew@gmail.com > Cc: pcn@ietf.org > Subject: Re: [PCN] A Simple Analytical Model of PCN - Revised version > > Hi Ruediger, > We use the mean rate, which is what exponentially weighted > moving average is trying to estimate and so the answer would > be "yes." > Thanks. > -Raj > > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: Tuesday, March 11, 2008 2:48 AM > To: jain@cse.wustl.edu; lachlan.andrew@gmail.com > Cc: pcn@ietf.org > Subject: RE: [PCN] A Simple Analytical Model of PCN - Revised version > > Hi Raj, hi Lachlan, > > if I understood the presentation right, you propose single > codepoint marking combined with excess marking. The admission > stop and termination decisions are based on rate > measurements. The PCN architecture document suggests to > smooth rate counts in egress nodes by working with an > exponentially weighted moving average. Did you apply EWMA? > > Regards, > > Rudiger > > | -----Original Message----- > | From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of > | Raj Jain > | Sent: Tuesday, March 11, 2008 2:07 AM > | To: 'Lachlan Andrew'; 'Bob Briscoe' > | Cc: 'Jinjing Jiang'; pcn@ietf.org > | Subject: Re: [PCN] A Simple Analytical Model of PCN - > Revised version > | > | Lachlan and Bob, > | > | Thanks for pointing out the issues with pdf. > | > | I have now replaced the pdfs with a different version. > | > | Same URL: > | http://www.cse.wustl.edu/~jain/ietf/pcn0803.htm > | > | No change in contents. > | > | If anyone finds problems with the symbols and equations in this > | version, please do let me know. > | > | Thanks. > | > | -Raj Jain > | > | > | > | -----Original Message----- > | From: Lachlan Andrew [mailto:lachlan.andrew@gmail.com] > | Sent: Monday, March 10, 2008 12:17 PM > | To: Bob Briscoe > | Cc: jain@cse.wustl.edu; Jinjing Jiang; pcn@ietf.org; Jinjing Jiang > | Subject: Re: [PCN] A Simple Analytical Model of PCN - > Revised version > | > | On 10/03/2008, Bob Briscoe wrote: > | > > | > In my acrobat reader a lot of the maths symbols come out > rendered > | > oddly - big greek letters and new paragraph symbols out of > | place in > | > the middle of the slide. Do others get the same? > | > | Yes. > | > | Lachlan > | > | > | -- > | Lachlan Andrew Dept of Computer Science, Caltech 1200 E California > | Blvd, Mail Code 256-80, Pasadena CA 91125, USA > | Ph: +1 (626) 395-8820 Fax: +1 (626) 568-3603 > | http://netlab.caltech.edu/lachlan > | > | _______________________________________________ > | 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 > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 12 05:29:11 2008 Return-Path: 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 739AE28C6B4; Wed, 12 Mar 2008 05:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.312 X-Spam-Level: X-Spam-Status: No, score=-100.312 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 AQTMR8qOC-fv; Wed, 12 Mar 2008 05:29:09 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6A9328C653; Wed, 12 Mar 2008 05:29:09 -0700 (PDT) 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 24C7528C63D for ; Wed, 12 Mar 2008 05:29:08 -0700 (PDT) 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 FXTHEUR9qSES for ; Wed, 12 Mar 2008 05:29:04 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id BC06D28C68D for ; Wed, 12 Mar 2008 05:29:02 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id m2CCQJUP029123 for ; Wed, 12 Mar 2008 13:26:27 +0100 (MET) Received: from 130.129.18.139 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Wed, 12 Mar 2008 12:26:18 +0000 To: "pcn@ietf.org" Date: Wed, 12 Mar 2008 12:26:18 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <1B6169C658325341A3B8066E23919E1CEF5987@S4DE8PSAANK.mitte.t-com.de> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 12 Mar 2008 13:26:27 +0100 (MET) Subject: [PCN] reaching consensus on selection algorithms/schemes X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi all Regarding the decission that is pending on the selection of the PCN solutions/schemes I would like to propose the following: 1) Solutions that should be standardized a.s.a.p.: CL-PHB + SM (Single Marking) with: * Admission control decission at the egress. * Flow termination decission at the ingress However, the architecture draft should: * Allow the possibility that in the future the flow termination detection and decission can also be done at the egress. Regarding motivation on this please see below! * Allow to optimize the implementation at the interior nodes, in case that this is needed. 2) In order to make PCN extensible to future scenarios, it should be possible in the future, (thus not now) to allow flow termination detection and termination at the egress. Future possible PCN scenarios are: * Centralized nodes, collocated with egress nodes can accomplish the detection and decission for flow termination. * end-to-edge scenarios, where the end points can be hosts and the edge can be an aggregator/boundary node. Now if the detection and decission for flow termination could be done at the egress, then there are two canditate solutions/schemes that can fulfil this requirement: * 3SM * LC-PCN In order to be able to select one of them, performance comparisons between these two schemes are required. 3) Allow solutions for the ECMP routing issue. In order to do that performance evaluation experiments are needed. Best regards, Georgios _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 12 06:07:00 2008 Return-Path: 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 ABF3128C7A1; Wed, 12 Mar 2008 06:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.338 X-Spam-Level: X-Spam-Status: No, score=-100.338 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 SIpyPkHkBADV; Wed, 12 Mar 2008 06:06:55 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9646D28C795; Wed, 12 Mar 2008 06:06:00 -0700 (PDT) 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 84B3D28C70C for ; Wed, 12 Mar 2008 06:05:59 -0700 (PDT) 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 Niv-s5CfxSGH for ; Wed, 12 Mar 2008 06:05:55 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id C3B9E28C827 for ; Wed, 12 Mar 2008 06:05:14 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id m2CD2s2O001925 for ; Wed, 12 Mar 2008 14:02:55 +0100 (MET) Received: from 130.129.18.139 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Wed, 12 Mar 2008 13:02:53 +0000 To: pcn@ietf.org Date: Wed, 12 Mar 2008 13:02:53 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: <92oIXP5F.1205326973.6224950.karagian@ewi.utwente.nl> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 12 Mar 2008 14:02:55 +0100 (MET) Subject: [PCN] regarding consensus on selection encoding options X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi all Regarding the selection of the encoding option that is pending I would like to propose the following. In order to compare Option 1 and Option 3 presented by Toby yesterday during the PCN meeting (see uploaded slides), I think that it will be usefull if certain clear comparison criteria are used, see below: (1) Fullfils requirements imposed by RFC4774 (2) Minimum number of required DSCPs (3) Minimum number of DSCPs required to be standardized (4) Minimum number of DSCPs required as experimental (5) Additional complexity required at the interior nodes (6) Additional complexity required at edges (ingress + egress) Below I will try to do this comparison. Before doing this comparison I consider that in the most cases a combination of CL-PHB for admission control and SM for flow termination will be used. Considering the above observation, then the comparison of Option 1 and Option 3 using the criteria listed above could be as follows: (1) Fullfils requirements imposed by RFC4774 Both Options (1 and 3) fullfil the requirements imposed by RFC4774. 2) Minimum number of required DSCPs Option 1 requires 3 DSCPs; Option 3 requires 2 DSCPs (3) Minimum number of DSCPs required to be standardized Both option 1 and option 3 require only one DSCP to be standardized, i.e., the DSCP that identifies the new PCN PHB. (4) Minimum number of DSCPs required as experimental Option 1 requires two additional experimental DSCPs. Option 3 requires one additional experimental DSCP. (5) Additional complexity required at the interior nodes Compared to Option 1, Option 3 requires more complexity at the interior nodes because it requires to monitor and interchange values between the DSCP and ECN fields. Option 1 needs only to monitor and change DSCP values. 6) Additional complexity required at edges (ingress + egress) Related to this criterion, note that Option 3 can fulfill the requirements imposed by RFC 4774 only by Ip over Ip tunelling of the end to end ECN traffic. Option 3 requires Ip over Ip tunelling that is provided by the ingress and egress edges. Therefore, compared to Option 1, Option 3 requires more complexity at the ingress and egress edges. Best regards, Georgios _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 12 07:28:44 2008 Return-Path: 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 99F063A6E79; Wed, 12 Mar 2008 07:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.543 X-Spam-Level: X-Spam-Status: No, score=-99.543 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_43=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 OXsxQo3rvSSj; Wed, 12 Mar 2008 07:28:39 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C51CD3A6B9C; Wed, 12 Mar 2008 07:28:34 -0700 (PDT) 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 4C4903A6A99 for ; Wed, 12 Mar 2008 07:28:33 -0700 (PDT) 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 xIPNdeYRCAyi for ; Wed, 12 Mar 2008 07:28:32 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 83E1328C6B5 for ; Wed, 12 Mar 2008 07:27:42 -0700 (PDT) Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2CEPLU21499 for ; Wed, 12 Mar 2008 14:25:21 GMT Received: from KCHAN-2K3.nortel.com ([47.16.102.57] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Mar 2008 10:25:03 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 12 Mar 2008 10:25:02 -0400 To: pcn@ietf.org From: "Kwok-Ho Chan" Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 12 Mar 2008 14:25:03.0900 (UTC) FILETIME=[DCED9DC0:01C8844C] Subject: [PCN] A note on "00" code point X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org With all the discussion of PCN can not use the "00" code point in the ECN field due to tunnelling constraints. I took a step back and see that "00" can still indicate Not-PCN Capable Packet. PCN is not using it, but other (non PCN) traffic is using it (this is same as 3168). This raises the possibility of using the PCN DSCP for other purpose than separating PCN and non PCN packets (current thinking in the PCN WG), giving us another code point. I don't think this idea will get blessing from the DiffServ police (I know they are watching :). As this will flatten the 8 bit DSCP+ECN space, e.g. having a filter/classifier read in 8 bits instead of 6 bits and make classification decision based on the 8 bits instead of 6 bits. -- Kwok -- _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 12 08:16:21 2008 Return-Path: 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 5CD043A6ACF; Wed, 12 Mar 2008 08:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.707 X-Spam-Level: X-Spam-Status: No, score=-100.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 tFTRtHflof9W; Wed, 12 Mar 2008 08:16:21 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E369128C5B4; Wed, 12 Mar 2008 08:16:19 -0700 (PDT) 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 69FAD28C712 for ; Wed, 12 Mar 2008 08:16:18 -0700 (PDT) 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 5YMdy2udophf for ; Wed, 12 Mar 2008 08:16:12 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id C9EDF3A6804 for ; Wed, 12 Mar 2008 08:16:06 -0700 (PDT) Received: from OMTA06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id 0AgP1Z00C16AWCUA90N200; Wed, 12 Mar 2008 15:12:55 +0000 Received: from [192.168.1.120] ([69.250.217.163]) by OMTA06.emeryville.ca.mail.comcast.net with comcast id 0FDm1Z00A3Y6jD98S00000; Wed, 12 Mar 2008 15:13:47 +0000 X-Authority-Analysis: v=1.0 c=1 a=SShzHhSX4BwA:10 a=SdJsXbLnmV5Qfbeu574A:9 a=me-L9-fsOzlt9KNieFkA:7 a=zAfjZDq1sOuE-ZbJH5cuzzM32hAA:4 a=HMmPKh5NLbsA:10 Message-Id: <16FDE4C8-D814-4007-A0DF-DAB2C46BCF50@g11.org.uk> From: ken carlberg To: Georgios Karagiannis In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 12 Mar 2008 11:13:45 -0400 References: X-Mailer: Apple Mail (2.919.2) Cc: "pcn@ietf.org" Subject: Re: [PCN] reaching consensus on selection algorithms/schemes X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Georgios, On Mar 12, 2008, at 8:26 AM, Georgios Karagiannis wrote: > However, the architecture draft should: > * Allow the possibility that in the future the flow termination > detection and decission can also be done at the egress. Regarding > motivation on this please see below! > * Allow to optimize the implementation at the interior nodes, in case > that this is needed. perhaps a different way to view this is the converse of what you are asking. by this I mean, does the architecture draft, as currently written, *prevent* the optimizations you describe? If not, perhaps we leave the document as is and augment it later with a subsequent draft that potentially and optionally optimizes the action of interior and border nodes. -ken _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 12 09:09:29 2008 Return-Path: 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 3B5F53A6EBB; Wed, 12 Mar 2008 09:09:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.086 X-Spam-Level: X-Spam-Status: No, score=-100.086 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 WoRk-lseB3DG; Wed, 12 Mar 2008 09:09:28 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48DB93A6EB1; Wed, 12 Mar 2008 09:09:28 -0700 (PDT) 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 936873A6EB1 for ; Wed, 12 Mar 2008 09:09:26 -0700 (PDT) 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 sng72jhTwdxm for ; Wed, 12 Mar 2008 09:09:25 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 0B1B13A6944 for ; Wed, 12 Mar 2008 09:09:24 -0700 (PDT) Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m2CG2gl25607 for ; Wed, 12 Mar 2008 16:02:43 GMT Received: from KCHAN-2K3.nortel.com ([47.16.102.57] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Mar 2008 12:06:13 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 12 Mar 2008 12:06:12 -0400 To: pcn@ietf.org From: "Kwok-Ho Chan" Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 12 Mar 2008 16:06:13.0673 (UTC) FILETIME=[FECB7990:01C8845A] Subject: [PCN] Usage of '01' and '10' code points X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi: A discussion on PCN's use of '01' and '10' code points in the ECN field. Much if not all of this info is in http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-comparison-03.txt more specifically in sections 2.2.3, 2.2.6, 3.1.4, paragraphs with '01' and '10' headings. We originally proposed to use both '01' and '10' code points to represent one encoding state of "Not-Pre-Congested" (or "Un-Marked") (see section 2.1 of encoding-comparison-03) because: 1. For the encoding options we do this, there were enough code points for us to do so. 2. Doing this increase ECN Nonce friendliness for the "leakage" situations. Packets entering the PCN domain with '01' or '10' encoding can only be changed to '11'. If by chance the "leaked-in" '01' and '10' encoded packets "leaks-out" with no pre-congestion on its path in the PCN domain, these packets are not affected by the PCN domain. This "leaked-in" and "leaks-out" may be due to the same configuration error at the ingress and egress node. 3. Possible ratios of Admission-Marked and Termination-Marked packets when '11' code point is used for both. But with the squeeze on the available code points due to the tunnelling constraints, we should re-visit if we should use both '01' and '10' code points for just one encoding state. How about: 1. Use '01' code point for Admission-Marked encoding state. Use '10' code point for Not-Pre-Congested (Un-Marked) encoding state. Please notice the use of '10' for Not-Pre-Congested to be friendlier to ECN not using nonce ('10' = ECT(0) means not congested for 3168 ECN when nonce is not used). The trade-offs of the new encoding scheme when comparing to using '01' and '10' for one encoding state are: 1. Less ECN Nonce friendly but still ECN friendly. 2. Can not have the flexibility of the possible separation of Admission and Termination Marked. The notion of "less ECN nonce friendly" can be philosophical: - Is it better to detect a configuration error as soon as possible and fix it? Or - Is it better to minimize the affect of the configuration error and hence harder to detect and have it not fixed for a longer period of time? And - Is it OK to not be able to detect the configuration error if it have no functional affect? So the trade-off of "Less ECN Nonce friendly" may be viewed as faster ECN Nonce violation detection. In light of the latest new constraints and trade-offs, I would like to ask the Working Group to think about and comment on: 1. Should we continue to use both '01' and '10' code points for just ONE encoding state? 2. Will it be acceptable to use '01' and '10' code points for TWO encoding states? There may be additional trade-offs not indicated above. Please share them with us if you know of additional ones. Thank you! -- Kwok Ho Chan -- _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 12 14:04:21 2008 Return-Path: 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 9CC133A6EEE; Wed, 12 Mar 2008 14:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.552 X-Spam-Level: X-Spam-Status: No, score=-100.552 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 UwSBn4gq+fez; Wed, 12 Mar 2008 14:04:19 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A022328C1B3; Wed, 12 Mar 2008 14:04:17 -0700 (PDT) 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 986F73A6918 for ; Wed, 12 Mar 2008 14:04:14 -0700 (PDT) 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 feYDkQqxUru0 for ; Wed, 12 Mar 2008 14:04:03 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id C900928C7EF for ; Wed, 12 Mar 2008 14:02:22 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 39B71215F4; Wed, 12 Mar 2008 22:00:03 +0100 (CET) X-AuditID: c1b4fb3e-ac194bb000004ec0-8d-47d844532cda Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 15F922155C; Wed, 12 Mar 2008 22:00:03 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Mar 2008 22:00:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 12 Mar 2008 22:00:02 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC050260E234@esealmw109.eemea.ericsson.se> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Usage of '01' and '10' code points thread-index: AciEX0Td/2QGu9dMQaOkJ5W3ITB6kAAITPdg References: From: "Ingemar Johansson S" To: "Kwok-Ho Chan" , X-OriginalArrivalTime: 12 Mar 2008 21:00:02.0882 (UTC) FILETIME=[0A9F4A20:01C88484] X-Brightmail-Tracker: AAAAAA== Subject: Re: [PCN] Usage of '01' and '10' code points X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Given that we discuss realtime appliations that run on RTP/UDP.. My thoughs regarding the 01 and 10 codepoinst are that they are actually not needed for ECN-nonce like it is done in eg RFC3540. The reason to this is that application that run over RTP/UDP do not have anything that resembles the nonce-sum that is available in the TCP header. It is possible that one may implement this as a special RTCP report but as e.g VoIP application do not have the typical client-server behavior that exist for instance for webservers and browsers I see very little use for the ECN nonce sum as you cannot build any trust on that anyway. Instead the ECN-CE will be reacted upon using other mechanisms such as rate change commands. My take is then that in order for a PCN domain to be "ECN friendly" but not "ECN nonce friendly" in a realtime perspective the following requirements apply: ECN '00' at PCN ingress should be '00' after PCN egress ECN '01' at PCN ingress can and should be either '10' or '01' after PCN egress ECN '10' at PCN ingress can and should be either '10' or '01' after PCN egress ECN '11' at PCN ingress should be '11' at PCN egress In doing like this an ECN capable node (could be a router or a 3GPP LTE eNB) after PCN-egress will be able to set ECN CE upon experienced congestion. The possible ECN nonce is broken with this but I don't see this as a problem. ECN '00' should never be set to '10' or '10' but I guess this is explained in RFC4774 (or is it RFC3168) I don't expect everybody to agree, for instance DCCP can echo the ECN nonce in the ack-vector. But then again I also here wonder how the trust relationship is built. /Ingemar > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Kwok-Ho Chan > Sent: den 12 mars 2008 12:06 > To: pcn@ietf.org > Subject: [PCN] Usage of '01' and '10' code points > > Hi: > A discussion on PCN's use of '01' and '10' code points in the > ECN field. > Much if not all of this info is in > http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-co mparison-03.txt > more specifically in sections 2.2.3, 2.2.6, 3.1.4, paragraphs > with '01' and '10' headings. > > We originally proposed to use both '01' and '10' code points > to represent one encoding state of "Not-Pre-Congested" (or > "Un-Marked") (see section 2.1 of > encoding-comparison-03) > because: > 1. For the encoding options we do this, there were enough > code points for us to do so. > 2. Doing this increase ECN Nonce friendliness for the > "leakage" situations. > Packets entering the PCN domain with '01' or '10' > encoding can only be changed to '11'. > If by chance the "leaked-in" '01' and '10' encoded > packets "leaks-out" with no pre-congestion > on its path in the PCN domain, these packets are not > affected by the PCN domain. > This "leaked-in" and "leaks-out" may be due to the same > configuration error at the ingress > and egress node. > 3. Possible ratios of Admission-Marked and Termination-Marked > packets when '11' code point > is used for both. > > But with the squeeze on the available code points due to the > tunnelling constraints, we should re-visit if we should use > both '01' and '10' code points for just one encoding state. > > How about: > 1. Use '01' code point for Admission-Marked encoding state. > Use '10' code point for Not-Pre-Congested (Un-Marked) > encoding state. > Please notice the use of '10' for Not-Pre-Congested to > be friendlier to ECN not using nonce > ('10' = ECT(0) means not congested for 3168 ECN when > nonce is not used). > > The trade-offs of the new encoding scheme when comparing to > using '01' and '10' for one encoding state are: > 1. Less ECN Nonce friendly but still ECN friendly. > 2. Can not have the flexibility of the possible separation of > Admission and Termination Marked. > > The notion of "less ECN nonce friendly" can be philosophical: > - Is it better to detect a configuration error as soon as > possible and fix it? > Or > - Is it better to minimize the affect of the configuration > error and hence harder to detect > and have it not fixed for a longer period of time? > And > - Is it OK to not be able to detect the configuration error > if it have no functional affect? > > So the trade-off of "Less ECN Nonce friendly" may be viewed > as faster ECN Nonce violation detection. > > > In light of the latest new constraints and trade-offs, I > would like to ask the Working Group to think about and comment on: > 1. Should we continue to use both '01' and '10' code points > for just ONE encoding state? > 2. Will it be acceptable to use '01' and '10' code points for > TWO encoding states? > > There may be additional trade-offs not indicated above. > Please share them with us if you know of additional ones. > > Thank you! > -- Kwok Ho Chan -- > > _______________________________________________ > 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 From pcn-bounces@ietf.org Wed Mar 12 14:20:24 2008 Return-Path: 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 7DD4728C4E3; Wed, 12 Mar 2008 14:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.259 X-Spam-Level: X-Spam-Status: No, score=-100.259 tagged_above=-999 required=5 tests=[AWL=-0.422, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_17=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 HuIjw2lxyNBo; Wed, 12 Mar 2008 14:20:23 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58B023A68E4; Wed, 12 Mar 2008 14:20:23 -0700 (PDT) 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 C17C33A694B for ; Wed, 12 Mar 2008 14:20:22 -0700 (PDT) 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 15YlUhG8tmJ5 for ; Wed, 12 Mar 2008 14:20:21 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 427133A685E for ; Wed, 12 Mar 2008 14:20:21 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id C3E0920518 for ; Wed, 12 Mar 2008 22:18:01 +0100 (CET) X-AuditID: c1b4fb3c-ae89cbb00000193b-71-47d84889225f Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id A091420462 for ; Wed, 12 Mar 2008 22:18:01 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Mar 2008 22:18:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 12 Mar 2008 22:18:00 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC050260E235@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC050260E234@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Usage of '01' and '10' code points thread-index: AciEX0Td/2QGu9dMQaOkJ5W3ITB6kAAITPdgAAFje2A= References: <026F8EEDAD2C4342A993203088C1FC050260E234@esealmw109.eemea.ericsson.se> From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 12 Mar 2008 21:18:01.0433 (UTC) FILETIME=[8D7D1C90:01C88486] X-Brightmail-Tracker: AAAAAA== Subject: Re: [PCN] Usage of '01' and '10' code points X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Sorry to see again that M$Outlook did some intelligent formatting on my email.... I repeat the essential bullets for the sake of clarity, hopefully it will stay intact now... + ECN '00' at PCN ingress should be '00' after PCN egress + ECN '01' at PCN ingress can and should be either '10' or '01' after PCN egress + ECN '10' at PCN ingress can and should be either '10' or '01' after PCN egress + ECN '11' at PCN ingress should be '11' at PCN egress /Ingemar > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Ingemar Johansson S > Sent: den 12 mars 2008 17:00 > To: Kwok-Ho Chan; pcn@ietf.org > Subject: Re: [PCN] Usage of '01' and '10' code points > > Hi > > Given that we discuss realtime appliations that run on RTP/UDP.. > My thoughs regarding the 01 and 10 codepoinst are that they > are actually not needed for ECN-nonce like it is done in eg > RFC3540. The reason to this is that application that run over > RTP/UDP do not have anything that resembles the nonce-sum > that is available in the TCP header. It is possible that one > may implement this as a special RTCP report but as e.g VoIP > application do not have the typical client-server behavior > that exist for instance for webservers and browsers I see > very little use for the ECN nonce sum as you cannot build any > trust on that anyway. Instead the ECN-CE will be reacted upon > using other mechanisms such as rate change commands. > > My take is then that in order for a PCN domain to be "ECN > friendly" but not "ECN nonce friendly" in a realtime > perspective the following requirements apply: > ECN '00' at PCN ingress should be '00' after PCN egress ECN > '01' at PCN ingress can and should be either '10' or '01' > after PCN egress ECN '10' at PCN ingress can and should be > either '10' or '01' after PCN egress ECN '11' at PCN ingress > should be '11' at PCN egress In doing like this an ECN > capable node (could be a router or a 3GPP LTE > eNB) after PCN-egress will be able to set ECN CE upon > experienced congestion. The possible ECN nonce is broken with > this but I don't see this as a problem. > ECN '00' should never be set to '10' or '10' but I guess this > is explained in RFC4774 (or is it RFC3168) > > I don't expect everybody to agree, for instance DCCP can echo > the ECN nonce in the ack-vector. But then again I also here > wonder how the trust relationship is built. > > /Ingemar > > > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of > > Kwok-Ho Chan > > Sent: den 12 mars 2008 12:06 > > To: pcn@ietf.org > > Subject: [PCN] Usage of '01' and '10' code points > > > > Hi: > > A discussion on PCN's use of '01' and '10' code points in the ECN > > field. > > Much if not all of this info is in > > http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-co > mparison-03.txt > > more specifically in sections 2.2.3, 2.2.6, 3.1.4, paragraphs with > > '01' and '10' headings. > > > > We originally proposed to use both '01' and '10' code points to > > represent one encoding state of "Not-Pre-Congested" (or > > "Un-Marked") (see section 2.1 of > > encoding-comparison-03) > > because: > > 1. For the encoding options we do this, there were enough > code points > > for us to do so. > > 2. Doing this increase ECN Nonce friendliness for the "leakage" > > situations. > > Packets entering the PCN domain with '01' or '10' > > encoding can only be changed to '11'. > > If by chance the "leaked-in" '01' and '10' encoded packets > > "leaks-out" with no pre-congestion > > on its path in the PCN domain, these packets are not > affected by > > the PCN domain. > > This "leaked-in" and "leaks-out" may be due to the same > > configuration error at the ingress > > and egress node. > > 3. Possible ratios of Admission-Marked and > Termination-Marked packets > > when '11' code point > > is used for both. > > > > But with the squeeze on the available code points due to the > > tunnelling constraints, we should re-visit if we should use > both '01' > > and '10' code points for just one encoding state. > > > > How about: > > 1. Use '01' code point for Admission-Marked encoding state. > > Use '10' code point for Not-Pre-Congested (Un-Marked) encoding > > state. > > Please notice the use of '10' for Not-Pre-Congested to be > > friendlier to ECN not using nonce > > ('10' = ECT(0) means not congested for 3168 ECN when > nonce is not > > used). > > > > The trade-offs of the new encoding scheme when comparing to > using '01' > > and '10' for one encoding state are: > > 1. Less ECN Nonce friendly but still ECN friendly. > > 2. Can not have the flexibility of the possible separation of > > Admission and Termination Marked. > > > > The notion of "less ECN nonce friendly" can be philosophical: > > - Is it better to detect a configuration error as soon as > possible and > > fix it? > > Or > > - Is it better to minimize the affect of the configuration > error and > > hence harder to detect > > and have it not fixed for a longer period of time? > > And > > - Is it OK to not be able to detect the configuration error > if it have > > no functional affect? > > > > So the trade-off of "Less ECN Nonce friendly" may be viewed > as faster > > ECN Nonce violation detection. > > > > > > In light of the latest new constraints and trade-offs, I > would like to > > ask the Working Group to think about and comment on: > > 1. Should we continue to use both '01' and '10' code points > for just > > ONE encoding state? > > 2. Will it be acceptable to use '01' and '10' code points for TWO > > encoding states? > > > > There may be additional trade-offs not indicated above. > > Please share them with us if you know of additional ones. > > > > Thank you! > > -- Kwok Ho Chan -- > > > > _______________________________________________ > > 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 > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 12 16:13:59 2008 Return-Path: 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 1738B28C57E; Wed, 12 Mar 2008 16:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.018 X-Spam-Level: X-Spam-Status: No, score=-102.018 tagged_above=-999 required=5 tests=[AWL=-1.581, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 N1IILt80j1cf; Wed, 12 Mar 2008 16:13:58 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4256828C37E; Wed, 12 Mar 2008 16:13:58 -0700 (PDT) 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 8FF9528C39C for ; Wed, 12 Mar 2008 16:13:57 -0700 (PDT) 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 KdJyUYJE5tzi for ; Wed, 12 Mar 2008 16:13:56 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 13E003A6894 for ; Wed, 12 Mar 2008 16:13:55 -0700 (PDT) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Mar 2008 23:11:37 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C88496.6B6255E4" Date: Wed, 12 Mar 2008 23:11:27 -0000 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Possible clever encoding for PCN Thread-Index: AciElmZkIrMBDw6WSZSJ5bmxbCMnQA== From: To: X-OriginalArrivalTime: 12 Mar 2008 23:11:37.0109 (UTC) FILETIME=[6BF2BC50:01C88496] Subject: [PCN] Possible clever encoding for PCN X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C88496.6B6255E4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, Bob and I just spent a fun 30 minutes trying to work out how to carry end-to-end ECN across PCN whilst still retaining all the PCN codepoints we need. We think we have succeeded... The attached 2 slides try to set this encoding out as clearly as possible. Note the new terminology being used! Also note that this is making the assumption that we will be re-using Fred Baker's DSCP and hence need to identify PCN traffic from not PCN traffic. Toby ____________________________________________________________________ Toby Moncaster, Networks Research Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734=20 (in case anyone is wondering at the title it stands for: you can please everyone all the time...) ------_=_NextPart_001_01C88496.6B6255E4 Content-Type: application/octet-stream; name="YCPEATT.pdf" Content-Transfer-Encoding: base64 Content-Description: YCPEATT.pdf Content-Disposition: attachment; filename="YCPEATT.pdf" JVBERi0xLjMKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nL1WS48cRQzWZsmy6UUJLJsACyFFeKgaaYqyXa7HFQkhRVwS5pZwSkQkxCIl OeTvx9XT9eiZzkoIiZlLPfz4bH921ytlDaCy+V8Wz6+Gn54E9fLNMB2rJ7/Oi9cvh1dDNJR/00G/ fn6lft6KYlTOGevU9k/RAmOtZa82oDayA2sYFVk2gUFtr4an+mi0xnKKFEjfkLW3wYLXx93xB7IO PiXr9c0mcTJu0AB4dPrDdno6bsRnSKLWm7iVj4ESh2LCR3HH7A0w/bF9NAFH+z7gwWfgYJ2Iz8Cf /SOGnGUbkz4bN7JG8esFbcZFhPqjUXw6S0ncSwTE3ucY2bCnmGNpSs9eN4n+/Ha3vjOSQZFJ+uMR QzCRMAPHaKLa/jZsf3yqP8lhpsBOnwsKS2S805+OG7LWmwjdfe/keETDFBLpi7o6H4PQgUPQdxex kYkMjvW9HGUAiBJ7CehkzmeB5VdxlZx8NgpzJMtxl32wLf0Ucr2FU9sXE0NK3EejS8kw4EHBIJkE 0ReVzyXkkAz48H9G3yQvxih8QY76i+pzxwFPiTqXlwulcvqlrLxwlfRXVb2Bb3KnFcbNvgjzqifl /W7dB9+BunGQE+9CdjZRDdaqxAKoK1MBU8oEB2VCwcbsikqP8Ovq8vbiNCcSAOeo831PplwmRyBk Kk3XMrbLokMvdOiotnGcDCKqza5zXuz1cl8S6SLgJCmKPY9maRdk9Fyudn5jxYOalcvrGn+qwMkq GXYdk1Nwt1ponu5NzYF75d7vxNqIM7PI7wZEIuNSH1pjnqqGTzuyNxcP6n0JURB+UzukIWyoG+3P VnvlP0c6cW0xwN08wMnzwQCfCGuBWagPxrHDPKjRYAzymTiut+1MhgGZLJdy3crpRZU8qXbO6ur+ QidnyqYAmQPl+I4wQALzIckXQ8jLFIXlzUJD1zA1n7NKQBabRXAfCDP0iBffj2s/fC7kDlMegrE0 56311fkYp74KU18Bce6K0tx9my7EcvuFQ6m1meyEUaX+D1eHYkC59nG27CQoKqZnnJLhb0u/pmwP 5KPIqL/L6bDyrNDfr3ydjipXpdu9vFuiyz4cywtGvjNCrMlHP2289yYl2EFx1iSEJZQl9mp31mCS RxH9+7xca3syLTVM7EGeXybG9wNaJrModVOy5emHmtqm/nBOwESqX7bD4wGiRKTeDqgeDaD+GgiJ FeRRnFBd7bYcMeXt38Pv88tSFKwoyKvN9cJ52wv3xp1NqZOdtr3snuOF+KHjLIyOQydcttUYcYTu vmzrvQvyxm33ZbsPfJGCFeAVGBThvYz0wB4P7wB3VTshZW5kc3RyZWFtCmVuZG9iago2IDAgb2Jq Cjk5MQplbmRvYmoKMTUgMCBvYmoKPDwvTGVuZ3RoIDE2IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2Rl Pj4Kc3RyZWFtCnicrVdLbxxFEFYSO9hjZMlREChBojEJzASm6ap+VV+REFLEhbA3zCmQSAgjxRz4 +3w9O4+e9c5m1+A9uB/V1V999eiad8poYmXybxi8vq6+fRXV27+rblm9+qEf3Lyt3lWibf7rFsrx 62v13QoHRdmgVm9whLQxxgfVkmqNSjbrZyM6JlKr6+qX+qumhYwzHOurujE6JAnB1582rdExGBdT fTktP22c9iTJ18+wyCaJs/XVXw1pEkymIbQ1Tcsxau8ZGlrWwbLM9F4U48c4Z9mYUJ/lVTYwKdb3 i/FJY3Ug4lAfF6sPi/Hp2hQygoPZUiFbnzfeB02ef1297JhhA5lt5LCwjqzIeE3Us/OiaVMK2vn6 XsPa25jsGpRjE1PI2rUPVkJ9lE0kaxkGDGuf5bVIZCKG3pgBAnmdtvrHGsgHRaCthBAxN+D8osl8 eWMFHMCMaIK19YM1BYlC/TlA2uDEwlHgQowkB8rHU3BP64wBN7b+umltYqc7R4wSj/I5Ig+LPx6V 3bqXPCb54gjGbJS9LvbaegF/nzTwFsyWTAclzWr1Y7V6MbN0hxaRpA9Cv6gL/kJsCAC1nLBhfP3N wKXLwTeZWpr9uJA5AQztouDCJ1kkJAjF+qNifL8Ynxfjs2LcNjlTxHJPid3GSQEeJmFAGqsHEDFX MHAyc8fOBIEWBPZhCfJgXD3bkiqnGZH1Idh1UveHjjYhLSeMOO1kn4TpGXHeFoxooM+LjnIQeI6s U8loESRPigh41EiHL+6I4P96deGhzeu2RsctqF1teJQTJsEFcR/dO73vXNAsS95/ittDcikhxktH /g9F0QVcfGcXL9bMu5WuFjgATxbybqM8HlCXAxktLpNxYCDtU95sQHixLMTAEpA7RvZSmWkdi9Fp Fokz2QBHp8RbODgkuJdULiXOLBlahKho7/ZRuLuZQFY55QNPnRaMQGKYQJIfiylJZinYEpNmn5vA 1W84dJHRpegzOFDt0ACBaqvFg/XcTfW7ff6hO5rV85Y8+kOkzV7qpt3jWQkHI8w+IYyHdF5f56Mt IPT2uchuEwRyG2V+APF8PPLlWDUmNZfjmhrKA1oWNLleWde5MOuY7N2gzzIw+N32vseKoG0ycssI C8eYcFvz8ZbnzhVcXW655aKJjO0wqA65GA2qp1r6xcBoxz3p4NBMP8M2gGD7+YZ1xqbiGZ7lskO3 4MgpPJbdHWXkrGOaelfByhTnUG4z1OntT3gYktzhvOzU3akWYLYOtR8JKpvcLJGJbt+JsGpZdJD9 Iq7I6u9X1U8V4QPJq38qUn9UCUooB0Jidd3NmKPk2Z/Vz/2XWBbFM1XIdVPP5AZBit6W+3k62++v ZPWyYnyPFbLdtJQ1kJnDmt0+w1UC7lWV+PO2dT4V28N02HZgq9geppugs+gAcgvmOY5SeE7jdtNK yOWlG6zPiMuy7/9UprijiIeEyrf+N7Qe98awmbe5Y+k7mobHYy4+xCIa/Yi4K499MMmejLKnuQCh 2xCcwperY9c9gNOps+nUh8XydNvVzVjSp8Xz6dRMQfF53MU+c7Dg2/nMIdihEKK6+b16g71/Ad9C MGplbmRzdHJlYW0KZW5kb2JqCjE2IDAgb2JqCjExODkKZW5kb2JqCjQgMCBvYmoKPDwvVHlwZS9Q YWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSA5MC9QYXJlbnQgMyAwIFIKL1Jlc291 cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxMiAwIFIKL0ZvbnQgMTMgMCBS Cj4+Ci9Db250ZW50cyA1IDAgUgo+PgplbmRvYmoKMTQgMCBvYmoKPDwvVHlwZS9QYWdlL01lZGlh Qm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSA5MC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1By b2NTZXRbL1BERiAvVGV4dF0KL0V4dEdTdGF0ZSAxOSAwIFIKL0ZvbnQgMjAgMCBSCj4+Ci9Db250 ZW50cyAxNSAwIFIKPj4KZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9LaWRzIFsKNCAw IFIKMTQgMCBSCl0gL0NvdW50IDIKL1JvdGF0ZSA5MD4+CmVuZG9iagoxIDAgb2JqCjw8L1R5cGUg L0NhdGFsb2cgL1BhZ2VzIDMgMCBSCj4+CmVuZG9iago3IDAgb2JqCjw8L1R5cGUvRXh0R1N0YXRl Ci9PUE0gMT4+ZW5kb2JqCjEyIDAgb2JqCjw8L1I3CjcgMCBSPj4KZW5kb2JqCjEzIDAgb2JqCjw8 L1I4CjggMCBSL1IxMAoxMCAwIFI+PgplbmRvYmoKMTkgMCBvYmoKPDwvUjcKNyAwIFI+PgplbmRv YmoKMjAgMCBvYmoKPDwvUjgKOCAwIFIvUjE3CjE3IDAgUj4+CmVuZG9iago4IDAgb2JqCjw8L0Jh c2VGb250L0xaSUdBTytBcmlhbC9Gb250RGVzY3JpcHRvciA5IDAgUi9UeXBlL0ZvbnQKL0ZpcnN0 Q2hhciAxL0xhc3RDaGFyIDQ2L1dpZHRoc1sgMjc4IDU1NiAyNzggMzMzIDU1NiA1NTYgNTU2IDUw MCAyMjIgNjExIDU1NiA4MzMgMjIyIDU1NiA1MDAKMjc4IDcyMiA4MzMgNTg0IDI3OCA1NTYgNTAw IDMzMyAzMzMgNzIyIDU1NiA2NjcgNzIyIDU1NiAyNzggNTAwCjUwMCAzMzMgNjY3IDYxMSA2Njcg NzIyIDY2NyAyMjIgNjY3IDIyMiAzNTAgNTg0IDI3OCAyNzggMzg5XQovRW5jb2RpbmcgMjQgMCBS L1N1YnR5cGUvVHJ1ZVR5cGU+PgplbmRvYmoKMjQgMCBvYmoKPDwvVHlwZS9FbmNvZGluZy9CYXNl RW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0RpZmZlcmVuY2VzWwoxL0kvbi90L3Ivby9kL3UvYy9p L1QvZS9tL2wvZy95L2NvbG9uCi9OL00vZXF1YWwvc3BhY2UvYS9rL3BhcmVubGVmdC9wYXJlbnJp Z2h0L3cvaC9FL0MvcC9wZXJpb2Qvcy94Ci9oeXBoZW4vUC9GL0EvRC9TL3F1b3RlbGVmdC9ZL3F1 b3RlcmlnaHQvYnVsbGV0L2dyZWF0ZXIvYnJhY2tldGxlZnQvYnJhY2tldHJpZ2h0L2FzdGVyaXNr XT4+CmVuZG9iagoxMCAwIG9iago8PC9CYXNlRm9udC9LUFNIQk8rQXJpYWwvRm9udERlc2NyaXB0 b3IgMTEgMCBSL1R5cGUvRm9udAovRmlyc3RDaGFyIDEvTGFzdENoYXIgMS9XaWR0aHNbIDUwMF0K L0VuY29kaW5nIDI1IDAgUi9TdWJ0eXBlL1RydWVUeXBlPj4KZW5kb2JqCjI1IDAgb2JqCjw8L1R5 cGUvRW5jb2RpbmcvQmFzZUVuY29kaW5nL1dpbkFuc2lFbmNvZGluZy9EaWZmZXJlbmNlc1sKMS94 XT4+CmVuZG9iagoxNyAwIG9iago8PC9CYXNlRm9udC9WTlpRWEwrQXJpYWwvRm9udERlc2NyaXB0 b3IgMTggMCBSL1R5cGUvRm9udAovRmlyc3RDaGFyIDEvTGFzdENoYXIgMTQvV2lkdGhzWyA3MjIg NTU2IDYxMSA2MTEgMjc4IDM4OSA2MTEgMjc4IDYxMSA1NTYgNjExIDU1NiAzMzMgNjExXQovRW5j b2RpbmcgMjYgMCBSL1N1YnR5cGUvVHJ1ZVR5cGU+PgplbmRvYmoKMjYgMCBvYmoKPDwvVHlwZS9F bmNvZGluZy9CYXNlRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL0RpZmZlcmVuY2VzWwoxL1IvZS9x L3UvaS9yL2Qvc3BhY2UvVC9hL24vcy90L29dPj4KZW5kb2JqCjkgMCBvYmoKPDwvVHlwZS9Gb250 RGVzY3JpcHRvci9Gb250TmFtZS9MWklHQU8rQXJpYWwvRm9udEJCb3hbLTEgLTIxMCA3NjggNzI4 XS9GbGFncyA0Ci9Bc2NlbnQgNzI4Ci9DYXBIZWlnaHQgNzI4Ci9EZXNjZW50IC0yMTAKL0l0YWxp Y0FuZ2xlIDAKL1N0ZW1WIDExNQovTWlzc2luZ1dpZHRoIDc1MAovRm9udEZpbGUyIDIxIDAgUj4+ CmVuZG9iagoyMSAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUKL0xlbmd0aDEgMjczNDAvTGVu Z3RoIDE2MjA3Pj5zdHJlYW0KeJztvXl4VEXaKF5VZz+9ne50ek+6O53uhHQgIQshEMkBEkAiEFYT SCQIyC47bihhFEHc0BlwHcFlFLehEwKG6FwyyjjjwsCM26ejgorbzEQZh8EF0n3fqtOBMDPf98z9 4z7P7/4e+3RVvadOnVNVb737qU4QRghZUCviUP2kqUUliH0W6JDNmLtszgrjfP42hPCOuevWhHYU /HEdVLyPkFh8xYoFy16/pvF+hCQznF+5YOk1VxjtPd0IVXcunD9n3u/vjd2F0OKfQeWQhVDhKHWk oMP1cJ67cNmaq9P93YsQeW/p8rlzjPMGqLe4ls25eoVprHk3wLugMnTlnGXz0+3zIXOvWL56jXG+ mJahFavmr5iSPPQltIf+1ZTQhbyQfMITyMvHkAeh1OeQvqBlclHqC3qdluTPcHdnOiG0Gz2LF6Fn 0UH0Ij4Jd+1BB1AH+h1yoxr0IFqPfoY2IxHNhJpb0BQ4BKj/GfamOlARehjw+DA6DG0vRTegLuTC ntSXaAPaxL0Bd20CTOegkageLUe340tSa1ETOsbfiCrQJehKtAK3phpSd6TuTj2GfoEOcL9L9SIT 8qG5cBxOfSX8V+p9NBDu2I7uQ8fw3co+pEMvrdDy52gVup9r5nFqQeoHGEEYXQVj4NEEdBh3kzg8 fT76HHvwem40POXRVCJ1CFoFUDNaiO5HXbgcjyVhoSk1IXUYuaCPq+Gp96F2tB+OTvQr9B42CydT j6VOIi8qRBfDfDrQ73E3l+zdmKwGjAmApQGoEq4sR/8L/RYdxRH8a7JcMAslgi5cm3oTOdFgNB1G +wTc+Rn+ltwAxwbuZX5MahSyAl7uothGv0EfYR8uwpPwDDKALCcPcauQDD0OhmMeWgT4vhee/iGO 4/3ETI5wj/JP82fErOTxlBVWJIYeQD9Hv8YWmGkIr8Y/wW/jT8hoMps8QD7mfsY/yf9RmgOzvgwt Q7ejp9G32IGH4sl4Fl6I1+PN+C58Hz6Mj+IvyEgyjSwhX3MLuZXcr/hRcEzlV/M3CjcLt4pfJBuS h5J/SH6bKkndjCYDPWyE0W9HD8HMDqAj6F04jqGPsYBN2ApHCIfxdHwdHDfg2/EjeDd+EndAL0fx x/hL/A3+Bz5DEBwi8ZMwyYEjQlaRq8jPyIPkCBxHyV/J95yby+HiXDlXxTVyy2FUm7ltcOzjPuJ9 /BE+BXguEXYIO4XdwtPCi8JJ0Sz9REby62cf7S3o/TCJkluSO5LtyY7URygT1tAHWAiiKhj9HDgW w3rvAIrbg97AZsCdDxfgEfgSwMxsvBivxFcDJm/C9+NfsLH/Er8AWHoHfw1jtpAAG/MgUk5GkUlw XEbmk5VkG7mbdJC3yQ+cxJk4G5fJFXBjuWZuPreGu4bbwSW417kPuI+509xZOFK8ygf5HD7Gx/mx /Gx+Lf8Q/zn/udAkvCZ8KqriMvFmsVP8mzREGiHVS5OlZulOab/0ptwC1PkS2oeeQ/0++Di3kavl 9qE7SCnvJb8nvwd6no3mcRMIUCrZjbeQ63EHyRWuFoeT4XgiOsnHANcvk53kNBnOTcB1eCpaTAYb TxOd/FNQVPEvoR7+BZjb7+HJV4tmfAP5WjSjdoxIJfT5G66Yj3Ovofe4Y1jiH0Z/4lXsxj3kCa4e qOBX/AihAYW5B9EvuZX4erSP1IJ0OiPfBnQ8ET8FcmEaLsHfcSnEkYlARRXcJ+hGtIT8F+oBPt6C 7sHz+AXoDlSK16PP0ePAFQOEK8UCMRO/QhbxW0kG7kCEfxJmV4lzMSc40U24mbtf/Jq8i9aiI7yK PuSegdEfIb/kJvAnhSl4IXDA9ehmtDK1EV0jNPB/xAsQh2egKH8cpNt6roQPQ7kBpEoTyLT9wN1d IAdGchOgxgOUcwnQxXSQEPfDcS/ICR4oaBHw+KUgxX6POsRppBMtEKwYpA5C/GvJKWhm6nF0X2oB ujJ1NxoI8mBzaj08cTf6FN2JduNNyevQCpQNnPMhvkQYQ44IY1IDyVbyLplKdly4voDtKPagP8Px SzgZITyPtvLvoKmoOnVb6i2g7nyQsPehy9F4dAJm+RX0MI7rRqXJiaQtNYZbAfM9hiannkgFsYoW ppaiSegF9AtJQHOkuD56+rSRevWIi6qGD6scWlFeVloyuLho0MDCeMGA/LxYNDeSEw4Fs7MCfp/X 43ZlOjMcds1mtZhNqiJLosBzBKPC2siYllAi1pLgY5Fx4wbS88gcqJjTr6IlEYKqMRe2SYRaWLPQ hS11aHnFP7XUjZb6uZZYC1WhqoGFodpIKHG4JhLqxDMnNwB8e02kMZToYfAEBm9jsAXgcBhuCNV6 FtaEErglVJsYs27h1tqWGnhcm0kdHRk9Xx1YiNpUE4AmgBLuyIo27B6BGUDctcPaCJItMKiEL1JT m/BGaugIEly0ds68RP3khtoafzjcOLAwgUfPjVyeQJFRCVucNUGjWTcJcXRCYt2EFtHZoFtDbYXd W2/r1NDlLXHzvMi8OU0NCW5OI+3DHod+axLua094zp/Cwx2jGzb3v+rnttZ6FoXo6datm0OJXZMb +l8N07yxEZ4B95LomJatY6Dr2wCJdVND0BvZ1NiQwJugyxCdCZ2VMb/5kVpa07I4lFAioyILty5u gaXxbU2gKdeE230+/UDqOPLVhrZOa4iEE9X+SOOcmkCbE22dcs1erx7yXnhlYGGbZjcQ22a1pQGz pT8w/9w1BrHmFKqbcg6zmI4ocjEQRCI0NwQjaYjAnIbSbP5QtHXuUGgGn0YMdyXmwYosSiijW7Zq w2g9vT8hRLVIaOs/EFBApOevF9bMSdeIUe0fiIKUTs6RGlzvgxPxeKKggJKINBrWFMY4gp2XDyxc 10kikRVaCApAH6oH3M5pHFYE6A+H6QLf2qmjy+Ek0Tq5wTgPocv97UgvijcmSAu90t13JXM6vdLa d+Xc7S0RoOQORE3ZzIQcO/e1aa6M2oXDEtj1P1yeb1yvmxqpmzyzIVS7tSWN27ppF5wZ14eeu5aG EhmjGzg/SUPEz7GrQJRN5xrTkwZzgo/CV2REPa9TkoEqWQ0OjUloLeOMvFENh//DmzpTJ+ldrDh/ W3qYiWHxC8+HX3B+wfDMWzkYMKjBumkzt25VL7gGpGZ0eHG6AIpH0xrCodEJNB04MwrfzlT3UJoa /QkdUDaaNgD6M6rSpxc09KfhRvhQ6hxYOAYE3datYyKhMVtbts7pTLVeHglpka0HyIvkxa0ralv6 CKcz1XWrPzHmtkbA1UI8DJiCoFFtEbxlcpuOt0yd2XBAAz9gy7SGdoLJ6JZRjW25cK3hQAghndUS Wksr6UmInqA6DJNsJzJr7z8Ank8ru8qzCnY+txMjVif31WE0t5MYdVpfHYE63qjTWR39UBkzelpD f+phLNk4kKoy8JxGJCei0Rr6YU8yprGaCz77aY24FbJqtA5J0IcGGnkGaFVLCuwFRNqm2UbmcG70 NaQUJA4FIS+CNAnSbEh3QtoJSUS2dM1ySBsgHYR0kl3ROXf73aV6JxS3smLv4qUl7HSOcdrUzE73 XtpolBMmG2XNxUazYUazwWVG9aBRRplXaJSOaEkrLVVLSfdIF+dCRyERtAJyTA4hG8ZgVeziMlEC EuHEdI3OOfbmxkp2HuR4hDnCYfACgqluDrdb7CUjVZIiXyMHCpKvSI9xhfTstdpLdo4cTz5GeyAd hMSRj+H4iHyENpDjgE4N8mpIOyEdhHQE0teQRHIcjmNwfEg+RDbyASqCVA1pNqSdkA5C+hqSRD6A XCPv08VhOYWrIRHyPuQa+RNM60+Q28h7AL1H3oOhvdFeUVlygAHxojQQjKYBtz8NOFwlneSP7d8P CHaST/aG4sFdI4vJmygBiUBnb8LD30QhSPWQWiCtgCQC9DZAb6NWSNsg7YKUgCTCPW/DPW/DPa9C eh3S26gYkg6pHpJMjrZDN53kSHtsVHCkC0zm34L7GiSHye9Y+Tp5mZWvkd+w8hUos6F8lbzcnh1E I01wHcE9GpQalEVwXSC/3pvrCKZG2slBQE8Q8iJI1ZAmQZoN6U5IIjlIctrnBR3wkOfRqzKClu3o S1Y+jh6Rkb44qMdGA42FaBYbdhFAkO0M7YwRPbbjPjilWeyOuwGiWeym2wCiWezajQDRLLZ0HUA0 i81bDBDNYjNnA0Sz2KRpAEHWSR56LjcvWDFpCQ6NtJGrAEtXAZauAixdhXjwyOBA3/N0bA+0FxQA xu7X4wMKgq1duPUF3DoFtz6CW+fj1htw60bcWoVbL8OtcdwawK3ZuFXHrc/joYCKVqx3XHBaqXtw 66u49Vncuhq3xnBrFLfm4tYQrtA7Sbj94lJW1LJi70jKV1BeNKLEBmMMA0bDQNZhYPuDkB+BlGJn OjQK5RiNvdm0zNlbUG2cDxpWsnzkOPIS3PgSLMNL6BgkHhboJSCjl+AhL8EDbJBXQ5oNqRvS15BS kERonQMDv5PlNsiLIFVDmg1pA6SvIYlsOF9DImh5eoh72MCK0oOeRM/IS3BQlzdMwnqWFtDi2jju zgC2ZeNJ2alsUoFcLhCCDrts78SW/d9avvvWgpSRCrmD3ImyYCG2pcs727/PCnbie9tjzwdHZuJ7 UDYPVIcrUQxHoRyKVrPzchSQaVmGAuRpKEvaAzPgNlt7rDDYha30rv3B7wMngl8GOgmAXwSeD74T 6uRxe/AtqHl6f/DNwC3BV4o6Zah5IdaJoegKsaYHAkODz77Kmm6EC/e3B2+gxf7g9YGxwSUBdmG+ ceGy1XCm24JTYjOD4+B5NYHLg/pqeOb+YHXgsmCV0aqc3rM/WAxDiBtgAQx2QIB1GslmD5xe0YkX 6oXSDqlBmgT+cYlUKIWloJQl+SWn7JA12SqbZVWWZVHmZSIj2dmZOq7HqZ5xikzdiDzNeQZrhObE UEwEywScqEQGV0fqpo7CdYnuuaju8lDi9NRIJ1bBhhAio3DCUYfqpo1KDI3XdUqpKYmKeF1Cqp/V 0IbxHY1QmyBbQHdOa+jEKVq1yU+t9QMIY/um2/20zN90e2Mj8rjWVXuqHSPslWNq/k3Wks7j5z+e C+CsxI66qQ2Jp7IaEyUUSGU11iV+Ss35A/gbfLK25gD+Gy0aGw5wI/A3tVNoPTeiprGxrhPPYO1Q CP8N2gHF/I21k7NRiLZDITnbaHe/0S4K90O7XFpAO0VBUdYuqiisHY9pu7bVubU1bbm5rI07hFaz Nqvdof5tXo1Cm2iUtXG1oldZm1ddrbRNYgRrEghAk+wAa4J9KMCaBLCPNZlxvklRuskt55rcwnri 8Pk2AaON5XhfG8txaBP/Tz/zR8XjeO/wxrlN1BVqidTOh9SSuHXdQk+i9fJQqG1uY9pHirVcPnch LefMTzRG5tck5kZqQm3Dm/7N5SZ6eXikpg011U5raGvS59e0D9eH10bm1DTuHVtfVnFBX7ec66us /t88rJ4+rIz2Nbbi31yuoJfH0r4qaF8VtK+x+ljWF2I0Xt/QJqNRjWB5s3IvMalAry3+cOMol7Zi BCPe4WHPDf4uMEh2IxM4ImZwai2Q6KWBIweOpJeAp+glK/V305c8NwwP+7vw7vQlDartkVEovmbt 6rXIU7uoxviuhg9UrVlLEW7k8dX/3Qeu1YLrWkOj4HWJgql1iWqwMdskCWpb6JQSw/rqTKZasLiN ykFQOYxWcty5hrSuitYpSrrhv67/2nQ5mnJBK3l+L9az8Rq0upFLZNdNIyAKpqUdiy4wl6h6WN0I E1yN43h13zPYsJEBIzrfvrRmbRpK42FNujTugltW96Hj3IdiicopFoAWECgXCaGwPWyPQgYyDZ0N cd1ndQGdQSG+mwq19cnJpEV4A2zoi3Q1zwYSzyHJmtaJS/einVYZSt0u7bRehjiNC3Ec94z957d5 4trp5t7TPdrpHlRdVV01uBg34xixl1UMqSgVJTgyNYyPbf/9hJkvbLwm76JIHMeTk1/A32HrV+/1 njnauHXH879KBpOhC/qfr5vzSb5GFFXDyKHQEag7OQxlBxjrl1nBq+vQNDIdgO86bDYGnOiwWBjw V92mqmS6zRq0EuszjvQYKUr+aZwZEWQvy4vBUepyuzI10rsRx+M5F+Vdu/GFmROOJCfj4/ijFw7s 2Drzj2d63/sq+U1ShlHq3FzyFozSg27Wx5uwSfVjv8qritlq0+ySaMLEQ2NfEuI52e2wSJIo0GgY C4ZZzCYnL3EyVkXBhJAWcmLnQVFApl+InXi7bhF+gXR7RhnyelfAqCdqp+ITTvWegAH3NldVFlU5 3JXwxXajpMXgYtScUeFywxREaUiFW5RcbimWJ0p5Qypi+qCd4zLwXZxzwaZBG669aPnVwyaNH7pu TclG/tk7hg7YVzN3e1nhHQXW8i3TJ225ffz0Owd5KRWMxJ1kMVkG9FKoe1eQFRyZgCcQgiOI+IQV 0MDLr7idDu5Es/YZKprQA2NYCcgsD2eOJANw57599CldkG1Gh+EpUd1DqpBKqmaj5WgD2oP4XXB9 F//wvWxdmmE94BGl5aWZXYcPHwaKRQfg3pv5GKPYoXqIF5AoKUSs4rkqLPLwpCJw9wilmIdl9pRT zSvhKdU9Wg/gprISvoOLM+CBHKQD8FCu8fDhs0/AwwlahR/mh/Eie/ZYPU8QMS+BiuJwlCNSlOfF aDHBO8kRcIUPCsinYK986Uw2W2Oy0FOV1qNVsb4qK+20KxwuB5YqD/PDzg7lfkcTd9nu3gd2Uzys QB/zw3lqGM7Uza3kTh4cZ8xJAnmezKSWBZnZLui4C9cjAdfrmehp8WlgrSoR+eSQgIW1Eu1d+6x5 ona6akIP8hb5euDj8WnGZA0KwLicfvnhZ8s5fDbFvUY2JufsxdW4am/yCsBoqhdkQKPQBXO24gX7 MVAqmU46U990pIHvgHdECpzSG81mcbpiprnA8iKtWFsgL1RatC3cNu0V4WWxWzupmWShEc8g9dpC U0L7u/nvlr9bFd7MW3grZ1IVgefNFqssSpIZYFk0SyCGoBvdZjaT6SgkmZ1wiXAcrcukdVyINzvh LiVbEORskRM7yQpdQbL5S51gQrqwCawhk+4wh9B8iZtSzx/hj/HcNh7zYPHppnpzt3TMzG0zYzM9 12zSEYlskFolIv3U9vY7Bo14IcHXA6jzebWeHuSprvL1VJ+ABYXvZmFQPH69dmjzIA8rGSnB+m7W Dh2yHjq0WTBKWO66hAn0QTbogw7exslSV+okQqnvhsKnEa9a2WzI3wguxREuzGWEOcqQHCn9A2n4 4OneBx5+F//tvjE5gVKh64cx+IVkDZmJdxy46vZbKb1ckfpcWAfSJQu9sW8uWZxFcGfqiw6TSZwO +PtCn02hECqxzAXKWpPVim7K2obuF57mfmE5wHVYfms5ik5k/T3LbnVk2bOyuAIx314QCAXHWmY4 L82c4V0oLMm6znGr437uPuv9gd34MbLb/pY1AzmRT3NqPh4o4MP2/Eros1sfmF+p2RDm/RnZZs6f zStazDYexUIYY1/QHQvJWDbT0cje7LlNhrBqntADdAr5KcrU1T12Sp4gUpubVyLACl6F3SIfyckl 5WWO3NISHkRVLJIjkkynw1VaMoTvePGi5Euf9iTfeWAPHv3i+7hw+MHSF3/65CdNyz67+dGPCRn8 9Zlf4yv/+Cme3nb8tYG77n4k+fVdzye/3PoClRoPAY3PBBq3Ae4+1YtCQTxaDmRlA/XYtWwbkmHI Cg7qVEkoIao8FJVqDsXDaijpZzLS9wWztBCm0oW1ArSfZiqGAbQtAD90MDruTH3bQe9hpK1SFkLN 2cObqFwzaKC5qrcqDVM5B2c0DS4efY0+hPNL4HcI4Hnwotfj8xDRpJpVi8qJmS6nK8PFiX7OHcYO K2QeORDGLtUeBtsA8FkAn424udQeLnGD5nJkOomVRKLhkiEVQ4aUl4FGi4Qfwt8/PfOGxjWrJ157 1+FNyTZcedcvBtdOuGfpxGeTrwtdmVmXXJ48cuiJZPLJOSXPDhlc++Xjn31bkA2zfgQhnr77N6Ht eqYoZMuyJCGOp4hUlWwTkiVKHVmao0yaxo0PqSELUX0WXvmPcfZDH85O9uHMPHyWQUBppE3orWJ0 dOpE/BzSHKD/NIo7mHVmOJ0e4XPPPsTFz77F3SR0PZusfiZpeZZyEYhefhPMQUG363E2hzslfG4a MIUHQyRkIsRn+g/GrZvYwM1pJkz+y/DV4U39ht9v/KC500Nv/uex7+Y+OPspSfTW03EPe7b3ChjD QRj6Rhg1h17fR0dJBMD03qEXlbGytMwoBxYbZf4Ao4xEjTIr2yg9PlbqBRatLCRsE/YIHBcC8Xsn 2oUSiC9COqpHx9BJJDhCULkNcay5iU3Xk0bDX/vQ8FUfGk7rmiG7GRoe4d9u7EfmYPO2t4KAbm5c uQpslT4TtArmTyddaj/4IhV2MMd7ERJtMEeNnGgjNPR7AMnwbIZi2WqxM3UEnQIAw/pKz6eQ2UEv CzYzpyBMZMVkRbJCVJNIR2vS6AhNsFD7aSuTBoP9rCM9j+/65nHWmEcRjOowy2Bo3d3a0aPdVInG 40xOxZG/TaSD0oMSm6fIco7lPMsFlsugO/UIhQgjC06kNEGs53WnynKpT7XKVEIEKRQTsDmkOsps LBPMHMJWYCoZuItOnD6NAewhz5MZyAG4mqFb0vQn9skb9liE6VxOFQHpMau2yphMszEbw41guV/f gIhNdhK/zK8z32z+HaDSfLH5Yhs3gI9aCq0N3Cx+neVq62aLbCKCXGkZYp1E6rgaSZcnWEZZ1XvJ fdwOaYe8m3tCEh3EZrUWC8QpCEQ2WyzFggygbJ5im4J1UNayrKgmoCerVaPr1OJodRBHF9mNLHhw uxACR2KwrpoVNaSbN4AB3QWTtGITXCGdoOIVcDxCthUa1jrJjOdCQovQKgCJkt177cOB5rygyU81 V3lAsDItDrDv3MmJZtDpgAat3wGmEtPtm69nqh0KMJnOq/BfIXPqDNDg22Amvc00eF3CDNfy4doB ZEl912ZVaS1z6yypN/eHK62F4UpLJ4AVldaSCgbuGwi1AysNlDeCDYBWNgM3NALDY5d7SAUO2yN2 HMH2e3EunlXs8pbj2Vh4PjljT7JB6DrzzV3j6h/gzv4whn/tTDl//AyVSA+CPgtSGYavb3OYKIuq GZllssfsAmuJ2gJhCslgRIUkGcwpmUgcJys8IYok81xIFIU+PhYouTIGFwxOAsWl+xg5N4dMOGSq N7WYVphaTYJJBnmIaGcW6Ow/E4x8WjD+qy5Uh/cTEvHmONWGYIIx0QDykJEsGFnUkN7MsxUy2O8A 4lLHnzPby+QQZEDBjYOLqeKDNeiQ9TGVMP3u/WMqZb3EAEsqpRxvJTVe9nsBLDFAWhthoG6KVEpW J6QMen5qfwaAWQaYBWAmBb9ry0yvXxz3Yx1YwlIMEgzW7sHfcqTrt2eTsGAb+Q2wWK1nWtOWB98L K2UBn7BdL5xvX+IkdVqdc5Y2y8mbzNnALcjtMTSPIyarFH+ylpYjp3Q/RZvsC/kwfH0ey/+pQvpX fertb4MwI2SitrKZnk/oOaeSmCGCm5FhRmSDEUbCYTvA5ywIMuDuCUvvbvwq+UpyC77uhYeaLxl8 U/IWocvqmL9/2fPJ3t5nOHzbhqYbMy1U5zalPuf/ApZrMcnU8+Zyc/nV3Bqej+aVc5WB0dzF0iVZ tcGa3DF5U7lGqSnr0vxbMqwR6oLQeeb2AdE+INYH5PUBEYYCo7EBRPuAWB+QR/XUGArlW2K5JJfL iw6xlUVqorVFM0MzItOjS02LLUusVzjne64xXWu51na9tjZ3dfRmbqvpFstW2+3aptwbo3dbdth2 ZGanNcHAcMzhj/mU2AAcQ2iAz8GXDI6h+bDsloHX+G/xE3/UZRmYnRfFUcEl0PU0fKfsgUp2totj dnAcXIlmSOmimTluRT3G4dcHRnOtFpMQBmvVL0sizxERR3NzoA5MF/9An06X+06gjR4XGshsc8bF Gg7hetyCV+BtWMSdOKFnDKRd0q5hxOOVGBqAB3Sm/txhtZLpA+jQLPS+Ab4SmBOOOah4oJccfcTl OOeiOaZRGvQOnmsYZmDKAPGA3zSRUtV5A18DXX+CZqfojOw0JgHsDGAjdUtXng9G4eaVGRXZBIx8 g7py82Kx8rIhQ0pLXK60F5DpdLt4t8uV6RRF8BFiTc9ZZv/u+uVPTa1vGp5cOnnRghu++dmj398s dNmefTLxcOVQ/G5D67U3n/n5b5N/vw+/o115+6WjVtfULoi458QrHp2//NfzFr2+0XrrHRtnTSot XZI/fN+6tUdWr/mSUmox8GsX84Zv0S0CyQaEI7ZBSekkq/eGDJ/yOTGESRGHOYD3YcaSVOiaGFvK aZ78ps+m/biPOc/2MWPSUND0ifL++/q7BIBOkH4nmj+j2slgx8HFLIAAdiHJSGbxW5N+wfLssz/8 nb2CAD0wBkZrxov3y8owjh8Ozsrnex3uMpAen+tWAHgvZBzN4NJ/7fWE6aX/0ocDwOdD5ojxA+QC tcjKL8QLxYWmD0Ve4DlOlCVFFBWRU1Qz9YdCqsmpglXFiQpHGclFa7kQwU5CsGg2iRgQhU2dxKsr qqpwBNBm7SQeXTErU3S1VQUTBu/TLSYTeOnclEnkTkIIrVEwRs4+eaabGPLMaYR9nEYh8ey3WF8M t+wG7/u0oSFONQOBGcVnFE+g108xCwc7KjeDsy6Dly4wd51Cm6mTrkFWl3CD/g5Q91w2K2a+K3UK 9MkpzPxzFi6h9qquKKAzZEg8aIg2L5X956O6YTt470xxg/Anw3tf+ysO19eOugwHPu59jizjJiTH rF+/ehvec3Zv70/pKt2aXEQ8jKbG6HGei2OiCWIcSQ7AkiT+kheimNpulHYUhUyn5PSM/POF6dAk kMCpKkYN51zEDHATIvbSzFvx7e++m1wkTd7+/bvbaU95yUW4g/VUrbt5IS6JGkfiCDtEQcDklzwX lagBDxYW7e0Z5QEaQDr177rA4XLQa+Vh3JFc/e67+Pbkou1i3naq0canvuAD/AiUjyrIQL1QsSgF XouvYICloABMw8wK/7CCiwuaLc0Fiy2LClqKt1puHnC/6wHfk5bM/L5wRR7lFi+FHvc+lb/f+3z+ Ie+R/D9mfpAv17hwNpVGdsoqDsf5UFM5ff02nUJBd9ATLywoq+QrCy/mxxXOkBvjV8iL4uvMm82v mL+3fB+3V5RZMa8V5Za5S8JOz+wByweQAYEia7X1TutOa8oq7LTusX5t5azmdHz4z30RY3D0NU2c bjVTBrWKNhvk1gDn7iRP7fdsdwYCFH+ndB9j5No8tSTAmQbM0eYgkZFsNJxLBWdabf3VsKtyeYrt XBqFNpkYcIphAYD3qcwAiHWU2ychcjvJLN2ap6OYFgvFimN7YkIlSHYmj0Gdvb2fAYMrmSmWHSkr ruyuJLsqcaWbjm0kfaI76skpyj0oHhFJUKwWiWilMxUZY4keOh7gWZORgytjpdMVNdq5OHjoeetg JQjzOJhllOuae/qcWKCX+KefUiF/Il7d03sCBHtRX/uVhiqrPBd/ZBKexr3QyigV3ky0V7CjvCyP CncpbwRhst6Vmel0uSMxTpSsYHLQsA804qrmHVi854Wxq8eVL3lvAS6t3bLhmqyE58qjt2x5ql5T 3DkvBNyXH1reVLJs0cJHYlk3Th/z9KaJGyc6rRZfblS9cuBFjSs9K2+t0+eMH3T1yTObLhqKP8gP aPkTisa1zJp00VXANfWpL7geoGgfnmn4nXqZdYMN20yYusMrwOfmHQGT5AnwJmzNlGSKfomhUjJT VEoaRaXEcHD4zZcN7XeouYSmwcV+faxixsHA6IzR7qkZU90tGS3uB8gD3P2Wx7THfGbZ4lUXk0Xc YmGteYWl1fK4eZ+yX91nNrvAFfuEcNac2bbltg02zoaBCPVripmP3gLD2gZO+3Hw1RVks5nQ+TEG YOi5VplRcI4f5pdrigdBymIaDIXVxjqlEDyOrjb20Wb44kBm7hEJB6VqiUhW2khSaSOJMaA02F92 KK2lYIkN8mheld6YdQBhuiGtZ9WpeM8qNncgB3tlkdZ8Ar5M14OGb8RuuvrIXuagiv2cXqeLzFW1 ZX39y/eS36768pZn3w/u8W6YueWpx25afAfe5H7uCM7C6jOYbNzzsH/J0pfeePvFn1ApNAbW7BhI OjvKwtP1x1TCW6KWMkuNRSh3lgcuJdPUKc6pgQVknjBfmetsCXQH3xTeyvjA+2nGp86v3X/xfpp1 PJgKuoLBuK/KVeWr860IbgtKg0iuZZBrGCm31JFayxjnxYFL1RmWBZZPxc9dP+BTVg1nclaTZkN+ wLUdqZnA/p5SjKJ2W1TTjtqxZtftLfZWOx/UKU0YIUW7gwoEOxNrlA3tIqUgOwsu2pn7RTFut1KM 2/v8ezu1t0bR1bGvceQelI5Ix6SUxNMlmiRxUjYjOcbJUrZBimzZmOCSmHySvNll9f1jZysn9PSe N7uaV9KXFb1VJ+iaVdFkp5zLlCD1UcPllFuBXY0FAzcHs9UCGw1Wjhs6/9CGt9YufvPGlh1Fe3tD z6xd94vd11398M0P3Xbm0Z2Y2zp5JLH+MIY4Xn/11y+/9/ohumZ1oDmygc8yYc2m6u4gCmSCDdEs NCvTTfO5JcJyZb5JzjTe1jEEnNCnUCgrQPM8x7vCD87TPn6wY5h3cGCkY4JvZGCyo8k7JTDHscw3 J3C1eHXmaXLaoyEXtlnc7npXi2uFi3MFbNu0XRrRNN4fUCXURZ6iFMuENDOYNYp3DbhjewZwj1sH n/19ZrJZjBCXSIE/s0Wx0PZKXkFZwoItviANqUVjZbTUR1JBHMRBV6mWK+m5BWV9KxXqt1IBtlIG gwXYGrnYesFKVfRfqfiE3hPgloG1w+xk6pn10NDZCcZc4LStrEq/zTLcNCZjV/WxmIZKS5DdKYVd dL1wOMbELHdZV+FXB75Mfo2d77+FrfjsF2r7prm39b5HJpuHzrhl/ZN4hvvRDhzEHDbj/OSHye+1 0J6uhXj7zaMXPg6rNyo5mfszrF42KsDL9RaTSXAWmqLOS0y1TlHJ8mYVmmLOwkilaYhzvGmMc4bU YFpo+kH9R6Z1UKQwb0RkRN4ledsKdxVKQ8JDBlQXjjGNCdcOmBaeNmCRNDc8d0BLYWvhe3lfhL+K fJ1nd7vEzE7S1pEfyJCY1NNCYJhTmdeKutFRMG86yfV6iRAI2NTanIBZdWWWRkvVqMdz1I01t+5u cbe6+ULwhcn0QsaCbsaC7nMs6GYs6Haxa7C6BgvSViI9N1gQgLP6eLpA7jU2HEU5wdyDtiO2Y7aU jQ/aqm2TQCiz1bX56OracujTbAH6JBvjQxvjQ5s3XrgmTFkxPrEfK54C5ruQG3tPnAYTrOcEXesT tGRO+EoQoG4aymfqMA9WmBg86QYLjflDsYx+jHnFHlPJ6DXXb/FY8brEn05e+YfbX7j28fl/2vW/ /nzf49ev3/3stVfvbvBNjpbMm1mRuBVXfXAvxrfd23p28XdHrn6aK/hD98HXX3r5JWpLbkaIo7F+ J55zALmA0jPBj6BGGDMWonw5V8t1WXhWNcztLXPLdrPdyQkY2QKC5DSp5qiilw4pSym4W8EuJg9d Onu5ks9yJ10ChZpJdvaahZlJio+2U5gvQBGpOOmSKFQYmmi/9MUMOz+9nwVUJ7oo87nLhpQlXCdd ZIVrlyvhSrl4F3FGjWCVBmM4SbdlhYByjiOeRUXSDscPupsOAvGG9U27Phey+kF30a4QYbYeYR7b xMyx9f2iJ7Bq6bhV/FQ83n8x42wnQU81iFTqkbC3OlbRKkWtotmPLbLNjxENJW1EwOw4TsPgzN/N tEfsbBnFTPvmjhu61/2yrmPtkvrbq4Su3m/ubn7swd7Z5OHN10294/re54Ent8BCVbG3AhI6rF+m DKEzmKRsU3YpCaVbOaacVCSkBJUVSquyM111XEkpalABe0DiCQce3g3gfQgir4pSVED8Tn4Xn+C7 +eO82M2f5AniQ/xROON5GlimeOPP4Y1neONV2ivvZIFww5ZmgOHl8pSJVIpDfqL8z9hbVdXLvNxq 4+W8nb2dx82rVsbZK3rAypaOjg7+L0eOnMnkY2feo3QJc+a+o++gyBzdLxr6TpwhzlQ4m+Xvwmnw WM10lCI1s+nw1D5A6QNYhFSjN07nrlKJQwxlMK/45F5HHvWST3ZA6RBYRZhV6DdBjciDZyxWKGPB YRMHqg3qVdxa9T3uE1F6XMQRMSZF5UpxqFJtmWRp5BvFBqlRuZ6/RrhPeVn8I/+2eEL8UvpW/F7O dKiqwHE8EUVJUWQ4UWQ5KolOSRI5no8KqlMQwIWGExkD+gVRkoEykcp3YpuuCDzziXJkehYOMYuN Ge6SbxsoJVMUkSjG2xCuRpOAQmAZ9MGMxtmrEGS8qGErhhyM0pmJh5i5iLxmy0fhsVf0k1RUME3Q WHRn5WkW3WGkTcMTNEJrd1fS+DlPfWwBvG0rAJImV8lVHMvTgTJLnYKDyk0cUTwWGrQFexDWmXra qlKYVanIWVlVIn2/nFUJxZvtIVa0hY2gayOLmK9E6f1TYqq7PcyCu+0uWnzYrlWKRsHOzKxoM/VF 3GnElnbl+IDHstMFvTmdVSyDu063e+jNf23zV6aDUY2Gz0LDUowvwcvHESwBJeKnvkwuxgc/TD68 Qeg6+wJOJNf1ziPBa5OzKF3eCFkF48VP9guMEdkrt4qhxqu3snKjLB5slDnGqzk9CmLVJgSFncIx gZ8E2UmBCworhFYhJfAgtVTCGYKMPokJtMzS8rKdCHeD6U/6S7Xvzku1rH5SzVhrxp1IpqzZLwCV SvWFpNI8iibyF/IoZVIWg2Cv6zA7ox+KmRs72Is7Q1eIMbANIvi39EXIqb73WgZAA0/6BJOlLMqf 4E8oH7k/DQlvCadDxC2HIorHH1I4LpIdEDOp6pSwGPF5NfVoFG+L7oqSqNvts0a32bGdZ1a0h1nQ zLlmVrSTTtJOOdpNJ2onzJY2M1uaudX2vii4ve/NmL0TN+tmT3SbH/vZ4/znHudnj/PTt4t2+jg/ 0wZ+5gz5KS8xJeQ30wf7+/x1P32eC5HSSBQfRZj6ZSSIKP9xjP+y/oX/mO+NXGlNc7YjvSyndCdT OcZSWA2WzI124qv3hsf2tx/SwhOsRK1fTU8/JdTcO7F2fs1nK8Ejq6qqAhHLmNjOdohV9ikkszMj 5jTb/dhhyexTSGlzEtY3k4Vg3TQz1BLz2PorqIdLHl+87p7gDa8+9NTeSNOIFT/raJh3ycZhfGz7 xNmXN3Tt2d+bR36+dPaw7Y/13kPar766/v67et/tsy0+A3px4ev1DIETM8hurVP7hPs84yR3OkPk qcitAoK5RsP3akc9xz0pDx+SnVanywG2BRZdFtViNVtzPcye8DDbwsSsChOzKkznrAoTYwJTDmtB McysChOzKuD8e2NBTcyqMFGrg4lDEzNcTBi+pokeynQ+amF4TnrICs8uT8LT7eE9HCnNdDHePN1h t6e3L/xbw0L9J8PC3s+w4NOc2K07/tlQmejWTvcPlLMwHYvG9K+FT48Ru6uu7jlvbbhEu6LKqqRy ohYDj9OPbaojvch0g8hKKoXZKqdjL/2WePMjaz9oebheUzsKloxb/QQfu2dP7YoJJdf3riY3X7ls 5N2v97JdNTXgz+XBKlqQFy/Zn+mhM8mgMT5m+1KWXE0hL7vgkFSveaw4Tp4hNsoLxEWyXKYNcwxz lXtqtTpHnavW0yQ0KVO0Zkeza4pnmbBMmactcyxzzfNchTMVUbDM4qYJ09RZ5qXcfGG+utSsugO8 ZAeR4cz1Mxvfz8hAotY8s/El5mCngzNUqzO3iwLMZqAAXQcGpF/Id+sZudGyYgkjSZNC4LwNPgYy gtZfTN07gK25yGylMWoHY2cW/0EBtr7MrUtzLZM/yMVWWIdHUnFA0GAfdfPSG06NlQMnr/l0c3O/ tWQhFBC11AdnseipwlTlcuFyhae6iTbJ0Cpg0ZDxMgT1N/5rHrvlN3/Cruv+cuuxZM+B9s03t+/d tLmdZOC8O9YlP+o9/Jef4Gxsef211//wm9dehQFtTi7iw7CCDpSNL9fvMGsDtYu0Oo2vDiVCJBga YI5klWSWZI3KWhHaFpKHuYf5x7vH+xvlWeYmd5N/sbzEvEhb5l7i7w694fzA84HvjewTzhPZx0Op kCvCx7V4Zjk/TBvDj9dmap+a/pKV1Ex2KzjkASrlXQGrCVm9uUdVrKm62qK2qnyILWGILSfYbZ8Z 7wNUT/r8hz6D7txeiFNsCVVKaxG2K2INziglpY4oQt1gBeFdOIFPYj6Iq/EkcGypnmPSGDNpjJk0 xoxCMIufYMrMLDxGmzIHALPwM4hIGijzBsdWeHC/DT1pQaz1njpx3p1Lbzll/JiOqEArtDKjT6i6 Mp2EOm55dq7f6m1+bNjdC7ccXbz22HUz7xxkf3zd1U8/sWZ1W3KR8Kutkyfflrr30eSZWy8Z1nuG e+zwodfeeu3Vd6gs3QSs+DKsoR29og8vysAajyN8GT+an8pfwa/hRcUuK7JiybArFsTJ2MSQj1Ql f5uM5ZxQBs4gOfb/3lc6Z1V8p9v7iTSRkfwFustwl8R+5uREx9hD/+IundCaT62iu58odugmSmb6 I+2VzVa2/aJ5Fd29ZiDKLbEAMYikTY+MWFQ967IRo0YNv8yZzcceXjlu2BN5Y6tbVvW+SbFQnfqC awMsFHNu/To+x5kzTBmv1OTOyJmfs165Q7kp9/GMpwtf5CyK2+dxF9cVvu0W/GQ6IVoJVj1NcpPS pDaZmsxNlsXyYmWxuti02LzY0hHryLPRF5K5A4bkzlQbTfNi8/LXRNbktub+VH3QfHf+PYXbix9T nzQ/mvdY/t7Yb2Ku/D6bJ6cPiPQBuX1AvuGHpNtQINIH5PYBWXRngiO7cqacFzWrvC8Uy+RNg7J8 NBiS4y1ksUVvtXeSd7Z3j/eIV7R5g97l3mNePui900u8v4K1yQS6YJEu3Umba3T7jYaPgkuBNUy3 jnbvdbrKjAiY1V6G8aCmrKVZJCuQKfHGKwrm6n3W5859pmfQBeYDg0xBH/blevUMT1kJvb2IMqnX Y+SUr7wuSiPeEL3TG6J3eZmL4mXRLm8nmdUu5RbArfsClUcLcAHthd5RQJUHfQwD6B0A/Hk/vanA x7oK5xWUtZR0l5DqktYSUkKjdrnIY1hWjORCBpZBiFCADoACupcOIpRrY6xuY8OzhVi4hurjEO3T xnZopQM3Ocf6HCjv4HRornnlhDTT90DSoFg1Mf1qJB5fGZ/Qz/picXAoq3tWslcj1Gqmr8JpYbwf Sb8eAT2t5w3MjgjOwphdc2gZGifmWEJ+pORLfiwMhCzbCadha8SPciIWszxA9eP8PEUV47wfBbUs qtHj1BszMrY7pSC+ceNG1E9AUY+a/hTAEDV5sbxBpLyM7gf9p1fscNC9HiymVN1uu+W69VeXR3/6 8n2TRg4tuGvq9b+aaU+YVy9av9jlKvLfdPCeGYtevv7Iu/iiwJJV82suiniiJRdvnDj2mvxgfNx1 CzxTmqZURAJZGWpu6cj1TTN3XvoM5dPc1DekQLgPudF/HUAq3aIYox52tz4SgFYvRthsUTGHXJoS t6mgJDiTTctBOdjiiJpxSpJrldoWaYXUKm2TeAQ6epeUkLqlo5IoUbVAZZVkqAUGfMNemqW32qUB Fok1bDVD+1MtQ4MIaSPAsF+kLrIYefCQtiv+yR0CQd9Dgz4nTlWxyHlvFRXy9tJS7RXqIMXjUbcR OLdHykvtFSDJInYnRT3RfJdUXb608Kab9u7blxHPz354pzZi/iNk7m1YWpq8/bben04o9DFPEmTZ cfpXt/CkA8hHI87gI5JQhqvMRkdb6nCWxTNwrpzhMuMMlwmEuR3QhEpdUY+bGq4+ZhW7mT3sdrBA 57mXkW4mvt3nLGG3Mx3yTMfX3My1cVNL2ELxkXLjbjd2T/Qxz5Mawb6TPrLCt8uX8KV8vM8cVc4p DgUjJaQcVY4rvNKnOJRziiMd31NZVI9tIWCRPGYFKyy8pkz0XuB80jDav5q7Vb3sjUV1laE5GBP5 eM1qsVmIaGybBpOXN/uRRbb7ETV4Cwo2ggqGe9PvNPJgcUrtQPAutukEYK56/VuXPTpJM3WY7FdO nnzH8I4HO8Ytm1S+mtzdu/f2wWMnT71zC6k88156z8VzsDoOPqtvl6qDhpUZfRmvgcW0vfJmh9nC hOgXuolC9pDZuNDdYTUCaSA8KWTX2blq5zAyg77Dok1FqsXMdgWY7ZjwKm9X056uQcp2kCuHD2tv H9beZBtW4ZN+5WqgiU7XDzh24gJ+gErG22fZ77Bz9hBFNIzgeF9w7njfy5aTuhIMl2mBLCMGpj8X zC3jRbOSIfoVr0PgES+aFJNVdmgog3NKAdlvygJrOCoVyHFrGSqXhsnDrTXcWFGXJsh1ptG2sfbx jlm2KY4l0jx5geMa8VppjXxA7LLtd/xDPKPkm+z5KN+SZ8235TmKnENRheMq+Wb5Xu4e8xN4N9lt ety8D+0Xu6y/498W31W+4L+wfe44Jf6gBEwiHbGZ5ZpovKhnQpvljnTIya9abbwD2WVJjkq2qJWa hFaJs2Bz1NKZeluvoHRoIVFcwOw+C3ZmiKrJHlPj9mn8FLXJvtS+3r7VrtpVnkOYLoexMOdR3cwM l6L4qSJji5N2gh6GfIevX3dyggAkKQmKqsoms1nV7Hbg4Lq9AnKAVrpYv0K1WUMv2SU5JNkdjrgg OQVBssI6Ry1Wp8VilcGPiauyE25HAoGxIidmvy+WHLxss5utFjY8B3Aq3YlPd+I4bHRHoeo8rVlw i4W+UOYsnfgJXQ1NUvFydQPdh0Om68okO15u32Andnpm0gTcwmJOnACN9+HTGaevYErPO+FUc7MH NBd8fd5egD87F/3r20Rr/OyM/bTKzvLNE/rvqL2wAKrcbNUOSVatiiYK01SXCE5t6LCEzCHyQuo4 WC3HkTV1tAMV20IOoFG2P4ft0alLlE1l+8KPtknFmFWEp9YlStmLaDl1vE0KGbWO9B7eA/RB+0HZ w7PlztTRdqmYPrEdDSVdRk/nHn7uPje7z546vlcN8SFEL6TjlfRpb+53VKJCSDREmXF+b5ARG6Ps x/b3hnFphntIRQbkkOEIl8fhuuTzXU9W86VPHthZftH+PcmO558c8A4f633ghP1VcmXvva8dJlec eY+s33f2CP0TAQhxfwNJo+H30/sSMm3YJPJEEYloAYq0MZvLVhRnRMl+UeN/zubAthwvi4jq9d7K mbYd/A75Puv9tm6hW+yWXrMpNt1V6eMylEyLTyvHw0wb8R0muchxKd8oNZoarPfge9V7Tc+RTvPv TK9aX9fe495S/mD5k/ap6uhjLpMZOew2jwVUh0ilm5VCNhERC1JVIrLNu5QkQAzRwq9fIYqcJCsK FkWFbi8DjQsS24JtNotmArVBLCbOrKmijdhU7WX0skK0KFKcCCkcsbxswZaomXOazZyqKBxHRLD1 zGakTnJgx8WWG8w5qm2OqNygq53Y/5wu1out7Edio3VriLuB5EwCXF5sX89ckeZTPZSOe32eHu1T 7VTPZ80X0DMNZjenqbX5eu0QosO32TbLjEqNHApKulVyVZooOqyerEoT20ucVWnOcVdykOh5e7hS Y5uzMytxTrhS0QN9u4jjjSwAw+LNpRiXuul+sgoaaebysA3flLzvo0cHBQqje99J3oVv/eC9Yckv ST5Ofj+2eFTpmaS59/d4fGOyGeYVTk7mvgIa8eFv0zSSpTptnIkLeG0O0SRm6A5byKSbQ2la8RbF fR/4PId9Xo0WzA1jasO/1xbANjqJZYHKfOcM2x6V0y06LEgov7hMo5lkVhwui8eRZ8oz51mGmIdY yq332U35jvyMca5GR2NGY+Yix6KMRZnXiOss19ivdV6bucmy1X6b47aMW5z3qrtNL2jP27ucf1Y/ d/7D0qt970wFsvsoypVhCvh5W43tJhtn854bvuEmOtKy1q9X2GxmDWSlijivMyMj6lCdcGIzgzCM mlRwdNQMumnMJNIHoIAWIEWBgwES6CTV+2yAC93ZSabppmqH7iCzHQcdxNGJR+234RxU61fpJYYt PWQuNk8yc/XmlJmYocXeIhvghlR3+EPrQTAC8nrprwWBiOgvCzzaqRNe7QR4/T6P1sMg5KGmYR9F yf1fj1CS2szoB6SeFaSNB6TN88ic+gKZUl/g/rLGmfpwf0WlmlNRaQUu25dZac8x9qE3UosIrWym 5JORZ7wZrqAbEjNcTORgUFVg6WxwDi+sGue2xwRTctmLH8RzgvFPOpJLR+YWr59RllzwpJaf619i y+Lze+9bu3H9OrLkzO/2jGqcSm3QZfgoWci9hkwoeABxeKpuVcTX6Vt4gtaaL32CsVIPKuoZXJxR xiLETmpZLdu+cNH27YsWbie/X/Szny0CmD6rlfs7niy8Ac+6QR9ynXybTCwy7pXwh9LXEvkV/TXm A9IvJTJTWioRWTIh7nvQZCZUheWhy/EGfCcN3NAfwErwLGmonIeqOLrzlHjNP7/GcM3SARhqkDfj E4juDK1iP8JFzChfST9o1UqcGSmnPz53i6KER/46VDCrsKKM4w/94Rc3V9UPGOOedSn0sJT7El8k vAKjXaPH3pA+kUib9JJEvpHxT+WHZbJa/olMpsvzZUJkLJs4JD8t0dFl43PDRoSrMgaK6C8iLxgm DRPBMI0Bar3svSeCMcLo4AMjpS8+nRL9kfaQivW/DsZnFQ4p5/jvYIjDJw8Y65o9lf5tq8x/e0xH u7GHHcNx439zbGbHQWJ83iHvcGt4D38t/xY9hLHGIb4vtUltchk9lFvAnk8f6l44vlC/MPmMw3yj +UZLs7XC5rK5NKt23D7TPtPxeEausyoz6EKuj10fu+d7K72v+e733R84kvVR0PJ/5Sj9v3hsDb7/ 4/Hj8ePx4/Hj8ePx4/Hj8ePx4/Hj8f+1g/3NX5L+K8BOxLG/d09fp4gAFE6+dPqUsQ1jLqkYVz9p fFPW4OIQVzPRZJ5Zlx+bap8xSysdkJs3ZF/V/s3hEboF/f/uw6P1LOcpfk4OSqUgxzSnf2YK8kI0 GV0K/uMUNBY1oDHoElSBxqF6NAmNR00oCw0Gxz8EOK1BE8EvNqOZqA7loxiaiuxoBpqFNFSKBqBc lIeGoH2oCu1Hm1EYjUA6MpCJkYP+ow6ARPrn5kauWjRnKftTmXgbPf8PP/KFpyfRydQFFem/AC2y lzRGov9j4n9MT6H1NHFZSO9LcD4SrnX9H6YDfYl/Bq2CtKIvCTNSSZZ+i66A9JAwAz3Cf4J29yW4 52D/JD6F7oV2D7I0g7XvS03QvvifE9SLNMG9t6ZTXv/Er0bjWUKoHsoxkOrSaRSkzfi3aAtNcJ2W N0L/m2k9pJp0uRlwsgmuV8PzcuH8RppgfPRPoNoghf9fSeQwWvb/YoJ1aUXAMoZc+x8+2GjTltjT NdtW9Q/ZbzDNI5/kFdDywFsdp3/Y07tAQ7IZTpU+nvnfO9fQbgplbmRzdHJlYW0KZW5kb2JqCjEx IDAgb2JqCjw8L1R5cGUvRm9udERlc2NyaXB0b3IvRm9udE5hbWUvS1BTSEJPK0FyaWFsL0ZvbnRC Qm94Wy0xIDAgNjI1IDYyNV0vRmxhZ3MgNAovQXNjZW50IDYyNQovQ2FwSGVpZ2h0IDYyNQovRGVz Y2VudCAwCi9JdGFsaWNBbmdsZSAwCi9TdGVtViA5MwovTWlzc2luZ1dpZHRoIDc1MAovRm9udEZp bGUyIDIyIDAgUj4+CmVuZG9iagoyMiAwIG9iago8PC9GaWx0ZXIvRmxhdGVEZWNvZGUKL0xlbmd0 aDEgODA1Ni9MZW5ndGggMzc4NT4+c3RyZWFtCnic7Vl9cBTHlX+vZ3ZmdlfSroTQJ3hmGSSwVouw +BAIGa0+VhFeEAIJ364M8QqhDzAYBWQifDZgOy7IgrF8rstdCI4dC4QTCMxKgFcyBpIjd9gUts9J +ZzYnEkKHMf4AxNj4sPauTezkkBJKuW/rip1dKtfv49f9+t+3T3TswIEgETYAhzULqwrKAQzjQ8Q ubtpTWN7XB7HA2BJ04YOZc4V1xlSvAtgqWlpb11Tf2LNTAAhn+TXWldvbInjU04S/nRbc+OKU5d3 jQeQvaSc2UaKBIdEePtXJE9sW9PROeRPI3z76rVNjXE5dRuA+OCaxs524WnJBpCgkFK5v3FN8xDe 6C+9fe36jrgsm/b2dc3tj2rCLMKTXXjYMgCZZumBLD4XMgD031P5wKhjK/VPDFtsrf479jtqfWSo xNMxOAE7oA96KEfAiTysgI2wnfLP4EMIw/PwFB6G9fAg7CH+JXyZtUMDRTEd2uHfYCpy+htwAB7G RBAgBV6Bs3A3PKU/iWPADplQAeugnzvN/Zf+CVbh/cAgGyphMRzlPoG3kWd3WjIs63UPWMAK/w5n 2XwadzKMhSKYBzWwlMa0j8b6C3gHJ1sq9PfABV6oI88bYSd0w6v4JGtmD7A93GnLEn2XTl6oJwly oQpWEmo9fBt20Tw+RRuOwZ/hRS6D3x27EvtS30MznwTToQx88ADN5hScgV/DRfgTLsEW5mb1XDtv 4Vv1NP0wjXk8FMJdlBfAEgjBQ7CZIvYMRFg3tyN2KnYNkPYUBx4adREU0/wbKFZn4TeYjJmYg5Ow GutwJT6H15nIZrNH2B52jbNwkynP5Lq5I9w57j3uM76a7+TfF+z6ZN2vt+md+rP6Cf23FFMZJsN8 6nMpfBMaaVbfhkfgMdhGq7Wb8jPwLOyFoxCFfhiAX8J78Fu4AtcwCQtxDpZgC67GTjyIR/BFfB3f ZMtYI3ueneVUroF87+GBr+Rr+fX8mzGIzYrtiEVir+lJeq/+H/pH+iBFU6aY51BEPRCAZvL8ODwF 3yeP++EQaJQH4B06I3+gyFkpOzEV03Ei3o4eLMCZWIuLsAFbsQM34qO4E7vw+7gbNeyj0RzHX+Bv 8AO8jFcoMhRmZmcOJrMJLJ952BRWw1rZVtbFDrAj7BjlN9iv2NvsHXaRfca+5JK5VMoTuFyumruL W8qt5Tq5jdwmbj/F8wx3nudp/Rz8ZD6f/w6/lz/Ev85f4r+02C07LU9b/tVy0XJRAMEp3CnUCm3C PwtR4dciJy4SW8RN4mbxUfGoBJIqHYBeOh0RmulNiS2FH8Ev8Tj8N/ZwqWw/1rJ9+D1M4jLgPu4H +J8WP3yXlTANF7A07o+4ATfAWO7H+Dl8DkcZz95GN78Pn4NjdJJ2sPtYJ+/Af+B/zA9iB/8mz7EL 0MM+MfwIqfw+8raBnhdrcC5xrbAGfshS4QzbQ6vwLfg5/FCwsi5a9ychl1XDDJxnrA37FC7R6UjG UlhF52QQuy0d7Ef4IPcBS4C7cZC9h3MsHdAiOOER7GM13Bm8QCfvGO0XP7ax2bgcBuF9fB7fZ0tg AXsMuvlWy6/wHLqxxtJG+w/489w8roWNYS/Bn6dDcJhOwlmYz52GpfhPdPrPMjfMY2vhGe5l/AMc xof4Vq6NRtnJeHyMzsIB6OOqeTuUw2HuMBzHF7i30A2H+E68H5/WfYPL4KrQwx/kIpaZ/Dj91di7 uBff0AfYZ1Ckv8otibXibj6TzuVDdHrXUYTssJ/a76YnRg9IxOXQedxJ+3UsPdusdMqr6Mk1H76J V+jEPEZRmomToYZNgPtYmagIqfQ0ngTgLav3ls69s2RO8exZRTOmTyu8Y2rBFE++O+/2yZNycyaq E1yKfNv4cdlZmRnpaWNTx6QkOx1JiQl2m1USBQutIkK+T60KKVpuSONz1epqjyGrjaRovEkR0hRS VY3GaErIhCmjkV5CtvwZ0htHekeQ6FRKoMSTr/hURTtbqSpRbFgUIP6JSjWoaB+b/AKT53NNIZEE l4taKL6MtkpFw5Di06o2tIV9oUrqL2K3VagVzTZPPkRsdmLtxGnpansE0+eiybB0X3GEgZRIo9Ky 1EqflqlWGkPQuBxf4wqtdlHAV5ntcgU9+RpWNKnLNVDLNYfbhECF6UYTKjTRdKOsNKYD25VI/snw jqgTlofcCSvUFY1LAxrXGDR8JLvJb6WW/uCFjBsidZ5SEdh6szWbC/syViqGGA5vVbTnFgVutroM GgxSH9SW5VSFwlXkeocRxYwCGogxfGMq8Uk1qz5DE1qlaFa1XG0LrwrRgmSFNVi80dWbleXt189D lk8J1wdUl1aarQYbK8dFUiG8eGNfplfJHG3x5EecyfFoRpIcQ0xC4s1M84jN5Ey4wfkXj4QTjRGp 82gbaEqTQiMJqDSRWQZpngXhplkEoxREaqWtoGVYqVkrQmFnsaE32muWHKeqhK8CLbv68UejNY1D GiHHeRUM1tgcIxuM7MO85nZreXnGvhAraCFpjHNNeYYnf0OUzVTbnQpVFD6oDVCzYHEBxdzlMlZ1 e9QLy0nQtiwKxGUFlmf3grfAHdRYyLCcHLaMXWJYtgxbRpqHVNq+h8G43o3VpNyRP4czbYyvrVjD tL9hbo7b/XWqf1FDQPGFQ0Ox9dePkuL2WSO2IU4bUxHgstkQx7I500o7cekI2BACCRqfQ3+CuZNX REWJtqKpQaVKc4aq4zRoc7m+ZqOoftloZVY3mg0NUyt2j5bnjJJHDS8hzNGA+Vzmr28Ih22jbFX0 3AmHq1SlKhwKN0b1LctVxamG+9letjfc7gsNr2hUH9ierVXtCNIk2rCYdiuD8oiK2xZFvLitriHQ 76RL67b6QC9DVhEqD0Ymki3QT3dZr6llI1pDUgwJ/Eg7vZdJpim7n+65W0wrbypMuSmKYOqkYR1C U5TFdU5TR8lDK0+rL86N1UCFdPL6uUG/tI9uNeKoN9dSA8MdI1JKdy0LXUecUEDvFWB5uk7vNBap 31yWzHrgEJUTVD6lwsNUogup3EuFAy/r6X1ymjdK1b1m1VezqHCLUc9fUGjK3up4bUuM19bieD11 moHb0+frNOQ9fYXFcTnvjrg8Madwc5mT3vxIjg3qIFpApZTKZio8Od/TN3Z8vJk11WjW3ZeVXeg4 wboJ0U3tus0hdnttZE5ZKCwU2adlRXiJenvWpJtNeq9JS01aYFLHkPVDw7tJT5j0kEkLTFpq0oUm XWtSE48fU/6I8iXKH+KH3hTIR5DRSa8qGb356JWxny6O9t7p8lNRtHuLpstTlAq5kMo05RtyPtUy lX/Mq5Y9VFx5lXIRUr9gRXrnQHq68RGWLHmjeODF2NbEwa2JYI1iaW/efLnMisUwwBvuZlLZRYXv zVsnH6fWiinSrmT7e+Xrnije3Sv/jxyVsFf+Uo4y9I6R/yRfkK/JL8lX5bvkV/L2y/2E2tUrR+Uo T6jn8qJsv9chb5cX0+AuyJ3yavl+xTStdlHltctN1Kghr0EO0OOPvNQoppdvyNTNUdlHxsq8KOJR 2St/V57mMZsWGk2PynfI6+QpsukuP+7u9vjYJhvVUXkSOZtgevHJSxKtidairnfFrhfErh6xa5PY VSZ2zRG7ZopdM8SuqWJXgdjlFrtyxK7xYqqUIjmlJClBskmSJEi8xOimmxrVz3vdxilJpVshVYLx FQy8yTuZQVn8EDGUGH0IaWM4P/PXlaNfO9kE/uWK9kWdGkUbPVssajlqKX7w15dnaLPc/qioL9aK 3H5NrL0nEEHcGSStxrbR0a0PRDHTUD2ebby7+2lVMx9/Ituo9cefCAYhbUNpRmnK3OTZVZV/hYSG qPtGynCPSv7ajf20yoE+Ub5TJLGOxC5D7DLEjPHa9/x1Ae0n44NaocHo44N+7ek6ZWmgnz6YDvgq +/GnRhUM9HP5eNC32NBz+ZXBoJ+WxsTRtj9o4A4aFeGkt6DUwEGp9JaJ4zGOU00cbbs4Lk0B1cSp acoo3G34UwOXZ1SESz8Pt5m429LP34SLDKi+yoiqDvc1YGIG4n1pJSZElgnikk0IHRXZhMjITEjV DYhnCDJlBDLF9MThDYwcxyQqw5hEw5P7a6Xmcrfbt9LYK7WBiATlQXqzmXWas32uue6JmXP3Zg/A m9wlsNPL3Ua3Q7taDqWlGW5nCRYICZpAKpGKgZ7jytiUPcADvmCiE0idOGTylHnKDBPtXsOUZFwz h0wZm+a4sgfwhSGTk9TJ5OOmcXZ0PEAJMnwrK0f+1g+lB4bqDvBreXV+rZReqhFR9NHNqzJIuqnD OrvdF9VPxpVTSFliKDluBDiis1qHgBSNowvzcaGMRTSEoHs9DYUc3RzBjvVu88PTuMJYKNNTXIS7 IgxfokUTQGRFvWDhozjlMAc20WCOIGRKgsWwM+Cwos96z3EK5hclgyU1zs9LFgyWQCnxzq+I3DHV lexKziFCJx6+UriTX3ktcB0U3vhpSx+k770FfC69A5K8qSnOZCWZTXJ4k2uTWxwbxfPJQjJNwzvP M2e6YE2zMhQEOr1MEEXgLYIgWq2SzcbR8zYhKclhtzOr1ZbkcEhJVgF5hySKHMcEm93ucIDNOl+w NdmjGPNak+ajowmkJnGAPswEZu9DrokNYIy6Tj3ihLU0qQF8nT7ouEgfTevqsguff+wcpDJEaXJO ynGakj57qzPp4VPSqa1O6VRSSbwm7hQxScSITooBLnMv+1aFcQIl/YveiTMcUf2LF7PGTZdsGSbv tY5Nny7aUtKnF8UXJagiTktPS8dpiOqk3EnI4Wuxa6cbCidj4blYOSacXjXBHTvFspn95VWNuG3w 94N/fNvXEnuYFrH47zJfuJVv5Vv5Vr6Vb+W/y2zeosxfggBS6RZlfNNkURGIuecvfsv+/5V4mGBS 3ojPZdT1YWp8CEI8Pggpxr9piBOMa2jZupWNq83PQuwy5K+ZpNHiZbisj1LE14dc4K3yf1R40GPx 8/A3krEu7P3WiHZo4F5HyVUpM76Q3et+fsKoj7zS8y/Xzw22SvvE67RHrMPr+L8XUKnRCmVuZHN0 cmVhbQplbmRvYmoKMTggMCBvYmoKPDwvVHlwZS9Gb250RGVzY3JpcHRvci9Gb250TmFtZS9WTlpR WEwrQXJpYWwvRm9udEJCb3hbMCAtMTk3IDcxNiA3MTVdL0ZsYWdzIDQKL0FzY2VudCA3MTUKL0Nh cEhlaWdodCA3MTUKL0Rlc2NlbnQgLTE5NwovSXRhbGljQW5nbGUgMAovU3RlbVYgMTA3Ci9NaXNz aW5nV2lkdGggNzUwCi9Gb250RmlsZTIgMjMgMCBSPj4KZW5kb2JqCjIzIDAgb2JqCjw8L0ZpbHRl ci9GbGF0ZURlY29kZQovTGVuZ3RoMSAxNjQ4MC9MZW5ndGggODkyMD4+c3RyZWFtCnic7XsJdFRV 1u4+5966NaTm1Jzh3kqlKiGVkJCRQCQ3IYlABAIErALTVIAgcYAgxIFuAREEggNOOLZEW4FGu7mp ICYMbdS2tQcbbIdGu/s3y8Z2aLOk+1f0V6h6+9wKCP3bvV6/99Zb673Fvey7z7C/c87eZ599zgkJ EAAwwXrgoGXmnOJSUJ9Jl+Fn3uJr27tS+Zo/ApB5i69fLX0m3vcbLMC8dsLSriuv1X10MB9A5wHQ /P7Ka25ampLPfhLAJi3raF/y2/f9uwFklIHKZVhgX2tPYocnMZ+77NrVN472h/JkyTUrFren8sU/ RxnXte03dplutXMAZgcWSsvbr+0YlS/Hj7trxarVqbysY/Vd13V01fmXMHmst67QHIRMlXZDJh+C TIDkibOU6EyeYHWM00+w96wUjT5xeAZ+T/KJBP3ka3DDV8RLxsFU4OFLtNQ+OAP3gwNaYQexQy64 YC5MJTzKhOF28kjy+uTHcAncA08knyMbknux/i74BXyFI/gPnkAVzED5udABH3MfQDT5MOhgM6TB RJhNXNAOb+P7BY7hXrgPfkZ+kPwKe3XABmyvBuqgLvlC8jQUwO38ds1x/bNwNxwiQnJxshOyIQd6 aDj5dvI9CEEUfgTP4JjCZIifAn64GjbBg8TL/QJT98OTkCBG2sZN1jyPPU2FebAcboAe2Au/InbS ojmuOZn8fvJDECAd8nFMnfAxqSDT6VO8MTkp+S4sgEF4FfVl7xC/gN+tWZCoTf4w+SI44TliIIfJ C5pSzZ1nbkk+nvwpGHE849AiM7CfRXArvAC/hL/B3+m65DqYAnOw55dJFpFICC3+NvXStXQt9waM RW3bcLTdsBMUnJGDcAiOoG3+AMPwAXGQDDKNLCJ3k79TI11Cj3KPcPu5N3nC/xjtHYAg2mg1PAUH 4DfwGhwlGmy/hLSQq8gK8gD5IRmmCv2Ufsnr+Fv5b/gzmlBiOPFNckbyC/CADy6DNbAObfsj6If9 8Ft4C/4O/wmniJWMJ8vI40Qhw+RTqqc5dCbtojvoU/Qn3Azubu4FvoKv56/mX+Pf1dym2aZt1yZO 70rcm/hJ4vXkc8nX0XfM2H4ImtCit6BXPAXPwxvY+jvwJ3if+Q+2P5HMJ9/DXlaRLeQ+8hPyMnmd fIJagvrm0Im0AXtdQa9DO22g99L7sPej+B6j79I/0b/SLzgNl8NVciu5xzmFG+COcX/hrXyIH8uP 42fy8/kkzkyp5lLNHM0ezdOaFzUnhRphidAlfKTdoN2o+82ZgjP/kYDEsoSS6Eff1aEnrUFLPAZP oN/vxzn4FVr0tzjiYfgcZ8FH/CQPx11NmkgzmU4uJ1eQDrKBbCb3kAfJI+QJ8lPUAHWgWhx7mNbR ObSddtCNdDO9g+7H9yD9JX2bHqcjOHI3F+DC3DhuKjefW8AtRx1Wc2u5jWjZu7m93FHuDe5D7iNu BGfNzWfz3fwa/iF+N7+ff11zmeZafJ/QPK8Z0ryuOa05LVDBJ2QKxcJVwh7hfa2grdS2aLdq39T+ p66LZJICHLkE5z3Ui2swm+6lDn4dGcGCLMKDBTUP4zzMwVXxn1DLJXBezKwex+akXj6dIQWZVxC/ mhyCCvIyrBMoh1GVH4Y4+SMd5l+il8BbJEa8/G5uueZX1A9PYzTaTg/TQ6Qe9tMaOo8+ygH5gOyB D9Dfb4T7yNVkFTxNRsgEcjOpIuvgTeri5pCNUJN8gvJET6aSk4AjgFv4JfA9+JcPqcZo/XHiMd7E /wDj0wDswBl9Bt4jP4aviSb5KUY3DqNRO0aZ29HfNwGLem24ztbhevRiBLlGOAr7iYARv0qYxK+B k/Bf8LHmIHpUPUbSDxOd/GP8n5NVySJcYbjKYA+uu2VwKa6YD9BLjmCe5a7AlW7AWFKKq7oF5sMS uBmj3t1JJflo8tbkTckV8GvEfk0KydekF1fEACJq4FV874J3yDZch5f+az3/2ZNYAkPwCfGQICnF 9TCiuV6zXbNXs1/zM81rwji09kZ4BD36ffRmA2qwGF6HT+BLosO58UIhlON4x+PYI3ANjXJHYDLx QReu2XyM4/WjmqzCVjag9R7F9XwE18ZJjBNXwM/gOKHEjRotxv512E4z2nkhSu/CGbyV9GPJEoza BfBX1NtMxtPV2J+MLe3AqDWEY/oj/AWtnVTHVYhxoYHMw7a+hMthCfZQCS2kD2fgAFRjZG3gfoP2 ziVWqCc55EnExXCFmiELqjV/JhQKEzOS42kndwT3mCSW9+LulQGXkJU4CgvqcQacZCZUJGbjGN7A HbWuVa6ddEnNxAnV46sqystKx5UUjy0qDBeMyc8LBXMDOX5JzM7KzPB5PW6X05Fut1ktZpMxzaDX aQUNz1EChY2BppikhGIKHwpMmVLE8oF2LGg/ryCmSFjUdKGMIsVUMelCSRkll/6DpJySlM9JEqtU AzVFhVJjQFJeawhIA2T+rAim72gIRCVlRE1PV9Pb1bQJ034/AqRGz7IGSSExqVFpun5ZT2OsAZvr SzNMDkzuMBQVQp8hDZNpmFLcga4+4p5E1AR1N07oo6Az4aAUX6ChUfEGGtgIFC7Y2L5EaZkVaWzI 8PujRYUKmbw4sEiBQL1iCasiMFntRhEmK1q1G6mTaQPbpL7CoZ7bB6ywKBY2Lgksab8ionDtUdaH LYz9NijuNSc832axcfvkyObzazO4nkZPp8SyPT2bJWVoVuT8Wj/7RqPYBmJpsCnW04Rd345GbJ4j YW90UzSikE3YpcQ0YVql9OsINLKS2FWSog/UB5b1XBXDqfH1KDD7Jn/c55MHk8Pga5R6WiMBv1Kb EYi2N2T2OaBn9k39XlnyXlhTVNhntaUM22e2jCaMpvMTHefq1JQqzlLNs89ZlrARBaaiQyjSYglH EgmgTuPZp2M89Cwej2L4RAmilCU4I52KfnKsxzqBlTO8oglaA1LPF4AeEBj59MKS9tESIWj9AliS +ck5V8P6s2klHFYKCpiLaCfjnOIYJ6n5iqLC6wdoZaDLKiFD80EL2rY9OqEYze/3swneNiDDIswo 62dFUnkJFmXEQS4ORxUaYzVDZ2ucc1nN+rM15+CxAHryfmCHeqeiC537Z7G60huXTVCI619Ud6Tq m+cEmmfNj0iNPbFR2za3XpBL1Y8/VzeaUtInR7gMOpqiGZxai055xTlhlokYFT6I/wTVqZcoHDql WkCkJsUam5L6Rg1+/z/FDGh154EGkicZSmXfwkZHqUwIX5ifeEH+gtEZezgcLx+iza3ze3oMF9Q1 YQDq6WkKSE09sZ72geT6RQHJGugZpLvp7p6uxtjZCR1IHtyWoTTdHkUllpEJ6KwU6vsCZMusPpls mTM/MmjFm8qW1kicEjo5Vh/ty8W6yCAeRWS1lJ4rZTmJ5aCZoKPHqU6tyhiUAdartbxaoOYXDxBQ y3RnywgsHqCpMqtahk8RsLnXTkrMgMlW+PrrRMiqllzwRFmJ0IP7dw2swBsABSsU484FwoxkEs8K 9GfQyj0MFkJATA5xD/ZbHaXyAPdQvyW9VK6zcvdDCxIFhZsOQ0gUVnB3wzokiuLN8aJxpYMs0W8w l1pRfhtISOuROOjFL1HzMhKT39af7mLN3xq32FTc9+Ml5alEv9VT2lLn4G4EwnVwy/HQL+JhcTlu qSK3GHkW8kXcErzesnHK/RZr6XrsrxbFa/HsNAar6zgXnkhEroHz4W7IxLrj5lQ/3fH8gtI6AzeZ 86giFs6EhwGR03HaeKkoHeKYiWVuS78+jY1vS9zqLD3CbeK0eFkTufUo5RYtRzgDFCMxTVr79abS 7XVGrhXVbEWziDhGAjvVr8wtj2ND2F8jl4kXGJG7msvCy5TINXHZcac4dIi7VxW7h7WC/U2K68oY 6zeZS4fq9NwkrFW4O9Hid6q9be8PjcezVojLhxIkikZdh6l1bDq5Hkz14DT14NT04NT04Ch6cKqB 24o1W1GmmFsDXdwNsB1pJ6Z5bNIZRwsOqonc/NJBzst50BLWQ2g7gqW+fr2ZjcwTt6erYp5+o7m0 9gi3CmYiURz86n63p3TFIa5AVaWw35PBAF1xvRFN507NBQJdbA6OcJlctmqJLNUCSp2IeQIWTgRC f0WPMevQN+hbbH7Z9Uflvx7lr43y36Z4coge68de5AH6O8aH6zLpB9jYQvon2IkpSg/Rl6AEAe/S ATYK+g4dhFrkxzG/BPkg8jLkB+P+V8UBOtCPDMf+SNzkYsrSl+Lh4tGEGBxNuDNGE3ZXaV2Qvkhf gExs4vfIc5G/QIfwyi7S55F7kA/hAfBV5M/SCpiIfP8o/zk9zHyaPkcP4FFUpP1xMxuCEtcyti8u MPbTOKRyLcXiYfpT+jTeYkX6k3jIh6V7+kO5ouUQtkfwsrg6niXa6wz0cRIhn6NQLx5UkYOdPhGv Yo1sjx+WxEG6nW6XPVVyUC6Sd3ElwZKikl2cFJSKpCppl1RnpXeCBo2HC5Zuw28VSBS9B0lG2k63 xvkqpe4M6sT0orAev71qKobfLjWFlyawnqs9qaZq6SaYiUSxjbVI65DWI92CF5TtdA3S95F+gHSz WrIaqRvpBgwfXYjoQkQXIrpURBciuhDRhYguFdGl9t6NxBAxRMQQEUNETEXEEBFDRAwRMRXBxhtD RExFtCCiBREtiGhRES2IaEFECyJaVEQLIloQ0aIiZETIiJARIasIGREyImREyCpCRoSMCFlFlCCi BBEliChRESWIKEFECSJKVEQJIkoQUaIiJERIiJAQIakICRESIiRESCpCQoSECElFWBFhRYQVEVYV YUWEFRFWRFhVhFWdn24khhhGxDAihhExrCKGETGMiGFEDKuIYUQMI2KY3tDHHat7GSHHEHIMIcdU yDGEHEPIMYQcUyHHEHIMIcdGVV+tGoOi26xFWoe0HolhhxA7hNghxA6p2CHVvbqRGFZBhIIIBRGK ilAQoSBCQYSiIhREKIhQVEQvInoR0YuIXhXRi4heRPQioldF9KqO243EEP++U/7bU0NvIREdbq50 PRmj8nXwqcrXwnGV3wx9Kv8B7FL592GDytdAlcpvgJDKsT2VrwZRR+JilaXOhSFgJtJCpBVIO5H2 IT2PpFVTR5HeQ0rSCjmHt2hnandq92mf12r2aYe11CLMFHYK+4TnBc0+YVigUl0GNalxFEML3KV+ 1+H3MyTcRPBbq6ZqaTn2W45xtgLfclou20akzwrI0QLyfAHZV0DuKiB1enop4dVIJ0EVXiBFEpGN oUnicaSqUN4kjEx3HvjULcZDleIAOZxiY+Qw8k+R+pB2IW1AqkIqRSpCCiKJalkBykfknNEmDyPl IfmRJNYFuFx4/LHbdPIgNZFd/S+bQM/6yctH3KF4XgmygXjeTGTPxfMWiXV6cgDy2DGIPIsz9zTy fXHxBFb/JMWeiYuHkO2Ji+XI2uJ5Y5EtiOe9JtaZyFwQeQZtHeVzUG/GZ8fFeSg2Ky6OQRaO54WY dAF2FMTaMSQCJ5AHR1G5qZ4CcXEispy4WM2kdZDHJp4IUKQOT4PEONePA/pskER4IqeJI+K94qcI /ysaFt3jHWmAR3Y0OEDmyQbxcNFjKFwnxusMTB73h75RrjD+rLgruFV8BNsiwQPiQ+JY8c6iAR0W 34Hj3qp2ERc34GXnaTldXC+WiKuLToirxGliuzhbbAtieVy8QjzMhglREqFPHxBbsMGpqEUwLl4a HFCH2CTeJMpinlgtHWb2hfGpdquKDjMLQGmq90K0b0FwgPn43KoBYpMLtCe127ULtPXaidqANkeb rc3SOnR2nVVn1hl1Bp1OJ+h4HdWBzjGQHJbD7BDsENSzsMCzL6+mrZR9KahnZEp0FKaBks410+Y5 9aRZGVoMzYsk5dScwAAx4F1CE6gnir0ZmlvrlfHh5gFtcrZSFW5WtC0LIn2E3BnFUoVuwZN6a2SA JFnRpgx2ae8jsOmOjEEgxLvpjmgUPK7raz219km26qaG7/jERr/hbx/P+cksZUfznIiyNyuqlLJE MivarNzCrvSD1EJNjQ2D1MxYNDLId1FL42xWznc1RFHshCqG3mxGMchjDMV09SAxMYwn9UwM5ygl F0I4yvkZQzmDCUKqXMhgUuV4wuT6jkuNDX2SpMoEAY6rMseDcJ4MegxiG/pCIVUqIJEIkyKRgKQO bIzakCiiSJGoihA816kNiUTtTCn+ViQ4KlJxTqRC7Ysj38qIKRlH/lkZRz7KhP83n476MOkf1732 JfZTkligsQMppmy7fplHWb9IkvrWdo/++CQUW7R4GePtHUp3oKNBWRtokPrGvfQd1S+x6nGBhj54 qbE10veS3NEQHyePawy0N0T7a2sidRf0tfVcX5Ga72ishjUWYX3V1n1HdR2rrmV91bG+6lhftXKt 2ldjJ/P7lkifDuqjeCtXeT9NM6APxzL80XqXtWsSc+jBiX7P2oyDPJA9kBaOKsZAvWJCYlVFdUV1 rArXGasysx+FjVZ51k70Zxwke0arrFhsC9TDWdMCE2pWKmY1K368STNXUeT2756zVexRqz3Q2NmA /zC/WiV8z5eEVd/5rP6up7u7exX7dIdXATQrBXOalcpZOBKtFruKNUSxbOzZMo5Ty/r0+saB5BBW hnEQZDXrjqXCJIwWlA1469LSXqFXS9lVYXW/L6t0xRHcwdch4T2O3hAvVu/L9Ib+nCC7v6zuL65I cbyfMh73+Uuxh/4qhDIeTHHZVoSJ7cHtRdureoO9Rb1VApYe2IWF4i62lcaLd3GwOrzqrCEwuTqK xsZhsf4ej2dmqR33skQ4HA2vIqq9/ruxyVmjnzPsqtFWV6nNrz47IanyVZASTlWGu8+CukchamW3 ClE7xNCLIViDL56mtFC/n5KEoB2gtXI6aPgEBwYtnyDg1QmaBOUOkxDoiUI84AlbT9WcqZlh/bxm +pkaqMW09TR+xpX4bX5bED8Y6OG0xA2dljXwDUj8EPYFO7Cvw5qDeL30w1fyhmrLVMvl2qvSrjLu 1e829wYOmI/rDYJOMLh1LkOlucncZNHqrHqbw+ywOKyV5krLpZZu803WNwxpN+pv9F6ftUW/xXtb lqB3OfRGi3mOudu80Xyf+UdmjVkyGR0mk9FidJrcrmC61UFijl4HdThA8gcpoSaz2Qk6M55B5Dww WU3U9GZGXq+gCEPCMYEXNncFiBQoCdCA3ykRCa+vFAbotv6ccYs9YdS6jaltbVt5qm3k87YR1L/G WsOMYK8ubluJnNjs1dWbx4bbzDdbf05s1YD5cSXQRla2tZXZ/KUul9MhaF0ud7qfG0sDAZutrLSy sqI8lBcKBHbQFX99a/2LL8Ruvqo/8djb17V+b2nNH966qmbmlNz9H2oOzvzVhqd+nzn+tqcT75Pa p6P+M49yM3Ij9dMWGDVsNy0E4AfRxlq4Tg4U60v4Ek2Lvku/Xr9drxWIhgZ5jmpBp3e7ffw6DdEM kCLZIGglUgLsJxgsa+PMLRQvenhN5alXd+aZlM7NsyJ9VB4frZmO+p+pwU9jR8MJVJ5pXoNzT9pw 4iv8Tr+NvJeYzt+RmMG/+NVX30zCZqcmP+LH8pMggAeLlfIyrU+Xqcly+aZlTMmcGvyD9T2bvtLb 5L08tNR7Zei20D3ee327fIMZr/hezTAKgsnpEryuPGGMM+q9gd5GdwnPCr8QjM+Xv2OlWbml42yF plw5PLY8V87Jx483q3xF7ulcmtuUxRZridlSfkkWgSxrlpL1X1l8VlYhKQMZSy14zqEw1y9n2mr9 coYVPx5fuR8X/rO81mgyFLI1j3Uqx2qVo0QhSsiyIy17XEg3Rp9viorGnUYqGknSSIyy2VVu9M0s J+UxnI07SwghZWP8C93kPTeZ6V7oXuHm3N6yzrqUTVdeN33k85UjbTOsbafCqdwJtqBGcHWiYc8g +7wtfEL1q3CfQCe3RuLFWWRldCSVGYTc5NBzGVnlrblLcmlbONqGCHQ2zmxNTcnKNmhbSfIqK8uY 03EOl9uPTpYnCIGcUEV5ZWVVZRW6XSBHIIKgFZwOV1kpFlVWkI5k+HdHDw80cxnBxCdpVi035cm2 J4/Me+Sely9rWdHcSr5X+UluVaThssYyaxp9f+zD90W3PpcYuH3TZZlVXl1TU3zL/DuaM4NS5qzG iYnf2Us9eTUT55WGqnI70OSt6A3t6KMWyITtcpE9KkQNUfs81zxPNPNB7UP6r/T6ruz12XQCV26c 4Cz3TuMajNOcDd6H9HoHC8uaNB+bAnOa1mxBIxvcY8ymEGE3FosFfHdlk2yrX+fNitSoRp4+MsO6 8lTN9JEzNX9RvbV2pHZkdDVOjsimTqHT0Glf6lrq6cwU2qJ+fwWzDtis9rJSN0YyhxuNUpmyEt+e +Kaub/5ziW8SL8Y3EO8Ze3HDmvYtG69csvnRBVGSR3TETLz3Uevprr2XLX/qyece34n61qG+eej9 DsgkPxoEa/IruSmt+iH9w6Yd1j2a3YZD+kOmAZ9O5yBT6KVCk2Fm9h7TAeGA7xXDq8a3DceNX2m/ NJkyLZlOGWfaKZtt5Rbn886jTs7JPNKSXatysxs5vUPGUGhvMcfM1OyxE7YxeTPKSZkdmEyWVK7y nDEpHi5KcU+mymULLotedia34rAX2u1sM+TT7B5m7tw0LfhJsdM/00zMvuLshdkrsndm89kWv042 WcrR4KNeHWYWbzvVhs6MsXGEbcYOj5zvqPXI2Rb84FLysDXHtqBo7Rm2K4IdB4ESdjYYFLKPLjnG 42dFcbmo+5gKAKywV7NBx92MKf16wyQ1W+evVbfS6Am2EtrU7s0yWsnMOjWz7s0yGkvdK6PFNbjI rguHMWaXsRC2EtrCRIMeIOWFKqxQVgqc38UcID2EDqAV3PRr4qn8eF/ir5s6ieONEWIXzsjchvb6 +XncjfOuqKkhZHbxw48/e/ef0BfCiVcSR27eNoVcs2bd5Mmr2B54LwbpZ9D32X57wyDo0ei1NkOt rG/R0/V6RT+kP6b/TK8R9TH9On0vFmg4QYubMYeeLsMxGEZkG27bgkbQ8gaqDRGeTZzen1vOe3W1 KZcPj27LamzGHYnTWNkWlQoI14XTcZMmSPcSb+JD4uUPED5x+ptpfOibd3Hu78YdJIre6oKdskeb 7k6fr1um4/EyUa4rtzboGiwfWzUCc4gsm9ZsEoxpabgEKQm5QJZyy/cBSWIjPg8blSsnt3y7p9dD uzwnPfQzD/EY0kJG3HbHxHF3Vh0OIb1GchIjp9c9OvqV1+H4rSNWdsDAmBg+pRaoCqn77LnV6/fb ytmsCIITtfE7MchlUycfTXyYO6t66uowKqfZ9kbbwzNFmv1Mx/iWjfGEyIce3T952cbvs7mYjevy YdTUBF54QJ7yEflQ92X6l07+FfqRhtq9Gq+eRq3z0ue5op4H6IPCg7oHjAP6t+gfNH/Uv2X8UPOh 8JHJulv3a/ob4SXdL4yabt1WYaOOs7EQZUhzMxM5eK2jWuuLZXRl0AyzH7y+SN15QWk6Wx+qOivb 0PUwGuk7rUsxFnV6eNIWRSXb0svtqBY4HRDIyQ0FHd/Gotk9Zx79GylP/PLTexJf9hBpx/Ll99+/ fPkOmnM7EXoSr3z2t8RLG5N7Htuzp/fRPXuYvgsS1/CLUF8bZMEP5Sp7DS03lTtqMqfRBlODY1qm rkskWTqnuzyqiRouN81Lj7qjvnlZuwy7Mr/SnzJ96TDawJzB1OPTnEy99DStxSp4MNhm28cQAiGb zcLCsP4uK7H6xFQAPrVy+kgNTqb1hKo3pAJwrXpgCONyI2oQ1nQalqZ3uju9S7MwCBMbi8F5IRtb gS53BfqrqrO6QVVyU6ueXPhsdw/hhq56pIZwiZOblizdurG9/Z7ENdR16ZwtO4mVABHnL/jh103c /h/tfELZ98hP2eloMx50q9ACVtgj5z+gIXozmaNZqunWcMX2iHmZucvOG/QWo2ikdxmTRlprnGmk xgF6gzxGq0Uv56hgyAe9VV+CRype71tn32mnC+3r7Pvsx+y83QohwjH90yhdT3oJJV5b7SDJhJRb n+fUp9q800+AJ7UboY9XlzJr4FaN9xz3HHYTw3uOoXQ8uoBf9Wz0AbdWdXUb6WV+Pfnqhlj08ksv mTi7mA89cHVDxRdj6/Ym/oY6lqBXW1HHAvqiPCTYhIAuz21zBx60P+h4IO/+Ar3W0eSg9kOmQfMr /g8CX5lO5QhjTHNNHab70x6w784ZNGrrAnJuQ+jKnCWhzfbNjttybs3VV4Uahaa0aaaZliZ/fY42 JzcvVGWs8FfkVAQqcrWCQWPT+z2mPGNOTk5Am5sjF64y3ui4yXn9mO6CLc6NBQ877y/Yn7M/YFpP 7nLf7nmo4McFSqHg9rtkf6DcJWeK5aKLvOcirjKdvyV4V5AGZU9WedDHjlyyG+NjSyEpKSTFhaQw 21+CzlVG/OrGZdHXqhxF1A1MrzeVgzd84wAz+WkM8Or5ajSOhFeyHAb7EUgdn+QKgRCBuEgop9Lf 5G8lUfcS0uk+RQzETXmfP4fmp5uMNN+3kCd8U35ai4/4mtK1tWfa8J/N7q4+S20rMwYhJ/lrvDni ATLFcwaSw/3ZuSw/3C/mpvJen5qXMzBxtYlU5jTlPGi6L+fnOW/mCP4co4nnfUyPZ3HPhjK2e/e7 i2rJ6Pam5nOC5YzLWT7cs0kJkUkL4WNkPTlJOEC/byExwquS6S6UJESeDjxZyJ/kKVPBJWPTrjK3 jO26ZWzULVdUlbvZ+dktB8fgB9u1uEX1qMq75/pkjOEWH2nxJX10VPmV7FCqPifCLPs5O7qmsilj pCqjqfPnSnza2tRNOzf5S1mfZq+15OMH7fDpAVO10WGsZsm4sRot9ElfWjWM3nyjGBXTgy71SFpR jqdWdDo8s7KAoEltxk48m/Hst6TYcbaE+OzLF19bFXQ4pyaeWbD23Q/efTM/8aVtYWRFiZQZIi9E I59/9s4ZUhyePTc/s1hyOmzNk+Y91HP4zm3jJtWLrkC2M3PptObb7vmdAuw/4D+id2t+iDvDa/IY CSQSMIyxTDBPM0ctWq8TPJzLCW57uoO47dRBPJxea9AaPczcFnD3uhU3F0M2hKf9AcLHnYQdXPvB yW7XeHI1pumLDcUAxWQhRgmUkPM9XMhtn+usdex07HNwMcd6x3bHMcdJhwYcVofkKHHwDq/vxt6z 94ZmpQrjxESME4PgSA6xa9np1K3M+rmXhZYR9VaOoifwFGQrs+DDYgxxBmwO1aZuZjS8DFTYAhVl FUEbXTOUlpeZN82z6AeXralO099yC/HxoeFE64ZwZsa7BWWzGsfdT44Ov/FkYiva5w6MMnP4EJ4S HpXdl9uutO3QcHrBK9TQGlszbbZ9SLUWpqqNT3OBwelwGPRCuiPkdAILkGaXelZwkSSu+X9xVtDr zh0SdOSkjuguPCScf0JIbTL/cEZoSx3mQ6ikP6U2XrMxyc2YcKTz6r2XEa84u3bKdQXEu3Puou/t 3UF7E57hjokzu0+QITwM4VP5f+39CD4iZf/spRPUN84NpF5ef+5dy5/iT2lu0HysvV2Xqdt+8b34 Xnwvvhffi+/F9+J78b34Xnwvvv/n3tQf9Y3+drsDOPVv4XxIAiYqprRGLpt7KVfVMGve5bP/1/6w 7P/lh4ca9csz+5w0J5P4JezLfvcJvxUwBVohApfBXLgUbVcFDTAL5sHlkDIWAbv656gAAvtv+brr OtuvUX9Limxn+f/JR3dh9iScTF5QMPqXCQL7taxRotXw/wVpXoEdjPg/Q+G/Tatg6jn6M7Qirzuf sP17/5FQ7m6k2aO0gMuCzShbQveCiPk7UuvjXzxsLuhfruxT9h1caKn5QudNTd4Tf65R/2p+8K1n 07/++vQZK+icKKs/O3f/AxvvbWoKZW5kc3RyZWFtCmVuZG9iagoyIDAgb2JqCjw8L1Byb2R1Y2Vy KEFGUEwgR2hvc3RzY3JpcHQgOC41NCkKL0NyZWF0aW9uRGF0ZShEOjIwMDgwMzEyMjMwOTI5KQov TW9kRGF0ZShEOjIwMDgwMzEyMjMwOTI5KQovVGl0bGUoTWljcm9zb2Z0IFBvd2VyUG9pbnQgLSBZ Q1BFQVRULnBwdCkKL0NyZWF0b3IoUHJpbW9QREYgaHR0cDovL3d3dy5wcmltb3BkZi5jb20pCi9B dXRob3IodG1vbmNhc3Rlcik+PmVuZG9iagp4cmVmCjAgMjcKMDAwMDAwMDAwMCA2NTUzNSBmIAow MDAwMDAyNzc3IDAwMDAwIG4gCjAwMDAwMzM4OTYgMDAwMDAgbiAKMDAwMDAwMjcwMSAwMDAwMCBu IAowMDAwMDAyMzc3IDAwMDAwIG4gCjAwMDAwMDAwMTUgMDAwMDAgbiAKMDAwMDAwMTA3NiAwMDAw MCBuIAowMDAwMDAyODI1IDAwMDAwIG4gCjAwMDAwMDMwMDggMDAwMDAgbiAKMDAwMDAwNDE0MSAw MDAwMCBuIAowMDAwMDAzNjAyIDAwMDAwIG4gCjAwMDAwMjA2MzIgMDAwMDAgbiAKMDAwMDAwMjg2 NiAwMDAwMCBuIAowMDAwMDAyODk2IDAwMDAwIG4gCjAwMDAwMDI1MzggMDAwMDAgbiAKMDAwMDAw MTA5NSAwMDAwMCBuIAowMDAwMDAyMzU2IDAwMDAwIG4gCjAwMDAwMDM4MzAgMDAwMDAgbiAKMDAw MDAyNDY5MyAwMDAwMCBuIAowMDAwMDAyOTM3IDAwMDAwIG4gCjAwMDAwMDI5NjcgMDAwMDAgbiAK MDAwMDAwNDM0MCAwMDAwMCBuIAowMDAwMDIwODI1IDAwMDAwIG4gCjAwMDAwMjQ4OTIgMDAwMDAg biAKMDAwMDAwMzMzMyAwMDAwMCBuIAowMDAwMDAzNzQ4IDAwMDAwIG4gCjAwMDAwMDQwMjkgMDAw MDAgbiAKdHJhaWxlcgo8PCAvU2l6ZSAyNyAvUm9vdCAxIDAgUiAvSW5mbyAyIDAgUgovSUQgWzw3 QTBFQTEzQzQ4MUIwRjc4QzU4RkUzRTI4MzlCNzU0NT48N0EwRUExM0M0ODFCMEY3OEM1OEZFM0Uy ODM5Qjc1NDU+XQo+PgpzdGFydHhyZWYKMzQxMTIKJSVFT0YK ------_=_NextPart_001_01C88496.6B6255E4 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn ------_=_NextPart_001_01C88496.6B6255E4-- From pcn-bounces@ietf.org Wed Mar 12 16:33:28 2008 Return-Path: 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 A22193A6C01; Wed, 12 Mar 2008 16:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.638 X-Spam-Level: X-Spam-Status: No, score=-100.638 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 8buPu56hE26W; Wed, 12 Mar 2008 16:33:27 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC0003A6AAC; Wed, 12 Mar 2008 16:33:27 -0700 (PDT) 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 A295A3A6AAC for ; Wed, 12 Mar 2008 16:33:26 -0700 (PDT) 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 axoICkDlEdrc for ; Wed, 12 Mar 2008 16:33:25 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 609473A6894 for ; Wed, 12 Mar 2008 16:33:25 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 4F8FAA068E; Thu, 13 Mar 2008 00:31:06 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 442DDA068A; Thu, 13 Mar 2008 00:31:06 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 11E56A0680; Thu, 13 Mar 2008 00:31:04 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m2CNV4V17683; Thu, 13 Mar 2008 00:31:04 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 3B713C87B6; Thu, 13 Mar 2008 00:31:04 +0100 (CET) Message-ID: <47D8677E.6090907@informatik.uni-wuerzburg.de> Date: Thu, 13 Mar 2008 00:30:06 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: toby.moncaster@bt.com References: In-Reply-To: X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Possible clever encoding for PCN X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Toby, hi Bob, yes, that's good. Side effects: 1) It disables ECN for EF-ADMIT if DSCPx is not available in the initial deployment model, but this holds for any encoding we considered so far unless we consumed at least 2 DSCPs. 2) When ECN is supported in the 3-codepoint model, endpoint of EM marked flows get 11 (CE) signals from PCN. This is not too bad as packets get marked in the 3-codepoint model only under heave overload. It's not problematic for most realtime flows that are not responsive to ECN anyway. Regards, Michael toby.moncaster@bt.com wrote: > Hi All, > > Bob and I just spent a fun 30 minutes trying to work out how to carry > end-to-end ECN across PCN whilst still retaining all the PCN codepoints > we need. We think we have succeeded... > > The attached 2 slides try to set this encoding out as clearly as > possible. Note the new terminology being used! Also note that this is > making the assumption that we will be re-using Fred Baker's DSCP and > hence need to identify PCN traffic from not PCN traffic. > > Toby > ____________________________________________________________________ > Toby Moncaster, Networks Research Centre, BT > B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 > > > > (in case anyone is wondering at the title it stands for: you can please > everyone all the time...) > ------------------------------------------------------------------------ > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn -- 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 From pcn-bounces@ietf.org Wed Mar 12 21:49:24 2008 Return-Path: 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 0ED4D3A6901; Wed, 12 Mar 2008 21:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.062 X-Spam-Level: X-Spam-Status: No, score=-100.062 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 D1JK16QUuJ7B; Wed, 12 Mar 2008 21:49:23 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C1CD3A6AC1; Wed, 12 Mar 2008 21:49:23 -0700 (PDT) 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 C27EB3A6AC1 for ; Wed, 12 Mar 2008 21:49:21 -0700 (PDT) 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 yqrdL+fzP4jJ for ; Wed, 12 Mar 2008 21:49:15 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 5D6F93A6901 for ; Wed, 12 Mar 2008 21:49:15 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Mar 2008 04:46:55 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Mar 2008 04:46:55 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1205383614512; Thu, 13 Mar 2008 04:46:54 +0000 Received: from mut.jungle.bt.co.uk ([10.73.128.36]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m2D4kgpB032592; Thu, 13 Mar 2008 04:46:53 GMT Message-Id: <200803130446.m2D4kgpB032592@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 13 Mar 2008 04:46:43 +0000 To: menth@informatik.uni-wuerzburg.de From: Bob Briscoe In-Reply-To: <47D8677E.6090907@informatik.uni-wuerzburg.de> References: <47D8677E.6090907@informatik.uni-wuerzburg.de> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 13 Mar 2008 04:46:55.0687 (UTC) FILETIME=[438E1D70:01C884C5] Cc: pcn@ietf.org Subject: Re: [PCN] Possible clever encoding for PCN X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Michael, [Terminology reminder at end.] 1) is true. 2) is a deliberate feature You will also notice (Toby omitted to mention) that, not only does endpoint get EM marks as CE, but it gets ThM as CE too. We've made the egress rules so that all PCN marking is deliberately leaked out into the next non-PCN region. If there's more than one PCN region on the path, at each new PCN ingress, the previously leaked out CE are set aside in the NM(CE) codepoint, while more PCN markings are collected across the next region. Then, at the next egress, any CE set aside at the ingress or any PCN marks collected across the next PCN region are again deliberately leaked out as CE. And so on. The upshot is that the endpoint sees all ECN markings and all PCN markings. This might seem strange, because each PCN region already responds to markings generated within each PCN region. But the idea is that, if the endpoints are adaptive, they /may/ be able to drop down a codec level when they see any CE marking (whether from PCN ThM, PCN EM or ECN). Then the PCN markings should go away. If the codecs don't or can't adapt, the PCN mechanisms will still be there. To be absolutely clear, this is brainstorm stuff. We have no idea whether the three congestion control mecahnisms (adaptive codecs, PCN admission control and flow termination at overload) can reliably work together without fighting or thrashing etc. This is just wire protocol possibilities, not system design. Terminology reminder: NM = Not Marked ThM = Threshold Marked EM = Excess-rate Marked Bob At 23:30 12/03/2008, Michael Menth wrote: >Hi Toby, hi Bob, > >yes, that's good. > >Side effects: >1) It disables ECN for EF-ADMIT if DSCPx is not available in the initial >deployment model, but this holds for any encoding we considered so far >unless we consumed at least 2 DSCPs. >2) When ECN is supported in the 3-codepoint model, endpoint of EM marked >flows get 11 (CE) signals from PCN. This is not too bad as packets get >marked in the 3-codepoint model only under heave overload. It's not >problematic for most realtime flows that are not responsive to ECN anyway. > >Regards, > > Michael > >toby.moncaster@bt.com wrote: > > Hi All, > > > > Bob and I just spent a fun 30 minutes trying to work out how to carry > > end-to-end ECN across PCN whilst still retaining all the PCN codepoints > > we need. We think we have succeeded... > > > > The attached 2 slides try to set this encoding out as clearly as > > possible. Note the new terminology being used! Also note that this is > > making the assumption that we will be re-using Fred Baker's DSCP and > > hence need to identify PCN traffic from not PCN traffic. > > > > Toby > > ____________________________________________________________________ > > Toby Moncaster, Networks Research Centre, BT > > B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 > > > > > > > > (in case anyone is wondering at the title it stands for: you can please > > everyone all the time...) > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > >-- >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 ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Mar 13 01:49:08 2008 Return-Path: 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 DD8833A6B13; Thu, 13 Mar 2008 01:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.254 X-Spam-Level: X-Spam-Status: No, score=-100.254 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 E+SOlRh3BCIA; Thu, 13 Mar 2008 01:49:07 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D391C3A687C; Thu, 13 Mar 2008 01:49:07 -0700 (PDT) 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 E8B5A3A6829 for ; Thu, 13 Mar 2008 01:49:06 -0700 (PDT) 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 tPXmNLNl-Blk for ; Thu, 13 Mar 2008 01:49:05 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 2A52A3A69E4 for ; Thu, 13 Mar 2008 01:49:04 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Thu, 13 Mar 2008 09:46:10 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Mar 2008 09:46:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 13 Mar 2008 09:47:26 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CEF5D45@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <200803130446.m2D4kgpB032592@bagheera.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Possible clever encoding for PCN Thread-Index: AciExUvQ2LYRtF/DQQGDTwjIZ7GI+wAGKpQg References: <47D8677E.6090907@informatik.uni-wuerzburg.de> <200803130446.m2D4kgpB032592@bagheera.jungle.bt.co.uk> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 13 Mar 2008 08:46:09.0797 (UTC) FILETIME=[AF457B50:01C884E6] Cc: pcn@ietf.org Subject: Re: [PCN] Possible clever encoding for PCN X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Bob, the proposed codepoint scheme is clearly a progress and I like the idea of allowing end to end CE communication for PCN traffic. A few questions for my understanding: Please clarify, whether packets use a single DSCP between domains or different ones. I can't read that from the table. If two DSCPs are assumed, it is intentional to remark ECT-EM packets to PCN-CE (i.e. change the DSCP at domain boundaries, see ingress transition definition)? 'Not-ECT' means 'PCN_and_Not-ECT' (in contrast to 'Not-PCN' and 'Not-PCN_and_ECT'). There's no such thing as 'PCN_and_ECT'? The ThM marked packets travel end to end as CE (which means the new design tries to reduce bandwidth instead of stopping admission). As an MPLS friend, one comment is whether it may be favourable to use DSCPx 01 and 10 to codepoints to identify NM(Not-ECT) and NM(CE). If RFC 5129 is supported, an ECT 10 or 01 field is allowed to be changed to 11, but not the 00 codepoint (RFC 5129 demands a drop). Communication of the end-system support of CE indications is a matter of end systems. SIP provides the required mechanisms, I'm not absolutely sure about RTSP. Regards, Rudiger | -----Original Message----- | From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On | Behalf Of Bob Briscoe | Sent: Thursday, March 13, 2008 5:47 AM | To: menth@informatik.uni-wuerzburg.de | Cc: pcn@ietf.org | Subject: Re: [PCN] Possible clever encoding for PCN | | Michael, | | [Terminology reminder at end.] | | 1) is true. | 2) is a deliberate feature | | You will also notice (Toby omitted to mention) that, not only | does endpoint get EM marks as CE, but it gets ThM as CE too. | We've made the egress rules so that all PCN marking is | deliberately leaked out into the next non-PCN region. If | there's more than one PCN region on the path, at each new PCN | ingress, the previously leaked out CE are set aside in the | NM(CE) codepoint, while more PCN markings are collected | across the next region. Then, at the next egress, any CE set | aside at the ingress or any PCN marks collected across the | next PCN region are again deliberately leaked out as CE. And so on. | | The upshot is that the endpoint sees all ECN markings and all | PCN markings. This might seem strange, because each PCN | region already responds to markings generated within each PCN | region. But the idea is that, if the endpoints are adaptive, | they /may/ be able to drop down a codec level when they see | any CE marking (whether from PCN ThM, PCN EM or ECN). Then | the PCN markings should go away. If the codecs don't or can't | adapt, the PCN mechanisms will still be there. | | To be absolutely clear, this is brainstorm stuff. We have no | idea whether the three congestion control mecahnisms | (adaptive codecs, PCN admission control and flow termination | at overload) can reliably work together without fighting or | thrashing etc. This is just wire protocol possibilities, not | system design. | | Terminology reminder: | NM = Not Marked | ThM = Threshold Marked | EM = Excess-rate Marked | | Bob | | At 23:30 12/03/2008, Michael Menth wrote: | >Hi Toby, hi Bob, | > | >yes, that's good. | > | >Side effects: | >1) It disables ECN for EF-ADMIT if DSCPx is not available in the | >initial deployment model, but this holds for any encoding we | considered | >so far unless we consumed at least 2 DSCPs. | >2) When ECN is supported in the 3-codepoint model, endpoint of EM | >marked flows get 11 (CE) signals from PCN. This is not too bad as | >packets get marked in the 3-codepoint model only under heave | overload. | >It's not problematic for most realtime flows that are not | responsive to ECN anyway. | > | >Regards, | > | > Michael | > | >toby.moncaster@bt.com wrote: | > > Hi All, | > > | > > Bob and I just spent a fun 30 minutes trying to work out how to | > > carry end-to-end ECN across PCN whilst still retaining | all the PCN | > > codepoints we need. We think we have succeeded... | > > | > > The attached 2 slides try to set this encoding out as clearly as | > > possible. Note the new terminology being used! Also note | that this | > > is making the assumption that we will be re-using Fred | Baker's DSCP | > > and hence need to identify PCN traffic from not PCN traffic. | > > | > > Toby | > > | ____________________________________________________________________ | > > Toby Moncaster, Networks Research | Centre, BT | > > B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 | > > | > > | > > | > > (in case anyone is wondering at the title it stands for: you can | > > please everyone all the time...) | > > | -------------------------------------------------------------------- | > > ---- | > > | > > _______________________________________________ | > > PCN mailing list | > > PCN@ietf.org | > > https://www.ietf.org/mailman/listinfo/pcn | > | >-- | >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 | | ______________________________________________________________ | ______________ | Bob Briscoe, Networks Research | Centre, BT Research | B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. | +44 1473 645196 | | | _______________________________________________ | 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 From pcn-bounces@ietf.org Thu Mar 13 06:54:38 2008 Return-Path: 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 9991C28C84A; Thu, 13 Mar 2008 06:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.243 X-Spam-Level: X-Spam-Status: No, score=-100.243 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 5batQGLfTWFE; Thu, 13 Mar 2008 06:54:37 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DE8828C819; Thu, 13 Mar 2008 06:54:37 -0700 (PDT) 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 763F83A6E70 for ; Thu, 13 Mar 2008 06:54:35 -0700 (PDT) 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 Ci5uG7urhgme for ; Thu, 13 Mar 2008 06:54:33 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 662903A6E67 for ; Thu, 13 Mar 2008 06:54:33 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 1BE1A22185; Thu, 13 Mar 2008 14:48:40 +0100 (CET) X-AuditID: c1b4fb3e-af19abb000004ec0-ac-47d930b79ea7 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.254.121]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E7EA620150; Thu, 13 Mar 2008 14:48:39 +0100 (CET) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Mar 2008 14:48:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 13 Mar 2008 14:48:38 +0100 Message-ID: <026F8EEDAD2C4342A993203088C1FC050260E238@esealmw109.eemea.ericsson.se> In-Reply-To: <200803130446.m2D4kgpB032592@bagheera.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Possible clever encoding for PCN thread-index: AciExUuNHGUuCgOkTiGSDuc04gYAUQASCvvw References: <47D8677E.6090907@informatik.uni-wuerzburg.de> <200803130446.m2D4kgpB032592@bagheera.jungle.bt.co.uk> From: "Ingemar Johansson S" To: "Bob Briscoe" , X-OriginalArrivalTime: 13 Mar 2008 13:48:39.0718 (UTC) FILETIME=[F177A460:01C88510] X-Brightmail-Tracker: AAAAAA== Cc: pcn@ietf.org Subject: Re: [PCN] Possible clever encoding for PCN X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi As a general 1st comment I am (slightly) positive to this approach. There is a certain risk that codecs over-react as ThM will be seen as ECN-CE by the endpoints but here I lack the knowledge in how common ThM will actually be compared to the experienced congestion experienced in e.g wireless nodes outside the PCN domain. One scenario: Video with two possible bitrate (200kbps and 50kbps), initially the codec rate is 200kbps. As more flows are admitted endpoints will eventually see the ThM (masked as ECN-CE). Some (or many or all?) of the endpoints will then adapt the codec rate to the lower codec rate (50kbps, after a while as the rate change effects, the ThM will go away and more flows will get admitted (with initial codec rate 200kbps) with the result that endpoints will again after while see ThM.... with the result that more endpoints adapt the rate to the lower rate. This can be both good and bad I guess, good in the sense that it is maybe codec rate adaptivity at its best, bad in the sense that in the end quality is generally sacrificed for capacity and the endpoints that don't do rate adaptation at all are the winners. In a scenario with "trusted" enpoints that follow a secified adaptation behavior this may however work. /Ingemar > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Bob Briscoe > Sent: den 13 mars 2008 00:47 > To: menth@informatik.uni-wuerzburg.de > Cc: pcn@ietf.org > Subject: Re: [PCN] Possible clever encoding for PCN > > Michael, > > [Terminology reminder at end.] > > 1) is true. > 2) is a deliberate feature > > You will also notice (Toby omitted to mention) that, not only > does endpoint get EM marks as CE, but it gets ThM as CE too. > We've made the egress rules so that all PCN marking is > deliberately leaked out into the next non-PCN region. If > there's more than one PCN region on the path, at each new PCN > ingress, the previously leaked out CE are set aside in the > NM(CE) codepoint, while more PCN markings are collected > across the next region. Then, at the next egress, any CE set > aside at the ingress or any PCN marks collected across the > next PCN region are again deliberately leaked out as CE. And so on. > > The upshot is that the endpoint sees all ECN markings and all > PCN markings. This might seem strange, because each PCN > region already responds to markings generated within each PCN > region. But the idea is that, if the endpoints are adaptive, > they /may/ be able to drop down a codec level when they see > any CE marking (whether from PCN ThM, PCN EM or ECN). Then > the PCN markings should go away. If the codecs don't or can't > adapt, the PCN mechanisms will still be there. > > To be absolutely clear, this is brainstorm stuff. We have no > idea whether the three congestion control mecahnisms > (adaptive codecs, PCN admission control and flow termination > at overload) can reliably work together without fighting or > thrashing etc. This is just wire protocol possibilities, not > system design. > > Terminology reminder: > NM = Not Marked > ThM = Threshold Marked > EM = Excess-rate Marked > > Bob > > At 23:30 12/03/2008, Michael Menth wrote: > >Hi Toby, hi Bob, > > > >yes, that's good. > > > >Side effects: > >1) It disables ECN for EF-ADMIT if DSCPx is not available in the > >initial deployment model, but this holds for any encoding we > considered > >so far unless we consumed at least 2 DSCPs. > >2) When ECN is supported in the 3-codepoint model, endpoint of EM > >marked flows get 11 (CE) signals from PCN. This is not too bad as > >packets get marked in the 3-codepoint model only under heave > overload. > >It's not problematic for most realtime flows that are not > responsive to ECN anyway. > > > >Regards, > > > > Michael > > > >toby.moncaster@bt.com wrote: > > > Hi All, > > > > > > Bob and I just spent a fun 30 minutes trying to work out how to > > > carry end-to-end ECN across PCN whilst still retaining > all the PCN > > > codepoints we need. We think we have succeeded... > > > > > > The attached 2 slides try to set this encoding out as clearly as > > > possible. Note the new terminology being used! Also note > that this > > > is making the assumption that we will be re-using Fred > Baker's DSCP > > > and hence need to identify PCN traffic from not PCN traffic. > > > > > > Toby > > > > ____________________________________________________________________ > > > Toby Moncaster, Networks Research > Centre, BT > > > B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 > > > > > > > > > > > > (in case anyone is wondering at the title it stands for: you can > > > please everyone all the time...) > > > > -------------------------------------------------------------------- > > > ---- > > > > > > _______________________________________________ > > > PCN mailing list > > > PCN@ietf.org > > > https://www.ietf.org/mailman/listinfo/pcn > > > >-- > >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 > > ______________________________________________________________ > ______________ > Bob Briscoe, Networks Research > Centre, BT Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. > +44 1473 645196 > > > _______________________________________________ > 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 From pcn-bounces@ietf.org Thu Mar 13 08:11:00 2008 Return-Path: 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 3F4AD28C1A0; Thu, 13 Mar 2008 08:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.087 X-Spam-Level: X-Spam-Status: No, score=-100.087 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 yzWBH+0oM6kU; Thu, 13 Mar 2008 08:10:56 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D7F53A67DF; Thu, 13 Mar 2008 08:10:56 -0700 (PDT) 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 221223A6AD5 for ; Thu, 13 Mar 2008 08:10:55 -0700 (PDT) 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 UFGNbrR97oCv for ; Thu, 13 Mar 2008 08:10:49 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 9602C3A67DF for ; Thu, 13 Mar 2008 08:10:48 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Mar 2008 15:08:29 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Mar 2008 15:08:29 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1205420908695; Thu, 13 Mar 2008 15:08:28 +0000 Received: from mut.jungle.bt.co.uk ([10.73.21.116]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m2DF8DAY009422 for ; Thu, 13 Mar 2008 15:08:26 GMT Message-Id: <200803131508.m2DF8DAY009422@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 13 Mar 2008 15:08:08 +0000 To: "PCN IETF list" From: Bob Briscoe Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 13 Mar 2008 15:08:29.0664 (UTC) FILETIME=[187F6600:01C8851C] Subject: [PCN] IETF-71 PCN mtg notes X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi, If anyone was taking their own notes in the second PCN mtg, could they send them to me to help me get a better record for the minutes? Cheers bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Mar 13 13:33:29 2008 Return-Path: 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 266003A6E55; Thu, 13 Mar 2008 13:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.969 X-Spam-Level: X-Spam-Status: No, score=-99.969 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_17=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 BAX2I9tIhis2; Thu, 13 Mar 2008 13:33:28 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 180463A6C29; Thu, 13 Mar 2008 13:33:27 -0700 (PDT) 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 5BABA3A6B85 for ; Thu, 13 Mar 2008 13:33:26 -0700 (PDT) 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 DiJUWFWXJKxj for ; Thu, 13 Mar 2008 13:33:25 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id EBD2C3A6C53 for ; Thu, 13 Mar 2008 13:33:22 -0700 (PDT) Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m2DKQcc13636; Thu, 13 Mar 2008 20:26:38 GMT Received: from KCHAN-2K3.nortel.com ([47.16.102.61] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Mar 2008 16:30:53 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 13 Mar 2008 16:30:51 -0400 To: "Ingemar Johansson S" From: "Kwok-Ho Chan" In-Reply-To: <026F8EEDAD2C4342A993203088C1FC050260E235@esealmw109.eemea. ericsson.se> References: <026F8EEDAD2C4342A993203088C1FC050260E234@esealmw109.eemea.ericsson.se> <026F8EEDAD2C4342A993203088C1FC050260E235@esealmw109.eemea.ericsson.se> Mime-Version: 1.0 Message-ID: X-OriginalArrivalTime: 13 Mar 2008 20:30:53.0082 (UTC) FILETIME=[2212BFA0:01C88549] Cc: pcn@ietf.org Subject: Re: [PCN] Usage of '01' and '10' code points X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ingemar: I think we are in agreement. Please see inline below. Thanks! -- Kwok -- At 05:18 PM 3/12/2008, Ingemar Johansson S wrote: >Hi > >Sorry to see again that M$Outlook did some intelligent formatting on my >email.... >I repeat the essential bullets for the sake of clarity, hopefully it >will stay intact now... > >+ ECN '00' at PCN ingress should be '00' after PCN egress > >+ ECN '01' at PCN ingress can and should be either '10' or '01' after >PCN egress > >+ ECN '10' at PCN ingress can and should be either '10' or '01' after >PCN egress IMHO, The ECN '01' and '10' codepoints at ingress can also become '11' at egress. And this is still acceptable to ECN, how friendly this is to ECN is still an open question. The ECN nonce friendliness may not be needed as you are pointing out. >+ ECN '11' at PCN ingress should be '11' at PCN egress > >/Ingemar > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > > Behalf Of Ingemar Johansson S > > Sent: den 12 mars 2008 17:00 > > To: Kwok-Ho Chan; pcn@ietf.org > > Subject: Re: [PCN] Usage of '01' and '10' code points > > > > Hi > > > > Given that we discuss realtime appliations that run on RTP/UDP.. > > My thoughs regarding the 01 and 10 codepoinst are that they > > are actually not needed for ECN-nonce like it is done in eg > > RFC3540. The reason to this is that application that run over > > RTP/UDP do not have anything that resembles the nonce-sum > > that is available in the TCP header. It is possible that one > > may implement this as a special RTCP report but as e.g VoIP > > application do not have the typical client-server behavior > > that exist for instance for webservers and browsers I see > > very little use for the ECN nonce sum as you cannot build any > > trust on that anyway. Instead the ECN-CE will be reacted upon > > using other mechanisms such as rate change commands. > > > > My take is then that in order for a PCN domain to be "ECN > > friendly" but not "ECN nonce friendly" in a realtime > > perspective the following requirements apply: > > ECN '00' at PCN ingress should be '00' after PCN egress ECN > > '01' at PCN ingress can and should be either '10' or '01' > > after PCN egress ECN '10' at PCN ingress can and should be > > either '10' or '01' after PCN egress ECN '11' at PCN ingress > > should be '11' at PCN egress In doing like this an ECN > > capable node (could be a router or a 3GPP LTE > > eNB) after PCN-egress will be able to set ECN CE upon > > experienced congestion. The possible ECN nonce is broken with > > this but I don't see this as a problem. > > ECN '00' should never be set to '10' or '10' but I guess this > > is explained in RFC4774 (or is it RFC3168) > > > > I don't expect everybody to agree, for instance DCCP can echo > > the ECN nonce in the ack-vector. But then again I also here > > wonder how the trust relationship is built. > > > > /Ingemar > > > > > > > > > -----Original Message----- > > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > > Behalf Of > > > Kwok-Ho Chan > > > Sent: den 12 mars 2008 12:06 > > > To: pcn@ietf.org > > > Subject: [PCN] Usage of '01' and '10' code points > > > > > > Hi: > > > A discussion on PCN's use of '01' and '10' code points in the ECN > > > field. > > > Much if not all of this info is in > > > http://www.ietf.org/internet-drafts/draft-chan-pcn-encoding-co > > mparison-03.txt > > > more specifically in sections 2.2.3, 2.2.6, 3.1.4, paragraphs with > > > '01' and '10' headings. > > > > > > We originally proposed to use both '01' and '10' code points to > > > represent one encoding state of "Not-Pre-Congested" (or > > > "Un-Marked") (see section 2.1 of > > > encoding-comparison-03) > > > because: > > > 1. For the encoding options we do this, there were enough > > code points > > > for us to do so. > > > 2. Doing this increase ECN Nonce friendliness for the "leakage" > > > situations. > > > Packets entering the PCN domain with '01' or '10' > > > encoding can only be changed to '11'. > > > If by chance the "leaked-in" '01' and '10' encoded packets > > > "leaks-out" with no pre-congestion > > > on its path in the PCN domain, these packets are not > > affected by > > > the PCN domain. > > > This "leaked-in" and "leaks-out" may be due to the same > > > configuration error at the ingress > > > and egress node. > > > 3. Possible ratios of Admission-Marked and > > Termination-Marked packets > > > when '11' code point > > > is used for both. > > > > > > But with the squeeze on the available code points due to the > > > tunnelling constraints, we should re-visit if we should use > > both '01' > > > and '10' code points for just one encoding state. > > > > > > How about: > > > 1. Use '01' code point for Admission-Marked encoding state. > > > Use '10' code point for Not-Pre-Congested (Un-Marked) encoding > > > state. > > > Please notice the use of '10' for Not-Pre-Congested to be > > > friendlier to ECN not using nonce > > > ('10' = ECT(0) means not congested for 3168 ECN when > > nonce is not > > > used). > > > > > > The trade-offs of the new encoding scheme when comparing to > > using '01' > > > and '10' for one encoding state are: > > > 1. Less ECN Nonce friendly but still ECN friendly. > > > 2. Can not have the flexibility of the possible separation of > > > Admission and Termination Marked. > > > > > > The notion of "less ECN nonce friendly" can be philosophical: > > > - Is it better to detect a configuration error as soon as > > possible and > > > fix it? > > > Or > > > - Is it better to minimize the affect of the configuration > > error and > > > hence harder to detect > > > and have it not fixed for a longer period of time? > > > And > > > - Is it OK to not be able to detect the configuration error > > if it have > > > no functional affect? > > > > > > So the trade-off of "Less ECN Nonce friendly" may be viewed > > as faster > > > ECN Nonce violation detection. > > > > > > > > > In light of the latest new constraints and trade-offs, I > > would like to > > > ask the Working Group to think about and comment on: > > > 1. Should we continue to use both '01' and '10' code points > > for just > > > ONE encoding state? > > > 2. Will it be acceptable to use '01' and '10' code points for TWO > > > encoding states? > > > > > > There may be additional trade-offs not indicated above. > > > Please share them with us if you know of additional ones. > > > > > > Thank you! > > > -- Kwok Ho Chan -- > > > > > > _______________________________________________ > > > 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 > > >_______________________________________________ >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 From pcn-bounces@ietf.org Thu Mar 13 19:35:58 2008 Return-Path: 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 418BD28C179; Thu, 13 Mar 2008 19:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.329 X-Spam-Level: X-Spam-Status: No, score=-100.329 tagged_above=-999 required=5 tests=[AWL=-0.492, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 KFmfe0addPYU; Thu, 13 Mar 2008 19:35:57 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 289DC28C0FE; Thu, 13 Mar 2008 19:35:57 -0700 (PDT) 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 B80CA28C0FE for ; Thu, 13 Mar 2008 19:35:55 -0700 (PDT) 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 PD1BOwq3bUUH for ; Thu, 13 Mar 2008 19:35:54 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id AFD9B3A67FA for ; Thu, 13 Mar 2008 19:35:53 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 345F5199259; Fri, 14 Mar 2008 03:33:35 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 286DA199257; Fri, 14 Mar 2008 03:33:35 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id E3DFE199142; Fri, 14 Mar 2008 03:33:33 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m2E24LV29966; Fri, 14 Mar 2008 03:04:21 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id BA6EAC821D; Fri, 14 Mar 2008 03:04:20 +0100 (CET) Message-ID: <47D9DCEB.4090801@informatik.uni-wuerzburg.de> Date: Fri, 14 Mar 2008 03:03:23 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Ingemar Johansson S References: <47D8677E.6090907@informatik.uni-wuerzburg.de> <200803130446.m2D4kgpB032592@bagheera.jungle.bt.co.uk> <026F8EEDAD2C4342A993203088C1FC050260E238@esealmw109.eemea.ericsson.se> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC050260E238@esealmw109.eemea.ericsson.se> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Possible clever encoding for PCN X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ingemar, hi Bob, if the admissible rate is exceeded on the bottleneck link, all packets are ThM- or EM-marked. The egress resets their markings to CE. Isn't that a bit tough for already admitted PCN flows that use TCP and are responsive to ECN? They need to reduce their rate and as a consequence, they cannot benefit from PCN-based admission control. Do I miss something? Regards, Michael Ingemar Johansson S wrote: > Hi > > As a general 1st comment I am (slightly) positive to this approach. > > There is a certain risk that codecs over-react as ThM will be seen as > ECN-CE by the endpoints but here I lack the knowledge in how common ThM > will actually be compared to the experienced congestion experienced in > e.g wireless nodes outside the PCN domain. > One scenario: > Video with two possible bitrate (200kbps and 50kbps), initially the > codec rate is 200kbps. > As more flows are admitted endpoints will eventually see the ThM (masked > as ECN-CE). > Some (or many or all?) of the endpoints will then adapt the codec rate > to the lower codec rate (50kbps, after a while as the rate change > effects, the ThM will go away and more flows will get admitted (with > initial codec rate 200kbps) with the result that endpoints will again > after while see ThM.... with the result that more endpoints adapt the > rate to the lower rate. > This can be both good and bad I guess, good in the sense that it is > maybe codec rate adaptivity at its best, bad in the sense that in the > end quality is generally sacrificed for capacity and the endpoints that > don't do rate adaptation at all are the winners. > In a scenario with "trusted" enpoints that follow a secified adaptation > behavior this may however work. > > /Ingemar > > > > > > >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On >> Behalf Of Bob Briscoe >> Sent: den 13 mars 2008 00:47 >> To: menth@informatik.uni-wuerzburg.de >> Cc: pcn@ietf.org >> Subject: Re: [PCN] Possible clever encoding for PCN >> >> Michael, >> >> [Terminology reminder at end.] >> >> 1) is true. >> 2) is a deliberate feature >> >> You will also notice (Toby omitted to mention) that, not only >> does endpoint get EM marks as CE, but it gets ThM as CE too. >> We've made the egress rules so that all PCN marking is >> deliberately leaked out into the next non-PCN region. If >> there's more than one PCN region on the path, at each new PCN >> ingress, the previously leaked out CE are set aside in the >> NM(CE) codepoint, while more PCN markings are collected >> across the next region. Then, at the next egress, any CE set >> aside at the ingress or any PCN marks collected across the >> next PCN region are again deliberately leaked out as CE. And so on. >> >> The upshot is that the endpoint sees all ECN markings and all >> PCN markings. This might seem strange, because each PCN >> region already responds to markings generated within each PCN >> region. But the idea is that, if the endpoints are adaptive, >> they /may/ be able to drop down a codec level when they see >> any CE marking (whether from PCN ThM, PCN EM or ECN). Then >> the PCN markings should go away. If the codecs don't or can't >> adapt, the PCN mechanisms will still be there. >> >> To be absolutely clear, this is brainstorm stuff. We have no >> idea whether the three congestion control mecahnisms >> (adaptive codecs, PCN admission control and flow termination >> at overload) can reliably work together without fighting or >> thrashing etc. This is just wire protocol possibilities, not >> system design. >> >> Terminology reminder: >> NM = Not Marked >> ThM = Threshold Marked >> EM = Excess-rate Marked >> >> Bob >> >> At 23:30 12/03/2008, Michael Menth wrote: >> >>> Hi Toby, hi Bob, >>> >>> yes, that's good. >>> >>> Side effects: >>> 1) It disables ECN for EF-ADMIT if DSCPx is not available in the >>> initial deployment model, but this holds for any encoding we >>> >> considered >> >>> so far unless we consumed at least 2 DSCPs. >>> 2) When ECN is supported in the 3-codepoint model, endpoint of EM >>> marked flows get 11 (CE) signals from PCN. This is not too bad as >>> packets get marked in the 3-codepoint model only under heave >>> >> overload. >> >>> It's not problematic for most realtime flows that are not >>> >> responsive to ECN anyway. >> >>> Regards, >>> >>> Michael >>> >>> toby.moncaster@bt.com wrote: >>> >>>> Hi All, >>>> >>>> Bob and I just spent a fun 30 minutes trying to work out how to >>>> carry end-to-end ECN across PCN whilst still retaining >>>> >> all the PCN >> >>>> codepoints we need. We think we have succeeded... >>>> >>>> The attached 2 slides try to set this encoding out as clearly as >>>> possible. Note the new terminology being used! Also note >>>> >> that this >> >>>> is making the assumption that we will be re-using Fred >>>> >> Baker's DSCP >> >>>> and hence need to identify PCN traffic from not PCN traffic. >>>> >>>> Toby >>>> >>>> >> ____________________________________________________________________ >> >>>> Toby Moncaster, Networks Research >>>> >> Centre, BT >> >>>> B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 >>>> >>>> >>>> >>>> (in case anyone is wondering at the title it stands for: you can >>>> please everyone all the time...) >>>> >>>> >> -------------------------------------------------------------------- >> >>>> ---- >>>> >>>> _______________________________________________ >>>> PCN mailing list >>>> PCN@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pcn >>>> >>> -- >>> 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 >>> >> ______________________________________________________________ >> ______________ >> Bob Briscoe, Networks Research >> Centre, BT Research >> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. >> +44 1473 645196 >> >> >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn >> >> -- 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 From pcn-bounces@ietf.org Fri Mar 14 07:57:59 2008 Return-Path: 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 C6E7628C968; Fri, 14 Mar 2008 07:57:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.273 X-Spam-Level: X-Spam-Status: No, score=-101.273 tagged_above=-999 required=5 tests=[AWL=-0.836, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 P1xXo6jNh0bC; Fri, 14 Mar 2008 07:57:59 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A3F728C919; Fri, 14 Mar 2008 07:57:55 -0700 (PDT) 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 1E7F528C919 for ; Fri, 14 Mar 2008 07:57:54 -0700 (PDT) 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 ndney5Xq37z9 for ; Fri, 14 Mar 2008 07:57:50 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 7C37728C918 for ; Fri, 14 Mar 2008 07:57:05 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m2EEsV3q022859 for ; Fri, 14 Mar 2008 09:54:47 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Mar 2008 09:54:38 -0500 Received: from [127.0.0.1] ([147.117.168.117]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Mar 2008 09:54:37 -0500 From: Steven Blake To: pcn Organization: Ericsson IP Infrastructure Date: Fri, 14 Mar 2008 10:54:36 -0400 Message-Id: <1205506476.2992.34.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) X-OriginalArrivalTime: 14 Mar 2008 14:54:37.0782 (UTC) FILETIME=[53120760:01C885E3] Subject: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Greetings. There were six concensus questions called during yesterday's PCN meeting. Before we call the questions on the list, I want to paraphrase them and make sure that everyone agrees that this captures the sense of the discussion. Q1: As an initial standardization activity, should the PCN wg produce a standards-track PCN scheme that requires only two encoding states? (Note: this question does not presume that the solution is Single Marking). Q2: Should the PCN wg produce an experimental-track extension to the standards-track PCN scheme that requires another encoding state (for a total of three encoding states)? Q3: Does the working group have enough information to make a decision about the way forward for the standards-track PCN scheme? Q4: Should the standards-track PCN scheme require (as a MUST implement feature) that interior PCN routers support Excess-Rate marking, according to the particular method of handling already marked packets and drops described in Anna Charny's presentation? http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf Q5: Should the standards-track PCN scheme require (as a MUST implement feature) that interior PCN routers support Threshold marking (in addition to Excess-Rate marking), according to the particular method described in Philip Eardley's presentation on Tuesday? http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf Q6: If presented with sufficient evidence in a timely fashion, would the PCN wg entertain the option of modifying the interior router Excess-Rate marking behavior for the standards-track PCN scheme (as described in question 4)? Please send comments to the list. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Mar 14 08:09:12 2008 Return-Path: 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 50BBE28C563; Fri, 14 Mar 2008 08:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.889 X-Spam-Level: X-Spam-Status: No, score=-100.889 tagged_above=-999 required=5 tests=[AWL=-0.452, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 D5q+YVbXXwV4; Fri, 14 Mar 2008 08:09:11 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AAA93A68E8; Fri, 14 Mar 2008 08:09:11 -0700 (PDT) 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 C79C93A6D2D for ; Fri, 14 Mar 2008 08:09:09 -0700 (PDT) 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 8D3cB0jWF+AH for ; Fri, 14 Mar 2008 08:09:08 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 1402D3A6A0D for ; Fri, 14 Mar 2008 08:09:07 -0700 (PDT) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Mar 2008 15:06:47 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 14 Mar 2008 15:06:46 -0000 Message-ID: In-Reply-To: <1205506476.2992.34.camel@neutrino> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciF45CpLcHuY5Z5TbK4RQE135I89wAAP67g From: To: , X-OriginalArrivalTime: 14 Mar 2008 15:06:47.0168 (UTC) FILETIME=[05D18000:01C885E5] Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Mostly fine. Question 2 I believe we agreed to call it "one or more" extensions at Georgios's request Question 6 you need to highlight that we suggested IETF72 in Dublin as being "in a timely fashion" for this new evidence. Toby ____________________________________________________________________ Toby Moncaster, Networks Research Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Steven Blake > Sent: 14 March 2008 14:55 > To: pcn > Subject: [PCN] Concensus questions from Thursday's PCN meeting > > Greetings. > > There were six concensus questions called during yesterday's PCN > meeting. Before we call the questions on the list, I want to > paraphrase > them and make sure that everyone agrees that this captures > the sense of > the discussion. > > > Q1: As an initial standardization activity, should the PCN wg > produce a > standards-track PCN scheme that requires only two encoding states? > (Note: this question does not presume that the solution is Single > Marking). > > Q2: Should the PCN wg produce an experimental-track extension to the > standards-track PCN scheme that requires another encoding > state (for > a total of three encoding states)? > > Q3: Does the working group have enough information to make a decision > about the way forward for the standards-track PCN scheme? > > Q4: Should the standards-track PCN scheme require (as a MUST implement > feature) that interior PCN routers support Excess-Rate marking, > according to the particular method of handling already marked > packets and drops described in Anna Charny's presentation? > http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf > > Q5: Should the standards-track PCN scheme require (as a MUST implement > feature) that interior PCN routers support Threshold marking (in > addition to Excess-Rate marking), according to the > particular method > described in Philip Eardley's presentation on Tuesday? > http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf > > Q6: If presented with sufficient evidence in a timely fashion, would > the PCN wg entertain the option of modifying the interior router > Excess-Rate marking behavior for the standards-track PCN > scheme (as > described in question 4)? > > > Please send comments to the list. > > > Regards, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven Blake > Ericsson/Redback Networks +1 919-472-9913 > > _______________________________________________ > 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 From pcn-bounces@ietf.org Fri Mar 14 08:20:52 2008 Return-Path: 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 C87A028C36E; Fri, 14 Mar 2008 08:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.518 X-Spam-Level: X-Spam-Status: No, score=-103.518 tagged_above=-999 required=5 tests=[AWL=-3.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 d8l8tMs+PbXJ; Fri, 14 Mar 2008 08:20:51 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4CAF3A6DB9; Fri, 14 Mar 2008 08:20:51 -0700 (PDT) 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 3F96028C155 for ; Fri, 14 Mar 2008 08:20:50 -0700 (PDT) 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 EX0Yunqlum6C for ; Fri, 14 Mar 2008 08:20:48 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id AD43B3A6D2D for ; Fri, 14 Mar 2008 08:20:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,501,1199682000"; d="scan'208";a="1786602" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 14 Mar 2008 11:18:28 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m2EFITAF010932; Fri, 14 Mar 2008 11:18:29 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2EFITqJ022480; Fri, 14 Mar 2008 15:18:29 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Mar 2008 11:18:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 14 Mar 2008 11:18:25 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciF45CpLcHuY5Z5TbK4RQE135I89wAAP67gAAB8muA= From: "Anna Charny (acharny)" To: , , X-OriginalArrivalTime: 14 Mar 2008 15:18:27.0617 (UTC) FILETIME=[A7518910:01C885E6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3729; t=1205507909; x=1206371909; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20(acharny)=22=20 |Subject:=20RE=3A=20[PCN]=20Concensus=20questions=20from=20 Thursday's=20PCN=20meeting |Sender:=20 |To:=20,=20,=20; bh=NvAXvYgC+56eGSYzk9PBJL6xxW3ODdPXZoDYbXR+Ni0=; b=U4kCLGEvKGcveRqwwYczQimouwVeHJTKSpWiEUE1sPnEUNsZeuUUw3KvEP 2R9+D/T3G2w4vddpUhYsTsOTxyVtWw5XNrtfaQCMeioXGlZ7x6UWx1eKKsRc 5XHqsx4YF0; Authentication-Results: rtp-dkim-2; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Steve, Agreed with Toby's comments. Fine with me otherwise. Anna > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of toby.moncaster@bt.com > Sent: Friday, March 14, 2008 11:07 AM > To: steven.blake@ericsson.com; pcn@ietf.org > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > > Mostly fine. > > Question 2 I believe we agreed to call it "one or more" > extensions at Georgios's request > > Question 6 you need to highlight that we suggested IETF72 in > Dublin as being "in a timely fashion" for this new evidence. > > Toby > ____________________________________________________________________ > Toby Moncaster, Networks Research > Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 > 1473 648734 > > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of > > Steven Blake > > Sent: 14 March 2008 14:55 > > To: pcn > > Subject: [PCN] Concensus questions from Thursday's PCN meeting > > > > Greetings. > > > > There were six concensus questions called during yesterday's PCN > > meeting. Before we call the questions on the list, I want to > > paraphrase them and make sure that everyone agrees that > this captures > > the sense of the discussion. > > > > > > Q1: As an initial standardization activity, should the PCN wg > > produce a > > standards-track PCN scheme that requires only two > encoding states? > > (Note: this question does not presume that the solution > is Single > > Marking). > > > > Q2: Should the PCN wg produce an experimental-track extension to the > > standards-track PCN scheme that requires another encoding > > state (for > > a total of three encoding states)? > > > > Q3: Does the working group have enough information to make > a decision > > about the way forward for the standards-track PCN scheme? > > > > Q4: Should the standards-track PCN scheme require (as a > MUST implement > > feature) that interior PCN routers support Excess-Rate marking, > > according to the particular method of handling already marked > > packets and drops described in Anna Charny's presentation? > > http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf > > > > Q5: Should the standards-track PCN scheme require (as a > MUST implement > > feature) that interior PCN routers support Threshold marking (in > > addition to Excess-Rate marking), according to the > > particular method > > described in Philip Eardley's presentation on Tuesday? > > http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf > > > > Q6: If presented with sufficient evidence in a timely fashion, would > > the PCN wg entertain the option of modifying the interior router > > Excess-Rate marking behavior for the standards-track PCN > > scheme (as > > described in question 4)? > > > > > > Please send comments to the list. > > > > > > Regards, > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > Steven Blake > > Ericsson/Redback Networks +1 919-472-9913 > > > > _______________________________________________ > > 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 > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Mar 14 08:30:04 2008 Return-Path: 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 03B2928C44E; Fri, 14 Mar 2008 08:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.332 X-Spam-Level: X-Spam-Status: No, score=-101.332 tagged_above=-999 required=5 tests=[AWL=-0.895, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 BlJLGtmKfYWG; Fri, 14 Mar 2008 08:30:03 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 367773A69B2; Fri, 14 Mar 2008 08:30:03 -0700 (PDT) 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 B7B1E3A6999 for ; Fri, 14 Mar 2008 08:30:01 -0700 (PDT) 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 PS28zydv3VrS for ; Fri, 14 Mar 2008 08:29:57 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 9AD4B28C432 for ; Fri, 14 Mar 2008 08:29:57 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m2EFRY84007558; Fri, 14 Mar 2008 10:27:34 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Mar 2008 10:27:34 -0500 Received: from [127.0.0.1] ([147.117.168.117]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Mar 2008 10:27:34 -0500 From: Steven Blake To: toby.moncaster@bt.com In-Reply-To: References: Organization: Ericsson IP Infrastructure Date: Fri, 14 Mar 2008 11:27:32 -0400 Message-Id: <1205508452.2992.38.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) X-OriginalArrivalTime: 14 Mar 2008 15:27:34.0410 (UTC) FILETIME=[ED3B86A0:01C885E7] Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org On Fri, 2008-03-14 at 15:06 +0000, toby.moncaster@bt.com wrote: > Mostly fine. > > Question 2 I believe we agreed to call it "one or more" extensions at > Georgios's request Correct: I had "extensions" in my notes, but failed to type it correctly. > Question 6 you need to highlight that we suggested IETF72 in Dublin as > being "in a timely fashion" for this new evidence. That wasn't part of the question specifically. By my personal view, I hope that we can make a decision one way or another much sooner than Dublin. Thanks, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Mar 14 08:48:33 2008 Return-Path: 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 C143F3A6E2C; Fri, 14 Mar 2008 08:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.101 X-Spam-Level: X-Spam-Status: No, score=-100.101 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 4y0Xy-pgPt8i; Fri, 14 Mar 2008 08:48:32 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3D7928C2CE; Fri, 14 Mar 2008 08:48:32 -0700 (PDT) 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 E768B28C320 for ; Fri, 14 Mar 2008 08:48:30 -0700 (PDT) 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 l9r2IowzzkXh for ; Fri, 14 Mar 2008 08:48:23 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 6AB753A69B2 for ; Fri, 14 Mar 2008 08:48:23 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Mar 2008 15:46:05 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Mar 2008 15:46:05 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1205509563470; Fri, 14 Mar 2008 15:46:03 +0000 Received: from mut.jungle.bt.co.uk ([10.73.85.174]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m2EFjuXk021026; Fri, 14 Mar 2008 15:46:01 GMT Message-Id: <200803141546.m2EFjuXk021026@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 14 Mar 2008 15:45:54 +0000 To: "Anna Charny (acharny)" From: Bob Briscoe In-Reply-To: References: <200803141416.m2EEFrvp015126@bagheera.jungle.bt.co.uk> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 14 Mar 2008 15:46:05.0047 (UTC) FILETIME=[83394870:01C885EA] Cc: PCN IETF list Subject: Re: [PCN] EF-ADMIT & PCN DSCP(s) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Anna, [Copying this to the PCN list.] I'm assuming PCN marking is applied to all the inelastic classes as a PHB group without re-marking their DSCP. So VOICE-ADMIT would just be one of the DSCPs that PCN would be configured to apply to. If the DSCP was already set to one of the inelastic classes the PCN ingress would preserve it (assuming appropriate authorisation for the flow). Otherwise, it would remark the DSCP to whichever of the (3) inelastic DSCPs was most appropriate. But the PCN domain would treat all three DSCPs the same - both for scheduling and for PCN marking. However, this only works simply if we don't use a second DSCP for re-marking (the experimental encoding). For the non-SM experiments, we'll have to use 3 local DSCPs to map the possible 3 inelastic DSCPs. If the expt is successful and operators want PCN, that makes the argument even stronger for fixing ECN tunnelling so we can use the two ECT codepoints separately rather than 2n DSCPs where n = 3. For MPLS, DSCPs are effectively tunneled, so there's not a problem mapping all 3 DSCPs to one (EF-ADMIT) over the MPLS domains (except of course for the severe shortage of codepoints). Bob At 14:56 14/03/2008, Anna Charny (acharny) wrote: >Bob, > >I suddenly got confused. I understand I think how using ED-Admit will >work as long as we are using only one DSCP. But if we remark ED-admit >when we start using the second DSCP, then in order to preserve the >end-to-end semantics of EF-Admit we would need to restore the DSCP at >the egress. > >If we then say that we can use PCN treatment for OTHER traffic classes >- then how do we know at the egress when we do and do not need to >restore the EF-Admit marking? > >Or do I misunderstand what you are saying? > >Anna > > > -----Original Message----- > > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > > Sent: Friday, March 14, 2008 10:16 AM > > To: Fred Baker (fred) > > Cc: Anna Charny (acharny); Toby MONCASTER; Phil EARDLEY; > > tsvwg-chairs@tools.ietf.org; CHAN, Kwok Ho; Georgios Karagiannis > > Subject: Re: EF-ADMIT & PCN DSCP(s) > > > > Fred, > > > > At 23:08 13/03/2008, Fred Baker wrote: > > >-----BEGIN PGP SIGNED MESSAGE----- > > >Hash: SHA1 > > > > > > > > >On Mar 13, 2008, at 6:38 PM, Bob Briscoe wrote: > > > > > >>But we can't say "Lower speed access links being the primary > > >>consideration" when we have an e2e path that goes through the fast > > >>middle too. > > > > > >Fine. So I'm offering to put text in that describes how to interact > > >with the high speed middle. > > > > > >Here's the problem. If I am building an end to end > > capability, it has > > >to work through both ends *and* the high speed middle. RFC > > 4594 and RFC > > >5127 are complimentary here: RFC 4594 describes classes that can be > > >used to avoid unfortunate traffic interactions in the low > > speed access, > > >and RFC 5127 tells how to combine those in the gigabit core without > > >breaking that. > > > > > >You are asking me to break that by applying a single DSCP to > > the whole > > >lot, preventing me from separating video service from voice > > service in > > >the access, and by using a common service profile for both, > > which per > > >the considerations of RFC 4594 are known to differ from the > > >application's perspective. > > > > No, re-read my post - I'm agreeing with you. I'm just writing > > down the thought process I went through to get to where you > > are. To, hopefully, help you write the draft in a way people > > will better understand. > > > > My last para: > > "So, I think this means PCN has to be a configurable marking > > for more than just VOICE-ADMIT. It has to be applicable to > > all 3 inelastic media-oriented service classes. > > " > > > > > > Bob > > > > > > >I think that breaking the access to simplify things in the > > core is very > > >silly. > > >-----BEGIN PGP SIGNATURE----- > > > > > >iD8DBQFH2bPebjEdbHIsm0MRAubmAKCXwxbkLfK53VcJHVWsQGBZQak2FgCg91Je > > >Z2qOS2YJZcGSi3zh9bfJvUU= > > >=c5CD > > >-----END PGP SIGNATURE----- > > > > ______________________________________________________________ > > ______________ > > Bob Briscoe, Networks Research > > Centre, BT Research > > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. > > +44 1473 645196 > > > > > > ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Mar 14 09:11:50 2008 Return-Path: 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 2339F3A6BD8; Fri, 14 Mar 2008 09:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.663 X-Spam-Level: X-Spam-Status: No, score=-100.663 tagged_above=-999 required=5 tests=[AWL=-0.826, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 eAoifLSeu9eb; Fri, 14 Mar 2008 09:11:48 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFA6D3A6AB4; Fri, 14 Mar 2008 09:11:48 -0700 (PDT) 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 929E63A680B for ; Fri, 14 Mar 2008 09:11:47 -0700 (PDT) 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 0xvkHaTjZV+g for ; Fri, 14 Mar 2008 09:11:46 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 03A513A6AB4 for ; Fri, 14 Mar 2008 09:11:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,502,1199682000"; d="scan'208";a="1797443" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 14 Mar 2008 12:09:28 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m2EG9SOf019737; Fri, 14 Mar 2008 12:09:28 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2EG9ST3011950; Fri, 14 Mar 2008 16:09:28 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Mar 2008 12:09:27 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 14 Mar 2008 12:09:24 -0400 Message-ID: In-Reply-To: <200803141546.m2EFjuXk021026@bagheera.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EF-ADMIT & PCN DSCP(s) Thread-Index: AciF6qK/WIo2QjZZRQqlfql+SqOlqgAAjvkA From: "Anna Charny (acharny)" To: "Bob Briscoe" X-OriginalArrivalTime: 14 Mar 2008 16:09:27.0889 (UTC) FILETIME=[C761FC10:01C885ED] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5973; t=1205510968; x=1206374968; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20(acharny)=22=20 |Subject:=20RE=3A=20EF-ADMIT=20&=20PCN=20DSCP(s) |Sender:=20 |To:=20=22Bob=20Briscoe=22=20; bh=xtlyZ2ApbVB1VU3O1nUceHvrp+VR8bW8UNB6d+gz3ew=; b=Yy3LY5L5fV3MnpTzB7vfUyYggu/hRUtNE4UpZtD/SticFptvLJjex8X/6M yFE7zlolo98HDWhEa5NPqp2mnJYBmbcuCQXS0dBo0FYV+eEorxAKU+EI+3Gj i4Ch3f1oNF; Authentication-Results: rtp-dkim-1; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: PCN IETF list Subject: Re: [PCN] EF-ADMIT & PCN DSCP(s) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Bob, OK, so I think we are in agreement. It would not work to use the EF-Admit if PCN is using 2 DSCPs. But it would work for the solution with 1 DSCP (and two encoding states). When 1 DSCP is used for PCN, the end-to-end semantics of EF-Admit remains independent of PCN. However, on a "PCN domain hop", PCN treatment will be applied to EF-admit to make the admission decision. And that seems perfectly OK. It (PCN domain hop) also can make a termination decision though - does this create any issue with the end-to-end semantics of EF-Admit? Right? Anna > -----Original Message----- > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > Sent: Friday, March 14, 2008 11:46 AM > To: Anna Charny (acharny) > Cc: PCN IETF list; Fred Baker (fred) > Subject: RE: EF-ADMIT & PCN DSCP(s) > > Anna, > > [Copying this to the PCN list.] > > I'm assuming PCN marking is applied to all the inelastic > classes as a PHB group without re-marking their DSCP. So > VOICE-ADMIT would just be one of the DSCPs that PCN would be > configured to apply to. > > If the DSCP was already set to one of the inelastic classes > the PCN ingress would preserve it (assuming appropriate > authorisation for the flow). Otherwise, it would remark the > DSCP to whichever of the (3) inelastic DSCPs was most > appropriate. But the PCN domain would treat all three DSCPs > the same - both for scheduling and for PCN marking. > > However, this only works simply if we don't use a second DSCP > for re-marking (the experimental encoding). > > For the non-SM experiments, we'll have to use 3 local DSCPs > to map the possible 3 inelastic DSCPs. If the expt is > successful and operators want PCN, that makes the argument > even stronger for fixing ECN tunnelling so we can use the two > ECT codepoints separately rather than 2n DSCPs where n = 3. > > For MPLS, DSCPs are effectively tunneled, so there's not a > problem mapping all 3 DSCPs to one (EF-ADMIT) over the MPLS > domains (except of course for the severe shortage of codepoints). > > > Bob > > At 14:56 14/03/2008, Anna Charny (acharny) wrote: > >Bob, > > > >I suddenly got confused. I understand I think how using > ED-Admit will > >work as long as we are using only one DSCP. But if we > remark ED-admit > >when we start using the second DSCP, then in order to preserve the > >end-to-end semantics of EF-Admit we would need to restore > the DSCP at > >the egress. > > > >If we then say that we can use PCN treatment for OTHER > traffic classes > >- then how do we know at the egress when we do and do not need to > >restore the EF-Admit marking? > > > >Or do I misunderstand what you are saying? > > > >Anna > > > > > -----Original Message----- > > > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > > > Sent: Friday, March 14, 2008 10:16 AM > > > To: Fred Baker (fred) > > > Cc: Anna Charny (acharny); Toby MONCASTER; Phil EARDLEY; > > > tsvwg-chairs@tools.ietf.org; CHAN, Kwok Ho; Georgios Karagiannis > > > Subject: Re: EF-ADMIT & PCN DSCP(s) > > > > > > Fred, > > > > > > At 23:08 13/03/2008, Fred Baker wrote: > > > >-----BEGIN PGP SIGNED MESSAGE----- > > > >Hash: SHA1 > > > > > > > > > > > >On Mar 13, 2008, at 6:38 PM, Bob Briscoe wrote: > > > > > > > >>But we can't say "Lower speed access links being the primary > > > >>consideration" when we have an e2e path that goes > through the fast > > > >>middle too. > > > > > > > >Fine. So I'm offering to put text in that describes how > to interact > > > >with the high speed middle. > > > > > > > >Here's the problem. If I am building an end to end > > > capability, it has > > > >to work through both ends *and* the high speed middle. RFC > > > 4594 and RFC > > > >5127 are complimentary here: RFC 4594 describes classes > that can be > > > >used to avoid unfortunate traffic interactions in the low > > > speed access, > > > >and RFC 5127 tells how to combine those in the gigabit > core without > > > >breaking that. > > > > > > > >You are asking me to break that by applying a single DSCP to > > > the whole > > > >lot, preventing me from separating video service from voice > > > service in > > > >the access, and by using a common service profile for both, > > > which per > > > >the considerations of RFC 4594 are known to differ from the > > > >application's perspective. > > > > > > No, re-read my post - I'm agreeing with you. I'm just > writing down > > > the thought process I went through to get to where you are. To, > > > hopefully, help you write the draft in a way people will better > > > understand. > > > > > > My last para: > > > "So, I think this means PCN has to be a configurable marking for > > > more than just VOICE-ADMIT. It has to be applicable to all 3 > > > inelastic media-oriented service classes. > > > " > > > > > > > > > Bob > > > > > > > > > >I think that breaking the access to simplify things in the > > > core is very > > > >silly. > > > >-----BEGIN PGP SIGNATURE----- > > > > > > > >iD8DBQFH2bPebjEdbHIsm0MRAubmAKCXwxbkLfK53VcJHVWsQGBZQak2FgCg91Je > > > >Z2qOS2YJZcGSi3zh9bfJvUU= > > > >=c5CD > > > >-----END PGP SIGNATURE----- > > > > > > ______________________________________________________________ > > > ______________ > > > Bob Briscoe, Networks Research > > > Centre, BT Research > > > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. > > > +44 1473 645196 > > > > > > > > > > > ______________________________________________________________ > ______________ > Bob Briscoe, Networks Research > Centre, BT Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. > +44 1473 645196 > > > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Mar 14 09:20:22 2008 Return-Path: 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 A9E8228C8F2; Fri, 14 Mar 2008 09:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.873 X-Spam-Level: X-Spam-Status: No, score=-100.873 tagged_above=-999 required=5 tests=[AWL=-1.036, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 PnRsvpi1CP9a; Fri, 14 Mar 2008 09:20:16 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ED9D28C900; Fri, 14 Mar 2008 09:20:16 -0700 (PDT) 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 3857628C8B8 for ; Fri, 14 Mar 2008 09:20:14 -0700 (PDT) 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 d+VvuBESNAam for ; Fri, 14 Mar 2008 09:20:12 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 02F023A6CB1 for ; Fri, 14 Mar 2008 09:20:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,502,1199692800"; d="scan'208";a="17357216" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 14 Mar 2008 09:17:55 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m2EGHt4j032108; Fri, 14 Mar 2008 09:17:55 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id m2EGHWeC011964; Fri, 14 Mar 2008 16:17:44 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Mar 2008 09:17:40 -0700 Received: from [10.150.133.6] ([10.21.71.56]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Mar 2008 09:17:40 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v753) X-Gpgmail-State: !signed Message-Id: From: Fred Baker Date: Fri, 14 Mar 2008 12:17:37 -0400 To: Anna Charny (acharny) X-Mailer: Apple Mail (2.753) X-OriginalArrivalTime: 14 Mar 2008 16:17:40.0603 (UTC) FILETIME=[ED102CB0:01C885EE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6101; t=1205511475; x=1206375475; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20EF-ADMIT=20&=20PCN=20DSCP(s) |Sender:=20; bh=alh78v2MPOE4eeg1L149e7yswmkfeVkqDSaqL+8wCGw=; b=fMNPig3Z5cXn9K11zHwlElE1uvFhjDMW+b5rKCaOUrFprgCZ7ECKxR/Ti4 xRGBos5RJ3hOGomi5zatmH0blUA/JTnmN5MpTU1pEmtEreSB7hP1yTCyEAFo MkxM7pjqNEia8lxhGg8tEO5zUQb95YAKrvmriafCjZfFNRp0wZ88Y=; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: PCN IETF list Subject: Re: [PCN] EF-ADMIT & PCN DSCP(s) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org so we're back to using a DSCP to signal a mechanism instead of what it is intended to signal, which is a service class? I thought we had agreed to use DSCPs for service classes, which might in turn use or not use the PCN mechanism? On Mar 14, 2008, at 12:09 PM, Anna Charny (acharny) wrote: > Hi Bob, > > OK, so I think we are in agreement. It would not work to use the > EF-Admit if PCN is using 2 DSCPs. But it would work for the solution > with 1 DSCP (and two encoding states). > > When 1 DSCP is used for PCN, the end-to-end semantics of EF-Admit > remains independent of PCN. However, on a "PCN domain hop", PCN > treatment will be applied to EF-admit to make the admission decision. > And that seems perfectly OK. > > It (PCN domain hop) also can make a termination decision though - does > this create any issue with the end-to-end semantics of EF-Admit? > > Right? > Anna > >> -----Original Message----- >> From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] >> Sent: Friday, March 14, 2008 11:46 AM >> To: Anna Charny (acharny) >> Cc: PCN IETF list; Fred Baker (fred) >> Subject: RE: EF-ADMIT & PCN DSCP(s) >> >> Anna, >> >> [Copying this to the PCN list.] >> >> I'm assuming PCN marking is applied to all the inelastic >> classes as a PHB group without re-marking their DSCP. So >> VOICE-ADMIT would just be one of the DSCPs that PCN would be >> configured to apply to. >> >> If the DSCP was already set to one of the inelastic classes >> the PCN ingress would preserve it (assuming appropriate >> authorisation for the flow). Otherwise, it would remark the >> DSCP to whichever of the (3) inelastic DSCPs was most >> appropriate. But the PCN domain would treat all three DSCPs >> the same - both for scheduling and for PCN marking. >> >> However, this only works simply if we don't use a second DSCP >> for re-marking (the experimental encoding). >> >> For the non-SM experiments, we'll have to use 3 local DSCPs >> to map the possible 3 inelastic DSCPs. If the expt is >> successful and operators want PCN, that makes the argument >> even stronger for fixing ECN tunnelling so we can use the two >> ECT codepoints separately rather than 2n DSCPs where n = 3. >> >> For MPLS, DSCPs are effectively tunneled, so there's not a >> problem mapping all 3 DSCPs to one (EF-ADMIT) over the MPLS >> domains (except of course for the severe shortage of codepoints). >> >> >> Bob >> >> At 14:56 14/03/2008, Anna Charny (acharny) wrote: >>> Bob, >>> >>> I suddenly got confused. I understand I think how using >> ED-Admit will >>> work as long as we are using only one DSCP. But if we >> remark ED-admit >>> when we start using the second DSCP, then in order to preserve the >>> end-to-end semantics of EF-Admit we would need to restore >> the DSCP at >>> the egress. >>> >>> If we then say that we can use PCN treatment for OTHER >> traffic classes >>> - then how do we know at the egress when we do and do not need to >>> restore the EF-Admit marking? >>> >>> Or do I misunderstand what you are saying? >>> >>> Anna >>> >>>> -----Original Message----- >>>> From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] >>>> Sent: Friday, March 14, 2008 10:16 AM >>>> To: Fred Baker (fred) >>>> Cc: Anna Charny (acharny); Toby MONCASTER; Phil EARDLEY; >>>> tsvwg-chairs@tools.ietf.org; CHAN, Kwok Ho; Georgios Karagiannis >>>> Subject: Re: EF-ADMIT & PCN DSCP(s) >>>> >>>> Fred, >>>> >>>> At 23:08 13/03/2008, Fred Baker wrote: >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> Hash: SHA1 >>>>> >>>>> >>>>> On Mar 13, 2008, at 6:38 PM, Bob Briscoe wrote: >>>>> >>>>>> But we can't say "Lower speed access links being the primary >>>>>> consideration" when we have an e2e path that goes >> through the fast >>>>>> middle too. >>>>> >>>>> Fine. So I'm offering to put text in that describes how >> to interact >>>>> with the high speed middle. >>>>> >>>>> Here's the problem. If I am building an end to end >>>> capability, it has >>>>> to work through both ends *and* the high speed middle. RFC >>>> 4594 and RFC >>>>> 5127 are complimentary here: RFC 4594 describes classes >> that can be >>>>> used to avoid unfortunate traffic interactions in the low >>>> speed access, >>>>> and RFC 5127 tells how to combine those in the gigabit >> core without >>>>> breaking that. >>>>> >>>>> You are asking me to break that by applying a single DSCP to >>>> the whole >>>>> lot, preventing me from separating video service from voice >>>> service in >>>>> the access, and by using a common service profile for both, >>>> which per >>>>> the considerations of RFC 4594 are known to differ from the >>>>> application's perspective. >>>> >>>> No, re-read my post - I'm agreeing with you. I'm just >> writing down >>>> the thought process I went through to get to where you are. To, >>>> hopefully, help you write the draft in a way people will better >>>> understand. >>>> >>>> My last para: >>>> "So, I think this means PCN has to be a configurable marking for >>>> more than just VOICE-ADMIT. It has to be applicable to all 3 >>>> inelastic media-oriented service classes. >>>> " >>>> >>>> >>>> Bob >>>> >>>> >>>>> I think that breaking the access to simplify things in the >>>> core is very >>>>> silly. >>>>> -----BEGIN PGP SIGNATURE----- >>>>> >>>>> iD8DBQFH2bPebjEdbHIsm0MRAubmAKCXwxbkLfK53VcJHVWsQGBZQak2FgCg91Je >>>>> Z2qOS2YJZcGSi3zh9bfJvUU= >>>>> =c5CD >>>>> -----END PGP SIGNATURE----- >>>> >>>> ______________________________________________________________ >>>> ______________ >>>> Bob Briscoe, Networks Research >>>> Centre, BT Research >>>> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. >>>> +44 1473 645196 >>>> >>>> >>>> >> >> ______________________________________________________________ >> ______________ >> Bob Briscoe, Networks Research >> Centre, BT Research >> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. >> +44 1473 645196 >> >> >> _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Mar 14 09:24:51 2008 Return-Path: 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 7F2543A6B19; Fri, 14 Mar 2008 09:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.647 X-Spam-Level: X-Spam-Status: No, score=-100.647 tagged_above=-999 required=5 tests=[AWL=-0.810, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 2sojUfAIAvQ2; Fri, 14 Mar 2008 09:24:50 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CD773A6800; Fri, 14 Mar 2008 09:24:50 -0700 (PDT) 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 9124C3A6800 for ; Fri, 14 Mar 2008 09:24:48 -0700 (PDT) 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 boSUwjMFJciz for ; Fri, 14 Mar 2008 09:24:42 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9701D28C36E for ; Fri, 14 Mar 2008 09:24:42 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 14 Mar 2008 09:22:25 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m2EGMPi3030544; Fri, 14 Mar 2008 09:22:25 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2EGMPfZ002219; Fri, 14 Mar 2008 16:22:25 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Mar 2008 12:22:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 14 Mar 2008 12:22:22 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: EF-ADMIT & PCN DSCP(s) Thread-Index: AciF7vY2CW5Hs7vfRWmaMQ6Sol9B8wAAB11w From: "Anna Charny (acharny)" To: "Fred Baker (fred)" X-OriginalArrivalTime: 14 Mar 2008 16:22:24.0994 (UTC) FILETIME=[9692CC20:01C885EF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7363; t=1205511745; x=1206375745; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20(acharny)=22=20 |Subject:=20RE=3A=20EF-ADMIT=20&=20PCN=20DSCP(s) |Sender:=20; bh=ReHF7dszN+neFr3HyfFA6WRoxrGJWes7SsdLfdlvOAo=; b=gGuOIRQq5VYXHAfsxLgXis9vusGQiwfZhhNte1XmEUfhFT+53f/thxJnfc rZlbujVLa5i8MrpDu3WYWwonjPmKg6TrWBc6JrlQhKQ3Ce1NnzIdfDvMDFBs fyGm9hZGkE; Authentication-Results: sj-dkim-4; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: PCN IETF list Subject: Re: [PCN] EF-ADMIT & PCN DSCP(s) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org > -----Original Message----- > From: Fred Baker (fred) > Sent: Friday, March 14, 2008 12:18 PM > To: Anna Charny (acharny) > Cc: Bob Briscoe; PCN IETF list > Subject: Re: EF-ADMIT & PCN DSCP(s) > > so we're back to using a DSCP to signal a mechanism instead > of what it is intended to signal, which is a service class? > > I thought we had agreed to use DSCPs for service classes, > which might in turn use or not use the PCN mechanism? I believe we are in violent agreement on the above. I am assuming that the DSCP is used to signal a service class of traffic (with the semantics of EF-Admit as described). And that service class may or may not use PCN mechanism. In particular, it may use it on some hops but not on others. This will work if PCN will not overwrite the DSCP value, which will be the case with the current two-encoding-states proposal. Is there something in what I said that made you think I meant otherwise? Anna > > On Mar 14, 2008, at 12:09 PM, Anna Charny (acharny) wrote: > > > Hi Bob, > > > > OK, so I think we are in agreement. It would not work to use the > > EF-Admit if PCN is using 2 DSCPs. But it would work for > the solution > > with 1 DSCP (and two encoding states). > > > > When 1 DSCP is used for PCN, the end-to-end semantics of EF-Admit > > remains independent of PCN. However, on a "PCN domain hop", PCN > > treatment will be applied to EF-admit to make the admission > decision. > > And that seems perfectly OK. > > > > It (PCN domain hop) also can make a termination decision > though - does > > this create any issue with the end-to-end semantics of EF-Admit? > > > > Right? > > Anna > > > >> -----Original Message----- > >> From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > >> Sent: Friday, March 14, 2008 11:46 AM > >> To: Anna Charny (acharny) > >> Cc: PCN IETF list; Fred Baker (fred) > >> Subject: RE: EF-ADMIT & PCN DSCP(s) > >> > >> Anna, > >> > >> [Copying this to the PCN list.] > >> > >> I'm assuming PCN marking is applied to all the inelastic > classes as a > >> PHB group without re-marking their DSCP. So VOICE-ADMIT > would just be > >> one of the DSCPs that PCN would be configured to apply to. > >> > >> If the DSCP was already set to one of the inelastic > classes the PCN > >> ingress would preserve it (assuming appropriate > authorisation for the > >> flow). Otherwise, it would remark the DSCP to whichever of the (3) > >> inelastic DSCPs was most appropriate. But the PCN domain > would treat > >> all three DSCPs the same - both for scheduling and for PCN marking. > >> > >> However, this only works simply if we don't use a second DSCP for > >> re-marking (the experimental encoding). > >> > >> For the non-SM experiments, we'll have to use 3 local DSCPs to map > >> the possible 3 inelastic DSCPs. If the expt is successful and > >> operators want PCN, that makes the argument even stronger > for fixing > >> ECN tunnelling so we can use the two ECT codepoints > separately rather > >> than 2n DSCPs where n = 3. > >> > >> For MPLS, DSCPs are effectively tunneled, so there's not a problem > >> mapping all 3 DSCPs to one (EF-ADMIT) over the MPLS > domains (except > >> of course for the severe shortage of codepoints). > >> > >> > >> Bob > >> > >> At 14:56 14/03/2008, Anna Charny (acharny) wrote: > >>> Bob, > >>> > >>> I suddenly got confused. I understand I think how using > >> ED-Admit will > >>> work as long as we are using only one DSCP. But if we > >> remark ED-admit > >>> when we start using the second DSCP, then in order to > preserve the > >>> end-to-end semantics of EF-Admit we would need to restore > >> the DSCP at > >>> the egress. > >>> > >>> If we then say that we can use PCN treatment for OTHER > >> traffic classes > >>> - then how do we know at the egress when we do and do > not need to > >>> restore the EF-Admit marking? > >>> > >>> Or do I misunderstand what you are saying? > >>> > >>> Anna > >>> > >>>> -----Original Message----- > >>>> From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > >>>> Sent: Friday, March 14, 2008 10:16 AM > >>>> To: Fred Baker (fred) > >>>> Cc: Anna Charny (acharny); Toby MONCASTER; Phil EARDLEY; > >>>> tsvwg-chairs@tools.ietf.org; CHAN, Kwok Ho; Georgios Karagiannis > >>>> Subject: Re: EF-ADMIT & PCN DSCP(s) > >>>> > >>>> Fred, > >>>> > >>>> At 23:08 13/03/2008, Fred Baker wrote: > >>>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>>> Hash: SHA1 > >>>>> > >>>>> > >>>>> On Mar 13, 2008, at 6:38 PM, Bob Briscoe wrote: > >>>>> > >>>>>> But we can't say "Lower speed access links being the primary > >>>>>> consideration" when we have an e2e path that goes > >> through the fast > >>>>>> middle too. > >>>>> > >>>>> Fine. So I'm offering to put text in that describes how > >> to interact > >>>>> with the high speed middle. > >>>>> > >>>>> Here's the problem. If I am building an end to end > >>>> capability, it has > >>>>> to work through both ends *and* the high speed middle. RFC > >>>> 4594 and RFC > >>>>> 5127 are complimentary here: RFC 4594 describes classes > >> that can be > >>>>> used to avoid unfortunate traffic interactions in the low > >>>> speed access, > >>>>> and RFC 5127 tells how to combine those in the gigabit > >> core without > >>>>> breaking that. > >>>>> > >>>>> You are asking me to break that by applying a single DSCP to > >>>> the whole > >>>>> lot, preventing me from separating video service from voice > >>>> service in > >>>>> the access, and by using a common service profile for both, > >>>> which per > >>>>> the considerations of RFC 4594 are known to differ from the > >>>>> application's perspective. > >>>> > >>>> No, re-read my post - I'm agreeing with you. I'm just > >> writing down > >>>> the thought process I went through to get to where you are. To, > >>>> hopefully, help you write the draft in a way people will better > >>>> understand. > >>>> > >>>> My last para: > >>>> "So, I think this means PCN has to be a configurable marking for > >>>> more than just VOICE-ADMIT. It has to be applicable to all 3 > >>>> inelastic media-oriented service classes. > >>>> " > >>>> > >>>> > >>>> Bob > >>>> > >>>> > >>>>> I think that breaking the access to simplify things in the > >>>> core is very > >>>>> silly. > >>>>> -----BEGIN PGP SIGNATURE----- > >>>>> > >>>>> iD8DBQFH2bPebjEdbHIsm0MRAubmAKCXwxbkLfK53VcJHVWsQGBZQak2FgCg91Je > >>>>> Z2qOS2YJZcGSi3zh9bfJvUU= > >>>>> =c5CD > >>>>> -----END PGP SIGNATURE----- > >>>> > >>>> ______________________________________________________________ > >>>> ______________ > >>>> Bob Briscoe, Networks Research > >>>> Centre, BT Research > >>>> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. > >>>> +44 1473 645196 > >>>> > >>>> > >>>> > >> > >> ______________________________________________________________ > >> ______________ > >> Bob Briscoe, Networks Research > >> Centre, BT Research > >> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. > >> +44 1473 645196 > >> > >> > >> > > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Mar 14 11:33:01 2008 Return-Path: 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 DC1703A67E6; Fri, 14 Mar 2008 11:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.271 X-Spam-Level: X-Spam-Status: No, score=-100.271 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 qtqHl5ov-Pxs; Fri, 14 Mar 2008 11:32:59 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5A2C28C227; Fri, 14 Mar 2008 11:32:52 -0700 (PDT) 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 27FFA3A6F08 for ; Fri, 14 Mar 2008 11:32:51 -0700 (PDT) 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 14U3+7J-qpy5 for ; Fri, 14 Mar 2008 11:32:50 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 2465328C12A for ; Fri, 14 Mar 2008 11:32:02 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id m2EITJd5015495; Fri, 14 Mar 2008 19:29:19 +0100 (MET) Received: from 76.160.222.32 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Fri, 14 Mar 2008 18:29:18 +0000 To: "Steven Blake" , "pcn" Date: Fri, 14 Mar 2008 18:29:18 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <1205506476.2992.34.camel@neutrino> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 14 Mar 2008 19:29:28 +0100 (MET) Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi all Before taking any decisions I would like to emphasize the following. In my opinion preferential dropping of any kind increases the complexity in the interior routers. Furthermore, when excess rate mechanisms are used, by preferentially dropping marked packets it severely decreases the robustness of the PCN domain operation. With robustness I mean, that due to a corner case or due to a msiconfiguration the operation of the PCN domain will completely collapse. This is because the admission control trigger (CLE) at the egress is much more sensistive when marked packets are dropped than either the situation that unmarked and marked packets are dropped randomly (current implementation of routers) or the situation that unmarked packets are dropped. Therefore, as an initial step is better to do not change the current router behaviour from the preferential dropping point of view. Regarding LC-PCN and 3SM operation at the core, the only requirements that have to be supported are: * use current router behaviour from the preferential dropping point of view. Thus drop marked and unmarked packets randomly. Do not preferentially drop marked packets. * use a parameter N (or S) that should be equal in whole PCN domain. The only change in the token bucket implementation will be that the token bucket should mark N packet (or bytes) instead of marking one packet (or byte). Note that if N = 1, then the token bucket operates the same as described in the SM draft. If N > 1, then the SM scheme can operate in the same way with the difference that the measured excess rate at the egress should be multipleied with N. All the other optimization features that are described in the LC-PCN draft are optional. Best regards, Georgios On 3/14/2008, "Steven Blake" wrote: >Greetings. > >There were six concensus questions called during yesterday's PCN >meeting. Before we call the questions on the list, I want to paraphrase >them and make sure that everyone agrees that this captures the sense of >the discussion. > > >Q1: As an initial standardization activity, should the PCN wg produce a > standards-track PCN scheme that requires only two encoding states? > (Note: this question does not presume that the solution is Single > Marking). > >Q2: Should the PCN wg produce an experimental-track extension to the > standards-track PCN scheme that requires another encoding state (for > a total of three encoding states)? > >Q3: Does the working group have enough information to make a decision > about the way forward for the standards-track PCN scheme? > >Q4: Should the standards-track PCN scheme require (as a MUST implement > feature) that interior PCN routers support Excess-Rate marking, > according to the particular method of handling already marked > packets and drops described in Anna Charny's presentation? > http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf > >Q5: Should the standards-track PCN scheme require (as a MUST implement > feature) that interior PCN routers support Threshold marking (in > addition to Excess-Rate marking), according to the particular method > described in Philip Eardley's presentation on Tuesday? > http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf > >Q6: If presented with sufficient evidence in a timely fashion, would > the PCN wg entertain the option of modifying the interior router > Excess-Rate marking behavior for the standards-track PCN scheme (as > described in question 4)? > > >Please send comments to the list. > > >Regards, > >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >Steven Blake >Ericsson/Redback Networks +1 919-472-9913 > >_______________________________________________ >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 From pcn-bounces@ietf.org Fri Mar 14 15:00:41 2008 Return-Path: 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 D0C3328C22A; Fri, 14 Mar 2008 15:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.503 X-Spam-Level: X-Spam-Status: No, score=-99.503 tagged_above=-999 required=5 tests=[AWL=-1.366, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MANGLED_SMALL=2.3, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 OLL-kDjBJN2z; Fri, 14 Mar 2008 15:00:40 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADF0B3A6970; Fri, 14 Mar 2008 15:00:40 -0700 (PDT) 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 53A3F3A6970 for ; Fri, 14 Mar 2008 15:00:40 -0700 (PDT) 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 rucNpzOx8yW5 for ; Fri, 14 Mar 2008 15:00:39 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C1F493A6895 for ; Fri, 14 Mar 2008 15:00:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,502,1199682000"; d="scan'208";a="1825064" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 14 Mar 2008 17:58:21 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m2ELwLDG008292; Fri, 14 Mar 2008 17:58:21 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id m2ELw30R020823; Fri, 14 Mar 2008 21:58:21 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Mar 2008 17:58:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 14 Mar 2008 17:58:01 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciGAZDfkkP7uKpFSiCjK5VExFTMfQAERusw From: "Anna Charny (acharny)" To: "Georgios Karagiannis" , "Steven Blake" , "pcn" X-OriginalArrivalTime: 14 Mar 2008 21:58:07.0095 (UTC) FILETIME=[7C338070:01C8861E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6792; t=1205531901; x=1206395901; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20(acharny)=22=20 |Subject:=20RE=3A=20[PCN]=20Concensus=20questions=20from=20 Thursday's=20PCN=20meeting |Sender:=20 |To:=20=22Georgios=20Karagiannis=22=20,=0A=20=20=20=20=20=20=20=20=22Steven=20Blake=22=20,=20=22pcn=22=20; bh=YGGg+PrlkJmRi8ojPychmfWBRTY4pQ2ByQ0JSoTqKL4=; b=JcusH2fAssW7KKauwKD1tZq5Qp6cpkEtEBqmDPfdEsPmfOXigpb/QYqvuO GHubpR1UxT3OUlb5zO1EsgAuN7oS9/JKT09lQejPJAAQOI6J1XT31BFFwISj PhimIaXFCe; Authentication-Results: rtp-dkim-1; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hello Georgios, A few comments: > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Georgios Karagiannis > Sent: Friday, March 14, 2008 2:29 PM > To: Steven Blake; pcn > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > > Hi all > > Before taking any decisions I would like to emphasize the following. > > In my opinion preferential dropping of any kind increases the > complexity in the interior routers. Yes, that is absolutely true > Furthermore, when excess > rate mechanisms are used, by preferentially dropping marked > packets it severely decreases the robustness of the PCN > domain operation. > With robustness I mean, that due to a corner case or due to a > msiconfiguration the operation of the PCN domain will > completely collapse. > This is because the admission control trigger (CLE) at the > egress is much more sensistive when marked packets are > dropped than either the situation that unmarked and marked > packets are dropped randomly (current implementation of > routers) or the situation that unmarked packets are dropped. Georgios, I do believe this is really quite an exaggeration. In SM, all excess-rate packets will be dropped only if the bottleneck link has admission threshold configured at the link speed. This is certainly not the expected configuration. And SM does not care about absolute amount of marked packets - it only needs to see a small percentage (~1%) of excess rate marks to work, as all of our simulations show. > Therefore, as an initial step is better to do not change the > current router behavior from the preferential dropping point of view. > The proposal as presented is that preferential drop is a SHOULD, not a must. Since it does not preclude interoperability, that is OK. If the preferential drop is not implemented, SM will potentially overterminate more in the case of multiple congested bottlenecks. > Regarding LC-PCN and 3SM operation at the core, the only > requirements that have to be supported are: > > * use current router behavior from the preferential dropping > point of view. No, not really. Performance of 3SM will be slowed down quite substantially if large number of excess-marked packets are dropped. Indeed 3SM is less sensitive to loss preference, however. It does however need 3 encoding states that we do not seem to have, and requires other modifications to the "current router behavior". As to LC-PCN, in the slides you sent to me for the presentation on Thursday you had the following for LC-PCN " [Loss preference] depends on thres.[hold] set[tting]. Typically, prefer not to drop ex[cess]. Rate". Did you change your mind and now believe it is wrong? LC-PCN will also need another modification to the "current router behavior" as it would need to mark only a subset of excess rate packets, which requires a modification to the token bucket. This as you say below is not an optional optimization, but is required for LC-PCN to work. The optional optimization is there to make the algorithm not overterminate. It is to the excitant equally optional as preferential drop for SM - as that too is there to not let SM overterminate :-). > Thus drop marked and unmarked packets randomly. Do not > preferentially drop marked packets. > Again, the proposed approach is to put a SHOULD in the preferential drop requirement. Best, Anna > * use a parameter N (or S) that should be equal in whole PCN domain. > The only change in the token bucket implementation will be > that the token bucket should mark N packet (or bytes) instead > of marking one packet (or byte). Note that if N = 1, then the > token bucket operates the same as described in the SM draft. > If N > 1, then the SM scheme can operate in the same way with > the difference that the measured excess rate at the egress > should be multipleied with N. > > All the other optimization features that are described in the > LC-PCN draft are optional. > > Best regards, > Georgios > > > > > On 3/14/2008, "Steven Blake" wrote: > > >Greetings. > > > >There were six concensus questions called during yesterday's PCN > >meeting. Before we call the questions on the list, I want to > >paraphrase them and make sure that everyone agrees that this > captures > >the sense of the discussion. > > > > > >Q1: As an initial standardization activity, should the PCN > wg produce a > > standards-track PCN scheme that requires only two > encoding states? > > (Note: this question does not presume that the solution is Single > > Marking). > > > >Q2: Should the PCN wg produce an experimental-track extension to the > > standards-track PCN scheme that requires another > encoding state (for > > a total of three encoding states)? > > > >Q3: Does the working group have enough information to make a decision > > about the way forward for the standards-track PCN scheme? > > > >Q4: Should the standards-track PCN scheme require (as a MUST > implement > > feature) that interior PCN routers support Excess-Rate marking, > > according to the particular method of handling already marked > > packets and drops described in Anna Charny's presentation? > > http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf > > > >Q5: Should the standards-track PCN scheme require (as a MUST > implement > > feature) that interior PCN routers support Threshold marking (in > > addition to Excess-Rate marking), according to the > particular method > > described in Philip Eardley's presentation on Tuesday? > > http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf > > > >Q6: If presented with sufficient evidence in a timely fashion, would > > the PCN wg entertain the option of modifying the interior router > > Excess-Rate marking behavior for the standards-track PCN > scheme (as > > described in question 4)? > > > > > >Please send comments to the list. > > > > > >Regards, > > > >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > >Steven Blake > >Ericsson/Redback Networks +1 919-472-9913 > > > >_______________________________________________ > >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 > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sun Mar 16 11:47:39 2008 Return-Path: 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 706FE3A6BAF; Sun, 16 Mar 2008 11:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.091 X-Spam-Level: X-Spam-Status: No, score=-100.091 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 LvoHRPGcpxvQ; Sun, 16 Mar 2008 11:47:38 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 828473A6941; Sun, 16 Mar 2008 11:47:38 -0700 (PDT) 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 39B883A68E9 for ; Sun, 16 Mar 2008 11:47:38 -0700 (PDT) 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 e4R-BIL7YFzE for ; Sun, 16 Mar 2008 11:47:37 -0700 (PDT) Received: from smtp106.rog.mail.re2.yahoo.com (smtp106.rog.mail.re2.yahoo.com [68.142.225.204]) by core3.amsl.com (Postfix) with SMTP id 4CC263A682F for ; Sun, 16 Mar 2008 11:47:36 -0700 (PDT) Received: (qmail 58408 invoked from network); 16 Mar 2008 18:45:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=OfWmS5cLLzTS8lcoATq+c9moKf0Vh730AqhIQx1uQk5myT6i0taWsqsEnQowJ/wEP77nbBNzPcYmvRBziE/8nrdeqHAj3Jauf3tBv2sJym6um0nsF/WPEn73yJSDuPLZ8fnZVPmJ+5l0lc97qU4tHMfdjpn/cbibWzR7JthSwQM= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@rogers.com@72.140.46.24 with plain) by smtp106.rog.mail.re2.yahoo.com with SMTP; 16 Mar 2008 18:45:20 -0000 X-YMail-OSG: nqKAbfUVM1mZ0wUz0M6lXUo3d3lGTBT_4BK0Zfo7ProrcBoK9lOAazboNNTTS5V6Xg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <47DD6AC2.7080209@rogers.com> Date: Sun, 16 Mar 2008 14:45:22 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: pcn , Michael Menth Subject: [PCN] CLEBAC vs. OBAC X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Michael, in your presentation you distinguished between Congestion Level Based Admission Control (CLEBAC) and Observation Based Admission Control (OBAC). CLEBAC uses a ratio estimate of congestion level, while OBAC is based on observation of one or more marked packets in an interval. Looking at your charts, I note that overall, OBAC provides a higher probability at any level that a given flow will be blocked (not admitted). Looking at the desirable effects, we see that although CLEBAC results in distinctly less unnecessary blocking at lower traffic levels, OBAC results in less over-admission at high traffic levels. Do you think the latter difference is significant? If so, we may want to define regimes where CLEBAC respectively OBAC operate. Tom Taylor _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sun Mar 16 18:32:59 2008 Return-Path: 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 7B3863A6AD1; Sun, 16 Mar 2008 18:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.89 X-Spam-Level: X-Spam-Status: No, score=-100.89 tagged_above=-999 required=5 tests=[AWL=-0.453, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 0ZWAxB4D1Fzf; Sun, 16 Mar 2008 18:32:58 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9555A3A6B39; Sun, 16 Mar 2008 18:32:58 -0700 (PDT) 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 E3AFF3A693A for ; Sun, 16 Mar 2008 18:32:57 -0700 (PDT) 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 G5onHJN46nYW for ; Sun, 16 Mar 2008 18:32:56 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id A73533A690B for ; Sun, 16 Mar 2008 18:32:54 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 7789AA1BE7; Mon, 17 Mar 2008 02:30:37 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 6A8E9A0723; Mon, 17 Mar 2008 02:30:37 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 7D0EEA060E; Mon, 17 Mar 2008 02:30:32 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m2H1UWV25738; Mon, 17 Mar 2008 02:30:32 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 1135FC88BE; Mon, 17 Mar 2008 02:30:30 +0100 (CET) Message-ID: <47DDC980.1060600@informatik.uni-wuerzburg.de> Date: Mon, 17 Mar 2008 02:29:36 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Tom Taylor References: <47DD6AC2.7080209@rogers.com> In-Reply-To: <47DD6AC2.7080209@rogers.com> Content-Type: multipart/mixed; boundary="------------070108040208030603020806" X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn Subject: Re: [PCN] CLEBAC vs. OBAC X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --------------070108040208030603020806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Tom, Tom Taylor wrote: > Michael, in your presentation you distinguished between Congestion > Level Based Admission Control (CLEBAC) and Observation Based Admission > Control (OBAC). CLEBAC uses a ratio estimate of congestion level, > while OBAC is based on observation of one or more marked packets in an > interval. You refer to http://www.ietf.org/proceedings/08mar/slides/pcn-8.pdf > > Looking at your charts, I note that overall, OBAC provides a higher > probability at any level that a given flow will be blocked (not > admitted). Yes, that must be the case. > Looking at the desirable effects, we see that although CLEBAC results > in distinctly less unnecessary blocking at lower traffic levels, OBAC > results in less over-admission at high traffic levels. Do you think > the latter difference is significant? It can be significant when PCN is used for what it is not made for: low ingress-egress aggregation. I don't say that this is a corner case or not interesting, but it is a case where PCN has problems. If you want to go to as small ingress-egress aggregates as possible, then OBAC might be a solution for such scenarios to mitigate the effect of false admission, but it cannot solve them. > If so, we may want to define regimes where CLEBAC respectively OBAC > operate. I don't think that it is possible or desirable to have both CLEBAC and OBAC to control the same ingress-egress aggregate. The large number of false negatives for OBAC disappear as soon as the token bucket size is set to larger values (see attached file), but it also delays the reaction of OBAC since it takes longer until marked feedback arrives when the admissible rate on a link is exceeded. Well, those are tradeoffs. Just to make it clear: I think that the major benefit of OBAC compared to CLEBAC is its fast reaction time which may be helpful in case of flashcrowds where you need a fast reaction and don't want to wait 1-2 measurement intervals which is needed in case of CLEBAC. Regards, Michael Menth > > Tom Taylor -- 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 --------------070108040208030603020806 Content-Type: application/postscript; name="AStop_OBAC_Exhaustive_EB=1000_minAStopTime.eps" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="AStop_OBAC_Exhaustive_EB=1000_minAStopTime.eps" JSFQUy1BZG9iZS0yLjAgRVBTRi0yLjANCiUlVGl0bGU6IEFTdG9wX09CQUNfRXhoYXVzdGl2 ZV9FQj0xMDAwX21pbkFTdG9wVGltZS5lcHMNCiUlQ3JlYXRvcjogZ251cGxvdCA0LjIgcGF0 Y2hsZXZlbCAyIA0KJSVDcmVhdGlvbkRhdGU6IFN1biBNYXIgMTYgMjA6MDE6NDcgMjAwOA0K JSVEb2N1bWVudEZvbnRzOiAoYXRlbmQpDQolJUJvdW5kaW5nQm94OiA1MCA1MCA0MTAgMzAy DQolJUVuZENvbW1lbnRzDQolJUJlZ2luUHJvbG9nDQovZ251ZGljdCAyNTYgZGljdCBkZWYN CmdudWRpY3QgYmVnaW4NCiUNCiUgVGhlIGZvbGxvd2luZyA2IHRydWUvZmFsc2UgZmxhZ3Mg bWF5IGJlIGVkaXRlZCBieSBoYW5kIGlmIHJlcXVpcmVkDQolIFRoZSB1bml0IGxpbmUgd2lk dGggbWF5IGFsc28gYmUgY2hhbmdlZA0KJQ0KL0NvbG9yIGZhbHNlIGRlZg0KL0JsYWNrdGV4 dCBmYWxzZSBkZWYNCi9Tb2xpZCBmYWxzZSBkZWYNCi9EYXNobGVuZ3RoIDIgZGVmDQovTGFu ZHNjYXBlIGZhbHNlIGRlZg0KL0xldmVsMSBmYWxzZSBkZWYNCi9Sb3VuZGVkIGZhbHNlIGRl Zg0KL1RyYW5zcGFyZW50UGF0dGVybnMgZmFsc2UgZGVmDQovZ251bGluZXdpZHRoIDUuMDAw IGRlZg0KL3VzZXJsaW5ld2lkdGggZ251bGluZXdpZHRoIGRlZg0KJQ0KL3ZzaGlmdCAtNzMg ZGVmDQovZGwxIHsNCiAgMTAuMCBEYXNobGVuZ3RoIG11bCBtdWwNCiAgUm91bmRlZCB7IGN1 cnJlbnRsaW5ld2lkdGggMC43NSBtdWwgc3ViIGR1cCAwIGxlIHsgcG9wIDAuMDEgfSBpZiB9 IGlmDQp9IGRlZg0KL2RsMiB7DQogIDEwLjAgRGFzaGxlbmd0aCBtdWwgbXVsDQogIFJvdW5k ZWQgeyBjdXJyZW50bGluZXdpZHRoIDAuNzUgbXVsIGFkZCB9IGlmDQp9IGRlZg0KL2hwdF8g MzEuNSBkZWYNCi92cHRfIDMxLjUgZGVmDQovaHB0IGhwdF8gZGVmDQovdnB0IHZwdF8gZGVm DQpMZXZlbDEge30gew0KL1NEaWN0IDEwIGRpY3QgZGVmDQpzeXN0ZW1kaWN0IC9wZGZtYXJr IGtub3duIG5vdCB7DQogIHVzZXJkaWN0IC9wZGZtYXJrIHN5c3RlbWRpY3QgL2NsZWFydG9t YXJrIGdldCBwdXQNCn0gaWYNClNEaWN0IGJlZ2luIFsNCiAgL1RpdGxlIChBU3RvcF9PQkFD X0V4aGF1c3RpdmVfRUI9MTAwMF9taW5BU3RvcFRpbWUuZXBzKQ0KICAvU3ViamVjdCAoZ251 cGxvdCBwbG90KQ0KICAvQ3JlYXRvciAoZ251cGxvdCA0LjIgcGF0Y2hsZXZlbCAyICkNCiAg L0F1dGhvciAoRnJhbmsgTGVocmllZGVyKQ0KJSAgL1Byb2R1Y2VyIChnbnVwbG90KQ0KJSAg L0tleXdvcmRzICgpDQogIC9DcmVhdGlvbkRhdGUgKFN1biBNYXIgMTYgMjA6MDE6NDcgMjAw OCkNCiAgL0RPQ0lORk8gcGRmbWFyaw0KZW5kDQp9IGlmZWxzZQ0KJQ0KJSBHbnVwbG90IFBy b2xvZyBWZXJzaW9uIDQuMiAoQXVndXN0IDIwMDYpDQolDQovTSB7bW92ZXRvfSBiaW5kIGRl Zg0KL0wge2xpbmV0b30gYmluZCBkZWYNCi9SIHtybW92ZXRvfSBiaW5kIGRlZg0KL1Yge3Js aW5ldG99IGJpbmQgZGVmDQovTiB7bmV3cGF0aCBtb3ZldG99IGJpbmQgZGVmDQovWiB7Y2xv c2VwYXRofSBiaW5kIGRlZg0KL0Mge3NldHJnYmNvbG9yfSBiaW5kIGRlZg0KL2Yge3JsaW5l dG8gZmlsbH0gYmluZCBkZWYNCi92cHQyIHZwdCAyIG11bCBkZWYNCi9ocHQyIGhwdCAyIG11 bCBkZWYNCi9Mc2hvdyB7Y3VycmVudHBvaW50IHN0cm9rZSBNIDAgdnNoaWZ0IFIgDQoJQmxh Y2t0ZXh0IHtnc2F2ZSAwIHNldGdyYXkgc2hvdyBncmVzdG9yZX0ge3Nob3d9IGlmZWxzZX0g ZGVmDQovUnNob3cge2N1cnJlbnRwb2ludCBzdHJva2UgTSBkdXAgc3RyaW5nd2lkdGggcG9w IG5lZyB2c2hpZnQgUg0KCUJsYWNrdGV4dCB7Z3NhdmUgMCBzZXRncmF5IHNob3cgZ3Jlc3Rv cmV9IHtzaG93fSBpZmVsc2V9IGRlZg0KL0NzaG93IHtjdXJyZW50cG9pbnQgc3Ryb2tlIE0g ZHVwIHN0cmluZ3dpZHRoIHBvcCAtMiBkaXYgdnNoaWZ0IFIgDQoJQmxhY2t0ZXh0IHtnc2F2 ZSAwIHNldGdyYXkgc2hvdyBncmVzdG9yZX0ge3Nob3d9IGlmZWxzZX0gZGVmDQovVVAge2R1 cCB2cHRfIG11bCAvdnB0IGV4Y2ggZGVmIGhwdF8gbXVsIC9ocHQgZXhjaCBkZWYNCiAgL2hw dDIgaHB0IDIgbXVsIGRlZiAvdnB0MiB2cHQgMiBtdWwgZGVmfSBkZWYNCi9ETCB7Q29sb3Ig e3NldHJnYmNvbG9yIFNvbGlkIHtwb3AgW119IGlmIDAgc2V0ZGFzaH0NCiB7cG9wIHBvcCBw b3AgMCBzZXRncmF5IFNvbGlkIHtwb3AgW119IGlmIDAgc2V0ZGFzaH0gaWZlbHNlfSBkZWYN Ci9CTCB7c3Ryb2tlIHVzZXJsaW5ld2lkdGggMiBtdWwgc2V0bGluZXdpZHRoDQoJUm91bmRl ZCB7MSBzZXRsaW5lam9pbiAxIHNldGxpbmVjYXB9IGlmfSBkZWYNCi9BTCB7c3Ryb2tlIHVz ZXJsaW5ld2lkdGggMiBkaXYgc2V0bGluZXdpZHRoDQoJUm91bmRlZCB7MSBzZXRsaW5lam9p biAxIHNldGxpbmVjYXB9IGlmfSBkZWYNCi9VTCB7ZHVwIGdudWxpbmV3aWR0aCBtdWwgL3Vz ZXJsaW5ld2lkdGggZXhjaCBkZWYNCglkdXAgMSBsdCB7cG9wIDF9IGlmIDEwIG11bCAvdWRs IGV4Y2ggZGVmfSBkZWYNCi9QTCB7c3Ryb2tlIHVzZXJsaW5ld2lkdGggc2V0bGluZXdpZHRo DQoJUm91bmRlZCB7MSBzZXRsaW5lam9pbiAxIHNldGxpbmVjYXB9IGlmfSBkZWYNCiUgRGVm YXVsdCBMaW5lIGNvbG9ycw0KL0xDdyB7MSAxIDF9IGRlZg0KL0xDYiB7MCAwIDB9IGRlZg0K L0xDYSB7MCAwIDB9IGRlZg0KL0xDMCB7MSAwIDB9IGRlZg0KL0xDMSB7MCAxIDB9IGRlZg0K L0xDMiB7MCAwIDF9IGRlZg0KL0xDMyB7MSAwIDF9IGRlZg0KL0xDNCB7MCAxIDF9IGRlZg0K L0xDNSB7MSAxIDB9IGRlZg0KL0xDNiB7MCAwIDB9IGRlZg0KL0xDNyB7MSAwLjMgMH0gZGVm DQovTEM4IHswLjUgMC41IDAuNX0gZGVmDQolIERlZmF1bHQgTGluZSBUeXBlcw0KL0xUdyB7 UEwgW10gMSBzZXRncmF5fSBkZWYNCi9MVGIge0JMIFtdIExDYiBETH0gZGVmDQovTFRhIHtB TCBbMSB1ZGwgbXVsIDIgdWRsIG11bF0gMCBzZXRkYXNoIExDYSBzZXRyZ2Jjb2xvcn0gZGVm DQovTFQwIHtQTCBbXSBMQzAgREx9IGRlZg0KL0xUMSB7UEwgWzQgZGwxIDIgZGwyXSBMQzEg REx9IGRlZg0KL0xUMiB7UEwgWzIgZGwxIDMgZGwyXSBMQzIgREx9IGRlZg0KL0xUMyB7UEwg WzEgZGwxIDEuNSBkbDJdIExDMyBETH0gZGVmDQovTFQ0IHtQTCBbNiBkbDEgMiBkbDIgMSBk bDEgMiBkbDJdIExDNCBETH0gZGVmDQovTFQ1IHtQTCBbMyBkbDEgMyBkbDIgMSBkbDEgMyBk bDJdIExDNSBETH0gZGVmDQovTFQ2IHtQTCBbMiBkbDEgMiBkbDIgMiBkbDEgNiBkbDJdIExD NiBETH0gZGVmDQovTFQ3IHtQTCBbMSBkbDEgMiBkbDIgNiBkbDEgMiBkbDIgMSBkbDEgMiBk bDJdIExDNyBETH0gZGVmDQovTFQ4IHtQTCBbMiBkbDEgMiBkbDIgMiBkbDEgMiBkbDIgMiBk bDEgMiBkbDIgMiBkbDEgNCBkbDJdIExDOCBETH0gZGVmDQovUG50IHtzdHJva2UgW10gMCBz ZXRkYXNoIGdzYXZlIDEgc2V0bGluZWNhcCBNIDAgMCBWIHN0cm9rZSBncmVzdG9yZX0gZGVm DQovRGlhIHtzdHJva2UgW10gMCBzZXRkYXNoIDIgY29weSB2cHQgYWRkIE0NCiAgaHB0IG5l ZyB2cHQgbmVnIFYgaHB0IHZwdCBuZWcgVg0KICBocHQgdnB0IFYgaHB0IG5lZyB2cHQgViBj bG9zZXBhdGggc3Ryb2tlDQogIFBudH0gZGVmDQovUGxzIHtzdHJva2UgW10gMCBzZXRkYXNo IHZwdCBzdWIgTSAwIHZwdDIgVg0KICBjdXJyZW50cG9pbnQgc3Ryb2tlIE0NCiAgaHB0IG5l ZyB2cHQgbmVnIFIgaHB0MiAwIFYgc3Ryb2tlDQogfSBkZWYNCi9Cb3gge3N0cm9rZSBbXSAw IHNldGRhc2ggMiBjb3B5IGV4Y2ggaHB0IHN1YiBleGNoIHZwdCBhZGQgTQ0KICAwIHZwdDIg bmVnIFYgaHB0MiAwIFYgMCB2cHQyIFYNCiAgaHB0MiBuZWcgMCBWIGNsb3NlcGF0aCBzdHJv a2UNCiAgUG50fSBkZWYNCi9DcnMge3N0cm9rZSBbXSAwIHNldGRhc2ggZXhjaCBocHQgc3Vi IGV4Y2ggdnB0IGFkZCBNDQogIGhwdDIgdnB0MiBuZWcgViBjdXJyZW50cG9pbnQgc3Ryb2tl IE0NCiAgaHB0MiBuZWcgMCBSIGhwdDIgdnB0MiBWIHN0cm9rZX0gZGVmDQovVHJpVSB7c3Ry b2tlIFtdIDAgc2V0ZGFzaCAyIGNvcHkgdnB0IDEuMTIgbXVsIGFkZCBNDQogIGhwdCBuZWcg dnB0IC0xLjYyIG11bCBWDQogIGhwdCAyIG11bCAwIFYNCiAgaHB0IG5lZyB2cHQgMS42MiBt dWwgViBjbG9zZXBhdGggc3Ryb2tlDQogIFBudH0gZGVmDQovU3RhciB7MiBjb3B5IFBscyBD cnN9IGRlZg0KL0JveEYge3N0cm9rZSBbXSAwIHNldGRhc2ggZXhjaCBocHQgc3ViIGV4Y2gg dnB0IGFkZCBNDQogIDAgdnB0MiBuZWcgViBocHQyIDAgViAwIHZwdDIgVg0KICBocHQyIG5l ZyAwIFYgY2xvc2VwYXRoIGZpbGx9IGRlZg0KL1RyaVVGIHtzdHJva2UgW10gMCBzZXRkYXNo IHZwdCAxLjEyIG11bCBhZGQgTQ0KICBocHQgbmVnIHZwdCAtMS42MiBtdWwgVg0KICBocHQg MiBtdWwgMCBWDQogIGhwdCBuZWcgdnB0IDEuNjIgbXVsIFYgY2xvc2VwYXRoIGZpbGx9IGRl Zg0KL1RyaUQge3N0cm9rZSBbXSAwIHNldGRhc2ggMiBjb3B5IHZwdCAxLjEyIG11bCBzdWIg TQ0KICBocHQgbmVnIHZwdCAxLjYyIG11bCBWDQogIGhwdCAyIG11bCAwIFYNCiAgaHB0IG5l ZyB2cHQgLTEuNjIgbXVsIFYgY2xvc2VwYXRoIHN0cm9rZQ0KICBQbnR9IGRlZg0KL1RyaURG IHtzdHJva2UgW10gMCBzZXRkYXNoIHZwdCAxLjEyIG11bCBzdWIgTQ0KICBocHQgbmVnIHZw dCAxLjYyIG11bCBWDQogIGhwdCAyIG11bCAwIFYNCiAgaHB0IG5lZyB2cHQgLTEuNjIgbXVs IFYgY2xvc2VwYXRoIGZpbGx9IGRlZg0KL0RpYUYge3N0cm9rZSBbXSAwIHNldGRhc2ggdnB0 IGFkZCBNDQogIGhwdCBuZWcgdnB0IG5lZyBWIGhwdCB2cHQgbmVnIFYNCiAgaHB0IHZwdCBW IGhwdCBuZWcgdnB0IFYgY2xvc2VwYXRoIGZpbGx9IGRlZg0KL1BlbnQge3N0cm9rZSBbXSAw IHNldGRhc2ggMiBjb3B5IGdzYXZlDQogIHRyYW5zbGF0ZSAwIGhwdCBNIDQgezcyIHJvdGF0 ZSAwIGhwdCBMfSByZXBlYXQNCiAgY2xvc2VwYXRoIHN0cm9rZSBncmVzdG9yZSBQbnR9IGRl Zg0KL1BlbnRGIHtzdHJva2UgW10gMCBzZXRkYXNoIGdzYXZlDQogIHRyYW5zbGF0ZSAwIGhw dCBNIDQgezcyIHJvdGF0ZSAwIGhwdCBMfSByZXBlYXQNCiAgY2xvc2VwYXRoIGZpbGwgZ3Jl c3RvcmV9IGRlZg0KL0NpcmNsZSB7c3Ryb2tlIFtdIDAgc2V0ZGFzaCAyIGNvcHkNCiAgaHB0 IDAgMzYwIGFyYyBzdHJva2UgUG50fSBkZWYNCi9DaXJjbGVGIHtzdHJva2UgW10gMCBzZXRk YXNoIGhwdCAwIDM2MCBhcmMgZmlsbH0gZGVmDQovQzAge0JMIFtdIDAgc2V0ZGFzaCAyIGNv cHkgbW92ZXRvIHZwdCA5MCA0NTAgYXJjfSBiaW5kIGRlZg0KL0MxIHtCTCBbXSAwIHNldGRh c2ggMiBjb3B5IG1vdmV0bw0KCTIgY29weSB2cHQgMCA5MCBhcmMgY2xvc2VwYXRoIGZpbGwN Cgl2cHQgMCAzNjAgYXJjIGNsb3NlcGF0aH0gYmluZCBkZWYNCi9DMiB7QkwgW10gMCBzZXRk YXNoIDIgY29weSBtb3ZldG8NCgkyIGNvcHkgdnB0IDkwIDE4MCBhcmMgY2xvc2VwYXRoIGZp bGwNCgl2cHQgMCAzNjAgYXJjIGNsb3NlcGF0aH0gYmluZCBkZWYNCi9DMyB7QkwgW10gMCBz ZXRkYXNoIDIgY29weSBtb3ZldG8NCgkyIGNvcHkgdnB0IDAgMTgwIGFyYyBjbG9zZXBhdGgg ZmlsbA0KCXZwdCAwIDM2MCBhcmMgY2xvc2VwYXRofSBiaW5kIGRlZg0KL0M0IHtCTCBbXSAw IHNldGRhc2ggMiBjb3B5IG1vdmV0bw0KCTIgY29weSB2cHQgMTgwIDI3MCBhcmMgY2xvc2Vw YXRoIGZpbGwNCgl2cHQgMCAzNjAgYXJjIGNsb3NlcGF0aH0gYmluZCBkZWYNCi9DNSB7Qkwg W10gMCBzZXRkYXNoIDIgY29weSBtb3ZldG8NCgkyIGNvcHkgdnB0IDAgOTAgYXJjDQoJMiBj b3B5IG1vdmV0bw0KCTIgY29weSB2cHQgMTgwIDI3MCBhcmMgY2xvc2VwYXRoIGZpbGwNCgl2 cHQgMCAzNjAgYXJjfSBiaW5kIGRlZg0KL0M2IHtCTCBbXSAwIHNldGRhc2ggMiBjb3B5IG1v dmV0bw0KCTIgY29weSB2cHQgOTAgMjcwIGFyYyBjbG9zZXBhdGggZmlsbA0KCXZwdCAwIDM2 MCBhcmMgY2xvc2VwYXRofSBiaW5kIGRlZg0KL0M3IHtCTCBbXSAwIHNldGRhc2ggMiBjb3B5 IG1vdmV0bw0KCTIgY29weSB2cHQgMCAyNzAgYXJjIGNsb3NlcGF0aCBmaWxsDQoJdnB0IDAg MzYwIGFyYyBjbG9zZXBhdGh9IGJpbmQgZGVmDQovQzgge0JMIFtdIDAgc2V0ZGFzaCAyIGNv cHkgbW92ZXRvDQoJMiBjb3B5IHZwdCAyNzAgMzYwIGFyYyBjbG9zZXBhdGggZmlsbA0KCXZw dCAwIDM2MCBhcmMgY2xvc2VwYXRofSBiaW5kIGRlZg0KL0M5IHtCTCBbXSAwIHNldGRhc2gg MiBjb3B5IG1vdmV0bw0KCTIgY29weSB2cHQgMjcwIDQ1MCBhcmMgY2xvc2VwYXRoIGZpbGwN Cgl2cHQgMCAzNjAgYXJjIGNsb3NlcGF0aH0gYmluZCBkZWYNCi9DMTAge0JMIFtdIDAgc2V0 ZGFzaCAyIGNvcHkgMiBjb3B5IG1vdmV0byB2cHQgMjcwIDM2MCBhcmMgY2xvc2VwYXRoIGZp bGwNCgkyIGNvcHkgbW92ZXRvDQoJMiBjb3B5IHZwdCA5MCAxODAgYXJjIGNsb3NlcGF0aCBm aWxsDQoJdnB0IDAgMzYwIGFyYyBjbG9zZXBhdGh9IGJpbmQgZGVmDQovQzExIHtCTCBbXSAw IHNldGRhc2ggMiBjb3B5IG1vdmV0bw0KCTIgY29weSB2cHQgMCAxODAgYXJjIGNsb3NlcGF0 aCBmaWxsDQoJMiBjb3B5IG1vdmV0bw0KCTIgY29weSB2cHQgMjcwIDM2MCBhcmMgY2xvc2Vw YXRoIGZpbGwNCgl2cHQgMCAzNjAgYXJjIGNsb3NlcGF0aH0gYmluZCBkZWYNCi9DMTIge0JM IFtdIDAgc2V0ZGFzaCAyIGNvcHkgbW92ZXRvDQoJMiBjb3B5IHZwdCAxODAgMzYwIGFyYyBj bG9zZXBhdGggZmlsbA0KCXZwdCAwIDM2MCBhcmMgY2xvc2VwYXRofSBiaW5kIGRlZg0KL0Mx MyB7QkwgW10gMCBzZXRkYXNoIDIgY29weSBtb3ZldG8NCgkyIGNvcHkgdnB0IDAgOTAgYXJj IGNsb3NlcGF0aCBmaWxsDQoJMiBjb3B5IG1vdmV0bw0KCTIgY29weSB2cHQgMTgwIDM2MCBh cmMgY2xvc2VwYXRoIGZpbGwNCgl2cHQgMCAzNjAgYXJjIGNsb3NlcGF0aH0gYmluZCBkZWYN Ci9DMTQge0JMIFtdIDAgc2V0ZGFzaCAyIGNvcHkgbW92ZXRvDQoJMiBjb3B5IHZwdCA5MCAz NjAgYXJjIGNsb3NlcGF0aCBmaWxsDQoJdnB0IDAgMzYwIGFyY30gYmluZCBkZWYNCi9DMTUg e0JMIFtdIDAgc2V0ZGFzaCAyIGNvcHkgdnB0IDAgMzYwIGFyYyBjbG9zZXBhdGggZmlsbA0K CXZwdCAwIDM2MCBhcmMgY2xvc2VwYXRofSBiaW5kIGRlZg0KL1JlYyB7bmV3cGF0aCA0IDIg cm9sbCBtb3ZldG8gMSBpbmRleCAwIHJsaW5ldG8gMCBleGNoIHJsaW5ldG8NCgluZWcgMCBy bGluZXRvIGNsb3NlcGF0aH0gYmluZCBkZWYNCi9TcXVhcmUge2R1cCBSZWN9IGJpbmQgZGVm DQovQnNxdWFyZSB7dnB0IHN1YiBleGNoIHZwdCBzdWIgZXhjaCB2cHQyIFNxdWFyZX0gYmlu ZCBkZWYNCi9TMCB7QkwgW10gMCBzZXRkYXNoIDIgY29weSBtb3ZldG8gMCB2cHQgcmxpbmV0 byBCTCBCc3F1YXJlfSBiaW5kIGRlZg0KL1MxIHtCTCBbXSAwIHNldGRhc2ggMiBjb3B5IHZw dCBTcXVhcmUgZmlsbCBCc3F1YXJlfSBiaW5kIGRlZg0KL1MyIHtCTCBbXSAwIHNldGRhc2gg MiBjb3B5IGV4Y2ggdnB0IHN1YiBleGNoIHZwdCBTcXVhcmUgZmlsbCBCc3F1YXJlfSBiaW5k IGRlZg0KL1MzIHtCTCBbXSAwIHNldGRhc2ggMiBjb3B5IGV4Y2ggdnB0IHN1YiBleGNoIHZw dDIgdnB0IFJlYyBmaWxsIEJzcXVhcmV9IGJpbmQgZGVmDQovUzQge0JMIFtdIDAgc2V0ZGFz aCAyIGNvcHkgZXhjaCB2cHQgc3ViIGV4Y2ggdnB0IHN1YiB2cHQgU3F1YXJlIGZpbGwgQnNx dWFyZX0gYmluZCBkZWYNCi9TNSB7QkwgW10gMCBzZXRkYXNoIDIgY29weSAyIGNvcHkgdnB0 IFNxdWFyZSBmaWxsDQoJZXhjaCB2cHQgc3ViIGV4Y2ggdnB0IHN1YiB2cHQgU3F1YXJlIGZp bGwgQnNxdWFyZX0gYmluZCBkZWYNCi9TNiB7QkwgW10gMCBzZXRkYXNoIDIgY29weSBleGNo IHZwdCBzdWIgZXhjaCB2cHQgc3ViIHZwdCB2cHQyIFJlYyBmaWxsIEJzcXVhcmV9IGJpbmQg ZGVmDQovUzcge0JMIFtdIDAgc2V0ZGFzaCAyIGNvcHkgZXhjaCB2cHQgc3ViIGV4Y2ggdnB0 IHN1YiB2cHQgdnB0MiBSZWMgZmlsbA0KCTIgY29weSB2cHQgU3F1YXJlIGZpbGwgQnNxdWFy ZX0gYmluZCBkZWYNCi9TOCB7QkwgW10gMCBzZXRkYXNoIDIgY29weSB2cHQgc3ViIHZwdCBT cXVhcmUgZmlsbCBCc3F1YXJlfSBiaW5kIGRlZg0KL1M5IHtCTCBbXSAwIHNldGRhc2ggMiBj b3B5IHZwdCBzdWIgdnB0IHZwdDIgUmVjIGZpbGwgQnNxdWFyZX0gYmluZCBkZWYNCi9TMTAg e0JMIFtdIDAgc2V0ZGFzaCAyIGNvcHkgdnB0IHN1YiB2cHQgU3F1YXJlIGZpbGwgMiBjb3B5 IGV4Y2ggdnB0IHN1YiBleGNoIHZwdCBTcXVhcmUgZmlsbA0KCUJzcXVhcmV9IGJpbmQgZGVm DQovUzExIHtCTCBbXSAwIHNldGRhc2ggMiBjb3B5IHZwdCBzdWIgdnB0IFNxdWFyZSBmaWxs IDIgY29weSBleGNoIHZwdCBzdWIgZXhjaCB2cHQyIHZwdCBSZWMgZmlsbA0KCUJzcXVhcmV9 IGJpbmQgZGVmDQovUzEyIHtCTCBbXSAwIHNldGRhc2ggMiBjb3B5IGV4Y2ggdnB0IHN1YiBl eGNoIHZwdCBzdWIgdnB0MiB2cHQgUmVjIGZpbGwgQnNxdWFyZX0gYmluZCBkZWYNCi9TMTMg e0JMIFtdIDAgc2V0ZGFzaCAyIGNvcHkgZXhjaCB2cHQgc3ViIGV4Y2ggdnB0IHN1YiB2cHQy IHZwdCBSZWMgZmlsbA0KCTIgY29weSB2cHQgU3F1YXJlIGZpbGwgQnNxdWFyZX0gYmluZCBk ZWYNCi9TMTQge0JMIFtdIDAgc2V0ZGFzaCAyIGNvcHkgZXhjaCB2cHQgc3ViIGV4Y2ggdnB0 IHN1YiB2cHQyIHZwdCBSZWMgZmlsbA0KCTIgY29weSBleGNoIHZwdCBzdWIgZXhjaCB2cHQg U3F1YXJlIGZpbGwgQnNxdWFyZX0gYmluZCBkZWYNCi9TMTUge0JMIFtdIDAgc2V0ZGFzaCAy IGNvcHkgQnNxdWFyZSBmaWxsIEJzcXVhcmV9IGJpbmQgZGVmDQovRDAge2dzYXZlIHRyYW5z bGF0ZSA0NSByb3RhdGUgMCAwIFMwIHN0cm9rZSBncmVzdG9yZX0gYmluZCBkZWYNCi9EMSB7 Z3NhdmUgdHJhbnNsYXRlIDQ1IHJvdGF0ZSAwIDAgUzEgc3Ryb2tlIGdyZXN0b3JlfSBiaW5k IGRlZg0KL0QyIHtnc2F2ZSB0cmFuc2xhdGUgNDUgcm90YXRlIDAgMCBTMiBzdHJva2UgZ3Jl c3RvcmV9IGJpbmQgZGVmDQovRDMge2dzYXZlIHRyYW5zbGF0ZSA0NSByb3RhdGUgMCAwIFMz IHN0cm9rZSBncmVzdG9yZX0gYmluZCBkZWYNCi9ENCB7Z3NhdmUgdHJhbnNsYXRlIDQ1IHJv dGF0ZSAwIDAgUzQgc3Ryb2tlIGdyZXN0b3JlfSBiaW5kIGRlZg0KL0Q1IHtnc2F2ZSB0cmFu c2xhdGUgNDUgcm90YXRlIDAgMCBTNSBzdHJva2UgZ3Jlc3RvcmV9IGJpbmQgZGVmDQovRDYg e2dzYXZlIHRyYW5zbGF0ZSA0NSByb3RhdGUgMCAwIFM2IHN0cm9rZSBncmVzdG9yZX0gYmlu ZCBkZWYNCi9ENyB7Z3NhdmUgdHJhbnNsYXRlIDQ1IHJvdGF0ZSAwIDAgUzcgc3Ryb2tlIGdy ZXN0b3JlfSBiaW5kIGRlZg0KL0Q4IHtnc2F2ZSB0cmFuc2xhdGUgNDUgcm90YXRlIDAgMCBT OCBzdHJva2UgZ3Jlc3RvcmV9IGJpbmQgZGVmDQovRDkge2dzYXZlIHRyYW5zbGF0ZSA0NSBy b3RhdGUgMCAwIFM5IHN0cm9rZSBncmVzdG9yZX0gYmluZCBkZWYNCi9EMTAge2dzYXZlIHRy YW5zbGF0ZSA0NSByb3RhdGUgMCAwIFMxMCBzdHJva2UgZ3Jlc3RvcmV9IGJpbmQgZGVmDQov RDExIHtnc2F2ZSB0cmFuc2xhdGUgNDUgcm90YXRlIDAgMCBTMTEgc3Ryb2tlIGdyZXN0b3Jl fSBiaW5kIGRlZg0KL0QxMiB7Z3NhdmUgdHJhbnNsYXRlIDQ1IHJvdGF0ZSAwIDAgUzEyIHN0 cm9rZSBncmVzdG9yZX0gYmluZCBkZWYNCi9EMTMge2dzYXZlIHRyYW5zbGF0ZSA0NSByb3Rh dGUgMCAwIFMxMyBzdHJva2UgZ3Jlc3RvcmV9IGJpbmQgZGVmDQovRDE0IHtnc2F2ZSB0cmFu c2xhdGUgNDUgcm90YXRlIDAgMCBTMTQgc3Ryb2tlIGdyZXN0b3JlfSBiaW5kIGRlZg0KL0Qx NSB7Z3NhdmUgdHJhbnNsYXRlIDQ1IHJvdGF0ZSAwIDAgUzE1IHN0cm9rZSBncmVzdG9yZX0g YmluZCBkZWYNCi9EaWFFIHtzdHJva2UgW10gMCBzZXRkYXNoIHZwdCBhZGQgTQ0KICBocHQg bmVnIHZwdCBuZWcgViBocHQgdnB0IG5lZyBWDQogIGhwdCB2cHQgViBocHQgbmVnIHZwdCBW IGNsb3NlcGF0aCBzdHJva2V9IGRlZg0KL0JveEUge3N0cm9rZSBbXSAwIHNldGRhc2ggZXhj aCBocHQgc3ViIGV4Y2ggdnB0IGFkZCBNDQogIDAgdnB0MiBuZWcgViBocHQyIDAgViAwIHZw dDIgVg0KICBocHQyIG5lZyAwIFYgY2xvc2VwYXRoIHN0cm9rZX0gZGVmDQovVHJpVUUge3N0 cm9rZSBbXSAwIHNldGRhc2ggdnB0IDEuMTIgbXVsIGFkZCBNDQogIGhwdCBuZWcgdnB0IC0x LjYyIG11bCBWDQogIGhwdCAyIG11bCAwIFYNCiAgaHB0IG5lZyB2cHQgMS42MiBtdWwgViBj bG9zZXBhdGggc3Ryb2tlfSBkZWYNCi9UcmlERSB7c3Ryb2tlIFtdIDAgc2V0ZGFzaCB2cHQg MS4xMiBtdWwgc3ViIE0NCiAgaHB0IG5lZyB2cHQgMS42MiBtdWwgVg0KICBocHQgMiBtdWwg MCBWDQogIGhwdCBuZWcgdnB0IC0xLjYyIG11bCBWIGNsb3NlcGF0aCBzdHJva2V9IGRlZg0K L1BlbnRFIHtzdHJva2UgW10gMCBzZXRkYXNoIGdzYXZlDQogIHRyYW5zbGF0ZSAwIGhwdCBN IDQgezcyIHJvdGF0ZSAwIGhwdCBMfSByZXBlYXQNCiAgY2xvc2VwYXRoIHN0cm9rZSBncmVz dG9yZX0gZGVmDQovQ2lyY0Uge3N0cm9rZSBbXSAwIHNldGRhc2ggDQogIGhwdCAwIDM2MCBh cmMgc3Ryb2tlfSBkZWYNCi9PcGFxdWUge2dzYXZlIGNsb3NlcGF0aCAxIHNldGdyYXkgZmls bCBncmVzdG9yZSAwIHNldGdyYXkgY2xvc2VwYXRofSBkZWYNCi9EaWFXIHtzdHJva2UgW10g MCBzZXRkYXNoIHZwdCBhZGQgTQ0KICBocHQgbmVnIHZwdCBuZWcgViBocHQgdnB0IG5lZyBW DQogIGhwdCB2cHQgViBocHQgbmVnIHZwdCBWIE9wYXF1ZSBzdHJva2V9IGRlZg0KL0JveFcg e3N0cm9rZSBbXSAwIHNldGRhc2ggZXhjaCBocHQgc3ViIGV4Y2ggdnB0IGFkZCBNDQogIDAg dnB0MiBuZWcgViBocHQyIDAgViAwIHZwdDIgVg0KICBocHQyIG5lZyAwIFYgT3BhcXVlIHN0 cm9rZX0gZGVmDQovVHJpVVcge3N0cm9rZSBbXSAwIHNldGRhc2ggdnB0IDEuMTIgbXVsIGFk ZCBNDQogIGhwdCBuZWcgdnB0IC0xLjYyIG11bCBWDQogIGhwdCAyIG11bCAwIFYNCiAgaHB0 IG5lZyB2cHQgMS42MiBtdWwgViBPcGFxdWUgc3Ryb2tlfSBkZWYNCi9UcmlEVyB7c3Ryb2tl IFtdIDAgc2V0ZGFzaCB2cHQgMS4xMiBtdWwgc3ViIE0NCiAgaHB0IG5lZyB2cHQgMS42MiBt dWwgVg0KICBocHQgMiBtdWwgMCBWDQogIGhwdCBuZWcgdnB0IC0xLjYyIG11bCBWIE9wYXF1 ZSBzdHJva2V9IGRlZg0KL1BlbnRXIHtzdHJva2UgW10gMCBzZXRkYXNoIGdzYXZlDQogIHRy YW5zbGF0ZSAwIGhwdCBNIDQgezcyIHJvdGF0ZSAwIGhwdCBMfSByZXBlYXQNCiAgT3BhcXVl IHN0cm9rZSBncmVzdG9yZX0gZGVmDQovQ2lyY1cge3N0cm9rZSBbXSAwIHNldGRhc2ggDQog IGhwdCAwIDM2MCBhcmMgT3BhcXVlIHN0cm9rZX0gZGVmDQovQm94RmlsbCB7Z3NhdmUgUmVj IDEgc2V0Z3JheSBmaWxsIGdyZXN0b3JlfSBkZWYNCi9EZW5zaXR5IHsNCiAgL0ZpbGxkZW4g ZXhjaCBkZWYNCiAgY3VycmVudHJnYmNvbG9yDQogIC9Db2xCIGV4Y2ggZGVmIC9Db2xHIGV4 Y2ggZGVmIC9Db2xSIGV4Y2ggZGVmDQogIC9Db2xSIENvbFIgRmlsbGRlbiBtdWwgRmlsbGRl biBzdWIgMSBhZGQgZGVmDQogIC9Db2xHIENvbEcgRmlsbGRlbiBtdWwgRmlsbGRlbiBzdWIg MSBhZGQgZGVmDQogIC9Db2xCIENvbEIgRmlsbGRlbiBtdWwgRmlsbGRlbiBzdWIgMSBhZGQg ZGVmDQogIENvbFIgQ29sRyBDb2xCIHNldHJnYmNvbG9yfSBkZWYNCi9Cb3hDb2xGaWxsIHtn c2F2ZSBSZWMgUG9seUZpbGx9IGRlZg0KL1BvbHlGaWxsIHtnc2F2ZSBEZW5zaXR5IGZpbGwg Z3Jlc3RvcmUgZ3Jlc3RvcmV9IGRlZg0KL2gge3JsaW5ldG8gcmxpbmV0byBybGluZXRvIGdz YXZlIGZpbGwgZ3Jlc3RvcmV9IGJpbmQgZGVmDQolDQolIFBvc3RTY3JpcHQgTGV2ZWwgMSBQ YXR0ZXJuIEZpbGwgcm91dGluZSBmb3IgcmVjdGFuZ2xlcw0KJSBVc2FnZTogeCB5IHcgaCBz IGEgWFggUGF0dGVybkZpbGwNCiUJeCx5ID0gbG93ZXIgbGVmdCBjb3JuZXIgb2YgYm94IHRv IGJlIGZpbGxlZA0KJQl3LGggPSB3aWR0aCBhbmQgaGVpZ2h0IG9mIGJveA0KJQkgIGEgPSBh bmdsZSBpbiBkZWdyZWVzIGJldHdlZW4gbGluZXMgYW5kIHgtYXhpcw0KJQkgWFggPSAwLzEg Zm9yIG5vL3llcyBjcm9zcy1oYXRjaA0KJQ0KL1BhdHRlcm5GaWxsIHtnc2F2ZSAvUEZhIFsg OSAyIHJvbGwgXSBkZWYNCiAgUEZhIDAgZ2V0IFBGYSAyIGdldCAyIGRpdiBhZGQgUEZhIDEg Z2V0IFBGYSAzIGdldCAyIGRpdiBhZGQgdHJhbnNsYXRlDQogIFBGYSAyIGdldCAtMiBkaXYg UEZhIDMgZ2V0IC0yIGRpdiBQRmEgMiBnZXQgUEZhIDMgZ2V0IFJlYw0KICBnc2F2ZSAxIHNl dGdyYXkgZmlsbCBncmVzdG9yZSBjbGlwDQogIGN1cnJlbnRsaW5ld2lkdGggMC41IG11bCBz ZXRsaW5ld2lkdGgNCiAgL1BGcyBQRmEgMiBnZXQgZHVwIG11bCBQRmEgMyBnZXQgZHVwIG11 bCBhZGQgc3FydCBkZWYNCiAgMCAwIE0gUEZhIDUgZ2V0IHJvdGF0ZSBQRnMgLTIgZGl2IGR1 cCB0cmFuc2xhdGUNCiAgMCAxIFBGcyBQRmEgNCBnZXQgZGl2IDEgYWRkIGZsb29yIGN2aQ0K CXtQRmEgNCBnZXQgbXVsIDAgTSAwIFBGcyBWfSBmb3INCiAgMCBQRmEgNiBnZXQgbmUgew0K CTAgMSBQRnMgUEZhIDQgZ2V0IGRpdiAxIGFkZCBmbG9vciBjdmkNCgl7UEZhIDQgZ2V0IG11 bCAwIDIgMSByb2xsIE0gUEZzIDAgVn0gZm9yDQogfSBpZg0KICBzdHJva2UgZ3Jlc3RvcmV9 IGRlZg0KJQ0KL2xhbmd1YWdlbGV2ZWwgd2hlcmUNCiB7cG9wIGxhbmd1YWdlbGV2ZWx9IHsx fSBpZmVsc2UNCiAyIGx0DQoJey9JbnRlcnByZXRMZXZlbDEgdHJ1ZSBkZWZ9DQoJey9JbnRl cnByZXRMZXZlbDEgTGV2ZWwxIGRlZn0NCiBpZmVsc2UNCiUNCiUgUG9zdFNjcmlwdCBsZXZl bCAyIHBhdHRlcm4gZmlsbCBkZWZpbml0aW9ucw0KJQ0KL0xldmVsMlBhdHRlcm5GaWxsIHsN Ci9UaWxlOHg4IHsvUGFpbnRUeXBlIDIgL1BhdHRlcm5UeXBlIDEgL1RpbGluZ1R5cGUgMSAv QkJveCBbMCAwIDggOF0gL1hTdGVwIDggL1lTdGVwIDh9DQoJYmluZCBkZWYNCi9LZWVwQ29s b3Ige2N1cnJlbnRyZ2Jjb2xvciBbL1BhdHRlcm4gL0RldmljZVJHQl0gc2V0Y29sb3JzcGFj ZX0gYmluZCBkZWYNCjw8IFRpbGU4eDgNCiAvUGFpbnRQcm9jIHswLjUgc2V0bGluZXdpZHRo IHBvcCAwIDAgTSA4IDggTCAwIDggTSA4IDAgTCBzdHJva2V9IA0KPj4gbWF0cml4IG1ha2Vw YXR0ZXJuDQovUGF0MSBleGNoIGRlZg0KPDwgVGlsZTh4OA0KIC9QYWludFByb2MgezAuNSBz ZXRsaW5ld2lkdGggcG9wIDAgMCBNIDggOCBMIDAgOCBNIDggMCBMIHN0cm9rZQ0KCTAgNCBN IDQgOCBMIDggNCBMIDQgMCBMIDAgNCBMIHN0cm9rZX0NCj4+IG1hdHJpeCBtYWtlcGF0dGVy bg0KL1BhdDIgZXhjaCBkZWYNCjw8IFRpbGU4eDgNCiAvUGFpbnRQcm9jIHswLjUgc2V0bGlu ZXdpZHRoIHBvcCAwIDAgTSAwIDggTA0KCTggOCBMIDggMCBMIDAgMCBMIGZpbGx9DQo+PiBt YXRyaXggbWFrZXBhdHRlcm4NCi9QYXQzIGV4Y2ggZGVmDQo8PCBUaWxlOHg4DQogL1BhaW50 UHJvYyB7MC41IHNldGxpbmV3aWR0aCBwb3AgLTQgOCBNIDggLTQgTA0KCTAgMTIgTSAxMiAw IEwgc3Ryb2tlfQ0KPj4gbWF0cml4IG1ha2VwYXR0ZXJuDQovUGF0NCBleGNoIGRlZg0KPDwg VGlsZTh4OA0KIC9QYWludFByb2MgezAuNSBzZXRsaW5ld2lkdGggcG9wIC00IDAgTSA4IDEy IEwNCgkwIC00IE0gMTIgOCBMIHN0cm9rZX0NCj4+IG1hdHJpeCBtYWtlcGF0dGVybg0KL1Bh dDUgZXhjaCBkZWYNCjw8IFRpbGU4eDgNCiAvUGFpbnRQcm9jIHswLjUgc2V0bGluZXdpZHRo IHBvcCAtMiA4IE0gNCAtNCBMDQoJMCAxMiBNIDggLTQgTCA0IDEyIE0gMTAgMCBMIHN0cm9r ZX0NCj4+IG1hdHJpeCBtYWtlcGF0dGVybg0KL1BhdDYgZXhjaCBkZWYNCjw8IFRpbGU4eDgN CiAvUGFpbnRQcm9jIHswLjUgc2V0bGluZXdpZHRoIHBvcCAtMiAwIE0gNCAxMiBMDQoJMCAt NCBNIDggMTIgTCA0IC00IE0gMTAgOCBMIHN0cm9rZX0NCj4+IG1hdHJpeCBtYWtlcGF0dGVy bg0KL1BhdDcgZXhjaCBkZWYNCjw8IFRpbGU4eDgNCiAvUGFpbnRQcm9jIHswLjUgc2V0bGlu ZXdpZHRoIHBvcCA4IC0yIE0gLTQgNCBMDQoJMTIgMCBNIC00IDggTCAxMiA0IE0gMCAxMCBM IHN0cm9rZX0NCj4+IG1hdHJpeCBtYWtlcGF0dGVybg0KL1BhdDggZXhjaCBkZWYNCjw8IFRp bGU4eDgNCiAvUGFpbnRQcm9jIHswLjUgc2V0bGluZXdpZHRoIHBvcCAwIC0yIE0gMTIgNCBM DQoJLTQgMCBNIDEyIDggTCAtNCA0IE0gOCAxMCBMIHN0cm9rZX0NCj4+IG1hdHJpeCBtYWtl cGF0dGVybg0KL1BhdDkgZXhjaCBkZWYNCi9QYXR0ZXJuMSB7UGF0dGVybkJnbmQgS2VlcENv bG9yIFBhdDEgc2V0cGF0dGVybn0gYmluZCBkZWYNCi9QYXR0ZXJuMiB7UGF0dGVybkJnbmQg S2VlcENvbG9yIFBhdDIgc2V0cGF0dGVybn0gYmluZCBkZWYNCi9QYXR0ZXJuMyB7UGF0dGVy bkJnbmQgS2VlcENvbG9yIFBhdDMgc2V0cGF0dGVybn0gYmluZCBkZWYNCi9QYXR0ZXJuNCB7 UGF0dGVybkJnbmQgS2VlcENvbG9yIExhbmRzY2FwZSB7UGF0NX0ge1BhdDR9IGlmZWxzZSBz ZXRwYXR0ZXJufSBiaW5kIGRlZg0KL1BhdHRlcm41IHtQYXR0ZXJuQmduZCBLZWVwQ29sb3Ig TGFuZHNjYXBlIHtQYXQ0fSB7UGF0NX0gaWZlbHNlIHNldHBhdHRlcm59IGJpbmQgZGVmDQov UGF0dGVybjYge1BhdHRlcm5CZ25kIEtlZXBDb2xvciBMYW5kc2NhcGUge1BhdDl9IHtQYXQ2 fSBpZmVsc2Ugc2V0cGF0dGVybn0gYmluZCBkZWYNCi9QYXR0ZXJuNyB7UGF0dGVybkJnbmQg S2VlcENvbG9yIExhbmRzY2FwZSB7UGF0OH0ge1BhdDd9IGlmZWxzZSBzZXRwYXR0ZXJufSBi aW5kIGRlZg0KfSBkZWYNCiUNCiUNCiVFbmQgb2YgUG9zdFNjcmlwdCBMZXZlbCAyIGNvZGUN CiUNCi9QYXR0ZXJuQmduZCB7DQogIFRyYW5zcGFyZW50UGF0dGVybnMge30ge2dzYXZlIDEg c2V0Z3JheSBmaWxsIGdyZXN0b3JlfSBpZmVsc2UNCn0gZGVmDQolDQolIFN1YnN0aXR1dGUg Zm9yIExldmVsIDIgcGF0dGVybiBmaWxsIGNvZGVzIHdpdGgNCiUgZ3JheXNjYWxlIGlmIExl dmVsIDIgc3VwcG9ydCBpcyBub3Qgc2VsZWN0ZWQuDQolDQovTGV2ZWwxUGF0dGVybkZpbGwg ew0KL1BhdHRlcm4xIHswLjI1MCBEZW5zaXR5fSBiaW5kIGRlZg0KL1BhdHRlcm4yIHswLjUw MCBEZW5zaXR5fSBiaW5kIGRlZg0KL1BhdHRlcm4zIHswLjc1MCBEZW5zaXR5fSBiaW5kIGRl Zg0KL1BhdHRlcm40IHswLjEyNSBEZW5zaXR5fSBiaW5kIGRlZg0KL1BhdHRlcm41IHswLjM3 NSBEZW5zaXR5fSBiaW5kIGRlZg0KL1BhdHRlcm42IHswLjYyNSBEZW5zaXR5fSBiaW5kIGRl Zg0KL1BhdHRlcm43IHswLjg3NSBEZW5zaXR5fSBiaW5kIGRlZg0KfSBkZWYNCiUNCiUgTm93 IHRlc3QgZm9yIHN1cHBvcnQgb2YgTGV2ZWwgMiBjb2RlDQolDQpMZXZlbDEge0xldmVsMVBh dHRlcm5GaWxsfSB7TGV2ZWwyUGF0dGVybkZpbGx9IGlmZWxzZQ0KJQ0KL1N5bWJvbC1PYmxp cXVlIC9TeW1ib2wgZmluZGZvbnQgWzEgMCAuMTY3IDEgMCAwXSBtYWtlZm9udA0KZHVwIGxl bmd0aCBkaWN0IGJlZ2luIHsxIGluZGV4IC9GSUQgZXEge3BvcCBwb3B9IHtkZWZ9IGlmZWxz ZX0gZm9yYWxsDQpjdXJyZW50ZGljdCBlbmQgZGVmaW5lZm9udCBwb3ANCi9NRnNob3cgew0K ICAgeyBkdXAgNSBnZXQgMyBnZQ0KICAgICB7IDUgZ2V0IDMgZXEge2dzYXZlfSB7Z3Jlc3Rv cmV9IGlmZWxzZSB9DQogICAgIHtkdXAgZHVwIDAgZ2V0IGZpbmRmb250IGV4Y2ggMSBnZXQg c2NhbGVmb250IHNldGZvbnQNCiAgICAgWyBjdXJyZW50cG9pbnQgXSBleGNoIGR1cCAyIGdl dCAwIGV4Y2ggUiBkdXAgNSBnZXQgMiBuZSB7ZHVwIGR1cCA2DQogICAgIGdldCBleGNoIDQg Z2V0IHtzaG93fSB7c3RyaW5nd2lkdGggcG9wIDAgUn0gaWZlbHNlIH1pZiBkdXAgNSBnZXQg MCBlcQ0KICAgICB7ZHVwIDMgZ2V0IHsyIGdldCBuZWcgMCBleGNoIFIgcG9wfSB7cG9wIGFs b2FkIHBvcCBNfSBpZmVsc2V9IHtkdXAgNQ0KICAgICBnZXQgMSBlcSB7ZHVwIDIgZ2V0IGV4 Y2ggZHVwIDMgZ2V0IGV4Y2ggNiBnZXQgc3RyaW5nd2lkdGggcG9wIC0yIGRpdg0KICAgICBk dXAgMCBSfSB7ZHVwIDYgZ2V0IHN0cmluZ3dpZHRoIHBvcCAtMiBkaXYgMCBSIDYgZ2V0DQog ICAgIHNob3cgMiBpbmRleCB7YWxvYWQgcG9wIE0gbmVnIDMgLTEgcm9sbCBuZWcgUiBwb3Ag cG9wfSB7cG9wIHBvcCBwb3ANCiAgICAgcG9wIGFsb2FkIHBvcCBNfSBpZmVsc2UgfWlmZWxz ZSB9aWZlbHNlIH0NCiAgICAgaWZlbHNlIH0NCiAgIGZvcmFsbH0gYmluZCBkZWYNCi9NRndp ZHRoIHswIGV4Y2ggeyBkdXAgNSBnZXQgMyBnZSB7IDUgZ2V0IDMgZXEgeyAwIH0geyBwb3Ag fSBpZmVsc2UgfQ0KIHtkdXAgMyBnZXR7ZHVwIGR1cCAwIGdldCBmaW5kZm9udCBleGNoIDEg Z2V0IHNjYWxlZm9udCBzZXRmb250DQogICAgIDYgZ2V0IHN0cmluZ3dpZHRoIHBvcCBhZGR9 IHtwb3B9IGlmZWxzZX0gaWZlbHNlfSBmb3JhbGx9IGJpbmQgZGVmDQovTUxzaG93IHsgY3Vy cmVudHBvaW50IHN0cm9rZSBNDQogIDAgZXhjaCBSDQogIEJsYWNrdGV4dCB7Z3NhdmUgMCBz ZXRncmF5IE1Gc2hvdyBncmVzdG9yZX0ge01Gc2hvd30gaWZlbHNlIH0gYmluZCBkZWYNCi9N UnNob3cgeyBjdXJyZW50cG9pbnQgc3Ryb2tlIE0NCiAgZXhjaCBkdXAgTUZ3aWR0aCBuZWcg MyAtMSByb2xsIFINCiAgQmxhY2t0ZXh0IHtnc2F2ZSAwIHNldGdyYXkgTUZzaG93IGdyZXN0 b3JlfSB7TUZzaG93fSBpZmVsc2UgfSBiaW5kIGRlZg0KL01Dc2hvdyB7IGN1cnJlbnRwb2lu dCBzdHJva2UgTQ0KICBleGNoIGR1cCBNRndpZHRoIC0yIGRpdiAzIC0xIHJvbGwgUg0KICBC bGFja3RleHQge2dzYXZlIDAgc2V0Z3JheSBNRnNob3cgZ3Jlc3RvcmV9IHtNRnNob3d9IGlm ZWxzZSB9IGJpbmQgZGVmDQovWFlzYXZlICAgIHsgWyggKSAxIDIgdHJ1ZSBmYWxzZSAzICgp XSB9IGJpbmQgZGVmDQovWFlyZXN0b3JlIHsgWyggKSAxIDIgdHJ1ZSBmYWxzZSA0ICgpXSB9 IGJpbmQgZGVmDQplbmQNCiUlRW5kUHJvbG9nDQpnbnVkaWN0IGJlZ2luDQpnc2F2ZQ0KNTAg NTAgdHJhbnNsYXRlDQowLjA1MCAwLjA1MCBzY2FsZQ0KMCBzZXRncmF5DQpuZXdwYXRoDQoo SGVsdmV0aWNhKSBmaW5kZm9udCAyMjAgc2NhbGVmb250IHNldGZvbnQNCjEuMDAwIFVMDQpM VGINCjExMjIgNjYwIE0NCjYzIDAgVg0KNTY0MSAwIFINCi02MyAwIFYNCnN0cm9rZQ0KOTkw IDY2MCBNDQpbIFsoSGVsdmV0aWNhKSAyMjAuMCAwLjAgdHJ1ZSB0cnVlIDAgKCAwKV0NCl0g LTczLjMgTVJzaG93DQoxLjAwMCBVTA0KTFRiDQoxMTIyIDE0MDQgTQ0KNjMgMCBWDQo1NjQx IDAgUg0KLTYzIDAgVg0Kc3Ryb2tlDQo5OTAgMTQwNCBNDQpbIFsoSGVsdmV0aWNhKSAyMjAu MCAwLjAgdHJ1ZSB0cnVlIDAgKCAwLjIpXQ0KXSAtNzMuMyBNUnNob3cNCjEuMDAwIFVMDQpM VGINCjExMjIgMjE0OCBNDQo2MyAwIFYNCjU2NDEgMCBSDQotNjMgMCBWDQpzdHJva2UNCjk5 MCAyMTQ4IE0NClsgWyhIZWx2ZXRpY2EpIDIyMC4wIDAuMCB0cnVlIHRydWUgMCAoIDAuNCld DQpdIC03My4zIE1Sc2hvdw0KMS4wMDAgVUwNCkxUYg0KMTEyMiAyODkyIE0NCjYzIDAgVg0K NTY0MSAwIFINCi02MyAwIFYNCnN0cm9rZQ0KOTkwIDI4OTIgTQ0KWyBbKEhlbHZldGljYSkg MjIwLjAgMC4wIHRydWUgdHJ1ZSAwICggMC42KV0NCl0gLTczLjMgTVJzaG93DQoxLjAwMCBV TA0KTFRiDQoxMTIyIDM2MzYgTQ0KNjMgMCBWDQo1NjQxIDAgUg0KLTYzIDAgVg0Kc3Ryb2tl DQo5OTAgMzYzNiBNDQpbIFsoSGVsdmV0aWNhKSAyMjAuMCAwLjAgdHJ1ZSB0cnVlIDAgKCAw LjgpXQ0KXSAtNzMuMyBNUnNob3cNCjEuMDAwIFVMDQpMVGINCjExMjIgNDM4MCBNDQo2MyAw IFYNCjU2NDEgMCBSDQotNjMgMCBWDQpzdHJva2UNCjk5MCA0MzgwIE0NClsgWyhIZWx2ZXRp Y2EpIDIyMC4wIDAuMCB0cnVlIHRydWUgMCAoIDEpXQ0KXSAtNzMuMyBNUnNob3cNCjEuMDAw IFVMDQpMVGINCjExMjIgNjYwIE0NCjAgNjMgVg0KMCAzNjU3IFINCjAgLTYzIFYNCnN0cm9r ZQ0KMTEyMiA0NDAgTQ0KWyBbKEhlbHZldGljYSkgMjIwLjAgMC4wIHRydWUgdHJ1ZSAwICgg OTApXQ0KXSAtNzMuMyBNQ3Nob3cNCjEuMDAwIFVMDQpMVGINCjI1NDggNjYwIE0NCjAgNjMg Vg0KMCAzNjU3IFINCjAgLTYzIFYNCnN0cm9rZQ0KMjU0OCA0NDAgTQ0KWyBbKEhlbHZldGlj YSkgMjIwLjAgMC4wIHRydWUgdHJ1ZSAwICggOTUpXQ0KXSAtNzMuMyBNQ3Nob3cNCjEuMDAw IFVMDQpMVGINCjM5NzQgNjYwIE0NCjAgNjMgVg0KMCAzNjU3IFINCjAgLTYzIFYNCnN0cm9r ZQ0KMzk3NCA0NDAgTQ0KWyBbKEhlbHZldGljYSkgMjIwLjAgMC4wIHRydWUgdHJ1ZSAwICgg MTAwKV0NCl0gLTczLjMgTUNzaG93DQoxLjAwMCBVTA0KTFRiDQo1NDAwIDY2MCBNDQowIDYz IFYNCjAgMzY1NyBSDQowIC02MyBWDQpzdHJva2UNCjU0MDAgNDQwIE0NClsgWyhIZWx2ZXRp Y2EpIDIyMC4wIDAuMCB0cnVlIHRydWUgMCAoIDEwNSldDQpdIC03My4zIE1Dc2hvdw0KMS4w MDAgVUwNCkxUYg0KNjgyNiA2NjAgTQ0KMCA2MyBWDQowIDM2NTcgUg0KMCAtNjMgVg0Kc3Ry b2tlDQo2ODI2IDQ0MCBNDQpbIFsoSGVsdmV0aWNhKSAyMjAuMCAwLjAgdHJ1ZSB0cnVlIDAg KCAxMTApXQ0KXSAtNzMuMyBNQ3Nob3cNCjEuMDAwIFVMDQpMVGINCjEuMDAwIFVMDQpMVGIN CjExMjIgNDM4MCBODQowIC0zNzIwIFYNCjU3MDQgMCBWDQowIDM3MjAgVg0KLTU3MDQgMCBW DQpaIHN0cm9rZQ0KTENiIHNldHJnYmNvbG9yDQoyMjAgMjUyMCBNDQpjdXJyZW50cG9pbnQg Z3NhdmUgdHJhbnNsYXRlIDkwIHJvdGF0ZSAwIDAgbW92ZXRvDQpbIFsoSGVsdmV0aWNhKSAy MjAuMCAwLjAgdHJ1ZSB0cnVlIDAgKEZyYWN0aW9uIG9mIHRpbWUgaW4gQVN0b3Agc3RhdGUp XQ0KXSAtNzMuMyBNQ3Nob3cNCmdyZXN0b3JlDQpMVGINCkxDYiBzZXRyZ2Jjb2xvcg0KMzk3 NCAxMTAgTQ0KWyBbKEhlbHZldGljYSkgMjIwLjAgMC4wIHRydWUgdHJ1ZSAwIChOdW1iZXIg b2YgZmxvd3MpXQ0KXSAtNzMuMyBNQ3Nob3cNCkxUYg0KMzk3NCA0NzEwIE0NClsgWyhIZWx2 ZXRpY2EpIDIyMC4wIDAuMCB0cnVlIHRydWUgMCAoT0JBQyBFeGhhdXN0aXZlIE0uIFwoVEIu c2l6ZT02MCBLQiwgVEIudGg9MjAgS0IsIGMpXQ0KWyhIZWx2ZXRpY2EpIDE3Ni4wIC02Ni4w IHRydWUgdHJ1ZSAwIChCKV0NClsoSGVsdmV0aWNhKSAyMjAuMCAwLjAgdHJ1ZSB0cnVlIDAg KD0wLjVcKSldDQpdIC01MS4zIE1Dc2hvdw0KMS4wMDAgVVANCjEuMDAwIFVMDQpMVDINCjM5 NzQgNjYwIE0NCjAgMzcyMCBWDQpzdHJva2UNCkxUYg0KMjA3NyA0MTUwIE0NClsgWyhIZWx2 ZXRpY2EpIDIyMC4wIDAuMCB0cnVlIHRydWUgMCAoRCldDQpYWXNhdmUNClsoSGVsdmV0aWNh KSAxNzYuMCAtNjYuMCB0cnVlIHRydWUgMCAoYmxvY2spXQ0KWFlyZXN0b3JlDQpbKEhlbHZl dGljYSkgMTc2LjAgMTEwLjAgdHJ1ZSB0cnVlIDAgKG1pbildDQpdIC03My4zIE1Dc2hvdw0K MS4wMDAgVVANCjEuMDAwIFVMDQpMVDANCkxUYg0KMjA0NiAzODA4IE0NClsgWyhIZWx2ZXRp Y2EpIDIyMC4wIDAuMCB0cnVlIHRydWUgMCAoMTAwIG1zKV0NCl0gLTczLjMgTVJzaG93DQpM VDANCjIxNzggMzgwOCBNDQo1OTEgMCBWDQotNTkxIDMxIFINCjAgLTYyIFYNCjU5MSA2MiBS DQowIC02MiBWDQoxMTIyIDY2MCBNDQotMzEgMCBSDQo2MiAwIFYNCi02MiAwIFINCjYyIDAg Vg0KMjU0IDAgUg0KLTMxIDAgUg0KNjIgMCBWDQotNjIgMCBSDQo2MiAwIFYNCjI1NCAwIFIN Ci0zMSAwIFINCjYyIDAgVg0KLTYyIDAgUg0KNjIgMCBWDQoyNTUgMCBSDQotMzEgMCBSDQo2 MiAwIFYNCi02MiAwIFINCjYyIDAgVg0KMjU0IDAgUg0KLTMxIDAgUg0KNjIgMCBWDQotNjIg MCBSDQo2MiAwIFYNCjI1NCAwIFINCi0zMSAwIFINCjYyIDAgVg0KLTYyIDAgUg0KNjIgMCBW DQoyNTQgMCBSDQotMzEgMCBSDQo2MiAwIFYNCi02MiAwIFINCjYyIDAgVg0KMjU0IDEgUg0K MCA0IFYNCi0zMSAtNCBSDQo2MiAwIFYNCi02MiA0IFINCjYyIDAgVg0KMjU1IDEyIFINCjAg MjIgVg0KLTMxIC0yMiBSDQo2MiAwIFYNCi02MiAyMiBSDQo2MiAwIFYNCjI1NCAxNzggUg0K MCA2MyBWDQotMzEgLTYzIFINCjYyIDAgVg0KLTYyIDYzIFINCjYyIDAgVg0KMjU0IDExMTUg Ug0KMCAxODcgVg0KLTMxIC0xODcgUg0KNjIgMCBWDQotNjIgMTg3IFINCjYyIDAgVg0KMjU0 IDE0ODQgUg0KMCAxMjkgVg0KLTMxIC0xMjkgUg0KNjIgMCBWDQotNjIgMTI5IFINCjYyIDAg Vg0KMjU0IDQxOCBSDQowIDMxIFYNCi0zMSAtMzEgUg0KNjIgMCBWDQotNjIgMzEgUg0KNjIg MCBWDQoyNTUgNTUgUg0KMCA5IFYNCi0zMSAtOSBSDQo2MiAwIFYNCi02MiA5IFINCjYyIDAg Vg0KMjU0IDkgUg0KMCAzIFYNCi0zMSAtMyBSDQo2MiAwIFYNCi02MiAzIFINCjYyIDAgVg0K MjU0IC0xIFINCjAgMSBWDQotMzEgLTEgUg0KNjIgMCBWDQotNjIgMSBSDQo2MiAwIFYNCjI1 NCAwIFINCi0zMSAwIFINCjYyIDAgVg0KLTYyIDAgUg0KNjIgMCBWDQoyNTQgMCBSDQotMzEg MCBSDQo2MiAwIFYNCi02MiAwIFINCjYyIDAgVg0KMjU1IDAgUg0KLTMxIDAgUg0KNjI4NyA0 MzgwIEwNCi02MiAwIFINCjYyIDAgVg0KMjU0IDAgUg0KLTMxIDAgUg0KNjIgMCBWDQotNjIg MCBSDQo2MiAwIFYNCjI1NCAwIFINCi0zMSAwIFINCjYyIDAgVg0KLTYyIDAgUg0KNjIgMCBW DQoxMTIyIDY2MCBCb3gNCjE0MDcgNjYwIEJveA0KMTY5MiA2NjAgQm94DQoxOTc4IDY2MCBC b3gNCjIyNjMgNjYwIEJveA0KMjU0OCA2NjAgQm94DQoyODMzIDY2MCBCb3gNCjMxMTggNjYz IEJveA0KMzQwNCA2ODggQm94DQozNjg5IDkwOCBCb3gNCjM5NzQgMjE0OSBCb3gNCjQyNTkg Mzc5MSBCb3gNCjQ1NDQgNDI4OCBCb3gNCjQ4MzAgNDM2NCBCb3gNCjUxMTUgNDM3OCBCb3gN CjU0MDAgNDM4MCBCb3gNCjU2ODUgNDM4MCBCb3gNCjU5NzAgNDM4MCBCb3gNCjYyNTYgNDM4 MCBCb3gNCjY1NDEgNDM4MCBCb3gNCjY4MjYgNDM4MCBCb3gNCjI0NzMgMzgwOCBCb3gNCjEu MDAwIFVMDQpMVDANCjExMjIgNjYwIE0NCjI4NSAwIFYNCjI4NSAwIFYNCjI4NiAwIFYNCjI4 NSAwIFYNCjI4NSAwIFYNCjI4NSAwIFYNCjI4NSAzIFYNCjI4NiAyNSBWDQoyODUgMjIwIFYN CjI4NSAxMjQxIFYNCjI4NSAxNjQyIFYNCjI4NSA0OTcgVg0KMjg2IDc2IFYNCjI4NSAxNCBW DQoyODUgMiBWDQoyODUgMCBWDQoyODUgMCBWDQoyODYgMCBWDQoyODUgMCBWDQoyODUgMCBW DQoxLjAwMCBVUA0Kc3Ryb2tlDQpMVDINCkxUYg0KMjA0NiAzNTg4IE0NClsgWyhIZWx2ZXRp Y2EpIDIyMC4wIDAuMCB0cnVlIHRydWUgMCAoMjAwIG1zKV0NCl0gLTczLjMgTVJzaG93DQpM VDINCjIxNzggMzU4OCBNDQo1OTEgMCBWDQotNTkxIDMxIFINCjAgLTYyIFYNCjU5MSA2MiBS DQowIC02MiBWDQoxMTIyIDY2MCBNDQotMzEgMCBSDQo2MiAwIFYNCi02MiAwIFINCjYyIDAg Vg0KMjU0IDAgUg0KLTMxIDAgUg0KNjIgMCBWDQotNjIgMCBSDQo2MiAwIFYNCjI1NCAwIFIN Ci0zMSAwIFINCjYyIDAgVg0KLTYyIDAgUg0KNjIgMCBWDQoyNTUgMCBSDQotMzEgMCBSDQo2 MiAwIFYNCi02MiAwIFINCjYyIDAgVg0KMjU0IDAgUg0KLTMxIDAgUg0KNjIgMCBWDQotNjIg MCBSDQo2MiAwIFYNCjI1NCAwIFINCi0zMSAwIFINCjYyIDAgVg0KLTYyIDAgUg0KNjIgMCBW DQoyNTQgMCBSDQotMzEgMCBSDQo2MiAwIFYNCi02MiAwIFINCjYyIDAgVg0KMjU0IDIgUg0K MCA1IFYNCi0zMSAtNSBSDQo2MiAwIFYNCi02MiA1IFINCjYyIDAgVg0KMjU1IDE3IFINCjAg MjYgVg0KLTMxIC0yNiBSDQo2MiAwIFYNCi02MiAyNiBSDQo2MiAwIFYNCjI1NCAyMDkgUg0K MCA3MCBWDQotMzEgLTcwIFINCjYyIDAgVg0KLTYyIDcwIFINCjYyIDAgVg0KMjU0IDExOTAg Ug0KMCAxODkgVg0KLTMxIC0xODkgUg0KNjIgMCBWDQotNjIgMTg5IFINCjYyIDAgVg0KMjU0 IDE0NTMgUg0KMCAxMjIgVg0KLTMxIC0xMjIgUg0KNjIgMCBWDQotNjIgMTIyIFINCjYyIDAg Vg0KMjU0IDM2MCBSDQowIDI1IFYNCi0zMSAtMjUgUg0KNjIgMCBWDQotNjIgMjUgUg0KNjIg MCBWDQoyNTUgMzkgUg0KMCA3IFYNCi0zMSAtNyBSDQo2MiAwIFYNCi02MiA3IFINCjYyIDAg Vg0KMjU0IDQgUg0KMCAyIFYNCi0zMSAtMiBSDQo2MiAwIFYNCi02MiAyIFINCjYyIDAgVg0K MjU0IC0xIFINCjAgMSBWDQotMzEgLTEgUg0KNjIgMCBWDQotNjIgMSBSDQo2MiAwIFYNCjI1 NCAwIFINCi0zMSAwIFINCjYyIDAgVg0KLTYyIDAgUg0KNjIgMCBWDQoyNTQgMCBSDQotMzEg MCBSDQo2MiAwIFYNCi02MiAwIFINCjYyIDAgVg0KMjU1IDAgUg0KLTMxIDAgUg0KNjI4NyA0 MzgwIEwNCi02MiAwIFINCjYyIDAgVg0KMjU0IDAgUg0KLTMxIDAgUg0KNjIgMCBWDQotNjIg MCBSDQo2MiAwIFYNCjI1NCAwIFINCi0zMSAwIFINCjYyIDAgVg0KLTYyIDAgUg0KNjIgMCBW DQoxMTIyIDY2MCBDaXJjbGUNCjE0MDcgNjYwIENpcmNsZQ0KMTY5MiA2NjAgQ2lyY2xlDQox OTc4IDY2MCBDaXJjbGUNCjIyNjMgNjYwIENpcmNsZQ0KMjU0OCA2NjAgQ2lyY2xlDQoyODMz IDY2MCBDaXJjbGUNCjMxMTggNjY1IENpcmNsZQ0KMzQwNCA2OTcgQ2lyY2xlDQozNjg5IDk1 NCBDaXJjbGUNCjM5NzQgMjI3MyBDaXJjbGUNCjQyNTkgMzg4MiBDaXJjbGUNCjQ1NDQgNDMx NSBDaXJjbGUNCjQ4MzAgNDM3MCBDaXJjbGUNCjUxMTUgNDM3OSBDaXJjbGUNCjU0MDAgNDM4 MCBDaXJjbGUNCjU2ODUgNDM4MCBDaXJjbGUNCjU5NzAgNDM4MCBDaXJjbGUNCjYyNTYgNDM4 MCBDaXJjbGUNCjY1NDEgNDM4MCBDaXJjbGUNCjY4MjYgNDM4MCBDaXJjbGUNCjI0NzMgMzU4 OCBDaXJjbGUNCjEuMDAwIFVMDQpMVDANCjExMjIgNjYwIE0NCjI4NSAwIFYNCjI4NSAwIFYN CjI4NiAwIFYNCjI4NSAwIFYNCjI4NSAwIFYNCjI4NSAwIFYNCjI4NSA1IFYNCjI4NiAzMiBW DQoyODUgMjU3IFYNCjI4NSAxMzE5IFYNCjI4NSAxNjA5IFYNCjI4NSA0MzMgVg0KMjg2IDU1 IFYNCjI4NSA5IFYNCjI4NSAxIFYNCjI4NSAwIFYNCjI4NSAwIFYNCjI4NiAwIFYNCjI4NSAw IFYNCjI4NSAwIFYNCjEuMDAwIFVQDQpzdHJva2UNCkxUNA0KTFRiDQoyMDQ2IDMzNjggTQ0K WyBbKEhlbHZldGljYSkgMjIwLjAgMC4wIHRydWUgdHJ1ZSAwICg0MDAgbXMpXQ0KXSAtNzMu MyBNUnNob3cNCkxUNA0KMjE3OCAzMzY4IE0NCjU5MSAwIFYNCi01OTEgMzEgUg0KMCAtNjIg Vg0KNTkxIDYyIFINCjAgLTYyIFYNCjExMjIgNjYwIE0NCi0zMSAwIFINCjYyIDAgVg0KLTYy IDAgUg0KNjIgMCBWDQoyNTQgMCBSDQotMzEgMCBSDQo2MiAwIFYNCi02MiAwIFINCjYyIDAg Vg0KMjU0IDAgUg0KLTMxIDAgUg0KNjIgMCBWDQotNjIgMCBSDQo2MiAwIFYNCjI1NSAwIFIN Ci0zMSAwIFINCjYyIDAgVg0KLTYyIDAgUg0KNjIgMCBWDQoyNTQgMCBSDQotMzEgMCBSDQo2 MiAwIFYNCi02MiAwIFINCjYyIDAgVg0KMjU0IDAgUg0KLTMxIDAgUg0KNjIgMCBWDQotNjIg MCBSDQo2MiAwIFYNCjI1NCAwIFINCjAgMSBWDQotMzEgLTEgUg0KNjIgMCBWDQotNjIgMSBS DQo2MiAwIFYNCjI1NCAyIFINCjAgOCBWDQotMzEgLTggUg0KNjIgMCBWDQotNjIgOCBSDQo2 MiAwIFYNCjI1NSAyMyBSDQowIDMzIFYNCi0zMSAtMzMgUg0KNjIgMCBWDQotNjIgMzMgUg0K NjIgMCBWDQoyNTQgMjU4IFINCjAgODEgVg0KLTMxIC04MSBSDQo2MiAwIFYNCi02MiA4MSBS DQo2MiAwIFYNCjI1NCAxMjgxIFINCjAgMTg4IFYNCi0zMSAtMTg4IFINCjYyIDAgVg0KLTYy IDE4OCBSDQo2MiAwIFYNCjI1NCAxMzk0IFINCjAgMTEzIFYNCi0zMSAtMTEzIFINCjYyIDAg Vg0KLTYyIDExMyBSDQo2MiAwIFYNCjI1NCAyODkgUg0KMCAyMCBWDQotMzEgLTIwIFINCjYy IDAgVg0KLTYyIDIwIFINCjYyIDAgVg0KMjU1IDIzIFINCjAgNCBWDQotMzEgLTQgUg0KNjIg MCBWDQotNjIgNCBSDQo2MiAwIFYNCjI1NCAxIFINCjAgMSBWDQotMzEgLTEgUg0KNjIgMCBW DQotNjIgMSBSDQo2MiAwIFYNCjI1NCAwIFINCi0zMSAwIFINCjYyIDAgVg0KLTYyIDAgUg0K NjIgMCBWDQoyNTQgMCBSDQotMzEgMCBSDQo2MiAwIFYNCi02MiAwIFINCjYyIDAgVg0KMjU0 IDAgUg0KLTMxIDAgUg0KNjIgMCBWDQotNjIgMCBSDQo2MiAwIFYNCjI1NSAwIFINCi0zMSAw IFINCjYyODcgNDM4MCBMDQotNjIgMCBSDQo2MiAwIFYNCjI1NCAwIFINCi0zMSAwIFINCjYy IDAgVg0KLTYyIDAgUg0KNjIgMCBWDQoyNTQgMCBSDQotMzEgMCBSDQo2MiAwIFYNCi02MiAw IFINCjYyIDAgVg0KMTEyMiA2NjAgVHJpVQ0KMTQwNyA2NjAgVHJpVQ0KMTY5MiA2NjAgVHJp VQ0KMTk3OCA2NjAgVHJpVQ0KMjI2MyA2NjAgVHJpVQ0KMjU0OCA2NjAgVHJpVQ0KMjgzMyA2 NjAgVHJpVQ0KMzExOCA2NjcgVHJpVQ0KMzQwNCA3MTEgVHJpVQ0KMzY4OSAxMDI1IFRyaVUN CjM5NzQgMjQ0MSBUcmlVDQo0MjU5IDM5ODUgVHJpVQ0KNDU0NCA0MzQxIFRyaVUNCjQ4MzAg NDM3NiBUcmlVDQo1MTE1IDQzODAgVHJpVQ0KNTQwMCA0MzgwIFRyaVUNCjU2ODUgNDM4MCBU cmlVDQo1OTcwIDQzODAgVHJpVQ0KNjI1NiA0MzgwIFRyaVUNCjY1NDEgNDM4MCBUcmlVDQo2 ODI2IDQzODAgVHJpVQ0KMjQ3MyAzMzY4IFRyaVUNCjEuMDAwIFVMDQpMVDANCjExMjIgNjYw IE0NCjI4NSAwIFYNCjI4NSAwIFYNCjI4NiAwIFYNCjI4NSAwIFYNCjI4NSAwIFYNCjI4NSAw IFYNCjI4NSA3IFYNCjI4NiA0NCBWDQoyODUgMzE0IFYNCjI4NSAxNDE2IFYNCjI4NSAxNTQ0 IFYNCjI4NSAzNTYgVg0KMjg2IDM1IFYNCjI4NSA0IFYNCjI4NSAwIFYNCjI4NSAwIFYNCjI4 NSAwIFYNCjI4NiAwIFYNCjI4NSAwIFYNCjI4NSAwIFYNCjEuMDAwIFVQDQpzdHJva2UNCkxU Ng0KTFRiDQoyMDQ2IDMxNDggTQ0KWyBbKEhlbHZldGljYSkgMjIwLjAgMC4wIHRydWUgdHJ1 ZSAwICg4MDAgbXMpXQ0KXSAtNzMuMyBNUnNob3cNCkxUNg0KMjE3OCAzMTQ4IE0NCjU5MSAw IFYNCi01OTEgMzEgUg0KMCAtNjIgVg0KNTkxIDYyIFINCjAgLTYyIFYNCjExMjIgNjYwIE0N Ci0zMSAwIFINCjYyIDAgVg0KLTYyIDAgUg0KNjIgMCBWDQoyNTQgMCBSDQotMzEgMCBSDQo2 MiAwIFYNCi02MiAwIFINCjYyIDAgVg0KMjU0IDAgUg0KLTMxIDAgUg0KNjIgMCBWDQotNjIg MCBSDQo2MiAwIFYNCjI1NSAwIFINCi0zMSAwIFINCjYyIDAgVg0KLTYyIDAgUg0KNjIgMCBW DQoyNTQgMCBSDQotMzEgMCBSDQo2MiAwIFYNCi02MiAwIFINCjYyIDAgVg0KMjU0IDAgUg0K LTMxIDAgUg0KNjIgMCBWDQotNjIgMCBSDQo2MiAwIFYNCjI1NCAwIFINCjAgMiBWDQotMzEg LTIgUg0KNjIgMCBWDQotNjIgMiBSDQo2MiAwIFYNCjI1NCA0IFINCjAgMTIgVg0KLTMxIC0x MiBSDQo2MiAwIFYNCi02MiAxMiBSDQo2MiAwIFYNCjI1NSAzNiBSDQowIDQyIFYNCi0zMSAt NDIgUg0KNjIgMCBWDQotNjIgNDIgUg0KNjIgMCBWDQoyNTQgMzM0IFINCjAgOTcgVg0KLTMx IC05NyBSDQo2MiAwIFYNCi02MiA5NyBSDQo2MiAwIFYNCjI1NCAxMzk5IFINCjAgMTg0IFYN Ci0zMSAtMTg0IFINCjYyIDAgVg0KLTYyIDE4NCBSDQo2MiAwIFYNCjI1NCAxMjc5IFINCjAg OTcgVg0KLTMxIC05NyBSDQo2MiAwIFYNCi02MiA5NyBSDQo2MiAwIFYNCjI1NCAyMTEgUg0K MCAxMiBWDQotMzEgLTEyIFINCjYyIDAgVg0KLTYyIDEyIFINCjYyIDAgVg0KMjU1IDkgUg0K MCAyIFYNCi0zMSAtMiBSDQo2MiAwIFYNCi02MiAyIFINCjYyIDAgVg0KMjU0IDAgUg0KLTMx IDAgUg0KNjIgMCBWDQotNjIgMCBSDQo2MiAwIFYNCjI1NCAwIFINCi0zMSAwIFINCjYyIDAg Vg0KLTYyIDAgUg0KNjIgMCBWDQoyNTQgMCBSDQotMzEgMCBSDQo2MiAwIFYNCi02MiAwIFIN CjYyIDAgVg0KMjU0IDAgUg0KLTMxIDAgUg0KNjIgMCBWDQotNjIgMCBSDQo2MiAwIFYNCjI1 NSAwIFINCi0zMSAwIFINCjYyODcgNDM4MCBMDQotNjIgMCBSDQo2MiAwIFYNCjI1NCAwIFIN Ci0zMSAwIFINCjYyIDAgVg0KLTYyIDAgUg0KNjIgMCBWDQoyNTQgMCBSDQotMzEgMCBSDQo2 MiAwIFYNCi02MiAwIFINCjYyIDAgVg0KMTEyMiA2NjAgVHJpRA0KMTQwNyA2NjAgVHJpRA0K MTY5MiA2NjAgVHJpRA0KMTk3OCA2NjAgVHJpRA0KMjI2MyA2NjAgVHJpRA0KMjU0OCA2NjAg VHJpRA0KMjgzMyA2NjEgVHJpRA0KMzExOCA2NzIgVHJpRA0KMzQwNCA3MzUgVHJpRA0KMzY4 OSAxMTM5IFRyaUQNCjM5NzQgMjY3OCBUcmlEDQo0MjU5IDQwOTggVHJpRA0KNDU0NCA0MzYz IFRyaUQNCjQ4MzAgNDM3OSBUcmlEDQo1MTE1IDQzODAgVHJpRA0KNTQwMCA0MzgwIFRyaUQN CjU2ODUgNDM4MCBUcmlEDQo1OTcwIDQzODAgVHJpRA0KNjI1NiA0MzgwIFRyaUQNCjY1NDEg NDM4MCBUcmlEDQo2ODI2IDQzODAgVHJpRA0KMjQ3MyAzMTQ4IFRyaUQNCjEuMDAwIFVMDQpM VDANCjExMjIgNjYwIE0NCjI4NSAwIFYNCjI4NSAwIFYNCjI4NiAwIFYNCjI4NSAwIFYNCjI4 NSAwIFYNCjI4NSAxIFYNCjI4NSAxMSBWDQoyODYgNjMgVg0KMjg1IDQwNCBWDQoyODUgMTUz OSBWDQoyODUgMTQyMCBWDQoyODUgMjY1IFYNCjI4NiAxNiBWDQoyODUgMSBWDQoyODUgMCBW DQoyODUgMCBWDQoyODUgMCBWDQoyODYgMCBWDQoyODUgMCBWDQoyODUgMCBWDQpzdHJva2UN CkxUYg0KMTEyMiA0MzgwIE4NCjAgLTM3MjAgVg0KNTcwNCAwIFYNCjAgMzcyMCBWDQotNTcw NCAwIFYNClogc3Ryb2tlDQoxLjAwMCBVUA0KMS4wMDAgVUwNCkxUYg0Kc3Ryb2tlDQpncmVz dG9yZQ0KZW5kDQpzaG93cGFnZQ0KJSVUcmFpbGVyDQolJURvY3VtZW50Rm9udHM6IEhlbHZl dGljYQ== --------------070108040208030603020806 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --------------070108040208030603020806-- From pcn-bounces@ietf.org Sun Mar 16 18:43:48 2008 Return-Path: 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 590E93A6D91; Sun, 16 Mar 2008 18:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.582 X-Spam-Level: X-Spam-Status: No, score=-98.582 tagged_above=-999 required=5 tests=[AWL=-0.445, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MANGLED_SMALL=2.3, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 yT0FkNYvbYf9; Sun, 16 Mar 2008 18:43:46 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0EF3A6A90; Sun, 16 Mar 2008 18:43:46 -0700 (PDT) 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 11A733A6A90 for ; Sun, 16 Mar 2008 18:43:45 -0700 (PDT) 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 5xcFIVHtBhV1 for ; Sun, 16 Mar 2008 18:43:43 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id F287D3A6A00 for ; Sun, 16 Mar 2008 18:43:42 -0700 (PDT) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 16 Mar 2008 18:41:26 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m2H1fQ61018553; Sun, 16 Mar 2008 18:41:26 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id m2H1Zxik022728; Mon, 17 Mar 2008 01:41:26 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Mar 2008 21:41:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 16 Mar 2008 21:41:18 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciHduV0QN6KrOPKQISoQDpgJ5Zp2AAWCyOg From: "Anna Charny (acharny)" To: "Georgios Karagiannis" , "Steven Blake" , "pcn" X-OriginalArrivalTime: 17 Mar 2008 01:41:19.0522 (UTC) FILETIME=[FF893020:01C887CF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14195; t=1205718086; x=1206582086; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20(acharny)=22=20 |Subject:=20RE=3A=20[PCN]=20Concensus=20questions=20from=20 Thursday's=20PCN=20meeting |Sender:=20; bh=iwo9VDcB4no6e6slGkmZX7wW7KMIKx1bI1Fl16xuc1c=; b=Mv/lz4I3u5bTlfV9PGecGUnWJANb/PTE8KyocJVRd2A/llMbNhTxJUPD2A AQ12bdby/s1WbKUnqw0r6XS2P86kMlmvH9BSLK5f4PkPNSuu8xrS39Wgxwqh FhU7aAklQn; Authentication-Results: sj-dkim-2; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Georgios, A few clarification questions below: > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: Sunday, March 16, 2008 11:03 AM > To: Anna Charny (acharny); Steven Blake; pcn > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > > Hello Anna > > Please see some comments in line! > > > On 3/14/2008, "Anna Charny (acharny)" wrote: > > >Hello Georgios, > > > >A few comments: > > > >> -----Original Message----- > >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > On Behalf Of > >> Georgios Karagiannis > >> Sent: Friday, March 14, 2008 2:29 PM > >> To: Steven Blake; pcn > >> Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > >> > >> Hi all > >> > >> Before taking any decisions I would like to emphasize the > following. > >> > >> In my opinion preferential dropping of any kind increases the > >> complexity in the interior routers. > > > >Yes, that is absolutely true > > > >> Furthermore, when excess > >> rate mechanisms are used, by preferentially dropping > marked packets > >> it severely decreases the robustness of the PCN domain operation. > >> With robustness I mean, that due to a corner case or due to a > >> msiconfiguration the operation of the PCN domain will completely > >> collapse. > >> This is because the admission control trigger (CLE) at the > egress is > >> much more sensistive when marked packets are dropped than > either the > >> situation that unmarked and marked packets are dropped randomly > >> (current implementation of > >> routers) or the situation that unmarked packets are dropped. > > > >Georgios, I do believe this is really quite an exaggeration. In SM, > >all excess-rate packets will be dropped only if the > bottleneck link has > >admission threshold configured at the link speed. This is certainly > >not the expected configuration. And SM does not care about absolute > >amount of marked packets - it only needs to see a small percentage > >(~1%) of excess rate marks to work, as all of our simulations show. > > Georgios: I will just give you an example: > I will describe two situations: > Situation 1: > Consider that an ingress-egress-aggregate includes flows that > are passing from at least two paths. Do you mean that a single ingress-egress aggregate is travercing two different paths 0- that is, are we talking about ECMP case? > Assume that path1 supports a maximum bandwidth capacity of C. > Now consider that the maximum bandwdith capacity of path2 is 15*C. > Consider also that both paths are fully utilized. So you are considering the case when there is 16x overload on the bottleneck after the failure - right? > > Consider that preferentially marked packets are dropped and > that path2 fails. > Now assume that all (maximum) traffic passing through path2 > will be rerouted through path1. If a bottleneck router > located in path1, say Rbott, is misconfigured (i.e., from the > point of view of having wrongly too high > configured-admissible-rate value), then it can be possible > that CLE measured at the egress cannot reach 1%. Note that > CLE = marked packets/ (marked packets + unmarked packets). > This is because Rbott will just allow an excess rate to pass > through that is equal to: C - configured-admissible-rate. The > rest of the marked packets, so the rest of the excess rate, > will be dropped by Rbott, since this routaer is preferentially > dropping marked packets. So it seems to me that in this example the egress will see the C-configured-admissible-rate of marked packets. In order for this to be less than 1% of the total traffic seen by this egress, configured-admissible-rate should be set to above 99% of the link speed. Right? Do you believe it is a realistic setting? Thank you, Anna > This will mean that the CLE > 1% will not be triggered, this > will mean that the flow termination will not be triggered and > that the operation of the PCN domain will collapse completely. > > > Situation 2: > Now consider that the router just operates as currently, > i.e., no preferential drop, randomly dropping marked and > unmarked packets. > Consider also that the two paths described in Situation 1 > above are used and that they are fully utilized. > Assume also that path2 fails and that the path2 traffic is > rerouted on path1. > Even if routers are misconfigured in path1 (i.e., from the > point of view of having wrongly too high > configured-admissible-rate value), now the CLE value will be > able for sure to reach the triggering value of 1%. > This is because the routers in path1 will drop randomly > marked and unmarked packets. > It is certain that in this case the CLE will reach 1% due to > the following reason. > In this example it is assumed that the maximum bandwidth > capacity supported by path2 is 15*C. This means that after > rerouting the traffic from path2 into path1, the ratio > between marked packets and unmarked packets that are passing > thorugh path1 can be equal or higher than 15. > Note that the routers in path1 will mark the excess rate above C, thus > 15 * C (i.e., the rerouted traffic from path2) as marked. > The above observation holds also for the situation that the > routers are preferentially dropping unmarked packets. > > Thus when routers are preferentially dropping marked packets > the robustness of the PCN domain operation is decreasing and > in some cases it severely decreases, which could cause the > complete collapse of the PCN domain operation. > > > > >> Therefore, as an initial step is better to do not change > the current > >> router behavior from the preferential dropping point of view. > >> > > > >The proposal as presented is that preferential drop is a > SHOULD, not a > >must. Since it does not preclude interoperability, that is OK. > >If the preferential drop is not implemented, SM will potentially > >overterminate more in the case of multiple congested bottlenecks. > > Georgios: I think that the robustness of the PCN domain > operation, is more important than overtermination. > > > > >> Regarding LC-PCN and 3SM operation at the core, the only > requirements > >> that have to be supported are: > >> > >> * use current router behavior from the preferential > dropping point of > >> view. > > > >No, not really. Performance of 3SM will be slowed down quite > >substantially if large number of excess-marked packets are dropped. > >Indeed 3SM is less sensitive to loss preference, however. It does > >however need 3 encoding states that we do not seem to have, and > >requires other modifications to the "current router behavior". > > Georgios: Please do not understand me wrong, I agree that > during the first step we should work on standardizing SM. > But we should allow the possibility in the future to > implement as experimental RFC the CL-PHB, and the > specification of a scheme that is able to detect and handle > the admission control and flow termination at the > PCN-egress-node in another experimental RFC. > > Now regarding the comment on 3SM, yes, I agree that it is > slower, but when the slowing down factor is implemented at > the core routers, a cleaver mechanism could be found later on > at the egress that uses this information and selects the > e.g., "big flows" first in order to increase the termination speed. > > > > >As to LC-PCN, in the slides you sent to me for the presentation on > >Thursday you had the following for LC-PCN " [Loss > preference] depends > >on thres.[hold] set[tting]. Typically, prefer not to drop > ex[cess]. Rate". > >Did you change your mind and now believe it is wrong? > > Georgios: I did not change my mind, typically yes the LC-PCN > should not drop marked packets. However, due to the fact that > the admission control and flow termination triggers at the > egress, are based on the ratio of (marked/(marked + > unmarked), than dropping randomly marked and unmarked > packets, as is done today will operate okay. > > >LC-PCN will also > >need another modification to the "current router behavior" > as it would > >need to mark only a subset of excess rate packets, which requires a > >modification to the token bucket. > > Georgios: Yes, I agree, I think from the point of view of > Token bucket operation, SM will need less changes to router operation. > The above listed comment by me on complexity increase, holds > only for implementing preferential dropping, instead of > implementing random dropping of marked and unmarked packets. > > >This is you say below is not an > >optional optimization, but is required for LC-PCN to work. The > >optional optimization is there to make the algorithm not > overterminate. > >It is to the excitant equally optional as preferential drop > for SM - as > >that too is there to not let SM overterminate :-). > > Georgios: Note that using N in LC-PCN is not an optional optimization. > The LC-PCN needs a very small change in the current token > bucket implementation. This small change is that the token > bucket should mark N packet (or bytes) instead of marking one > packet (or byte). Note that if N = 1, then the token bucket > operates the same as described in the SM draft. > If N > 1, then the SM scheme can operate in the same way with > the difference that the measured excess rate at the egress > should be multipleied with N. > > Thus my proposal is to now standardise SM, and in addition, > the core router should allow, for the near future, the > specification of the CL-PHB behaviour in an experimental RFC > and the specification of a scheme that is able to detect and > handle the admission control and flow termination at the > PCN-egress-node in another experimental RFC. > > > > Best regards, > Georgios > > > > > >> Thus drop marked and unmarked packets randomly. Do not > preferentially > >> drop marked packets. > >> > > > >Again, the proposed approach is to put a SHOULD in the preferential > >drop requirement. > > > >Best, > >Anna > > > > > >> * use a parameter N (or S) that should be equal in whole > PCN domain. > >> The only change in the token bucket implementation will be > that the > >> token bucket should mark N packet (or bytes) instead of > marking one > >> packet (or byte). Note that if N = 1, then the token > bucket operates > >> the same as described in the SM draft. > >> If N > 1, then the SM scheme can operate in the same way with the > >> difference that the measured excess rate at the egress should be > >> multipleied with N. > >> > >> All the other optimization features that are described in > the LC-PCN > >> draft are optional. > >> > >> Best regards, > >> Georgios > >> > >> > >> > >> > >> On 3/14/2008, "Steven Blake" wrote: > >> > >> >Greetings. > >> > > >> >There were six concensus questions called during yesterday's PCN > >> >meeting. Before we call the questions on the list, I want to > >> >paraphrase them and make sure that everyone agrees that this > >> captures > >> >the sense of the discussion. > >> > > >> > > >> >Q1: As an initial standardization activity, should the PCN > >> wg produce a > >> > standards-track PCN scheme that requires only two > >> encoding states? > >> > (Note: this question does not presume that the > solution is Single > >> > Marking). > >> > > >> >Q2: Should the PCN wg produce an experimental-track > extension to the > >> > standards-track PCN scheme that requires another > >> encoding state (for > >> > a total of three encoding states)? > >> > > >> >Q3: Does the working group have enough information to > make a decision > >> > about the way forward for the standards-track PCN scheme? > >> > > >> >Q4: Should the standards-track PCN scheme require (as a MUST > >> implement > >> > feature) that interior PCN routers support > Excess-Rate marking, > >> > according to the particular method of handling already marked > >> > packets and drops described in Anna Charny's presentation? > >> > http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf > >> > > >> >Q5: Should the standards-track PCN scheme require (as a MUST > >> implement > >> > feature) that interior PCN routers support Threshold > marking (in > >> > addition to Excess-Rate marking), according to the > >> particular method > >> > described in Philip Eardley's presentation on Tuesday? > >> > http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf > >> > > >> >Q6: If presented with sufficient evidence in a timely > fashion, would > >> > the PCN wg entertain the option of modifying the > interior router > >> > Excess-Rate marking behavior for the standards-track PCN > >> scheme (as > >> > described in question 4)? > >> > > >> > > >> >Please send comments to the list. > >> > > >> > > >> >Regards, > >> > > >> >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > >> >Steven Blake > >> >Ericsson/Redback Networks +1 919-472-9913 > >> > > >> >_______________________________________________ > >> >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 > >> > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sun Mar 16 19:59:55 2008 Return-Path: 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 E03683A6E06; Sun, 16 Mar 2008 19:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.218 X-Spam-Level: X-Spam-Status: No, score=-101.218 tagged_above=-999 required=5 tests=[AWL=-3.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MANGLED_SMALL=2.3, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 PnatMNDeGriS; Sun, 16 Mar 2008 19:59:54 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F4413A6B65; Sun, 16 Mar 2008 19:59:54 -0700 (PDT) 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 84E2C3A687A for ; Sun, 16 Mar 2008 19:59:53 -0700 (PDT) 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 nhKaUCttWpX2 for ; Sun, 16 Mar 2008 19:59:51 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id B90FC3A6B65 for ; Sun, 16 Mar 2008 19:59:51 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m2H2vYJC032052 for ; Sun, 16 Mar 2008 21:57:34 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Mar 2008 21:57:34 -0500 Received: from [127.0.0.1] ([147.117.168.117]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Mar 2008 21:57:33 -0500 From: Steven Blake To: pcn Content-Type: multipart/mixed; boundary="=-7tb5cB1i3UmviaM3Wrdr" Date: Sun, 16 Mar 2008 22:57:32 -0400 Message-Id: <1205722652.16771.8.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-OriginalArrivalTime: 17 Mar 2008 02:57:34.0151 (UTC) FILETIME=[A63A2D70:01C887DA] Subject: [PCN] [Fwd: RE: Concensus questions from Thursday's PCN meeting] X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org --=-7tb5cB1i3UmviaM3Wrdr Content-Type: text/plain Content-Transfer-Encoding: 7bit Forwarded from Georgios. For some reason it has not shown up on the pcn list yet. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 --=-7tb5cB1i3UmviaM3Wrdr Content-Disposition: inline Content-Description: Forwarded message - RE: [PCN] Concensus questions from Thursday's PCN meeting Content-Type: message/rfc822 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw720.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Mar 2008 10:03:10 -0500 Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Mar 2008 10:03:10 -0500 Received: from esealmw126.eemea.ericsson.se ([130.100.184.161]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Mar 2008 16:03:08 +0100 Received: from mailgw8.ericsson.se ([193.180.251.59]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 16 Mar 2008 16:03:08 +0100 Received: from mailgw8.ericsson.se (unknown [127.0.0.1]) by mailgw8.ericsson.se (Symantec Mail Security) with ESMTP id 4B3E5520002 for ; Sun, 16 Mar 2008 16:03:08 +0100 (CET) X-AuditID: c1b4fb3b-a960bbb000001b12-d7-47dd36abaae1 Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by mailgw8.ericsson.se (Symantec Mail Security) with ESMTP id 7245349802C for ; Sun, 16 Mar 2008 16:03:07 +0100 (CET) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id m2GF2pfI028163; Sun, 16 Mar 2008 16:02:51 +0100 (MET) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Sun, 16 Mar 2008 15:02:50 +0000 To: "Anna Charny (acharny)" , "Steven Blake" , "pcn" Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting Date: Sun, 16 Mar 2008 15:02:50 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Sun, 16 Mar 2008 16:03:00 +0100 (MET) X-Brightmail-Tracker: AAAAAglcFnkJZLRo Return-Path: karagian@cs.utwente.nl X-OriginalArrivalTime: 16 Mar 2008 15:03:08.0334 (UTC) FILETIME=[D83594E0:01C88776] Content-Transfer-Encoding: 7bit Hello Anna Please see some comments in line! On 3/14/2008, "Anna Charny (acharny)" wrote: >Hello Georgios, > >A few comments: > >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On >> Behalf Of Georgios Karagiannis >> Sent: Friday, March 14, 2008 2:29 PM >> To: Steven Blake; pcn >> Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting >> >> Hi all >> >> Before taking any decisions I would like to emphasize the following. >> >> In my opinion preferential dropping of any kind increases the >> complexity in the interior routers. > >Yes, that is absolutely true > >> Furthermore, when excess >> rate mechanisms are used, by preferentially dropping marked >> packets it severely decreases the robustness of the PCN >> domain operation. >> With robustness I mean, that due to a corner case or due to a >> msiconfiguration the operation of the PCN domain will >> completely collapse. >> This is because the admission control trigger (CLE) at the >> egress is much more sensistive when marked packets are >> dropped than either the situation that unmarked and marked >> packets are dropped randomly (current implementation of >> routers) or the situation that unmarked packets are dropped. > >Georgios, I do believe this is really quite an exaggeration. In SM, all >excess-rate packets will be dropped only if the bottleneck link has >admission threshold configured at the link speed. This is certainly not >the expected configuration. And SM does not care about absolute amount >of marked packets - it only needs to see a small percentage (~1%) of >excess rate marks to work, as all of our simulations show. Georgios: I will just give you an example: I will describe two situations: Situation 1: Consider that an ingress-egress-aggregate includes flows that are passing from at least two paths. Assume that path1 supports a maximum bandwidth capacity of C. Now consider that the maximum bandwdith capacity of path2 is 15*C. Consider also that both paths are fully utilized. Consider that preferentially marked packets are dropped and that path2 fails. Now assume that all (maximum) traffic passing through path2 will be rerouted through path1. If a bottleneck router located in path1, say Rbott, is misconfigured (i.e., from the point of view of having wrongly too high configured-admissible-rate value), then it can be possible that CLE measured at the egress cannot reach 1%. Note that CLE = marked packets/ (marked packets + unmarked packets). This is because Rbott will just allow an excess rate to pass through that is equal to: C - configured-admissible-rate. The rest of the marked packets, so the rest of the excess rate, will be dropped by Rbott, since this router is preferentially dropping marked packets. This will mean that the CLE > 1% will not be triggered, this will mean that the flow termination will not be triggered and that the operation of the PCN domain will collapse completely. Situation 2: Now consider that the router just operates as currently, i.e., no preferential drop, randomly dropping marked and unmarked packets. Consider also that the two paths described in Situation 1 above are used and that they are fully utilized. Assume also that path2 fails and that the path2 traffic is rerouted on path1. Even if routers are misconfigured in path1 (i.e., from the point of view of having wrongly too high configured-admissible-rate value), now the CLE value will be able for sure to reach the triggering value of 1%. This is because the routers in path1 will drop randomly marked and unmarked packets. It is certain that in this case the CLE will reach 1% due to the following reason. In this example it is assumed that the maximum bandwidth capacity supported by path2 is 15*C. This means that after rerouting the traffic from path2 into path1, the ratio between marked packets and unmarked packets that are passing thorugh path1 can be equal or higher than 15. Note that the routers in path1 will mark the excess rate above C, thus 15 * C (i.e., the rerouted traffic from path2) as marked. The above observation holds also for the situation that the routers are preferentially dropping unmarked packets. Thus when routers are preferentially dropping marked packets the robustness of the PCN domain operation is decreasing and in some cases it severely decreases, which could cause the complete collapse of the PCN domain operation. > >> Therefore, as an initial step is better to do not change the >> current router behavior from the preferential dropping point of view. >> > >The proposal as presented is that preferential drop is a SHOULD, not a >must. Since it does not preclude interoperability, that is OK. >If the preferential drop is not implemented, SM will potentially >overterminate more in the case of multiple congested bottlenecks. Georgios: I think that the robustness of the PCN domain operation, is more important than overtermination. > >> Regarding LC-PCN and 3SM operation at the core, the only >> requirements that have to be supported are: >> >> * use current router behavior from the preferential dropping >> point of view. > >No, not really. Performance of 3SM will be slowed down quite >substantially if large number of excess-marked packets are dropped. >Indeed 3SM is less sensitive to loss preference, however. It does >however need 3 encoding states that we do not seem to have, and requires >other modifications to the "current router behavior". Georgios: Please do not understand me wrong, I agree that during the first step we should work on standardizing SM. But we should allow the possibility in the future to implement as experimental RFC the CL-PHB, and the specification of a scheme that is able to detect and handle the admission control and flow termination at the PCN-egress-node in another experimental RFC. Now regarding the comment on 3SM, yes, I agree that it is slower, but when the slowing down factor is implemented at the core routers, a cleaver mechanism could be found later on at the egress that uses this information and selects the e.g., "big flows" first in order to increase the termination speed. > >As to LC-PCN, in the slides you sent to me for the presentation on >Thursday you had the following for LC-PCN " [Loss preference] depends on >thres.[hold] set[tting]. Typically, prefer not to drop ex[cess]. Rate". >Did you change your mind and now believe it is wrong? Georgios: I did not change my mind, typically yes the LC-PCN should not drop marked packets. However, due to the fact that the admission control and flow termination triggers at the egress, are based on the ratio of (marked/(marked + unmarked), than dropping randomly marked and unmarked packets, as is done today will operate okay. >LC-PCN will also >need another modification to the "current router behavior" as it would >need to mark only a subset of excess rate packets, which requires a >modification to the token bucket. Georgios: Yes, I agree, I think from the point of view of Token bucket operation, SM will need less changes to router operation. The above listed comment by me on complexity increase, holds only for implementing preferential dropping, instead of implementing random dropping of marked and unmarked packets. >This is you say below is not an >optional optimization, but is required for LC-PCN to work. The optional >optimization is there to make the algorithm not overterminate. It is to >the excitant equally optional as preferential drop for SM - as that too >is there to not let SM overterminate :-). Georgios: Note that using N in LC-PCN is not an optional optimization. The LC-PCN needs a very small change in the current token bucket implementation. This small change is that the token bucket should mark N packet (or bytes) instead of marking one packet (or byte). Note that if N = 1, then the token bucket operates the same as described in the SM draft. If N > 1, then the SM scheme can operate in the same way with the difference that the measured excess rate at the egress should be multipleied with N. Thus my proposal is to now standardise SM, and in addition, the core router should allow, for the near future, the specification of the CL-PHB behaviour in an experimental RFC and the specification of a scheme that is able to detect and handle the admission control and flow termination at the PCN-egress-node in another experimental RFC. Best regards, Georgios > >> Thus drop marked and unmarked packets randomly. Do not >> preferentially drop marked packets. >> > >Again, the proposed approach is to put a SHOULD in the preferential drop >requirement. > >Best, >Anna > > >> * use a parameter N (or S) that should be equal in whole PCN domain. >> The only change in the token bucket implementation will be >> that the token bucket should mark N packet (or bytes) instead >> of marking one packet (or byte). Note that if N = 1, then the >> token bucket operates the same as described in the SM draft. >> If N > 1, then the SM scheme can operate in the same way with >> the difference that the measured excess rate at the egress >> should be multipleied with N. >> >> All the other optimization features that are described in the >> LC-PCN draft are optional. >> >> Best regards, >> Georgios >> >> >> >> >> On 3/14/2008, "Steven Blake" wrote: >> >> >Greetings. >> > >> >There were six concensus questions called during yesterday's PCN >> >meeting. Before we call the questions on the list, I want to >> >paraphrase them and make sure that everyone agrees that this >> captures >> >the sense of the discussion. >> > >> > >> >Q1: As an initial standardization activity, should the PCN >> wg produce a >> > standards-track PCN scheme that requires only two >> encoding states? >> > (Note: this question does not presume that the solution is Single >> > Marking). >> > >> >Q2: Should the PCN wg produce an experimental-track extension to the >> > standards-track PCN scheme that requires another >> encoding state (for >> > a total of three encoding states)? >> > >> >Q3: Does the working group have enough information to make a decision >> > about the way forward for the standards-track PCN scheme? >> > >> >Q4: Should the standards-track PCN scheme require (as a MUST >> implement >> > feature) that interior PCN routers support Excess-Rate marking, >> > according to the particular method of handling already marked >> > packets and drops described in Anna Charny's presentation? >> > http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf >> > >> >Q5: Should the standards-track PCN scheme require (as a MUST >> implement >> > feature) that interior PCN routers support Threshold marking (in >> > addition to Excess-Rate marking), according to the >> particular method >> > described in Philip Eardley's presentation on Tuesday? >> > http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf >> > >> >Q6: If presented with sufficient evidence in a timely fashion, would >> > the PCN wg entertain the option of modifying the interior router >> > Excess-Rate marking behavior for the standards-track PCN >> scheme (as >> > described in question 4)? >> > >> > >> >Please send comments to the list. >> > >> > >> >Regards, >> > >> >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> >Steven Blake >> >Ericsson/Redback Networks +1 919-472-9913 >> > >> >_______________________________________________ >> >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 >> --=-7tb5cB1i3UmviaM3Wrdr Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --=-7tb5cB1i3UmviaM3Wrdr-- From pcn-bounces@ietf.org Sun Mar 16 23:15:43 2008 Return-Path: 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 65EDF3A6A76; Sun, 16 Mar 2008 23:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.479 X-Spam-Level: X-Spam-Status: No, score=-99.479 tagged_above=-999 required=5 tests=[AWL=0.958, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 bZMEtNfPbsSf; Sun, 16 Mar 2008 23:15:41 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D48603A69DE; Sun, 16 Mar 2008 23:15:41 -0700 (PDT) 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 7B13A3A6767 for ; Sun, 16 Mar 2008 23:15:40 -0700 (PDT) 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 JJkHa2Zbdstg for ; Sun, 16 Mar 2008 23:15:39 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id AFB933A6901 for ; Sun, 16 Mar 2008 23:15:38 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id m2H6D1rt028537; Mon, 17 Mar 2008 07:13:01 +0100 (MET) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Mon, 17 Mar 2008 06:13:01 +0000 To: "Anna Charny (acharny)" , "Steven Blake" , "pcn" Date: Mon, 17 Mar 2008 06:13:00 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 17 Mar 2008 07:13:15 +0100 (MET) Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Anna Please see in line! On 3/17/2008, "Anna Charny (acharny)" wrote: >Hi Georgios, > >A few clarification questions below: > >> -----Original Message----- >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> Sent: Sunday, March 16, 2008 11:03 AM >> To: Anna Charny (acharny); Steven Blake; pcn >> Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting >> >> Hello Anna >> >> Please see some comments in line! >> >> >> On 3/14/2008, "Anna Charny (acharny)" wrote: >> >> >Hello Georgios, >> > >> >A few comments: >> > >> >> -----Original Message----- >> >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] >> On Behalf Of >> >> Georgios Karagiannis >> >> Sent: Friday, March 14, 2008 2:29 PM >> >> To: Steven Blake; pcn >> >> Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting >> >> >> >> Hi all >> >> >> >> Before taking any decisions I would like to emphasize the >> following. >> >> >> >> In my opinion preferential dropping of any kind increases the >> >> complexity in the interior routers. >> > >> >Yes, that is absolutely true >> > >> >> Furthermore, when excess >> >> rate mechanisms are used, by preferentially dropping >> marked packets >> >> it severely decreases the robustness of the PCN domain operation. >> >> With robustness I mean, that due to a corner case or due to a >> >> msiconfiguration the operation of the PCN domain will completely >> >> collapse. >> >> This is because the admission control trigger (CLE) at the >> egress is >> >> much more sensistive when marked packets are dropped than >> either the >> >> situation that unmarked and marked packets are dropped randomly >> >> (current implementation of >> >> routers) or the situation that unmarked packets are dropped. >> > >> >Georgios, I do believe this is really quite an exaggeration. In SM, >> >all excess-rate packets will be dropped only if the >> bottleneck link has >> >admission threshold configured at the link speed. This is certainly >> >not the expected configuration. And SM does not care about absolute >> >amount of marked packets - it only needs to see a small percentage >> >(~1%) of excess rate marks to work, as all of our simulations show. >> >> Georgios: I will just give you an example: >> I will describe two situations: >> Situation 1: >> Consider that an ingress-egress-aggregate includes flows that >> are passing from at least two paths. > > >Do you mean that a single ingress-egress aggregate is travercing two >different paths 0- that is, are we talking about ECMP case? Georgios: In the description of the example I had to say that after rerouting the flows belonging to the two paths will be included in the same ingress-egress-aggregate. Before rerouting, path2 is part of another ingress-egress-aggregate. However, it should be considered that both paths start from the same ingress. After rerouting, the flows that were forwarded through path2 will be rerouted/forwarded through path1. > >> Assume that path1 supports a maximum bandwidth capacity of C. >> Now consider that the maximum bandwdith capacity of path2 is 15*C. >> Consider also that both paths are fully utilized. > >So you are considering the case when there is 16x overload on the >bottleneck after the failure - right? Georgios: Yes! > >> >> Consider that preferentially marked packets are dropped and >> that path2 fails. >> Now assume that all (maximum) traffic passing through path2 >> will be rerouted through path1. If a bottleneck router >> located in path1, say Rbott, is misconfigured (i.e., from the >> point of view of having wrongly too high >> configured-admissible-rate value), then it can be possible >> that CLE measured at the egress cannot reach 1%. Note that >> CLE = marked packets/ (marked packets + unmarked packets). >> This is because Rbott will just allow an excess rate to pass >> through that is equal to: C - configured-admissible-rate. The >> rest of the marked packets, so the rest of the excess rate, >> will be dropped by Rbott, since this routaer is preferentially >> dropping marked packets. > >So it seems to me that in this example the egress will see the >C-configured-admissible-rate of marked packets. In order for this to be >less than 1% of the total traffic seen by this egress, >configured-admissible-rate should be set to above 99% of the link speed. >Right? Do you believe it is a realistic setting? Georgios: If no misconfiguration occurs and if ECMP is not applied, then you are right. But in my statements, I was talking about corner cases and misconfigurations. A corner case is the situation where at the same time ECMP occurs, meaning that the egress router, for the same ingress-egress-aggregate will receive more unmarked packets then the ones received only from one path, i.e., path1 in this case. This will mean that the value of the CLE at the egress can decrease dramatically, depending on the value of the unmarked rate received from other paths than path1. Note that CLE = marked/(marked + unmarked). Best regards, Georgios > > >Thank you, >Anna > > >> This will mean that the CLE > 1% will not be triggered, this >> will mean that the flow termination will not be triggered and >> that the operation of the PCN domain will collapse completely. >> >> >> Situation 2: >> Now consider that the router just operates as currently, >> i.e., no preferential drop, randomly dropping marked and >> unmarked packets. >> Consider also that the two paths described in Situation 1 >> above are used and that they are fully utilized. >> Assume also that path2 fails and that the path2 traffic is >> rerouted on path1. >> Even if routers are misconfigured in path1 (i.e., from the >> point of view of having wrongly too high >> configured-admissible-rate value), now the CLE value will be >> able for sure to reach the triggering value of 1%. >> This is because the routers in path1 will drop randomly >> marked and unmarked packets. >> It is certain that in this case the CLE will reach 1% due to >> the following reason. >> In this example it is assumed that the maximum bandwidth >> capacity supported by path2 is 15*C. This means that after >> rerouting the traffic from path2 into path1, the ratio >> between marked packets and unmarked packets that are passing >> thorugh path1 can be equal or higher than 15. >> Note that the routers in path1 will mark the excess rate above C, thus >> 15 * C (i.e., the rerouted traffic from path2) as marked. >> The above observation holds also for the situation that the >> routers are preferentially dropping unmarked packets. >> >> Thus when routers are preferentially dropping marked packets >> the robustness of the PCN domain operation is decreasing and >> in some cases it severely decreases, which could cause the >> complete collapse of the PCN domain operation. >> >> > >> >> Therefore, as an initial step is better to do not change >> the current >> >> router behavior from the preferential dropping point of view. >> >> >> > >> >The proposal as presented is that preferential drop is a >> SHOULD, not a >> >must. Since it does not preclude interoperability, that is OK. >> >If the preferential drop is not implemented, SM will potentially >> >overterminate more in the case of multiple congested bottlenecks. >> >> Georgios: I think that the robustness of the PCN domain >> operation, is more important than overtermination. >> >> > >> >> Regarding LC-PCN and 3SM operation at the core, the only >> requirements >> >> that have to be supported are: >> >> >> >> * use current router behavior from the preferential >> dropping point of >> >> view. >> > >> >No, not really. Performance of 3SM will be slowed down quite >> >substantially if large number of excess-marked packets are dropped. >> >Indeed 3SM is less sensitive to loss preference, however. It does >> >however need 3 encoding states that we do not seem to have, and >> >requires other modifications to the "current router behavior". >> >> Georgios: Please do not understand me wrong, I agree that >> during the first step we should work on standardizing SM. >> But we should allow the possibility in the future to >> implement as experimental RFC the CL-PHB, and the >> specification of a scheme that is able to detect and handle >> the admission control and flow termination at the >> PCN-egress-node in another experimental RFC. >> >> Now regarding the comment on 3SM, yes, I agree that it is >> slower, but when the slowing down factor is implemented at >> the core routers, a cleaver mechanism could be found later on >> at the egress that uses this information and selects the >> e.g., "big flows" first in order to increase the termination speed. >> >> > >> >As to LC-PCN, in the slides you sent to me for the presentation on >> >Thursday you had the following for LC-PCN " [Loss >> preference] depends >> >on thres.[hold] set[tting]. Typically, prefer not to drop >> ex[cess]. Rate". >> >Did you change your mind and now believe it is wrong? >> >> Georgios: I did not change my mind, typically yes the LC-PCN >> should not drop marked packets. However, due to the fact that >> the admission control and flow termination triggers at the >> egress, are based on the ratio of (marked/(marked + >> unmarked), than dropping randomly marked and unmarked >> packets, as is done today will operate okay. >> >> >LC-PCN will also >> >need another modification to the "current router behavior" >> as it would >> >need to mark only a subset of excess rate packets, which requires a >> >modification to the token bucket. >> >> Georgios: Yes, I agree, I think from the point of view of >> Token bucket operation, SM will need less changes to router operation. >> The above listed comment by me on complexity increase, holds >> only for implementing preferential dropping, instead of >> implementing random dropping of marked and unmarked packets. >> >> >This is you say below is not an >> >optional optimization, but is required for LC-PCN to work. The >> >optional optimization is there to make the algorithm not >> overterminate. >> >It is to the excitant equally optional as preferential drop >> for SM - as >> >that too is there to not let SM overterminate :-). >> >> Georgios: Note that using N in LC-PCN is not an optional optimization. >> The LC-PCN needs a very small change in the current token >> bucket implementation. This small change is that the token >> bucket should mark N packet (or bytes) instead of marking one >> packet (or byte). Note that if N = 1, then the token bucket >> operates the same as described in the SM draft. >> If N > 1, then the SM scheme can operate in the same way with >> the difference that the measured excess rate at the egress >> should be multipleied with N. >> >> Thus my proposal is to now standardise SM, and in addition, >> the core router should allow, for the near future, the >> specification of the CL-PHB behaviour in an experimental RFC >> and the specification of a scheme that is able to detect and >> handle the admission control and flow termination at the >> PCN-egress-node in another experimental RFC. >> >> >> >> Best regards, >> Georgios >> >> >> > >> >> Thus drop marked and unmarked packets randomly. Do not >> preferentially >> >> drop marked packets. >> >> >> > >> >Again, the proposed approach is to put a SHOULD in the preferential >> >drop requirement. >> > >> >Best, >> >Anna >> > >> > >> >> * use a parameter N (or S) that should be equal in whole >> PCN domain. >> >> The only change in the token bucket implementation will be >> that the >> >> token bucket should mark N packet (or bytes) instead of >> marking one >> >> packet (or byte). Note that if N = 1, then the token >> bucket operates >> >> the same as described in the SM draft. >> >> If N > 1, then the SM scheme can operate in the same way with the >> >> difference that the measured excess rate at the egress should be >> >> multipleied with N. >> >> >> >> All the other optimization features that are described in >> the LC-PCN >> >> draft are optional. >> >> >> >> Best regards, >> >> Georgios >> >> >> >> >> >> >> >> >> >> On 3/14/2008, "Steven Blake" wrote: >> >> >> >> >Greetings. >> >> > >> >> >There were six concensus questions called during yesterday's PCN >> >> >meeting. Before we call the questions on the list, I want to >> >> >paraphrase them and make sure that everyone agrees that this >> >> captures >> >> >the sense of the discussion. >> >> > >> >> > >> >> >Q1: As an initial standardization activity, should the PCN >> >> wg produce a >> >> > standards-track PCN scheme that requires only two >> >> encoding states? >> >> > (Note: this question does not presume that the >> solution is Single >> >> > Marking). >> >> > >> >> >Q2: Should the PCN wg produce an experimental-track >> extension to the >> >> > standards-track PCN scheme that requires another >> >> encoding state (for >> >> > a total of three encoding states)? >> >> > >> >> >Q3: Does the working group have enough information to >> make a decision >> >> > about the way forward for the standards-track PCN scheme? >> >> > >> >> >Q4: Should the standards-track PCN scheme require (as a MUST >> >> implement >> >> > feature) that interior PCN routers support >> Excess-Rate marking, >> >> > according to the particular method of handling already marked >> >> > packets and drops described in Anna Charny's presentation? >> >> > http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf >> >> > >> >> >Q5: Should the standards-track PCN scheme require (as a MUST >> >> implement >> >> > feature) that interior PCN routers support Threshold >> marking (in >> >> > addition to Excess-Rate marking), according to the >> >> particular method >> >> > described in Philip Eardley's presentation on Tuesday? >> >> > http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf >> >> > >> >> >Q6: If presented with sufficient evidence in a timely >> fashion, would >> >> > the PCN wg entertain the option of modifying the >> interior router >> >> > Excess-Rate marking behavior for the standards-track PCN >> >> scheme (as >> >> > described in question 4)? >> >> > >> >> > >> >> >Please send comments to the list. >> >> > >> >> > >> >> >Regards, >> >> > >> >> >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> >> >Steven Blake >> >> >Ericsson/Redback Networks +1 919-472-9913 >> >> > >> >> >_______________________________________________ >> >> >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 >> >> >> _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sun Mar 16 23:43:47 2008 Return-Path: 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 9A4273A683C; Sun, 16 Mar 2008 23:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.823 X-Spam-Level: X-Spam-Status: No, score=-99.823 tagged_above=-999 required=5 tests=[AWL=0.614, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 E7uzloaUeLWE; Sun, 16 Mar 2008 23:43:45 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B0CC28C1BB; Sun, 16 Mar 2008 23:43:42 -0700 (PDT) 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 63BE13A69E8 for ; Sun, 16 Mar 2008 23:43:40 -0700 (PDT) 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 3TEyVUeERqoA for ; Sun, 16 Mar 2008 23:43:38 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 4DE803A6C02 for ; Sun, 16 Mar 2008 23:42:00 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id m2H6dCII029915; Mon, 17 Mar 2008 07:39:12 +0100 (MET) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Mon, 17 Mar 2008 06:39:12 +0000 To: "Anna Charny (acharny)" , "Steven Blake" , "pcn" Date: Mon, 17 Mar 2008 06:39:11 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 17 Mar 2008 07:39:14 +0100 (MET) Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Anna Please ignore the previous email! Consider the answers to your previous email being the ones that I send in this email! Yes I was referring to an ECMP situation. Please see in line! On 3/17/2008, "Anna Charny (acharny)" wrote: >Hi Georgios, > >A few clarification questions below: > >> -----Original Message----- >> From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> Sent: Sunday, March 16, 2008 11:03 AM >> To: Anna Charny (acharny); Steven Blake; pcn >> Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting >> >> Hello Anna >> >> Please see some comments in line! >> >> >> On 3/14/2008, "Anna Charny (acharny)" wrote: >> >> >Hello Georgios, >> > >> >A few comments: >> > >> >> -----Original Message----- >> >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] >> On Behalf Of >> >> Georgios Karagiannis >> >> Sent: Friday, March 14, 2008 2:29 PM >> >> To: Steven Blake; pcn >> >> Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting >> >> >> >> Hi all >> >> >> >> Before taking any decisions I would like to emphasize the >> following. >> >> >> >> In my opinion preferential dropping of any kind increases the >> >> complexity in the interior routers. >> > >> >Yes, that is absolutely true >> > >> >> Furthermore, when excess >> >> rate mechanisms are used, by preferentially dropping >> marked packets >> >> it severely decreases the robustness of the PCN domain operation. >> >> With robustness I mean, that due to a corner case or due to a >> >> msiconfiguration the operation of the PCN domain will completely >> >> collapse. >> >> This is because the admission control trigger (CLE) at the >> egress is >> >> much more sensistive when marked packets are dropped than >> either the >> >> situation that unmarked and marked packets are dropped randomly >> >> (current implementation of >> >> routers) or the situation that unmarked packets are dropped. >> > >> >Georgios, I do believe this is really quite an exaggeration. In SM, >> >all excess-rate packets will be dropped only if the >> bottleneck link has >> >admission threshold configured at the link speed. This is certainly >> >not the expected configuration. And SM does not care about absolute >> >amount of marked packets - it only needs to see a small percentage >> >(~1%) of excess rate marks to work, as all of our simulations show. >> >> Georgios: I will just give you an example: >> I will describe two situations: >> Situation 1: >> Consider that an ingress-egress-aggregate includes flows that >> are passing from at least two paths. > > >Do you mean that a single ingress-egress aggregate is travercing two >different paths 0- that is, are we talking about ECMP case? Georgios: Yes, I am refering to an ECMP situation. > >> Assume that path1 supports a maximum bandwidth capacity of C. >> Now consider that the maximum bandwdith capacity of path2 is 15*C. >> Consider also that both paths are fully utilized. > >So you are considering the case when there is 16x overload on the >bottleneck after the failure - right? Georgios: Yes! > >> >> Consider that preferentially marked packets are dropped and >> that path2 fails. >> Now assume that all (maximum) traffic passing through path2 >> will be rerouted through path1. If a bottleneck router >> located in path1, say Rbott, is misconfigured (i.e., from the >> point of view of having wrongly too high >> configured-admissible-rate value), then it can be possible >> that CLE measured at the egress cannot reach 1%. Note that >> CLE = marked packets/ (marked packets + unmarked packets). >> This is because Rbott will just allow an excess rate to pass >> through that is equal to: C - configured-admissible-rate. The >> rest of the marked packets, so the rest of the excess rate, >> will be dropped by Rbott, since this routaer is preferentially >> dropping marked packets. > >So it seems to me that in this example the egress will see the >C-configured-admissible-rate of marked packets. In order for this to be >less than 1% of the total traffic seen by this egress, >configured-admissible-rate should be set to above 99% of the link speed. >Right? Do you believe it is a realistic setting? Georgios: If no misconfiguration occurs and if ECMP is not applied, then you are right. But in my statements, I was talking about corner cases and misconfigurations. A corner case is the situation where at the same time ECMP occurs, meaning that the egress router, for the same ingress-egress-aggregate will receive more unmarked packets then the ones received only from one path, i.e., path1 in this case. This will mean that the value of the CLE at the egress can decrease dramatically, depending on the value of the unmarked rate received from other paths than path1. Note that CLE = marked/(marked + unmarked). Best regards, Georgios > > >Thank you, >Anna > > >> This will mean that the CLE > 1% will not be triggered, this >> will mean that the flow termination will not be triggered and >> that the operation of the PCN domain will collapse completely. >> >> >> Situation 2: >> Now consider that the router just operates as currently, >> i.e., no preferential drop, randomly dropping marked and >> unmarked packets. >> Consider also that the two paths described in Situation 1 >> above are used and that they are fully utilized. >> Assume also that path2 fails and that the path2 traffic is >> rerouted on path1. >> Even if routers are misconfigured in path1 (i.e., from the >> point of view of having wrongly too high >> configured-admissible-rate value), now the CLE value will be >> able for sure to reach the triggering value of 1%. >> This is because the routers in path1 will drop randomly >> marked and unmarked packets. >> It is certain that in this case the CLE will reach 1% due to >> the following reason. >> In this example it is assumed that the maximum bandwidth >> capacity supported by path2 is 15*C. This means that after >> rerouting the traffic from path2 into path1, the ratio >> between marked packets and unmarked packets that are passing >> thorugh path1 can be equal or higher than 15. >> Note that the routers in path1 will mark the excess rate above C, thus >> 15 * C (i.e., the rerouted traffic from path2) as marked. >> The above observation holds also for the situation that the >> routers are preferentially dropping unmarked packets. >> >> Thus when routers are preferentially dropping marked packets >> the robustness of the PCN domain operation is decreasing and >> in some cases it severely decreases, which could cause the >> complete collapse of the PCN domain operation. >> >> > >> >> Therefore, as an initial step is better to do not change >> the current >> >> router behavior from the preferential dropping point of view. >> >> >> > >> >The proposal as presented is that preferential drop is a >> SHOULD, not a >> >must. Since it does not preclude interoperability, that is OK. >> >If the preferential drop is not implemented, SM will potentially >> >overterminate more in the case of multiple congested bottlenecks. >> >> Georgios: I think that the robustness of the PCN domain >> operation, is more important than overtermination. >> >> > >> >> Regarding LC-PCN and 3SM operation at the core, the only >> requirements >> >> that have to be supported are: >> >> >> >> * use current router behavior from the preferential >> dropping point of >> >> view. >> > >> >No, not really. Performance of 3SM will be slowed down quite >> >substantially if large number of excess-marked packets are dropped. >> >Indeed 3SM is less sensitive to loss preference, however. It does >> >however need 3 encoding states that we do not seem to have, and >> >requires other modifications to the "current router behavior". >> >> Georgios: Please do not understand me wrong, I agree that >> during the first step we should work on standardizing SM. >> But we should allow the possibility in the future to >> implement as experimental RFC the CL-PHB, and the >> specification of a scheme that is able to detect and handle >> the admission control and flow termination at the >> PCN-egress-node in another experimental RFC. >> >> Now regarding the comment on 3SM, yes, I agree that it is >> slower, but when the slowing down factor is implemented at >> the core routers, a cleaver mechanism could be found later on >> at the egress that uses this information and selects the >> e.g., "big flows" first in order to increase the termination speed. >> >> > >> >As to LC-PCN, in the slides you sent to me for the presentation on >> >Thursday you had the following for LC-PCN " [Loss >> preference] depends >> >on thres.[hold] set[tting]. Typically, prefer not to drop >> ex[cess]. Rate". >> >Did you change your mind and now believe it is wrong? >> >> Georgios: I did not change my mind, typically yes the LC-PCN >> should not drop marked packets. However, due to the fact that >> the admission control and flow termination triggers at the >> egress, are based on the ratio of (marked/(marked + >> unmarked), than dropping randomly marked and unmarked >> packets, as is done today will operate okay. >> >> >LC-PCN will also >> >need another modification to the "current router behavior" >> as it would >> >need to mark only a subset of excess rate packets, which requires a >> >modification to the token bucket. >> >> Georgios: Yes, I agree, I think from the point of view of >> Token bucket operation, SM will need less changes to router operation. >> The above listed comment by me on complexity increase, holds >> only for implementing preferential dropping, instead of >> implementing random dropping of marked and unmarked packets. >> >> >This is you say below is not an >> >optional optimization, but is required for LC-PCN to work. The >> >optional optimization is there to make the algorithm not >> overterminate. >> >It is to the excitant equally optional as preferential drop >> for SM - as >> >that too is there to not let SM overterminate :-). >> >> Georgios: Note that using N in LC-PCN is not an optional optimization. >> The LC-PCN needs a very small change in the current token >> bucket implementation. This small change is that the token >> bucket should mark N packet (or bytes) instead of marking one >> packet (or byte). Note that if N = 1, then the token bucket >> operates the same as described in the SM draft. >> If N > 1, then the SM scheme can operate in the same way with >> the difference that the measured excess rate at the egress >> should be multipleied with N. >> >> Thus my proposal is to now standardise SM, and in addition, >> the core router should allow, for the near future, the >> specification of the CL-PHB behaviour in an experimental RFC >> and the specification of a scheme that is able to detect and >> handle the admission control and flow termination at the >> PCN-egress-node in another experimental RFC. >> >> >> >> Best regards, >> Georgios >> >> >> > >> >> Thus drop marked and unmarked packets randomly. Do not >> preferentially >> >> drop marked packets. >> >> >> > >> >Again, the proposed approach is to put a SHOULD in the preferential >> >drop requirement. >> > >> >Best, >> >Anna >> > >> > >> >> * use a parameter N (or S) that should be equal in whole >> PCN domain. >> >> The only change in the token bucket implementation will be >> that the >> >> token bucket should mark N packet (or bytes) instead of >> marking one >> >> packet (or byte). Note that if N = 1, then the token >> bucket operates >> >> the same as described in the SM draft. >> >> If N > 1, then the SM scheme can operate in the same way with the >> >> difference that the measured excess rate at the egress should be >> >> multipleied with N. >> >> >> >> All the other optimization features that are described in >> the LC-PCN >> >> draft are optional. >> >> >> >> Best regards, >> >> Georgios >> >> >> >> >> >> >> >> >> >> On 3/14/2008, "Steven Blake" wrote: >> >> >> >> >Greetings. >> >> > >> >> >There were six concensus questions called during yesterday's PCN >> >> >meeting. Before we call the questions on the list, I want to >> >> >paraphrase them and make sure that everyone agrees that this >> >> captures >> >> >the sense of the discussion. >> >> > >> >> > >> >> >Q1: As an initial standardization activity, should the PCN >> >> wg produce a >> >> > standards-track PCN scheme that requires only two >> >> encoding states? >> >> > (Note: this question does not presume that the >> solution is Single >> >> > Marking). >> >> > >> >> >Q2: Should the PCN wg produce an experimental-track >> extension to the >> >> > standards-track PCN scheme that requires another >> >> encoding state (for >> >> > a total of three encoding states)? >> >> > >> >> >Q3: Does the working group have enough information to >> make a decision >> >> > about the way forward for the standards-track PCN scheme? >> >> > >> >> >Q4: Should the standards-track PCN scheme require (as a MUST >> >> implement >> >> > feature) that interior PCN routers support >> Excess-Rate marking, >> >> > according to the particular method of handling already marked >> >> > packets and drops described in Anna Charny's presentation? >> >> > http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf >> >> > >> >> >Q5: Should the standards-track PCN scheme require (as a MUST >> >> implement >> >> > feature) that interior PCN routers support Threshold >> marking (in >> >> > addition to Excess-Rate marking), according to the >> >> particular method >> >> > described in Philip Eardley's presentation on Tuesday? >> >> > http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf >> >> > >> >> >Q6: If presented with sufficient evidence in a timely >> fashion, would >> >> > the PCN wg entertain the option of modifying the >> interior router >> >> > Excess-Rate marking behavior for the standards-track PCN >> >> scheme (as >> >> > described in question 4)? >> >> > >> >> > >> >> >Please send comments to the list. >> >> > >> >> > >> >> >Regards, >> >> > >> >> >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> >> >Steven Blake >> >> >Ericsson/Redback Networks +1 919-472-9913 >> >> > >> >> >_______________________________________________ >> >> >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 >> >> >> _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 17 00:57:32 2008 Return-Path: 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 C0E853A6BBC; Mon, 17 Mar 2008 00:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.906 X-Spam-Level: X-Spam-Status: No, score=-100.906 tagged_above=-999 required=5 tests=[AWL=-0.469, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 60+cM3pUBDtc; Mon, 17 Mar 2008 00:57:31 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF67F3A6CE1; Mon, 17 Mar 2008 00:57:31 -0700 (PDT) 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 D2F043A684C for ; Mon, 17 Mar 2008 00:57:28 -0700 (PDT) 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 mCq1jqN2qTr7 for ; Mon, 17 Mar 2008 00:57:27 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id EDECC28C159 for ; Mon, 17 Mar 2008 00:57:11 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Mon, 17 Mar 2008 08:54:53 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Mar 2008 08:54:53 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 17 Mar 2008 08:56:14 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciIBF++zKz17E/GQcib+W/rjB17Bg== References: From: "Geib, Ruediger" To: X-OriginalArrivalTime: 17 Mar 2008 07:54:53.0208 (UTC) FILETIME=[2F224180:01C88804] Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Georgios, I'm sorry, this is not a serious discussion. Stephen, could stuff like this be taken to another mailing list? Regards, Rudiger | -----Original Message----- | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | Sent: Sunday, March 16, 2008 4:03 PM | To: Anna Charny (acharny); Steven Blake; pcn | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | | Hello Anna | | Please see some comments in line! | | [snip] | | Georgios: I will just give you an example: | I will describe two situations: | Situation 1: | Consider that an ingress-egress-aggregate includes flows that | are passing from at least two paths. | Assume that path1 supports a maximum bandwidth capacity of C. | Now consider that the maximum bandwdith capacity of path2 is 15*C. | Consider also that both paths are fully utilized. | | Consider that preferentially marked packets are dropped and | that path2 fails. | Now assume that all (maximum) traffic passing through path2 | will be rerouted through path1. _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 17 01:37:00 2008 Return-Path: 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 D9A7C3A6D0F; Mon, 17 Mar 2008 01:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.454 X-Spam-Level: X-Spam-Status: No, score=-100.454 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 UkqYi8pjp1rW; Mon, 17 Mar 2008 01:37:00 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 169AD3A6C02; Mon, 17 Mar 2008 01:37:00 -0700 (PDT) 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 B330B3A6CE0 for ; Mon, 17 Mar 2008 01:36:58 -0700 (PDT) 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 nzkZH4460Gcn for ; Mon, 17 Mar 2008 01:36:51 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id A35623A6C02 for ; Mon, 17 Mar 2008 01:36:51 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m2H8Y9Hb007160; Mon, 17 Mar 2008 09:34:24 +0100 (MET) From: "Georgios Karagiannis" To: "'Geib, Ruediger'" References: <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de> Date: Mon, 17 Mar 2008 09:34:04 +0100 Message-ID: <000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciIBF++zKz17E/GQcib+W/rjB17BgABJ68g X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 17 Mar 2008 09:34:24 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ruediger What do you mean? Do you mean that you do not want to discuss corner cases (ECMP related cases) that could collapse the PCN domain operation? What I am saying is that if the routers do not preferentially drop marked packets then the PCN domain operation is more robust and more stable than in the situation that the router is preferentially dropping marked packets. Are you saying that this statement is not right? Best regards, Georgios > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: maandag 17 maart 2008 8:56 > To: karagian@cs.utwente.nl > Cc: pcn@ietf.org > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > > Georgios, > > I'm sorry, this is not a serious discussion. > > Stephen, could stuff like this be taken to another mailing list? > > Regards, > > Rudiger > > | -----Original Message----- > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | Sent: Sunday, March 16, 2008 4:03 PM > | To: Anna Charny (acharny); Steven Blake; pcn > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > | > | Hello Anna > | > | Please see some comments in line! > | > | > [snip] > | > | Georgios: I will just give you an example: > | I will describe two situations: > | Situation 1: > | Consider that an ingress-egress-aggregate includes flows that are > | passing from at least two paths. > | Assume that path1 supports a maximum bandwidth capacity of C. > | Now consider that the maximum bandwdith capacity of path2 is 15*C. > | Consider also that both paths are fully utilized. > | > | Consider that preferentially marked packets are dropped and > that path2 > | fails. > | Now assume that all (maximum) traffic passing through path2 will be > | rerouted through path1. > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 17 01:43:27 2008 Return-Path: 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 64B683A6D67; Mon, 17 Mar 2008 01:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.14 X-Spam-Level: X-Spam-Status: No, score=-101.14 tagged_above=-999 required=5 tests=[AWL=-0.703, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 pmuRFvRcVtnQ; Mon, 17 Mar 2008 01:43:26 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89CE828C1B6; Mon, 17 Mar 2008 01:43:26 -0700 (PDT) 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 264BA3A6CD2 for ; Mon, 17 Mar 2008 01:43:25 -0700 (PDT) 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 6IlWPYsp4gJS for ; Mon, 17 Mar 2008 01:43:24 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id C51A13A6818 for ; Mon, 17 Mar 2008 01:43:23 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail21.telekom.de with ESMTP; Mon, 17 Mar 2008 09:41:03 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Mar 2008 09:41:03 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 17 Mar 2008 09:42:25 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CF6423C@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciIBF++zKz17E/GQcib+W/rjB17BgABJ68gAABXALA= References: <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de> <000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 17 Mar 2008 08:41:03.0310 (UTC) FILETIME=[A23E46E0:01C8880A] Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Georgios, PCN is designed for deployment in traffic engineered networks. Please = decribe, how to engineer a high performance carrier backbone and then = review the assumptions your discussion is based on. Regards, Rudiger | -----Original Message----- | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] = | Sent: Monday, March 17, 2008 9:34 AM | To: Geib, R=FCdiger | Cc: pcn@ietf.org | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | = | Hi Ruediger | = | What do you mean? | Do you mean that you do not want to discuss corner cases (ECMP related | cases) that could | collapse the PCN domain operation? | What I am saying is that if the routers do not preferentially = | drop marked packets then the PCN domain operation is more = | robust and more stable than in the situation that the router = | is preferentially dropping marked packets. | = | Are you saying that this statement is not right? | = | = | Best regards, | Georgios | = | = | > -----Original Message----- | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > Sent: maandag 17 maart 2008 8:56 | > To: karagian@cs.utwente.nl | > Cc: pcn@ietf.org | > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | > = | > Georgios, | > = | > I'm sorry, this is not a serious discussion. | > = | > Stephen, could stuff like this be taken to another mailing list? = | > = | > Regards, | > = | > Rudiger | > = | > | -----Original Message----- | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > | Sent: Sunday, March 16, 2008 4:03 PM | > | To: Anna Charny (acharny); Steven Blake; pcn | > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | > | = | > | Hello Anna | > | = | > | Please see some comments in line! | > | = | > | = | > [snip] | > | = | > | Georgios: I will just give you an example: | > | I will describe two situations: | > | Situation 1: | > | Consider that an ingress-egress-aggregate includes flows that are = | > | passing from at least two paths. | > | Assume that path1 supports a maximum bandwidth capacity of C. = | > | Now consider that the maximum bandwdith capacity of path2 is 15*C. | > | Consider also that both paths are fully utilized. | > | = | > | Consider that preferentially marked packets are dropped and | > that path2 | > | fails. | > | Now assume that all (maximum) traffic passing through = | path2 will be = | > | rerouted through path1. | > = | = | = | = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 17 03:05:23 2008 Return-Path: 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 31E3628C262; Mon, 17 Mar 2008 03:05:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.476 X-Spam-Level: X-Spam-Status: No, score=-99.476 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 XfRdSV2un4Ly; Mon, 17 Mar 2008 03:05:18 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26DCB3A6D17; Mon, 17 Mar 2008 03:05:18 -0700 (PDT) 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 225FB3A6B89 for ; Mon, 17 Mar 2008 03:05:16 -0700 (PDT) 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 X0RhzHJTIZiO for ; Mon, 17 Mar 2008 03:05:14 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 77EDF3A6D17 for ; Mon, 17 Mar 2008 03:05:14 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m2HA2pJp014041; Mon, 17 Mar 2008 11:02:57 +0100 (MET) From: "Georgios Karagiannis" To: "'Geib, Ruediger'" References: <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de> <000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6423C@S4DE8PSAANK.mitte.t-com.de> Date: Mon, 17 Mar 2008 11:02:46 +0100 Message-ID: <001301c88816$114dab60$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1B6169C658325341A3B8066E23919E1CF6423C@S4DE8PSAANK.mitte.t-com.de> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciIBF++zKz17E/GQcib+W/rjB17BgABJ68gAABXALAAAifOMA== X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 17 Mar 2008 11:02:57 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ruediger I will try to explain this more clearly. Here are the assumptions: * In the PCN domain we assume that ECMP routing is possible! * ingress-eggress-aggregate can contain flows that are passing = through one path or more paths (when ECMP routing is used). * routers are currently dropping packets randomly. Thus marked and unmarked packets will be = dropped randomly * When excess rate measurements are used, the triggering of admission control and flow = termination are done at the egress by using the CLE. One example of this trigger is: CLE > 1%. Note that CLE =3D marked/(unmarked + marked). This means that if this trigger is not activated while a severe congestion occurs in the PCN domain, then the operation of the PCN domain will completely collapse. My statement is: If the routers do not preferentially drop marked packets then the PCN domain operation, even in corner case and misconfiguration = situations, is more robust and more stable than in the situation that the router is preferentially dropping marked packets. The below example show such a corner case! I will describe two situations: Situation 1: Consider that an ingress-egress-aggregate due to ECMP routing it = includes flows that are passing from at least two paths. Assume that path1 supports a maximum bandwidth capacity of C. Now consider = that the maximum bandwdith capacity of path2 is 15*C. Consider also that both paths are fully utilized. Consider that preferentially marked packets are dropped and that path2 fails. Now assume that all (maximum) traffic passing through path2 will be rerouted through path1. = If a bottleneck router located in path1, say Rbott, is misconfigured (i.e., from the point of = view of having wrongly too high configured-admissible-rate value), or even if it is well configured, then it can be possible that CLE measured at the egress cannot reach 1%. Note that = CLE =3D marked packets/ (marked packets + unmarked packets). This is because Rbott will just allow an excess rate to pass through that is equal to: C - configured-admissible-rate. The rest of the marked packets, so the = rest of the excess rate, will be dropped by Rbott, since this router is = preferentially dropping marked packets. Furthermore, note that due to the ECMP routing flows that are belonging to = the same ingress-egress-aggregate and that are passing through another path, than path1, which is not congested, will forward traffic towards the egress node that will be unmarked. This will mean that the CLE > 1% will not be triggered, this will mean that = the flow termination will not be triggered and that the operation of the PCN domain = will collapse completely. Situation 2: Now consider that the router just operates as currently, i.e., no preferential drop, = randomly dropping marked and unmarked packets. Consider also that the two paths described in Situation 1 above are used, = ECMP routing is used, and that they are fully utilized. Assume also that path2 fails and that the path2 traffic is rerouted on path1. Now the CLE value will have a higher probability of reaching the triggering value of 1%. This is because the routers in path1 will drop randomly marked and unmarked packets. It is more certain that in this case the CLE will reach 1% due to the following reason. In this example it is assumed that the maximum bandwidth capacity supported by path2 is 15*C. = This means that after rerouting the traffic from path2 into path1, the ratio between marked = packets and unmarked packets that are passing thorugh path1 can be equal or higher than 16. Note that the routers in path1 will mark the excess rate above C, thus 16 * C (i.e., the rerouted traffic from path2) as marked. The above observation holds also for the situation that the routers are preferentially = dropping unmarked packets. Thus when routers are preferentially dropping marked packets the robustness of the = PCN domain operation is decreasing and in some cases it severely decreases, = which could cause the complete collapse of the PCN domain operation. Best regards, Georgios > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] = > Sent: maandag 17 maart 2008 9:42 > To: karagian@cs.utwente.nl > Cc: pcn@ietf.org > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > = > Hi Georgios, > = > PCN is designed for deployment in traffic engineered = > networks. Please decribe, how to engineer a high performance = > carrier backbone and then review the assumptions your = > discussion is based on. > = > Regards, > = > Rudiger > = > | -----Original Message----- > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | Sent: Monday, March 17, 2008 9:34 AM > | To: Geib, R=FCdiger > | Cc: pcn@ietf.org > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > | = > | Hi Ruediger > | = > | What do you mean? > | Do you mean that you do not want to discuss corner cases = > (ECMP related > | cases) that could > | collapse the PCN domain operation? > | What I am saying is that if the routers do not preferentially drop = > | marked packets then the PCN domain operation is more robust = > and more = > | stable than in the situation that the router is preferentially = > | dropping marked packets. > | = > | Are you saying that this statement is not right? > | = > | = > | Best regards, > | Georgios > | = > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 17 06:34:53 2008 Return-Path: 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 ADCDA3A6DAE; Mon, 17 Mar 2008 06:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.789 X-Spam-Level: X-Spam-Status: No, score=-100.789 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 9fsg8Buh6NBN; Mon, 17 Mar 2008 06:34:52 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FF0C3A6D8D; Mon, 17 Mar 2008 06:34:52 -0700 (PDT) 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 D776E3A6D6A for ; Mon, 17 Mar 2008 06:34:51 -0700 (PDT) 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 VduHwuvCbdrl for ; Mon, 17 Mar 2008 06:34:47 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 24CA128C199 for ; Mon, 17 Mar 2008 06:34:46 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Mon, 17 Mar 2008 14:32:25 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Mar 2008 14:32:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 Mar 2008 14:33:45 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CF644B1@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <001301c88816$114dab60$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciIBF++zKz17E/GQcib+W/rjB17BgABJ68gAABXALAAAifOMAAH2Kyw References: <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de> <000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6423C@S4DE8PSAANK.mitte.t-com.de> <001301c88816$114dab60$810c5982@dynamic.ewi.utwente.nl> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 17 Mar 2008 13:32:24.0542 (UTC) FILETIME=[55DE97E0:01C88833] Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Georgios, What you describe isn't backbone traffic engineering. What you = describe may happen in corporate VPNs, where a DSL access is = used to back up a WAN Fast Ethernet access or the like. I don't = object to have standards on PCN for VPNs, but I'm not = interested in this issue for now. If you know any carrier who's operating his network with a = 16:1 load balancing for QoS traffic on any particular link set, = please publish the name, we are all interested in hearing it. Regards, Rudiger = | -----Original Message----- | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] = | Sent: Monday, March 17, 2008 11:03 AM | To: Geib, R=FCdiger | Cc: pcn@ietf.org | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | = | Hi Ruediger | = | I will try to explain this more clearly. | Here are the assumptions: | * In the PCN domain we assume that ECMP routing is possible! | * ingress-eggress-aggregate can contain flows that are = | passing through one path or more paths (when ECMP routing is used). | = | * routers are currently dropping packets randomly. Thus = | marked and unmarked packets will be | dropped randomly | = | * When excess rate measurements are used, the triggering of = | admission control and flow | termination are done at the egress by using the CLE. One = | example of this trigger is: | CLE > 1%. Note that CLE =3D marked/(unmarked + marked). This = | means that if this trigger is not activated while a severe | congestion occurs in the PCN domain, then the operation of = | the PCN domain will completely collapse. | = | = | My statement is: | If the routers do not preferentially drop marked packets then = | the PCN domain | operation, even in corner case and misconfiguration = | situations, is more robust and more stable than in the = | situation that the | router is preferentially dropping marked packets. | = | The below example show such a corner case! | = | = | I will describe two situations: | = | Situation 1: | Consider that an ingress-egress-aggregate due to ECMP routing it = | includes flows that are passing from at least two paths. | Assume that path1 supports a maximum bandwidth capacity of C. = | Now consider = | that the maximum bandwdith capacity of path2 is 15*C. | Consider also that both paths are fully utilized. | = | Consider that preferentially marked packets are dropped and that path2 | fails. | Now assume that all (maximum) traffic passing through path2 = | will be rerouted | through path1. = | If a bottleneck router located in path1, say Rbott, is = | misconfigured (i.e., | from the point of = | view of having wrongly too high configured-admissible-rate = | value), or even | if it is well configured, | then it can be possible that CLE measured at the egress = | cannot reach 1%. | Note that = | CLE =3D marked packets/ (marked packets + unmarked packets). | This is because Rbott will just allow an excess rate to pass = | through that is | = | equal to: C - configured-admissible-rate. The rest of the = | marked packets, so | the = | rest of the excess rate, will be dropped by Rbott, since this = | router is = | preferentially dropping marked packets. | Furthermore, note that due to the ECMP routing flows that are = | belonging to = | the same ingress-egress-aggregate and that are passing = | through another path, | = | than path1, which is not congested, will forward traffic = | towards the egress | node | that will be unmarked. | This will mean that the CLE > 1% will not be triggered, this = | will mean that = | the flow termination will not be triggered and that the = | operation of the PCN | domain = | will collapse completely. | = | = | Situation 2: | Now consider that the router just operates as currently, i.e., no | preferential drop, = | randomly dropping marked and unmarked packets. | Consider also that the two paths described in Situation 1 = | above are used, = | ECMP routing is used, and that they are fully utilized. | Assume also that path2 fails and that the path2 traffic is rerouted on | path1. | Now the CLE value will have a higher probability of reaching = | the triggering | value of 1%. | = | This is because the routers in path1 will drop randomly = | marked and unmarked | packets. | It is more certain that in this case the CLE will reach 1% due to the | following reason. | In this example it is assumed that the maximum bandwidth = | capacity supported | by path2 is 15*C. = | This means that after rerouting the traffic from path2 into = | path1, the ratio | between marked = | packets and unmarked packets that are passing thorugh path1 = | can be equal or | higher than 16. | Note that the routers in path1 will mark the excess rate above C, thus | 16 * C (i.e., the rerouted traffic from path2) as marked. | The above observation holds also for the situation that the = | routers are | preferentially = | dropping unmarked packets. | = | Thus when routers are preferentially dropping marked packets = | the robustness | of the = | PCN domain operation is decreasing and in some cases it = | severely decreases, = | which could cause the complete collapse of the PCN domain operation. | = | Best regards, | Georgios | = | = | = | = | = | > -----Original Message----- | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] = | > Sent: maandag 17 maart 2008 9:42 | > To: karagian@cs.utwente.nl | > Cc: pcn@ietf.org | > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | > = | > Hi Georgios, | > = | > PCN is designed for deployment in traffic engineered = | > networks. Please decribe, how to engineer a high performance = | > carrier backbone and then review the assumptions your = | > discussion is based on. | > = | > Regards, | > = | > Rudiger | > = | > | -----Original Message----- | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > | Sent: Monday, March 17, 2008 9:34 AM | > | To: Geib, R=FCdiger | > | Cc: pcn@ietf.org | > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | > | = | > | Hi Ruediger | > | = | > | What do you mean? | > | Do you mean that you do not want to discuss corner cases = | > (ECMP related | > | cases) that could | > | collapse the PCN domain operation? | > | What I am saying is that if the routers do not = | preferentially drop = | > | marked packets then the PCN domain operation is more robust = | > and more = | > | stable than in the situation that the router is preferentially = | > | dropping marked packets. | > | = | > | Are you saying that this statement is not right? | > | = | > | = | > | Best regards, | > | Georgios | > | = | > | = | = | = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 17 06:51:02 2008 Return-Path: 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 5DA6028C1DB; Mon, 17 Mar 2008 06:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.165 X-Spam-Level: X-Spam-Status: No, score=-100.165 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 MyHFIAkj1CEM; Mon, 17 Mar 2008 06:51:01 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D56E3A6BD9; Mon, 17 Mar 2008 06:51:01 -0700 (PDT) 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 D90903A68BE for ; Mon, 17 Mar 2008 06:50:59 -0700 (PDT) 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 rauMh1RSvmuW for ; Mon, 17 Mar 2008 06:50:58 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 749FC3A6BD9 for ; Mon, 17 Mar 2008 06:50:58 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m2HDmbkB012137; Mon, 17 Mar 2008 14:48:40 +0100 (MET) From: "Georgios Karagiannis" To: "'Geib, Ruediger'" References: <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de> <000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6423C@S4DE8PSAANK.mitte.t-com.de> <001301c88816$114dab60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF644B1@S4DE8PSAANK.mitte.t-com.de> Date: Mon, 17 Mar 2008 14:48:31 +0100 Message-ID: <000001c88835$998bcf60$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <1B6169C658325341A3B8066E23919E1CF644B1@S4DE8PSAANK.mitte.t-com.de> Thread-Index: AciIBF++zKz17E/GQcib+W/rjB17BgABJ68gAABXALAAAifOMAAH2KywAACjCyA= X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 17 Mar 2008 14:48:41 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ruediger You missed my point! The explanation applies to all types of IP networks. Please note that the problem occurs also when path2 and path1 use exactly the same = maximum capacity, say C! In this case, if pathh2 fails then path1 will see an excess rate equal to at least C. The rest of the explanation is identical to the one used during my previous example! Best regards, Georgios = > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] = > Sent: maandag 17 maart 2008 14:34 > To: karagian@cs.utwente.nl > Cc: pcn@ietf.org > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > = > Hi Georgios, > = > What you describe isn't backbone traffic engineering. What = > you describe may happen in corporate VPNs, where a DSL access = > is used to back up a WAN Fast Ethernet access or the like. I = > don't object to have standards on PCN for VPNs, but I'm not = > interested in this issue for now. > = > If you know any carrier who's operating his network with a > 16:1 load balancing for QoS traffic on any particular link = > set, please publish the name, we are all interested in hearing it. > = > Regards, > = > Rudiger > = > = > = > | -----Original Message----- > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | Sent: Monday, March 17, 2008 11:03 AM > | To: Geib, R=FCdiger > | Cc: pcn@ietf.org > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > | = > | Hi Ruediger > | = > | I will try to explain this more clearly. > | Here are the assumptions: > | * In the PCN domain we assume that ECMP routing is possible! > | * ingress-eggress-aggregate can contain flows that are = > passing through = > | one path or more paths (when ECMP routing is used). > | = > | * routers are currently dropping packets randomly. Thus marked and = > | unmarked packets will be > | dropped randomly > | = > | * When excess rate measurements are used, the triggering of = > admission = > | control and flow > | termination are done at the egress by using the CLE. One = > example of = > | this trigger is: > | CLE > 1%. Note that CLE =3D marked/(unmarked + marked). This means = > | that if this trigger is not activated while a severe > | congestion occurs in the PCN domain, then the operation = > of the PCN = > | domain will completely collapse. > | = > | = > | My statement is: > | If the routers do not preferentially drop marked packets = > then the PCN = > | domain operation, even in corner case and misconfiguration = > situations, = > | is more robust and more stable than in the situation that = > the router = > | is preferentially dropping marked packets. > | = > | The below example show such a corner case! > | = > | = > | I will describe two situations: > | = > | Situation 1: > | Consider that an ingress-egress-aggregate due to ECMP routing it = > | includes flows that are passing from at least two paths. > | Assume that path1 supports a maximum bandwidth capacity of C. = > | Now consider > | that the maximum bandwdith capacity of path2 is 15*C. > | Consider also that both paths are fully utilized. > | = > | Consider that preferentially marked packets are dropped and = > that path2 = > | fails. > | Now assume that all (maximum) traffic passing through path2 will be = > | rerouted through path1. > | If a bottleneck router located in path1, say Rbott, is = > misconfigured = > | (i.e., from the point of view of having wrongly too high = > | configured-admissible-rate value), or even if it is well = > configured, = > | then it can be possible that CLE measured at the egress = > cannot reach = > | 1%. > | Note that > | CLE =3D marked packets/ (marked packets + unmarked packets). > | This is because Rbott will just allow an excess rate to = > pass through = > | that is > | = > | equal to: C - configured-admissible-rate. The rest of the marked = > | packets, so the rest of the excess rate, will be dropped by Rbott, = > | since this router is preferentially dropping marked packets. > | Furthermore, note that due to the ECMP routing flows that are = > | belonging to the same ingress-egress-aggregate and that are passing = > | through another path, > | = > | than path1, which is not congested, will forward traffic = > towards the = > | egress node that will be unmarked. > | This will mean that the CLE > 1% will not be triggered, = > this will mean = > | that the flow termination will not be triggered and that = > the operation = > | of the PCN domain will collapse completely. > | = > | = > | Situation 2: > | Now consider that the router just operates as currently, i.e., no = > | preferential drop, randomly dropping marked and unmarked packets. > | Consider also that the two paths described in Situation 1 above are = > | used, ECMP routing is used, and that they are fully utilized. > | Assume also that path2 fails and that the path2 traffic is = > rerouted on = > | path1. > | Now the CLE value will have a higher probability of reaching the = > | triggering value of 1%. > | = > | This is because the routers in path1 will drop randomly marked and = > | unmarked packets. > | It is more certain that in this case the CLE will reach 1% = > due to the = > | following reason. > | In this example it is assumed that the maximum bandwidth capacity = > | supported by path2 is 15*C. > | This means that after rerouting the traffic from path2 into = > path1, the = > | ratio between marked packets and unmarked packets that are passing = > | thorugh path1 can be equal or higher than 16. > | Note that the routers in path1 will mark the excess rate = > above C, thus > | 16 * C (i.e., the rerouted traffic from path2) as marked. > | The above observation holds also for the situation that the routers = > | are preferentially dropping unmarked packets. > | = > | Thus when routers are preferentially dropping marked packets the = > | robustness of the PCN domain operation is decreasing and in = > some cases = > | it severely decreases, which could cause the complete = > collapse of the = > | PCN domain operation. > | = > | Best regards, > | Georgios > | = > | = > | = > | = > | = > | > -----Original Message----- > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > | > Sent: maandag 17 maart 2008 9:42 > | > To: karagian@cs.utwente.nl > | > Cc: pcn@ietf.org > | > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > | > = > | > Hi Georgios, > | > = > | > PCN is designed for deployment in traffic engineered networks. = > | > Please decribe, how to engineer a high performance = > carrier backbone = > | > and then review the assumptions your discussion is based on. > | > = > | > Regards, > | > = > | > Rudiger > | > = > | > | -----Original Message----- > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | > | Sent: Monday, March 17, 2008 9:34 AM > | > | To: Geib, R=FCdiger > | > | Cc: pcn@ietf.org > | > | Subject: RE: [PCN] Concensus questions from Thursday's = > PCN meeting > | > | = > | > | Hi Ruediger > | > | = > | > | What do you mean? > | > | Do you mean that you do not want to discuss corner cases > | > (ECMP related > | > | cases) that could > | > | collapse the PCN domain operation? > | > | What I am saying is that if the routers do not > | preferentially drop > | > | marked packets then the PCN domain operation is more robust > | > and more > | > | stable than in the situation that the router is preferentially = > | > | dropping marked packets. > | > | = > | > | Are you saying that this statement is not right? > | > | = > | > | = > | > | Best regards, > | > | Georgios > | > | = > | > > | = > | = > | = > = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 17 07:26:33 2008 Return-Path: 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 013793A6DF6; Mon, 17 Mar 2008 07:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 Qk+ATkK7SXjS; Mon, 17 Mar 2008 07:26:31 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3A2B3A6D65; Mon, 17 Mar 2008 07:26:31 -0700 (PDT) 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 514B128C14B for ; Mon, 17 Mar 2008 07:26:28 -0700 (PDT) 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 344wq8m++Mzt for ; Mon, 17 Mar 2008 07:26:27 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 7F84828C10A for ; Mon, 17 Mar 2008 07:26:25 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Mon, 17 Mar 2008 15:24:08 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Mar 2008 15:24:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 Mar 2008 15:25:30 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CF6451A@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <000001c88835$998bcf60$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciIBF++zKz17E/GQcib+W/rjB17BgABJ68gAABXALAAAifOMAAH2KywAACjCyAAAJeqgA== References: <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de> <000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6423C@S4DE8PSAANK.mitte.t-com.de> <001301c88816$114dab60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF644B1@S4DE8PSAANK.mitte.t-com.de> <000001c88835$998bcf60$810c5982@dynamic.ewi.utwente.nl> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 17 Mar 2008 14:24:07.0984 (UTC) FILETIME=[8FAA4300:01C8883A] Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Georgios, Unfortunately you missed my point. No such thing as you describe has been, is or will for = the foreseeable future be engineered in the IP backbone = of the company I'm working for. = My expectation on the backbone of any carrier offering = transport QoS is, that it is engineered to survive probable failures (like single link losses) without impact on the = performance of QoS traffic. This is where we should start = from, if we discuss PCN. From there on, PCN is able to = add value. = Links without traffic engineering followed by misconfigured = routers aren't the arguments which will convince = either product management or backbone engineering of the = company I work for to deploy PCN. = As a general comment: I don't regard PCN as a plug and = play toy for the operational equivalent of a 'script = kiddie'. If others share that view and our documents = don't state that, we should add text. Regards, Rudiger | -----Original Message----- | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] = | Sent: Monday, March 17, 2008 2:49 PM | To: Geib, R=FCdiger | Cc: pcn@ietf.org | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | = | Hi Ruediger | = | You missed my point! | The explanation applies to all types of IP networks. | Please note that the problem occurs also when path2 and path1 = | use exactly the same maximum capacity, say C! | = | In this case, if pathh2 fails then path1 will see an excess = | rate equal to at least C. | The rest of the explanation is identical to the one used = | during my previous example! | = | = | = | Best regards, | Georgios | = | = | = | = | = | > -----Original Message----- | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > Sent: maandag 17 maart 2008 14:34 | > To: karagian@cs.utwente.nl | > Cc: pcn@ietf.org | > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | > = | > Hi Georgios, | > = | > What you describe isn't backbone traffic engineering. What you = | > describe may happen in corporate VPNs, where a DSL access = | is used to = | > back up a WAN Fast Ethernet access or the like. I don't = | object to have = | > standards on PCN for VPNs, but I'm not interested in this issue for = | > now. | > = | > If you know any carrier who's operating his network with a | > 16:1 load balancing for QoS traffic on any particular link = | set, please = | > publish the name, we are all interested in hearing it. | > = | > Regards, | > = | > Rudiger | > = | > = | > = | > | -----Original Message----- | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > | Sent: Monday, March 17, 2008 11:03 AM | > | To: Geib, R=FCdiger | > | Cc: pcn@ietf.org | > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | > | = | > | Hi Ruediger | > | = | > | I will try to explain this more clearly. | > | Here are the assumptions: | > | * In the PCN domain we assume that ECMP routing is possible! | > | * ingress-eggress-aggregate can contain flows that are | > passing through | > | one path or more paths (when ECMP routing is used). | > | = | > | * routers are currently dropping packets randomly. Thus = | marked and = | > | unmarked packets will be | > | dropped randomly | > | = | > | * When excess rate measurements are used, the triggering of | > admission | > | control and flow | > | termination are done at the egress by using the CLE. One | > example of | > | this trigger is: | > | CLE > 1%. Note that CLE =3D marked/(unmarked + marked). = | This means = | > | that if this trigger is not activated while a severe | > | congestion occurs in the PCN domain, then the operation | > of the PCN | > | domain will completely collapse. | > | = | > | = | > | My statement is: | > | If the routers do not preferentially drop marked packets | > then the PCN | > | domain operation, even in corner case and misconfiguration | > situations, | > | is more robust and more stable than in the situation that | > the router | > | is preferentially dropping marked packets. | > | = | > | The below example show such a corner case! | > | = | > | = | > | I will describe two situations: | > | = | > | Situation 1: | > | Consider that an ingress-egress-aggregate due to ECMP routing it = | > | includes flows that are passing from at least two paths. | > | Assume that path1 supports a maximum bandwidth capacity of C. = | > | Now consider | > | that the maximum bandwdith capacity of path2 is 15*C. | > | Consider also that both paths are fully utilized. | > | = | > | Consider that preferentially marked packets are dropped and | > that path2 | > | fails. | > | Now assume that all (maximum) traffic passing through = | path2 will be = | > | rerouted through path1. | > | If a bottleneck router located in path1, say Rbott, is | > misconfigured | > | (i.e., from the point of view of having wrongly too high = | > | configured-admissible-rate value), or even if it is well | > configured, | > | then it can be possible that CLE measured at the egress | > cannot reach | > | 1%. | > | Note that | > | CLE =3D marked packets/ (marked packets + unmarked packets). | > | This is because Rbott will just allow an excess rate to | > pass through | > | that is | > | = | > | equal to: C - configured-admissible-rate. The rest of the marked = | > | packets, so the rest of the excess rate, will be dropped = | by Rbott, = | > | since this router is preferentially dropping marked packets. | > | Furthermore, note that due to the ECMP routing flows that are = | > | belonging to the same ingress-egress-aggregate and that = | are passing = | > | through another path, | > | = | > | than path1, which is not congested, will forward traffic | > towards the | > | egress node that will be unmarked. | > | This will mean that the CLE > 1% will not be triggered, | > this will mean | > | that the flow termination will not be triggered and that | > the operation | > | of the PCN domain will collapse completely. | > | = | > | = | > | Situation 2: | > | Now consider that the router just operates as currently, i.e., no = | > | preferential drop, randomly dropping marked and unmarked packets. | > | Consider also that the two paths described in Situation 1 = | above are = | > | used, ECMP routing is used, and that they are fully utilized. | > | Assume also that path2 fails and that the path2 traffic is | > rerouted on | > | path1. | > | Now the CLE value will have a higher probability of reaching the = | > | triggering value of 1%. | > | = | > | This is because the routers in path1 will drop randomly = | marked and = | > | unmarked packets. | > | It is more certain that in this case the CLE will reach 1% | > due to the | > | following reason. | > | In this example it is assumed that the maximum bandwidth capacity = | > | supported by path2 is 15*C. | > | This means that after rerouting the traffic from path2 into | > path1, the | > | ratio between marked packets and unmarked packets that = | are passing = | > | thorugh path1 can be equal or higher than 16. | > | Note that the routers in path1 will mark the excess rate | > above C, thus | > | 16 * C (i.e., the rerouted traffic from path2) as marked. | > | The above observation holds also for the situation that = | the routers = | > | are preferentially dropping unmarked packets. | > | = | > | Thus when routers are preferentially dropping marked packets the = | > | robustness of the PCN domain operation is decreasing and in | > some cases | > | it severely decreases, which could cause the complete | > collapse of the | > | PCN domain operation. | > | = | > | Best regards, | > | Georgios | > | = | > | = | > | = | > | = | > | = | > | > -----Original Message----- | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > | > Sent: maandag 17 maart 2008 9:42 | > | > To: karagian@cs.utwente.nl | > | > Cc: pcn@ietf.org | > | > Subject: RE: [PCN] Concensus questions from Thursday's = | PCN meeting | > | > = | > | > Hi Georgios, | > | > = | > | > PCN is designed for deployment in traffic engineered networks. = | > | > Please decribe, how to engineer a high performance | > carrier backbone | > | > and then review the assumptions your discussion is based on. | > | > = | > | > Regards, | > | > = | > | > Rudiger | > | > = | > | > | -----Original Message----- | > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > | > | Sent: Monday, March 17, 2008 9:34 AM | > | > | To: Geib, R=FCdiger | > | > | Cc: pcn@ietf.org | > | > | Subject: RE: [PCN] Concensus questions from Thursday's | > PCN meeting | > | > | = | > | > | Hi Ruediger | > | > | = | > | > | What do you mean? | > | > | Do you mean that you do not want to discuss corner cases | > | > (ECMP related | > | > | cases) that could | > | > | collapse the PCN domain operation? | > | > | What I am saying is that if the routers do not | > | preferentially drop | > | > | marked packets then the PCN domain operation is more robust | > | > and more | > | > | stable than in the situation that the router is = | preferentially = | > | > | dropping marked packets. | > | > | = | > | > | Are you saying that this statement is not right? | > | > | = | > | > | = | > | > | Best regards, | > | > | Georgios | > | > | = | > | > | > | = | > | = | > | = | > = | = | = | = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 17 07:36:37 2008 Return-Path: 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 4208B3A6DE8; Mon, 17 Mar 2008 07:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.536 X-Spam-Level: X-Spam-Status: No, score=-99.536 tagged_above=-999 required=5 tests=[AWL=-0.495, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 L8NBkwhnduHU; Mon, 17 Mar 2008 07:36:35 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A21953A6E11; Mon, 17 Mar 2008 07:36:35 -0700 (PDT) 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 3C6913A6D95 for ; Mon, 17 Mar 2008 07:36:31 -0700 (PDT) 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 ZGl15wXRbXUl for ; Mon, 17 Mar 2008 07:36:25 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 8972D28C3C1 for ; Mon, 17 Mar 2008 07:35:59 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m2HEXb6w017944; Mon, 17 Mar 2008 15:33:40 +0100 (MET) From: "Georgios Karagiannis" To: "'Geib, Ruediger'" References: <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de> <000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6423C@S4DE8PSAANK.mitte.t-com.de> <001301c88816$114dab60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF644B1@S4DE8PSAANK.mitte.t-com.de> <000001c88835$998bcf60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6451A@S4DE8PSAANK.mitte.t-com.de> Date: Mon, 17 Mar 2008 15:33:33 +0100 Message-ID: <000601c8883b$e3828950$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <1B6169C658325341A3B8066E23919E1CF6451A@S4DE8PSAANK.mitte.t-com.de> Thread-Index: AciIBF++zKz17E/GQcib+W/rjB17BgABJ68gAABXALAAAifOMAAH2KywAACjCyAAAJeqgAAA4wtQ X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 17 Mar 2008 15:33:42 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ruediger Please note that typical IP networks (thus not MPLS/GMPLS based domains) = can recover from failures by using rerouting. Or do you know another = standardized mechanism in typical IP networks (thus not MPLS/GMPLS based) that can provide = another kind of recovery from failures. Furthermore, I will just explain the example again with maximum capacity of pathh2 being equal = to maximum capacity of path1 =3D C. Please explain what you do not understand in this example! Here are the assumptions: * In the PCN domain we assume that ECMP routing is possible! * ingress-eggress-aggregate can contain flows that are passing through one path or more paths (when ECMP routing is used). * routers are currently dropping packets randomly. Thus marked and unmarked packets will be dropped randomly * When excess rate measurements are used, the triggering of admission control and flow termination are done at the egress by using the CLE. One example of this trigger is: CLE > 1%. Note that CLE =3D marked/(unmarked + marked). This means that if this trigger is not activated while a severe congestion occurs in the PCN domain, then the operation of the PCN domain will completely collapse. My statement is: If the routers do not preferentially drop marked packets then the PCN domain operation, even in corner case and misconfiguration = situations, is more robust and more stable than in the situation that the router is preferentially dropping marked packets. The below example show such a corner case! I will describe two situations: Situation 1: Consider that an ingress-egress-aggregate due to ECMP routing it = includes flows that are passing from at least two paths. Assume that path1 supports a maximum bandwidth capacity of C. Now consider = that the maximum bandwdith capacity of path2 is C. Consider also that both paths are fully utilized. Consider that preferentially marked packets are dropped and that path2 fails. Now assume that all (maximum) traffic passing through path2 will be rerouted through path1. = If a bottleneck router located in path1, say Rbott, is misconfigured (i.e., from the point of = view of having wrongly too high configured-admissible-rate value), or even if it is well configured, then it can be possible that CLE measured at the egress cannot reach 1%. Note that = CLE =3D marked packets/ (marked packets + unmarked packets). This is because Rbott will just allow an excess rate to pass through that is equal to: C - configured-admissible-rate. The rest of the marked packets, so the = rest of the excess rate, will be dropped by Rbott, since this router is = preferentially dropping marked packets. Furthermore, note that due to the ECMP routing flows that are belonging to = the same ingress-egress-aggregate and that are passing through another path, than path1, which is not congested, will forward traffic towards the egress node that will be unmarked. This will mean that the CLE > 1% will not be triggered, this will mean that = the flow termination will not be triggered and that the operation of the PCN domain = will collapse completely. Situation 2: Now consider that the router just operates as currently, i.e., no preferential drop, = randomly dropping marked and unmarked packets. Consider also that the two paths described in Situation 1 above are used, = ECMP routing is used, and that they are fully utilized. Assume also that path2 fails and that the path2 traffic is rerouted on path1. Now the CLE value will have a higher probability of reaching the triggering value of 1%. This is because the routers in path1 will drop randomly marked and unmarked packets. It is more certain that in this case the CLE will reach 1% due to the following reason. In this example it is assumed that the maximum bandwidth capacity supported by path2 is C. = This means that after rerouting the traffic from path2 into path1, the ratio between marked = packets and unmarked packets that are passing thorugh path1 can be equal or higher than 100%. Note that the routers in path1 will mark the excess rate above C, thus 1*C (i.e., the rerouted traffic from path2) as marked. The above observation holds also for the situation that the routers are preferentially = dropping unmarked packets. Thus when routers are preferentially dropping marked packets the robustness of the = PCN domain operation is decreasing and in some cases it severely decreases, = which could cause the complete collapse of the PCN domain operation. Best regards, Georgios = > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] = > Sent: maandag 17 maart 2008 15:26 > To: karagian@cs.utwente.nl > Cc: pcn@ietf.org > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > = > Hi Georgios, > = > Unfortunately you missed my point. > = > No such thing as you describe has been, is or will for the = > foreseeable future be engineered in the IP backbone of the = > company I'm working for. = > = > My expectation on the backbone of any carrier offering = > transport QoS is, that it is engineered to survive probable = > failures (like single link losses) without impact on the = > performance of QoS traffic. This is where we should start = > from, if we discuss PCN. From there on, PCN is able to add value. = > = > Links without traffic engineering followed by misconfigured = > routers aren't the arguments which will convince either = > product management or backbone engineering of the company I = > work for to deploy PCN. = > = > As a general comment: I don't regard PCN as a plug and play = > toy for the operational equivalent of a 'script kiddie'. If = > others share that view and our documents don't state that, we = > should add text. > = > Regards, > = > Rudiger > = > | -----Original Message----- > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | Sent: Monday, March 17, 2008 2:49 PM > | To: Geib, R=FCdiger > | Cc: pcn@ietf.org > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > | = > | Hi Ruediger > | = > | You missed my point! > | The explanation applies to all types of IP networks. > | Please note that the problem occurs also when path2 and path1 use = > | exactly the same maximum capacity, say C! > | = > | In this case, if pathh2 fails then path1 will see an excess = > rate equal = > | to at least C. > | The rest of the explanation is identical to the one used during my = > | previous example! > | = > | = > | = > | Best regards, > | Georgios > | = > | = > | = > | = > | = > | > -----Original Message----- > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > | > Sent: maandag 17 maart 2008 14:34 > | > To: karagian@cs.utwente.nl > | > Cc: pcn@ietf.org > | > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > | > = > | > Hi Georgios, > | > = > | > What you describe isn't backbone traffic engineering. What you = > | > describe may happen in corporate VPNs, where a DSL access > | is used to > | > back up a WAN Fast Ethernet access or the like. I don't > | object to have > | > standards on PCN for VPNs, but I'm not interested in this = > issue for = > | > now. > | > = > | > If you know any carrier who's operating his network with a > | > 16:1 load balancing for QoS traffic on any particular link > | set, please > | > publish the name, we are all interested in hearing it. > | > = > | > Regards, > | > = > | > Rudiger > | > = > | > = > | > = > | > | -----Original Message----- > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | > | Sent: Monday, March 17, 2008 11:03 AM > | > | To: Geib, R=FCdiger > | > | Cc: pcn@ietf.org > | > | Subject: RE: [PCN] Concensus questions from Thursday's = > PCN meeting > | > | = > | > | Hi Ruediger > | > | = > | > | I will try to explain this more clearly. > | > | Here are the assumptions: > | > | * In the PCN domain we assume that ECMP routing is possible! > | > | * ingress-eggress-aggregate can contain flows that are > | > passing through > | > | one path or more paths (when ECMP routing is used). > | > | = > | > | * routers are currently dropping packets randomly. Thus > | marked and > | > | unmarked packets will be > | > | dropped randomly > | > | = > | > | * When excess rate measurements are used, the triggering of > | > admission > | > | control and flow > | > | termination are done at the egress by using the CLE. One > | > example of > | > | this trigger is: > | > | CLE > 1%. Note that CLE =3D marked/(unmarked + marked). = > | This means > | > | that if this trigger is not activated while a severe > | > | congestion occurs in the PCN domain, then the operation > | > of the PCN > | > | domain will completely collapse. > | > | = > | > | = > | > | My statement is: > | > | If the routers do not preferentially drop marked packets > | > then the PCN > | > | domain operation, even in corner case and misconfiguration > | > situations, > | > | is more robust and more stable than in the situation that > | > the router > | > | is preferentially dropping marked packets. > | > | = > | > | The below example show such a corner case! > | > | = > | > | = > | > | I will describe two situations: > | > | = > | > | Situation 1: > | > | Consider that an ingress-egress-aggregate due to ECMP = > routing it = > | > | includes flows that are passing from at least two paths. > | > | Assume that path1 supports a maximum bandwidth capacity of C. = > | > | Now consider > | > | that the maximum bandwdith capacity of path2 is 15*C. > | > | Consider also that both paths are fully utilized. > | > | = > | > | Consider that preferentially marked packets are dropped and > | > that path2 > | > | fails. > | > | Now assume that all (maximum) traffic passing through > | path2 will be > | > | rerouted through path1. > | > | If a bottleneck router located in path1, say Rbott, is > | > misconfigured > | > | (i.e., from the point of view of having wrongly too high = > | > | configured-admissible-rate value), or even if it is well > | > configured, > | > | then it can be possible that CLE measured at the egress > | > cannot reach > | > | 1%. > | > | Note that > | > | CLE =3D marked packets/ (marked packets + unmarked packets). > | > | This is because Rbott will just allow an excess rate to > | > pass through > | > | that is > | > | = > | > | equal to: C - configured-admissible-rate. The rest of = > the marked = > | > | packets, so the rest of the excess rate, will be dropped > | by Rbott, > | > | since this router is preferentially dropping marked packets. > | > | Furthermore, note that due to the ECMP routing flows that are = > | > | belonging to the same ingress-egress-aggregate and that > | are passing > | > | through another path, > | > | = > | > | than path1, which is not congested, will forward traffic > | > towards the > | > | egress node that will be unmarked. > | > | This will mean that the CLE > 1% will not be triggered, > | > this will mean > | > | that the flow termination will not be triggered and that > | > the operation > | > | of the PCN domain will collapse completely. > | > | = > | > | = > | > | Situation 2: > | > | Now consider that the router just operates as = > currently, i.e., no = > | > | preferential drop, randomly dropping marked and = > unmarked packets. > | > | Consider also that the two paths described in Situation 1 > | above are > | > | used, ECMP routing is used, and that they are fully utilized. > | > | Assume also that path2 fails and that the path2 traffic is > | > rerouted on > | > | path1. > | > | Now the CLE value will have a higher probability of = > reaching the = > | > | triggering value of 1%. > | > | = > | > | This is because the routers in path1 will drop randomly > | marked and > | > | unmarked packets. > | > | It is more certain that in this case the CLE will reach 1% > | > due to the > | > | following reason. > | > | In this example it is assumed that the maximum = > bandwidth capacity = > | > | supported by path2 is 15*C. > | > | This means that after rerouting the traffic from path2 into > | > path1, the > | > | ratio between marked packets and unmarked packets that > | are passing > | > | thorugh path1 can be equal or higher than 16. > | > | Note that the routers in path1 will mark the excess rate > | > above C, thus > | > | 16 * C (i.e., the rerouted traffic from path2) as marked. > | > | The above observation holds also for the situation that > | the routers > | > | are preferentially dropping unmarked packets. > | > | = > | > | Thus when routers are preferentially dropping marked = > packets the = > | > | robustness of the PCN domain operation is decreasing and in > | > some cases > | > | it severely decreases, which could cause the complete > | > collapse of the > | > | PCN domain operation. > | > | = > | > | Best regards, > | > | Georgios > | > | = > | > | = > | > | = > | > | = > | > | = > | > | > -----Original Message----- > | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > | > | > Sent: maandag 17 maart 2008 9:42 > | > | > To: karagian@cs.utwente.nl > | > | > Cc: pcn@ietf.org > | > | > Subject: RE: [PCN] Concensus questions from Thursday's > | PCN meeting > | > | > = > | > | > Hi Georgios, > | > | > = > | > | > PCN is designed for deployment in traffic engineered = > networks. = > | > | > Please decribe, how to engineer a high performance > | > carrier backbone > | > | > and then review the assumptions your discussion is based on. > | > | > = > | > | > Regards, > | > | > = > | > | > Rudiger > | > | > = > | > | > | -----Original Message----- > | > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | > | > | Sent: Monday, March 17, 2008 9:34 AM > | > | > | To: Geib, R=FCdiger > | > | > | Cc: pcn@ietf.org > | > | > | Subject: RE: [PCN] Concensus questions from Thursday's > | > PCN meeting > | > | > | = > | > | > | Hi Ruediger > | > | > | = > | > | > | What do you mean? > | > | > | Do you mean that you do not want to discuss corner cases > | > | > (ECMP related > | > | > | cases) that could > | > | > | collapse the PCN domain operation? > | > | > | What I am saying is that if the routers do not > | > | preferentially drop > | > | > | marked packets then the PCN domain operation is more robust > | > | > and more > | > | > | stable than in the situation that the router is > | preferentially > | > | > | dropping marked packets. > | > | > | = > | > | > | Are you saying that this statement is not right? > | > | > | = > | > | > | = > | > | > | Best regards, > | > | > | Georgios > | > | > | = > | > | > > | > | = > | > | = > | > | = > | > = > | = > | = > | = > = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 17 08:33:19 2008 Return-Path: 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 4C7933A6D0F; Mon, 17 Mar 2008 08:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.749 X-Spam-Level: X-Spam-Status: No, score=-100.749 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 4JtTh4b30TCI; Mon, 17 Mar 2008 08:33:14 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A07C63A6BE0; Mon, 17 Mar 2008 08:33:14 -0700 (PDT) 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 ACB6F3A6AA4 for ; Mon, 17 Mar 2008 08:33:13 -0700 (PDT) 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 YkPRpz9jHCmi for ; Mon, 17 Mar 2008 08:33:07 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id D96FF3A68B6 for ; Mon, 17 Mar 2008 08:33:06 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail21.telekom.de with ESMTP; Mon, 17 Mar 2008 16:30:49 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Mar 2008 16:30:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 Mar 2008 16:32:12 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CF64580@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <000601c8883b$e3828950$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciIBF++zKz17E/GQcib+W/rjB17BgABJ68gAABXALAAAifOMAAH2KywAACjCyAAAJeqgAAA4wtQAAGeymA= References: <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de> <000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6423C@S4DE8PSAANK.mitte.t-com.de> <001301c88816$114dab60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF644B1@S4DE8PSAANK.mitte.t-com.de> <000001c88835$998bcf60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6451A@S4DE8PSAANK.mitte.t-com.de> <000601c8883b$e3828950$810c5982@dynamic.ewi.utwente.nl> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 17 Mar 2008 15:30:49.0356 (UTC) FILETIME=[E0AB2CC0:01C88843] Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Georgios, QoS on redundant links means, that one link is able to carry the QoS = traffic of the other. This may not hold for non QoS traffic. This is, = what typical carrier backbones providing QoS are engineered for = (commonly known as traffic engineering). Should a misconfiguration occur, things may go wrong. Operational = staff corrects this a soon as the misconfiguration is identified. The engineering of carrier backbones is often done with automated = tools, leaving little room for human errors. However maintenance = work may result in humanne system interference. I doubt that = Telekom's engineering department is willing to accept extra = protocol and router complexitiy to deal with operator configuration = errors. While I time and again hear of the worst misconfigs, I = can't recall that my colleagues try to adapt standardisation = afterwards. Regards, Rudiger | -----Original Message----- | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] = | Sent: Monday, March 17, 2008 3:34 PM | To: Geib, R=FCdiger | Cc: pcn@ietf.org | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | = | Hi Ruediger | = | Please note that typical IP networks (thus not MPLS/GMPLS = | based domains) can recover from failures by using rerouting. = | Or do you know another standardized mechanism in typical IP = | networks (thus not MPLS/GMPLS based) that can provide another = | kind of recovery from failures. | = | Furthermore, I will just explain the example again with = | maximum capacity of | pathh2 being equal | to maximum capacity of path1 =3D C. | Please explain what you do not understand in this example! | = | Here are the assumptions: | * In the PCN domain we assume that ECMP routing is possible! | * ingress-eggress-aggregate can contain flows that are = | passing through one path or more paths (when ECMP routing is used). | = | * routers are currently dropping packets randomly. Thus = | marked and unmarked packets will be | dropped randomly | = | * When excess rate measurements are used, the triggering of = | admission control and flow | termination are done at the egress by using the CLE. One = | example of this trigger is: | CLE > 1%. Note that CLE =3D marked/(unmarked + marked). This = | means that if this trigger is not activated while a severe | congestion occurs in the PCN domain, then the operation of = | the PCN domain will completely collapse. | = | = | My statement is: | If the routers do not preferentially drop marked packets then = | the PCN domain operation, even in corner case and = | misconfiguration situations, is more robust and more stable = | than in the situation that the router is preferentially = | dropping marked packets. | = | The below example show such a corner case! | = | = | I will describe two situations: | = | Situation 1: | Consider that an ingress-egress-aggregate due to ECMP routing = | it includes flows that are passing from at least two paths. | Assume that path1 supports a maximum bandwidth capacity of C. = | Now consider that the maximum bandwdith capacity of path2 is C. | Consider also that both paths are fully utilized. | = | Consider that preferentially marked packets are dropped and = | that path2 fails. | Now assume that all (maximum) traffic passing through path2 = | will be rerouted through path1. = | If a bottleneck router located in path1, say Rbott, is = | misconfigured (i.e., from the point of view of having wrongly = | too high configured-admissible-rate value), or even if it is = | well configured, then it can be possible that CLE measured at = | the egress cannot reach 1%. | Note that | CLE =3D marked packets/ (marked packets + unmarked packets). | This is because Rbott will just allow an excess rate to pass = | through that is | = | equal to: C - configured-admissible-rate. The rest of the = | marked packets, so the rest of the excess rate, will be = | dropped by Rbott, since this router is preferentially = | dropping marked packets. | Furthermore, note that due to the ECMP routing flows that are = | belonging to the same ingress-egress-aggregate and that are = | passing through another path, | = | than path1, which is not congested, will forward traffic = | towards the egress node that will be unmarked. | This will mean that the CLE > 1% will not be triggered, this = | will mean that the flow termination will not be triggered and = | that the operation of the PCN domain will collapse completely. | = | = | Situation 2: | Now consider that the router just operates as currently, = | i.e., no preferential drop, randomly dropping marked and = | unmarked packets. | Consider also that the two paths described in Situation 1 = | above are used, ECMP routing is used, and that they are fully = | utilized. | Assume also that path2 fails and that the path2 traffic is = | rerouted on path1. | Now the CLE value will have a higher probability of reaching = | the triggering value of 1%. | = | This is because the routers in path1 will drop randomly = | marked and unmarked packets. | It is more certain that in this case the CLE will reach 1% = | due to the following reason. | In this example it is assumed that the maximum bandwidth = | capacity supported by path2 is C. = | This means that after rerouting the traffic from path2 into = | path1, the ratio between marked packets and unmarked packets = | that are passing thorugh path1 can be equal or higher than 100%. | Note that the routers in path1 will mark the excess rate = | above C, thus 1*C (i.e., the rerouted traffic from path2) as marked. | The above observation holds also for the situation that the = | routers are preferentially dropping unmarked packets. | = | Thus when routers are preferentially dropping marked packets = | the robustness of the PCN domain operation is decreasing and = | in some cases it severely decreases, which could cause the = | complete collapse of the PCN domain operation. | = | Best regards, | Georgios | = | = | = | = | > -----Original Message----- | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > Sent: maandag 17 maart 2008 15:26 | > To: karagian@cs.utwente.nl | > Cc: pcn@ietf.org | > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | > = | > Hi Georgios, | > = | > Unfortunately you missed my point. | > = | > No such thing as you describe has been, is or will for the = | foreseeable = | > future be engineered in the IP backbone of the company I'm working = | > for. | > = | > My expectation on the backbone of any carrier offering = | transport QoS = | > is, that it is engineered to survive probable failures (like single = | > link losses) without impact on the performance of QoS = | traffic. This is = | > where we should start from, if we discuss PCN. From there = | on, PCN is = | > able to add value. | > = | > Links without traffic engineering followed by misconfigured routers = | > aren't the arguments which will convince either product = | management or = | > backbone engineering of the company I work for to deploy PCN. | > = | > As a general comment: I don't regard PCN as a plug and play toy for = | > the operational equivalent of a 'script kiddie'. If others = | share that = | > view and our documents don't state that, we should add text. | > = | > Regards, | > = | > Rudiger | > = | > | -----Original Message----- | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > | Sent: Monday, March 17, 2008 2:49 PM | > | To: Geib, R=FCdiger | > | Cc: pcn@ietf.org | > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | > | = | > | Hi Ruediger | > | = | > | You missed my point! | > | The explanation applies to all types of IP networks. | > | Please note that the problem occurs also when path2 and path1 use = | > | exactly the same maximum capacity, say C! | > | = | > | In this case, if pathh2 fails then path1 will see an excess | > rate equal | > | to at least C. | > | The rest of the explanation is identical to the one used = | during my = | > | previous example! | > | = | > | = | > | = | > | Best regards, | > | Georgios | > | = | > | = | > | = | > | = | > | = | > | > -----Original Message----- | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > | > Sent: maandag 17 maart 2008 14:34 | > | > To: karagian@cs.utwente.nl | > | > Cc: pcn@ietf.org | > | > Subject: RE: [PCN] Concensus questions from Thursday's = | PCN meeting | > | > = | > | > Hi Georgios, | > | > = | > | > What you describe isn't backbone traffic engineering. What you = | > | > describe may happen in corporate VPNs, where a DSL access | > | is used to | > | > back up a WAN Fast Ethernet access or the like. I don't | > | object to have | > | > standards on PCN for VPNs, but I'm not interested in this | > issue for | > | > now. | > | > = | > | > If you know any carrier who's operating his network with a | > | > 16:1 load balancing for QoS traffic on any particular link | > | set, please | > | > publish the name, we are all interested in hearing it. | > | > = | > | > Regards, | > | > = | > | > Rudiger | > | > = | > | > = | > | > = | > | > | -----Original Message----- | > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > | > | Sent: Monday, March 17, 2008 11:03 AM | > | > | To: Geib, R=FCdiger | > | > | Cc: pcn@ietf.org | > | > | Subject: RE: [PCN] Concensus questions from Thursday's | > PCN meeting | > | > | = | > | > | Hi Ruediger | > | > | = | > | > | I will try to explain this more clearly. | > | > | Here are the assumptions: | > | > | * In the PCN domain we assume that ECMP routing is possible! | > | > | * ingress-eggress-aggregate can contain flows that are | > | > passing through | > | > | one path or more paths (when ECMP routing is used). | > | > | = | > | > | * routers are currently dropping packets randomly. Thus | > | marked and | > | > | unmarked packets will be | > | > | dropped randomly | > | > | = | > | > | * When excess rate measurements are used, the triggering of | > | > admission | > | > | control and flow | > | > | termination are done at the egress by using the CLE. One | > | > example of | > | > | this trigger is: | > | > | CLE > 1%. Note that CLE =3D marked/(unmarked + marked). = | > | This means | > | > | that if this trigger is not activated while a severe | > | > | congestion occurs in the PCN domain, then the operation | > | > of the PCN | > | > | domain will completely collapse. | > | > | = | > | > | = | > | > | My statement is: | > | > | If the routers do not preferentially drop marked packets | > | > then the PCN | > | > | domain operation, even in corner case and misconfiguration | > | > situations, | > | > | is more robust and more stable than in the situation that | > | > the router | > | > | is preferentially dropping marked packets. | > | > | = | > | > | The below example show such a corner case! | > | > | = | > | > | = | > | > | I will describe two situations: | > | > | = | > | > | Situation 1: | > | > | Consider that an ingress-egress-aggregate due to ECMP | > routing it | > | > | includes flows that are passing from at least two paths. | > | > | Assume that path1 supports a maximum bandwidth capacity of C. = | > | > | Now consider | > | > | that the maximum bandwdith capacity of path2 is 15*C. | > | > | Consider also that both paths are fully utilized. | > | > | = | > | > | Consider that preferentially marked packets are dropped and | > | > that path2 | > | > | fails. | > | > | Now assume that all (maximum) traffic passing through | > | path2 will be | > | > | rerouted through path1. | > | > | If a bottleneck router located in path1, say Rbott, is | > | > misconfigured | > | > | (i.e., from the point of view of having wrongly too high = | > | > | configured-admissible-rate value), or even if it is well | > | > configured, | > | > | then it can be possible that CLE measured at the egress | > | > cannot reach | > | > | 1%. | > | > | Note that | > | > | CLE =3D marked packets/ (marked packets + unmarked packets). | > | > | This is because Rbott will just allow an excess rate to | > | > pass through | > | > | that is | > | > | = | > | > | equal to: C - configured-admissible-rate. The rest of | > the marked | > | > | packets, so the rest of the excess rate, will be dropped | > | by Rbott, | > | > | since this router is preferentially dropping marked packets. | > | > | Furthermore, note that due to the ECMP routing flows that are = | > | > | belonging to the same ingress-egress-aggregate and that | > | are passing | > | > | through another path, | > | > | = | > | > | than path1, which is not congested, will forward traffic | > | > towards the | > | > | egress node that will be unmarked. | > | > | This will mean that the CLE > 1% will not be triggered, | > | > this will mean | > | > | that the flow termination will not be triggered and that | > | > the operation | > | > | of the PCN domain will collapse completely. | > | > | = | > | > | = | > | > | Situation 2: | > | > | Now consider that the router just operates as | > currently, i.e., no | > | > | preferential drop, randomly dropping marked and | > unmarked packets. | > | > | Consider also that the two paths described in Situation 1 | > | above are | > | > | used, ECMP routing is used, and that they are fully utilized. | > | > | Assume also that path2 fails and that the path2 traffic is | > | > rerouted on | > | > | path1. | > | > | Now the CLE value will have a higher probability of | > reaching the | > | > | triggering value of 1%. | > | > | = | > | > | This is because the routers in path1 will drop randomly | > | marked and | > | > | unmarked packets. | > | > | It is more certain that in this case the CLE will reach 1% | > | > due to the | > | > | following reason. | > | > | In this example it is assumed that the maximum | > bandwidth capacity | > | > | supported by path2 is 15*C. | > | > | This means that after rerouting the traffic from path2 into | > | > path1, the | > | > | ratio between marked packets and unmarked packets that | > | are passing | > | > | thorugh path1 can be equal or higher than 16. | > | > | Note that the routers in path1 will mark the excess rate | > | > above C, thus | > | > | 16 * C (i.e., the rerouted traffic from path2) as marked. | > | > | The above observation holds also for the situation that | > | the routers | > | > | are preferentially dropping unmarked packets. | > | > | = | > | > | Thus when routers are preferentially dropping marked | > packets the | > | > | robustness of the PCN domain operation is decreasing and in | > | > some cases | > | > | it severely decreases, which could cause the complete | > | > collapse of the | > | > | PCN domain operation. | > | > | = | > | > | Best regards, | > | > | Georgios | > | > | = | > | > | = | > | > | = | > | > | = | > | > | = | > | > | > -----Original Message----- | > | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > | > | > Sent: maandag 17 maart 2008 9:42 | > | > | > To: karagian@cs.utwente.nl | > | > | > Cc: pcn@ietf.org | > | > | > Subject: RE: [PCN] Concensus questions from Thursday's | > | PCN meeting | > | > | > = | > | > | > Hi Georgios, | > | > | > = | > | > | > PCN is designed for deployment in traffic engineered | > networks. = | > | > | > Please decribe, how to engineer a high performance | > | > carrier backbone | > | > | > and then review the assumptions your discussion is based on. | > | > | > = | > | > | > Regards, | > | > | > = | > | > | > Rudiger | > | > | > = | > | > | > | -----Original Message----- | > | > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > | > | > | Sent: Monday, March 17, 2008 9:34 AM | > | > | > | To: Geib, R=FCdiger | > | > | > | Cc: pcn@ietf.org | > | > | > | Subject: RE: [PCN] Concensus questions from Thursday's | > | > PCN meeting | > | > | > | = | > | > | > | Hi Ruediger | > | > | > | = | > | > | > | What do you mean? | > | > | > | Do you mean that you do not want to discuss corner cases | > | > | > (ECMP related | > | > | > | cases) that could | > | > | > | collapse the PCN domain operation? | > | > | > | What I am saying is that if the routers do not | > | > | preferentially drop | > | > | > | marked packets then the PCN domain operation is = | more robust | > | > | > and more | > | > | > | stable than in the situation that the router is | > | preferentially | > | > | > | dropping marked packets. | > | > | > | = | > | > | > | Are you saying that this statement is not right? | > | > | > | = | > | > | > | = | > | > | > | Best regards, | > | > | > | Georgios | > | > | > | = | > | > | > | > | > | = | > | > | = | > | > | = | > | > = | > | = | > | = | > | = | > = | = | = | = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 17 08:37:59 2008 Return-Path: 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 727F43A6E10; Mon, 17 Mar 2008 08:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.756 X-Spam-Level: X-Spam-Status: No, score=-98.756 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100] 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 o87i5lXdz6YV; Mon, 17 Mar 2008 08:37:55 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1B093A6ABE; Mon, 17 Mar 2008 08:37:55 -0700 (PDT) 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 E739B3A6ABE for ; Mon, 17 Mar 2008 08:37:54 -0700 (PDT) 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 sOjhLMEuFHFo for ; Mon, 17 Mar 2008 08:37:54 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 0AE523A6946 for ; Mon, 17 Mar 2008 08:37:53 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m2HFZaJn024001 for ; Mon, 17 Mar 2008 10:35:37 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Mar 2008 10:35:36 -0500 Received: from [147.117.169.77] ([147.117.169.77]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Mar 2008 10:35:36 -0500 From: Steven Blake To: pcn Organization: Ericsson IP Infrastructure Date: Mon, 17 Mar 2008 11:35:35 -0400 Message-Id: <1205768135.4200.2.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) X-OriginalArrivalTime: 17 Mar 2008 15:35:36.0520 (UTC) FILETIME=[8BD4EC80:01C88844] Subject: [PCN] Testing X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org please ignore =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 17 08:41:42 2008 Return-Path: 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 42FCE3A6E11; Mon, 17 Mar 2008 08:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.163 X-Spam-Level: X-Spam-Status: No, score=-100.163 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 xb2+s30XoCBx; Mon, 17 Mar 2008 08:41:35 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C963E3A6AD5; Mon, 17 Mar 2008 08:41:35 -0700 (PDT) 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 9D5273A6D8A for ; Mon, 17 Mar 2008 08:41:31 -0700 (PDT) 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 IaKNzUwUhhjB for ; Mon, 17 Mar 2008 08:41:25 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 433BA3A6D0F for ; Mon, 17 Mar 2008 08:40:54 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m2HFcUkA023965; Mon, 17 Mar 2008 16:38:34 +0100 (MET) From: "Georgios Karagiannis" To: "'Geib, Ruediger'" References: <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de> <000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6423C@S4DE8PSAANK.mitte.t-com.de> <001301c88816$114dab60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF644B1@S4DE8PSAANK.mitte.t-com.de> <000001c88835$998bcf60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6451A@S4DE8PSAANK.mitte.t-com.de> <000601c8883b$e3828950$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF64580@S4DE8PSAANK.mitte.t-com.de> Date: Mon, 17 Mar 2008 16:38:25 +0100 Message-ID: <000901c88844$f35c1130$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <1B6169C658325341A3B8066E23919E1CF64580@S4DE8PSAANK.mitte.t-com.de> Thread-Index: AciIBF++zKz17E/GQcib+W/rjB17BgABJ68gAABXALAAAifOMAAH2KywAACjCyAAAJeqgAAA4wtQAAGeymAAAM8HgA== X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 17 Mar 2008 16:38:37 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ruediger I do not understand what you try to say. Please note that flow termination is used for the below explained reason, see below text taken from the PCN architecture draft: o The termination mechanism complements admission control. It allows the network to recover from sudden unexpected surges of PCN-traffic on some links, thus restoring QoS to the remaining flows. Such scenarios are expected to be rare but not impossible. They can be caused by large network failures that redirect lots of admitted PCN-traffic to other links, or by malfunction of the measurement-based admission control in the presence of admitted flows that send for a while with an atypically low rate and then increase their rates in a correlated way. Best regards, Georgios = > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] = > Sent: maandag 17 maart 2008 16:32 > To: karagian@cs.utwente.nl > Cc: pcn@ietf.org > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > = > Hi Georgios, > = > QoS on redundant links means, that one link is able to carry = > the QoS traffic of the other. This may not hold for non QoS = > traffic. This is, what typical carrier backbones providing = > QoS are engineered for (commonly known as traffic engineering). > = > Should a misconfiguration occur, things may go wrong. = > Operational staff corrects this a soon as the = > misconfiguration is identified. > = > The engineering of carrier backbones is often done with = > automated tools, leaving little room for human errors. = > However maintenance work may result in humanne system = > interference. I doubt that Telekom's engineering department = > is willing to accept extra protocol and router complexitiy to = > deal with operator configuration errors. While I time and = > again hear of the worst misconfigs, I can't recall that my = > colleagues try to adapt standardisation afterwards. > = > Regards, > = > Rudiger > = > | -----Original Message----- > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | Sent: Monday, March 17, 2008 3:34 PM > | To: Geib, R=FCdiger > | Cc: pcn@ietf.org > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > | = > | Hi Ruediger > | = > | Please note that typical IP networks (thus not MPLS/GMPLS based = > | domains) can recover from failures by using rerouting. > | Or do you know another standardized mechanism in typical IP = > networks = > | (thus not MPLS/GMPLS based) that can provide another kind = > of recovery = > | from failures. > | = > | Furthermore, I will just explain the example again with maximum = > | capacity of > | pathh2 being equal > | to maximum capacity of path1 =3D C. > | Please explain what you do not understand in this example! > | = > | Here are the assumptions: > | * In the PCN domain we assume that ECMP routing is possible! > | * ingress-eggress-aggregate can contain flows that are = > passing through = > | one path or more paths (when ECMP routing is used). > | = > | * routers are currently dropping packets randomly. Thus marked and = > | unmarked packets will be > | dropped randomly > | = > | * When excess rate measurements are used, the triggering of = > admission = > | control and flow > | termination are done at the egress by using the CLE. One = > example of = > | this trigger is: > | CLE > 1%. Note that CLE =3D marked/(unmarked + marked). This means = > | that if this trigger is not activated while a severe > | congestion occurs in the PCN domain, then the operation = > of the PCN = > | domain will completely collapse. > | = > | = > | My statement is: > | If the routers do not preferentially drop marked packets = > then the PCN = > | domain operation, even in corner case and misconfiguration = > situations, = > | is more robust and more stable than in the situation that = > the router = > | is preferentially dropping marked packets. > | = > | The below example show such a corner case! > | = > | = > | I will describe two situations: > | = > | Situation 1: > | Consider that an ingress-egress-aggregate due to ECMP routing it = > | includes flows that are passing from at least two paths. > | Assume that path1 supports a maximum bandwidth capacity of C. = > | Now consider that the maximum bandwdith capacity of path2 is C. > | Consider also that both paths are fully utilized. > | = > | Consider that preferentially marked packets are dropped and = > that path2 = > | fails. > | Now assume that all (maximum) traffic passing through path2 will be = > | rerouted through path1. > | If a bottleneck router located in path1, say Rbott, is = > misconfigured = > | (i.e., from the point of view of having wrongly too high = > | configured-admissible-rate value), or even if it is well = > configured, = > | then it can be possible that CLE measured at the egress = > cannot reach = > | 1%. > | Note that > | CLE =3D marked packets/ (marked packets + unmarked packets). > | This is because Rbott will just allow an excess rate to = > pass through = > | that is > | = > | equal to: C - configured-admissible-rate. The rest of the marked = > | packets, so the rest of the excess rate, will be dropped by Rbott, = > | since this router is preferentially dropping marked packets. > | Furthermore, note that due to the ECMP routing flows that are = > | belonging to the same ingress-egress-aggregate and that are passing = > | through another path, > | = > | than path1, which is not congested, will forward traffic = > towards the = > | egress node that will be unmarked. > | This will mean that the CLE > 1% will not be triggered, = > this will mean = > | that the flow termination will not be triggered and that = > the operation = > | of the PCN domain will collapse completely. > | = > | = > | Situation 2: > | Now consider that the router just operates as currently, i.e., no = > | preferential drop, randomly dropping marked and unmarked packets. > | Consider also that the two paths described in Situation 1 above are = > | used, ECMP routing is used, and that they are fully utilized. > | Assume also that path2 fails and that the path2 traffic is = > rerouted on = > | path1. > | Now the CLE value will have a higher probability of reaching the = > | triggering value of 1%. > | = > | This is because the routers in path1 will drop randomly marked and = > | unmarked packets. > | It is more certain that in this case the CLE will reach 1% = > due to the = > | following reason. > | In this example it is assumed that the maximum bandwidth capacity = > | supported by path2 is C. > | This means that after rerouting the traffic from path2 into = > path1, the = > | ratio between marked packets and unmarked packets that are passing = > | thorugh path1 can be equal or higher than 100%. > | Note that the routers in path1 will mark the excess rate = > above C, thus = > | 1*C (i.e., the rerouted traffic from path2) as marked. > | The above observation holds also for the situation that the routers = > | are preferentially dropping unmarked packets. > | = > | Thus when routers are preferentially dropping marked packets the = > | robustness of the PCN domain operation is decreasing and in = > some cases = > | it severely decreases, which could cause the complete = > collapse of the = > | PCN domain operation. > | = > | Best regards, > | Georgios > | = > | = > | = > | = > | > -----Original Message----- > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > | > Sent: maandag 17 maart 2008 15:26 > | > To: karagian@cs.utwente.nl > | > Cc: pcn@ietf.org > | > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > | > = > | > Hi Georgios, > | > = > | > Unfortunately you missed my point. > | > = > | > No such thing as you describe has been, is or will for the > | foreseeable > | > future be engineered in the IP backbone of the company = > I'm working = > | > for. > | > = > | > My expectation on the backbone of any carrier offering > | transport QoS > | > is, that it is engineered to survive probable failures = > (like single = > | > link losses) without impact on the performance of QoS > | traffic. This is > | > where we should start from, if we discuss PCN. From there > | on, PCN is > | > able to add value. > | > = > | > Links without traffic engineering followed by = > misconfigured routers = > | > aren't the arguments which will convince either product > | management or > | > backbone engineering of the company I work for to deploy PCN. > | > = > | > As a general comment: I don't regard PCN as a plug and = > play toy for = > | > the operational equivalent of a 'script kiddie'. If others > | share that > | > view and our documents don't state that, we should add text. > | > = > | > Regards, > | > = > | > Rudiger > | > = > | > | -----Original Message----- > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | > | Sent: Monday, March 17, 2008 2:49 PM > | > | To: Geib, R=FCdiger > | > | Cc: pcn@ietf.org > | > | Subject: RE: [PCN] Concensus questions from Thursday's = > PCN meeting > | > | = > | > | Hi Ruediger > | > | = > | > | You missed my point! > | > | The explanation applies to all types of IP networks. > | > | Please note that the problem occurs also when path2 and = > path1 use = > | > | exactly the same maximum capacity, say C! > | > | = > | > | In this case, if pathh2 fails then path1 will see an excess > | > rate equal > | > | to at least C. > | > | The rest of the explanation is identical to the one used > | during my > | > | previous example! > | > | = > | > | = > | > | = > | > | Best regards, > | > | Georgios > | > | = > | > | = > | > | = > | > | = > | > | = > | > | > -----Original Message----- > | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > | > | > Sent: maandag 17 maart 2008 14:34 > | > | > To: karagian@cs.utwente.nl > | > | > Cc: pcn@ietf.org > | > | > Subject: RE: [PCN] Concensus questions from Thursday's > | PCN meeting > | > | > = > | > | > Hi Georgios, > | > | > = > | > | > What you describe isn't backbone traffic engineering. = > What you = > | > | > describe may happen in corporate VPNs, where a DSL access > | > | is used to > | > | > back up a WAN Fast Ethernet access or the like. I don't > | > | object to have > | > | > standards on PCN for VPNs, but I'm not interested in this > | > issue for > | > | > now. > | > | > = > | > | > If you know any carrier who's operating his network with a > | > | > 16:1 load balancing for QoS traffic on any particular link > | > | set, please > | > | > publish the name, we are all interested in hearing it. > | > | > = > | > | > Regards, > | > | > = > | > | > Rudiger > | > | > = > | > | > = > | > | > = > | > | > | -----Original Message----- > | > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | > | > | Sent: Monday, March 17, 2008 11:03 AM > | > | > | To: Geib, R=FCdiger > | > | > | Cc: pcn@ietf.org > | > | > | Subject: RE: [PCN] Concensus questions from Thursday's > | > PCN meeting > | > | > | = > | > | > | Hi Ruediger > | > | > | = > | > | > | I will try to explain this more clearly. > | > | > | Here are the assumptions: > | > | > | * In the PCN domain we assume that ECMP routing is possible! > | > | > | * ingress-eggress-aggregate can contain flows that are > | > | > passing through > | > | > | one path or more paths (when ECMP routing is used). > | > | > | = > | > | > | * routers are currently dropping packets randomly. Thus > | > | marked and > | > | > | unmarked packets will be > | > | > | dropped randomly > | > | > | = > | > | > | * When excess rate measurements are used, the triggering of > | > | > admission > | > | > | control and flow > | > | > | termination are done at the egress by using the CLE. One > | > | > example of > | > | > | this trigger is: > | > | > | CLE > 1%. Note that CLE =3D marked/(unmarked + marked). = > | > | This means > | > | > | that if this trigger is not activated while a severe > | > | > | congestion occurs in the PCN domain, then the operation > | > | > of the PCN > | > | > | domain will completely collapse. > | > | > | = > | > | > | = > | > | > | My statement is: > | > | > | If the routers do not preferentially drop marked packets > | > | > then the PCN > | > | > | domain operation, even in corner case and misconfiguration > | > | > situations, > | > | > | is more robust and more stable than in the situation that > | > | > the router > | > | > | is preferentially dropping marked packets. > | > | > | = > | > | > | The below example show such a corner case! > | > | > | = > | > | > | = > | > | > | I will describe two situations: > | > | > | = > | > | > | Situation 1: > | > | > | Consider that an ingress-egress-aggregate due to ECMP > | > routing it > | > | > | includes flows that are passing from at least two paths. > | > | > | Assume that path1 supports a maximum bandwidth = > capacity of C. = > | > | > | Now consider > | > | > | that the maximum bandwdith capacity of path2 is 15*C. > | > | > | Consider also that both paths are fully utilized. > | > | > | = > | > | > | Consider that preferentially marked packets are dropped and > | > | > that path2 > | > | > | fails. > | > | > | Now assume that all (maximum) traffic passing through > | > | path2 will be > | > | > | rerouted through path1. > | > | > | If a bottleneck router located in path1, say Rbott, is > | > | > misconfigured > | > | > | (i.e., from the point of view of having wrongly too high = > | > | > | configured-admissible-rate value), or even if it is well > | > | > configured, > | > | > | then it can be possible that CLE measured at the egress > | > | > cannot reach > | > | > | 1%. > | > | > | Note that > | > | > | CLE =3D marked packets/ (marked packets + unmarked packets). > | > | > | This is because Rbott will just allow an excess rate to > | > | > pass through > | > | > | that is > | > | > | = > | > | > | equal to: C - configured-admissible-rate. The rest of > | > the marked > | > | > | packets, so the rest of the excess rate, will be dropped > | > | by Rbott, > | > | > | since this router is preferentially dropping marked packets. > | > | > | Furthermore, note that due to the ECMP routing = > flows that are = > | > | > | belonging to the same ingress-egress-aggregate and that > | > | are passing > | > | > | through another path, > | > | > | = > | > | > | than path1, which is not congested, will forward traffic > | > | > towards the > | > | > | egress node that will be unmarked. > | > | > | This will mean that the CLE > 1% will not be triggered, > | > | > this will mean > | > | > | that the flow termination will not be triggered and that > | > | > the operation > | > | > | of the PCN domain will collapse completely. > | > | > | = > | > | > | = > | > | > | Situation 2: > | > | > | Now consider that the router just operates as > | > currently, i.e., no > | > | > | preferential drop, randomly dropping marked and > | > unmarked packets. > | > | > | Consider also that the two paths described in Situation 1 > | > | above are > | > | > | used, ECMP routing is used, and that they are fully = > utilized. > | > | > | Assume also that path2 fails and that the path2 traffic is > | > | > rerouted on > | > | > | path1. > | > | > | Now the CLE value will have a higher probability of > | > reaching the > | > | > | triggering value of 1%. > | > | > | = > | > | > | This is because the routers in path1 will drop randomly > | > | marked and > | > | > | unmarked packets. > | > | > | It is more certain that in this case the CLE will reach 1% > | > | > due to the > | > | > | following reason. > | > | > | In this example it is assumed that the maximum > | > bandwidth capacity > | > | > | supported by path2 is 15*C. > | > | > | This means that after rerouting the traffic from path2 into > | > | > path1, the > | > | > | ratio between marked packets and unmarked packets that > | > | are passing > | > | > | thorugh path1 can be equal or higher than 16. > | > | > | Note that the routers in path1 will mark the excess rate > | > | > above C, thus > | > | > | 16 * C (i.e., the rerouted traffic from path2) as marked. > | > | > | The above observation holds also for the situation that > | > | the routers > | > | > | are preferentially dropping unmarked packets. > | > | > | = > | > | > | Thus when routers are preferentially dropping marked > | > packets the > | > | > | robustness of the PCN domain operation is decreasing and in > | > | > some cases > | > | > | it severely decreases, which could cause the complete > | > | > collapse of the > | > | > | PCN domain operation. > | > | > | = > | > | > | Best regards, > | > | > | Georgios > | > | > | = > | > | > | = > | > | > | = > | > | > | = > | > | > | = > | > | > | > -----Original Message----- > | > | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > | > | > | > Sent: maandag 17 maart 2008 9:42 > | > | > | > To: karagian@cs.utwente.nl > | > | > | > Cc: pcn@ietf.org > | > | > | > Subject: RE: [PCN] Concensus questions from Thursday's > | > | PCN meeting > | > | > | > = > | > | > | > Hi Georgios, > | > | > | > = > | > | > | > PCN is designed for deployment in traffic engineered > | > networks. = > | > | > | > Please decribe, how to engineer a high performance > | > | > carrier backbone > | > | > | > and then review the assumptions your discussion = > is based on. > | > | > | > = > | > | > | > Regards, > | > | > | > = > | > | > | > Rudiger > | > | > | > = > | > | > | > | -----Original Message----- > | > | > | > | From: Georgios Karagiannis = > [mailto:karagian@cs.utwente.nl] > | > | > | > | Sent: Monday, March 17, 2008 9:34 AM > | > | > | > | To: Geib, R=FCdiger > | > | > | > | Cc: pcn@ietf.org > | > | > | > | Subject: RE: [PCN] Concensus questions from Thursday's > | > | > PCN meeting > | > | > | > | = > | > | > | > | Hi Ruediger > | > | > | > | = > | > | > | > | What do you mean? > | > | > | > | Do you mean that you do not want to discuss corner cases > | > | > | > (ECMP related > | > | > | > | cases) that could > | > | > | > | collapse the PCN domain operation? > | > | > | > | What I am saying is that if the routers do not > | > | > | preferentially drop > | > | > | > | marked packets then the PCN domain operation is > | more robust > | > | > | > and more > | > | > | > | stable than in the situation that the router is > | > | preferentially > | > | > | > | dropping marked packets. > | > | > | > | = > | > | > | > | Are you saying that this statement is not right? > | > | > | > | = > | > | > | > | = > | > | > | > | Best regards, > | > | > | > | Georgios > | > | > | > | = > | > | > | > > | > | > | = > | > | > | = > | > | > | = > | > | > = > | > | = > | > | = > | > | = > | > = > | = > | = > | = > = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 17 09:10:48 2008 Return-Path: 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 1B97528C40B; Mon, 17 Mar 2008 09:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.671 X-Spam-Level: X-Spam-Status: No, score=-100.671 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 n8yq3VDQ805O; Mon, 17 Mar 2008 09:10:40 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2A443A6C1A; Mon, 17 Mar 2008 09:10:39 -0700 (PDT) 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 C40323A6B88 for ; Mon, 17 Mar 2008 09:10:38 -0700 (PDT) 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 sXB91fKddPuy for ; Mon, 17 Mar 2008 09:10:36 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 0F3883A6946 for ; Mon, 17 Mar 2008 09:10:35 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail21.telekom.de with ESMTP; Mon, 17 Mar 2008 17:08:18 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 Mar 2008 17:08:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 Mar 2008 17:09:39 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CF645A3@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <000901c88844$f35c1130$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciIBF++zKz17E/GQcib+W/rjB17BgABJ68gAABXALAAAifOMAAH2KywAACjCyAAAJeqgAAA4wtQAAGeymAAAM8HgAAA8S7A References: <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de> <000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6423C@S4DE8PSAANK.mitte.t-com.de> <001301c88816$114dab60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF644B1@S4DE8PSAANK.mitte.t-com.de> <000001c88835$998bcf60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6451A@S4DE8PSAANK.mitte.t-com.de> <000601c8883b$e3828950$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF64580@S4DE8PSAANK.mitte.t-com.de> <000901c88844$f35c1130$810c5982@dynamic.ewi.utwente.nl> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 17 Mar 2008 16:08:16.0711 (UTC) FILETIME=[1C325570:01C88849] Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Georgios, what I say is if PCN decides to deal with catastrophic events in = combination with misconfigured routers, then it will end up = standardising solutions for academic problems. Regards, Rudiger | -----Original Message----- | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] = | Sent: Monday, March 17, 2008 4:38 PM | To: Geib, R=FCdiger | Cc: pcn@ietf.org | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | = | Hi Ruediger | = | I do not understand what you try to say. Please note that = | flow termination is used for the below explained reason, see = | below text taken from the PCN architecture draft: | = | o The termination mechanism complements admission control. It | allows the network to recover from sudden unexpected surges of | PCN-traffic on some links, thus restoring QoS to the remaining | flows. Such scenarios are expected to be rare but not = | impossible. | They can be caused by large network failures that = | redirect lots of | admitted PCN-traffic to other links, or by malfunction of the | measurement-based admission control in the presence of admitted | flows that send for a while with an atypically low rate and then | increase their rates in a correlated way. | = | Best regards, | Georgios | = | = | = | > -----Original Message----- | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > Sent: maandag 17 maart 2008 16:32 | > To: karagian@cs.utwente.nl | > Cc: pcn@ietf.org | > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | > = | > Hi Georgios, | > = | > QoS on redundant links means, that one link is able to = | carry the QoS = | > traffic of the other. This may not hold for non QoS = | traffic. This is, = | > what typical carrier backbones providing QoS are engineered for = | > (commonly known as traffic engineering). | > = | > Should a misconfiguration occur, things may go wrong. = | > Operational staff corrects this a soon as the misconfiguration is = | > identified. | > = | > The engineering of carrier backbones is often done with automated = | > tools, leaving little room for human errors. | > However maintenance work may result in humanne system = | interference. I = | > doubt that Telekom's engineering department is willing to = | accept extra = | > protocol and router complexitiy to deal with operator configuration = | > errors. While I time and again hear of the worst = | misconfigs, I can't = | > recall that my colleagues try to adapt standardisation afterwards. | > = | > Regards, | > = | > Rudiger | > = | > | -----Original Message----- | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > | Sent: Monday, March 17, 2008 3:34 PM | > | To: Geib, R=FCdiger | > | Cc: pcn@ietf.org | > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | > | = | > | Hi Ruediger | > | = | > | Please note that typical IP networks (thus not MPLS/GMPLS based | > | domains) can recover from failures by using rerouting. | > | Or do you know another standardized mechanism in typical IP | > networks | > | (thus not MPLS/GMPLS based) that can provide another kind | > of recovery | > | from failures. | > | = | > | Furthermore, I will just explain the example again with maximum = | > | capacity of | > | pathh2 being equal | > | to maximum capacity of path1 =3D C. | > | Please explain what you do not understand in this example! | > | = | > | Here are the assumptions: | > | * In the PCN domain we assume that ECMP routing is possible! | > | * ingress-eggress-aggregate can contain flows that are | > passing through | > | one path or more paths (when ECMP routing is used). | > | = | > | * routers are currently dropping packets randomly. Thus = | marked and = | > | unmarked packets will be | > | dropped randomly | > | = | > | * When excess rate measurements are used, the triggering of | > admission | > | control and flow | > | termination are done at the egress by using the CLE. One | > example of | > | this trigger is: | > | CLE > 1%. Note that CLE =3D marked/(unmarked + marked). = | This means = | > | that if this trigger is not activated while a severe | > | congestion occurs in the PCN domain, then the operation | > of the PCN | > | domain will completely collapse. | > | = | > | = | > | My statement is: | > | If the routers do not preferentially drop marked packets | > then the PCN | > | domain operation, even in corner case and misconfiguration | > situations, | > | is more robust and more stable than in the situation that | > the router | > | is preferentially dropping marked packets. | > | = | > | The below example show such a corner case! | > | = | > | = | > | I will describe two situations: | > | = | > | Situation 1: | > | Consider that an ingress-egress-aggregate due to ECMP routing it = | > | includes flows that are passing from at least two paths. | > | Assume that path1 supports a maximum bandwidth capacity of C. = | > | Now consider that the maximum bandwdith capacity of path2 is C. | > | Consider also that both paths are fully utilized. | > | = | > | Consider that preferentially marked packets are dropped and | > that path2 | > | fails. | > | Now assume that all (maximum) traffic passing through = | path2 will be = | > | rerouted through path1. | > | If a bottleneck router located in path1, say Rbott, is | > misconfigured | > | (i.e., from the point of view of having wrongly too high = | > | configured-admissible-rate value), or even if it is well | > configured, | > | then it can be possible that CLE measured at the egress | > cannot reach | > | 1%. | > | Note that | > | CLE =3D marked packets/ (marked packets + unmarked packets). | > | This is because Rbott will just allow an excess rate to | > pass through | > | that is | > | = | > | equal to: C - configured-admissible-rate. The rest of the marked = | > | packets, so the rest of the excess rate, will be dropped = | by Rbott, = | > | since this router is preferentially dropping marked packets. | > | Furthermore, note that due to the ECMP routing flows that are = | > | belonging to the same ingress-egress-aggregate and that = | are passing = | > | through another path, | > | = | > | than path1, which is not congested, will forward traffic | > towards the | > | egress node that will be unmarked. | > | This will mean that the CLE > 1% will not be triggered, | > this will mean | > | that the flow termination will not be triggered and that | > the operation | > | of the PCN domain will collapse completely. | > | = | > | = | > | Situation 2: | > | Now consider that the router just operates as currently, i.e., no = | > | preferential drop, randomly dropping marked and unmarked packets. | > | Consider also that the two paths described in Situation 1 = | above are = | > | used, ECMP routing is used, and that they are fully utilized. | > | Assume also that path2 fails and that the path2 traffic is | > rerouted on | > | path1. | > | Now the CLE value will have a higher probability of reaching the = | > | triggering value of 1%. | > | = | > | This is because the routers in path1 will drop randomly = | marked and = | > | unmarked packets. | > | It is more certain that in this case the CLE will reach 1% | > due to the | > | following reason. | > | In this example it is assumed that the maximum bandwidth capacity = | > | supported by path2 is C. | > | This means that after rerouting the traffic from path2 into | > path1, the | > | ratio between marked packets and unmarked packets that = | are passing = | > | thorugh path1 can be equal or higher than 100%. | > | Note that the routers in path1 will mark the excess rate | > above C, thus | > | 1*C (i.e., the rerouted traffic from path2) as marked. | > | The above observation holds also for the situation that = | the routers = | > | are preferentially dropping unmarked packets. | > | = | > | Thus when routers are preferentially dropping marked packets the = | > | robustness of the PCN domain operation is decreasing and in | > some cases | > | it severely decreases, which could cause the complete | > collapse of the | > | PCN domain operation. | > | = | > | Best regards, | > | Georgios | > | = | > | = | > | = | > | = | > | > -----Original Message----- | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > | > Sent: maandag 17 maart 2008 15:26 | > | > To: karagian@cs.utwente.nl | > | > Cc: pcn@ietf.org | > | > Subject: RE: [PCN] Concensus questions from Thursday's = | PCN meeting | > | > = | > | > Hi Georgios, | > | > = | > | > Unfortunately you missed my point. | > | > = | > | > No such thing as you describe has been, is or will for the | > | foreseeable | > | > future be engineered in the IP backbone of the company | > I'm working | > | > for. | > | > = | > | > My expectation on the backbone of any carrier offering | > | transport QoS | > | > is, that it is engineered to survive probable failures | > (like single | > | > link losses) without impact on the performance of QoS | > | traffic. This is | > | > where we should start from, if we discuss PCN. From there | > | on, PCN is | > | > able to add value. | > | > = | > | > Links without traffic engineering followed by | > misconfigured routers | > | > aren't the arguments which will convince either product | > | management or | > | > backbone engineering of the company I work for to deploy PCN. | > | > = | > | > As a general comment: I don't regard PCN as a plug and | > play toy for | > | > the operational equivalent of a 'script kiddie'. If others | > | share that | > | > view and our documents don't state that, we should add text. | > | > = | > | > Regards, | > | > = | > | > Rudiger | > | > = | > | > | -----Original Message----- | > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > | > | Sent: Monday, March 17, 2008 2:49 PM | > | > | To: Geib, R=FCdiger | > | > | Cc: pcn@ietf.org | > | > | Subject: RE: [PCN] Concensus questions from Thursday's | > PCN meeting | > | > | = | > | > | Hi Ruediger | > | > | = | > | > | You missed my point! | > | > | The explanation applies to all types of IP networks. | > | > | Please note that the problem occurs also when path2 and | > path1 use | > | > | exactly the same maximum capacity, say C! | > | > | = | > | > | In this case, if pathh2 fails then path1 will see an excess | > | > rate equal | > | > | to at least C. | > | > | The rest of the explanation is identical to the one used | > | during my | > | > | previous example! | > | > | = | > | > | = | > | > | = | > | > | Best regards, | > | > | Georgios | > | > | = | > | > | = | > | > | = | > | > | = | > | > | = | > | > | > -----Original Message----- | > | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > | > | > Sent: maandag 17 maart 2008 14:34 | > | > | > To: karagian@cs.utwente.nl | > | > | > Cc: pcn@ietf.org | > | > | > Subject: RE: [PCN] Concensus questions from Thursday's | > | PCN meeting | > | > | > = | > | > | > Hi Georgios, | > | > | > = | > | > | > What you describe isn't backbone traffic engineering. = | > What you | > | > | > describe may happen in corporate VPNs, where a DSL access | > | > | is used to | > | > | > back up a WAN Fast Ethernet access or the like. I don't | > | > | object to have | > | > | > standards on PCN for VPNs, but I'm not interested in this | > | > issue for | > | > | > now. | > | > | > = | > | > | > If you know any carrier who's operating his network with a | > | > | > 16:1 load balancing for QoS traffic on any particular link | > | > | set, please | > | > | > publish the name, we are all interested in hearing it. | > | > | > = | > | > | > Regards, | > | > | > = | > | > | > Rudiger | > | > | > = | > | > | > = | > | > | > = | > | > | > | -----Original Message----- | > | > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > | > | > | Sent: Monday, March 17, 2008 11:03 AM | > | > | > | To: Geib, R=FCdiger | > | > | > | Cc: pcn@ietf.org | > | > | > | Subject: RE: [PCN] Concensus questions from Thursday's | > | > PCN meeting | > | > | > | = | > | > | > | Hi Ruediger | > | > | > | = | > | > | > | I will try to explain this more clearly. | > | > | > | Here are the assumptions: | > | > | > | * In the PCN domain we assume that ECMP routing = | is possible! | > | > | > | * ingress-eggress-aggregate can contain flows that are | > | > | > passing through | > | > | > | one path or more paths (when ECMP routing is used). | > | > | > | = | > | > | > | * routers are currently dropping packets randomly. Thus | > | > | marked and | > | > | > | unmarked packets will be | > | > | > | dropped randomly | > | > | > | = | > | > | > | * When excess rate measurements are used, the = | triggering of | > | > | > admission | > | > | > | control and flow | > | > | > | termination are done at the egress by using the CLE. One | > | > | > example of | > | > | > | this trigger is: | > | > | > | CLE > 1%. Note that CLE =3D marked/(unmarked + marked). = | > | > | This means | > | > | > | that if this trigger is not activated while a severe | > | > | > | congestion occurs in the PCN domain, then the operation | > | > | > of the PCN | > | > | > | domain will completely collapse. | > | > | > | = | > | > | > | = | > | > | > | My statement is: | > | > | > | If the routers do not preferentially drop marked packets | > | > | > then the PCN | > | > | > | domain operation, even in corner case and misconfiguration | > | > | > situations, | > | > | > | is more robust and more stable than in the situation that | > | > | > the router | > | > | > | is preferentially dropping marked packets. | > | > | > | = | > | > | > | The below example show such a corner case! | > | > | > | = | > | > | > | = | > | > | > | I will describe two situations: | > | > | > | = | > | > | > | Situation 1: | > | > | > | Consider that an ingress-egress-aggregate due to ECMP | > | > routing it | > | > | > | includes flows that are passing from at least two paths. | > | > | > | Assume that path1 supports a maximum bandwidth | > capacity of C. = | > | > | > | Now consider | > | > | > | that the maximum bandwdith capacity of path2 is 15*C. | > | > | > | Consider also that both paths are fully utilized. | > | > | > | = | > | > | > | Consider that preferentially marked packets are = | dropped and | > | > | > that path2 | > | > | > | fails. | > | > | > | Now assume that all (maximum) traffic passing through | > | > | path2 will be | > | > | > | rerouted through path1. | > | > | > | If a bottleneck router located in path1, say Rbott, is | > | > | > misconfigured | > | > | > | (i.e., from the point of view of having wrongly too high = | > | > | > | configured-admissible-rate value), or even if it is well | > | > | > configured, | > | > | > | then it can be possible that CLE measured at the egress | > | > | > cannot reach | > | > | > | 1%. | > | > | > | Note that | > | > | > | CLE =3D marked packets/ (marked packets + unmarked packets). | > | > | > | This is because Rbott will just allow an excess rate to | > | > | > pass through | > | > | > | that is | > | > | > | = | > | > | > | equal to: C - configured-admissible-rate. The rest of | > | > the marked | > | > | > | packets, so the rest of the excess rate, will be dropped | > | > | by Rbott, | > | > | > | since this router is preferentially dropping = | marked packets. | > | > | > | Furthermore, note that due to the ECMP routing | > flows that are | > | > | > | belonging to the same ingress-egress-aggregate and that | > | > | are passing | > | > | > | through another path, | > | > | > | = | > | > | > | than path1, which is not congested, will forward traffic | > | > | > towards the | > | > | > | egress node that will be unmarked. | > | > | > | This will mean that the CLE > 1% will not be triggered, | > | > | > this will mean | > | > | > | that the flow termination will not be triggered and that | > | > | > the operation | > | > | > | of the PCN domain will collapse completely. | > | > | > | = | > | > | > | = | > | > | > | Situation 2: | > | > | > | Now consider that the router just operates as | > | > currently, i.e., no | > | > | > | preferential drop, randomly dropping marked and | > | > unmarked packets. | > | > | > | Consider also that the two paths described in Situation 1 | > | > | above are | > | > | > | used, ECMP routing is used, and that they are fully | > utilized. | > | > | > | Assume also that path2 fails and that the path2 traffic is | > | > | > rerouted on | > | > | > | path1. | > | > | > | Now the CLE value will have a higher probability of | > | > reaching the | > | > | > | triggering value of 1%. | > | > | > | = | > | > | > | This is because the routers in path1 will drop randomly | > | > | marked and | > | > | > | unmarked packets. | > | > | > | It is more certain that in this case the CLE will reach 1% | > | > | > due to the | > | > | > | following reason. | > | > | > | In this example it is assumed that the maximum | > | > bandwidth capacity | > | > | > | supported by path2 is 15*C. | > | > | > | This means that after rerouting the traffic from = | path2 into | > | > | > path1, the | > | > | > | ratio between marked packets and unmarked packets that | > | > | are passing | > | > | > | thorugh path1 can be equal or higher than 16. | > | > | > | Note that the routers in path1 will mark the excess rate | > | > | > above C, thus | > | > | > | 16 * C (i.e., the rerouted traffic from path2) as marked. | > | > | > | The above observation holds also for the situation that | > | > | the routers | > | > | > | are preferentially dropping unmarked packets. | > | > | > | = | > | > | > | Thus when routers are preferentially dropping marked | > | > packets the | > | > | > | robustness of the PCN domain operation is = | decreasing and in | > | > | > some cases | > | > | > | it severely decreases, which could cause the complete | > | > | > collapse of the | > | > | > | PCN domain operation. | > | > | > | = | > | > | > | Best regards, | > | > | > | Georgios | > | > | > | = | > | > | > | = | > | > | > | = | > | > | > | = | > | > | > | = | > | > | > | > -----Original Message----- | > | > | > | > From: Geib, Ruediger = | [mailto:Ruediger.Geib@t-systems.com] | > | > | > | > Sent: maandag 17 maart 2008 9:42 | > | > | > | > To: karagian@cs.utwente.nl | > | > | > | > Cc: pcn@ietf.org | > | > | > | > Subject: RE: [PCN] Concensus questions from Thursday's | > | > | PCN meeting | > | > | > | > = | > | > | > | > Hi Georgios, | > | > | > | > = | > | > | > | > PCN is designed for deployment in traffic engineered | > | > networks. = | > | > | > | > Please decribe, how to engineer a high performance | > | > | > carrier backbone | > | > | > | > and then review the assumptions your discussion | > is based on. | > | > | > | > = | > | > | > | > Regards, | > | > | > | > = | > | > | > | > Rudiger | > | > | > | > = | > | > | > | > | -----Original Message----- | > | > | > | > | From: Georgios Karagiannis | > [mailto:karagian@cs.utwente.nl] | > | > | > | > | Sent: Monday, March 17, 2008 9:34 AM | > | > | > | > | To: Geib, R=FCdiger | > | > | > | > | Cc: pcn@ietf.org | > | > | > | > | Subject: RE: [PCN] Concensus questions from Thursday's | > | > | > PCN meeting | > | > | > | > | = | > | > | > | > | Hi Ruediger | > | > | > | > | = | > | > | > | > | What do you mean? | > | > | > | > | Do you mean that you do not want to discuss = | corner cases | > | > | > | > (ECMP related | > | > | > | > | cases) that could | > | > | > | > | collapse the PCN domain operation? | > | > | > | > | What I am saying is that if the routers do not | > | > | > | preferentially drop | > | > | > | > | marked packets then the PCN domain operation is | > | more robust | > | > | > | > and more | > | > | > | > | stable than in the situation that the router is | > | > | preferentially | > | > | > | > | dropping marked packets. | > | > | > | > | = | > | > | > | > | Are you saying that this statement is not right? | > | > | > | > | = | > | > | > | > | = | > | > | > | > | Best regards, | > | > | > | > | Georgios | > | > | > | > | = | > | > | > | > | > | > | > | = | > | > | > | = | > | > | > | = | > | > | > = | > | > | = | > | > | = | > | > | = | > | > = | > | = | > | = | > | = | > = | = | = | = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 17 09:13:34 2008 Return-Path: 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 0E2E928C3E0; Mon, 17 Mar 2008 09:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.518 X-Spam-Level: X-Spam-Status: No, score=-101.518 tagged_above=-999 required=5 tests=[AWL=-1.081, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 a+5jR7szU-Vo; Mon, 17 Mar 2008 09:13:32 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53C383A6E5C; Mon, 17 Mar 2008 09:13:30 -0700 (PDT) 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 4761A28C441 for ; Mon, 17 Mar 2008 09:13:29 -0700 (PDT) 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 rcu4RkfUlYuN for ; Mon, 17 Mar 2008 09:13:24 -0700 (PDT) Received: from smtp-6-99.vip.sina.com (smtp.vip.sina.com [202.108.3.172]) by core3.amsl.com (Postfix) with ESMTP id A74FF3A6E1A for ; Mon, 17 Mar 2008 09:13:22 -0700 (PDT) Received: from ibmPC (unknown [211.160.21.17]) by smtp-6-99.vip.sina.com (SINAMAIL) with ESMTP id A6B1C28496; Tue, 18 Mar 2008 00:11:03 +0800 (CST) Message-ID: <380CCA5031B54E7283DD4CA106A48664@ibmPC> From: "Wei Gengyu" To: "Georgios Karagiannis" , "'Geib, Ruediger'" References: <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de><000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF6423C@S4DE8PSAANK.mitte.t-com.de><001301c88816$114dab60$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF644B1@S4DE8PSAANK.mitte.t-com.de><000001c88835$998bcf60$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF6451A@S4DE8PSAANK.mitte.t-com.de> <000601c8883b$e3828950$810c5982@dynamic.ewi.utwente.nl> In-Reply-To: <000601c8883b$e3828950$810c5982@dynamic.ewi.utwente.nl> Date: Tue, 18 Mar 2008 00:10:53 +0800 Organization: BUPT MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.5840.16384 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.5840.16384 Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi, both and all, Even you discuss the problem in a model, would you please notice the typical model of communication system = performance. For a communication system, suppose the output capacity is C; when the input rate is much bigger than C, the switch node is in congestion, the output did not kept give the maximum throuput, i.e. C. The output is much less than C. It decreses sharply. When the input is 16 times of output, or 2 times of input, the output is no= t = stable. The number of marked or unmarked packets you count might be undetermined. Gengyu ----- Original Message ----- = From: "Georgios Karagiannis" To: "'Geib, Ruediger'" Cc: Sent: Monday, March 17, 2008 10:33 PM Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting Hi Ruediger Please note that typical IP networks (thus not MPLS/GMPLS based domains) can recover from failures by using rerouting. Or do you know another standardized mechanism in typical IP networks (thus not MPLS/GMPLS based) that can provide another kind of recovery from failures. Furthermore, I will just explain the example again with maximum capacity of pathh2 being equal to maximum capacity of path1 =3D C. Please explain what you do not understand in this example! Here are the assumptions: * In the PCN domain we assume that ECMP routing is possible! * ingress-eggress-aggregate can contain flows that are passing through one path or more paths (when ECMP routing is used). * routers are currently dropping packets randomly. Thus marked and unmarked packets will be dropped randomly * When excess rate measurements are used, the triggering of admission control and flow termination are done at the egress by using the CLE. One example of this trigger is: CLE > 1%. Note that CLE =3D marked/(unmarked + marked). This means that if this trigger is not activated while a severe congestion occurs in the PCN domain, then the operation of the PCN domain will completely collapse. My statement is: If the routers do not preferentially drop marked packets then the PCN domain operation, even in corner case and misconfiguration situations, is more robust and more stable than in the situation that the router is preferentially dropping marked packets. The below example show such a corner case! I will describe two situations: Situation 1: Consider that an ingress-egress-aggregate due to ECMP routing it includes flows that are passing from at least two paths. Assume that path1 supports a maximum bandwidth capacity of C. Now consider that the maximum bandwdith capacity of path2 is C. Consider also that both paths are fully utilized. Consider that preferentially marked packets are dropped and that path2 fails. Now assume that all (maximum) traffic passing through path2 will be rerouted through path1. If a bottleneck router located in path1, say Rbott, is misconfigured (i.e., from the point of view of having wrongly too high configured-admissible-rate value), or even if it is well configured, then it can be possible that CLE measured at the egress cannot reach 1%. Note that CLE =3D marked packets/ (marked packets + unmarked packets). This is because Rbott will just allow an excess rate to pass through that is equal to: C - configured-admissible-rate. The rest of the marked packets, so the rest of the excess rate, will be dropped by Rbott, since this router is preferentially dropping marked packets. Furthermore, note that due to the ECMP routing flows that are belonging to the same ingress-egress-aggregate and that are passing through another path, than path1, which is not congested, will forward traffic towards the egress node that will be unmarked. This will mean that the CLE > 1% will not be triggered, this will mean that the flow termination will not be triggered and that the operation of the PCN domain will collapse completely. Situation 2: Now consider that the router just operates as currently, i.e., no preferential drop, randomly dropping marked and unmarked packets. Consider also that the two paths described in Situation 1 above are used, ECMP routing is used, and that they are fully utilized. Assume also that path2 fails and that the path2 traffic is rerouted on path1. Now the CLE value will have a higher probability of reaching the triggering value of 1%. This is because the routers in path1 will drop randomly marked and unmarked packets. It is more certain that in this case the CLE will reach 1% due to the following reason. In this example it is assumed that the maximum bandwidth capacity supported by path2 is C. This means that after rerouting the traffic from path2 into path1, the ratio between marked packets and unmarked packets that are passing thorugh path1 can be equal or higher than 100%. Note that the routers in path1 will mark the excess rate above C, thus 1*C (i.e., the rerouted traffic from path2) as marked. The above observation holds also for the situation that the routers are preferentially dropping unmarked packets. Thus when routers are preferentially dropping marked packets the robustness of the PCN domain operation is decreasing and in some cases it severely decreases, which could cause the complete collapse of the PCN domain operation. Best regards, Georgios > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: maandag 17 maart 2008 15:26 > To: karagian@cs.utwente.nl > Cc: pcn@ietf.org > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > > Hi Georgios, > > Unfortunately you missed my point. > > No such thing as you describe has been, is or will for the > foreseeable future be engineered in the IP backbone of the > company I'm working for. > > My expectation on the backbone of any carrier offering > transport QoS is, that it is engineered to survive probable > failures (like single link losses) without impact on the > performance of QoS traffic. This is where we should start > from, if we discuss PCN. From there on, PCN is able to add value. > > Links without traffic engineering followed by misconfigured > routers aren't the arguments which will convince either > product management or backbone engineering of the company I > work for to deploy PCN. > > As a general comment: I don't regard PCN as a plug and play > toy for the operational equivalent of a 'script kiddie'. If > others share that view and our documents don't state that, we > should add text. > > Regards, > > Rudiger > > | -----Original Message----- > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | Sent: Monday, March 17, 2008 2:49 PM > | To: Geib, R=FCdiger > | Cc: pcn@ietf.org > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > | > | Hi Ruediger > | > | You missed my point! > | The explanation applies to all types of IP networks. > | Please note that the problem occurs also when path2 and path1 use > | exactly the same maximum capacity, say C! > | > | In this case, if pathh2 fails then path1 will see an excess > rate equal > | to at least C. > | The rest of the explanation is identical to the one used during my > | previous example! > | > | > | > | Best regards, > | Georgios > | > | > | > | > | > | > -----Original Message----- > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > | > Sent: maandag 17 maart 2008 14:34 > | > To: karagian@cs.utwente.nl > | > Cc: pcn@ietf.org > | > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > | > > | > Hi Georgios, > | > > | > What you describe isn't backbone traffic engineering. What you > | > describe may happen in corporate VPNs, where a DSL access > | is used to > | > back up a WAN Fast Ethernet access or the like. I don't > | object to have > | > standards on PCN for VPNs, but I'm not interested in this > issue for > | > now. > | > > | > If you know any carrier who's operating his network with a > | > 16:1 load balancing for QoS traffic on any particular link > | set, please > | > publish the name, we are all interested in hearing it. > | > > | > Regards, > | > > | > Rudiger > | > > | > > | > > | > | -----Original Message----- > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | > | Sent: Monday, March 17, 2008 11:03 AM > | > | To: Geib, R=FCdiger > | > | Cc: pcn@ietf.org > | > | Subject: RE: [PCN] Concensus questions from Thursday's > PCN meeting > | > | > | > | Hi Ruediger > | > | > | > | I will try to explain this more clearly. > | > | Here are the assumptions: > | > | * In the PCN domain we assume that ECMP routing is possible! > | > | * ingress-eggress-aggregate can contain flows that are > | > passing through > | > | one path or more paths (when ECMP routing is used). > | > | > | > | * routers are currently dropping packets randomly. Thus > | marked and > | > | unmarked packets will be > | > | dropped randomly > | > | > | > | * When excess rate measurements are used, the triggering of > | > admission > | > | control and flow > | > | termination are done at the egress by using the CLE. One > | > example of > | > | this trigger is: > | > | CLE > 1%. Note that CLE =3D marked/(unmarked + marked). > | This means > | > | that if this trigger is not activated while a severe > | > | congestion occurs in the PCN domain, then the operation > | > of the PCN > | > | domain will completely collapse. > | > | > | > | > | > | My statement is: > | > | If the routers do not preferentially drop marked packets > | > then the PCN > | > | domain operation, even in corner case and misconfiguration > | > situations, > | > | is more robust and more stable than in the situation that > | > the router > | > | is preferentially dropping marked packets. > | > | > | > | The below example show such a corner case! > | > | > | > | > | > | I will describe two situations: > | > | > | > | Situation 1: > | > | Consider that an ingress-egress-aggregate due to ECMP > routing it > | > | includes flows that are passing from at least two paths. > | > | Assume that path1 supports a maximum bandwidth capacity of C. > | > | Now consider > | > | that the maximum bandwdith capacity of path2 is 15*C. > | > | Consider also that both paths are fully utilized. > | > | > | > | Consider that preferentially marked packets are dropped and > | > that path2 > | > | fails. > | > | Now assume that all (maximum) traffic passing through > | path2 will be > | > | rerouted through path1. > | > | If a bottleneck router located in path1, say Rbott, is > | > misconfigured > | > | (i.e., from the point of view of having wrongly too high > | > | configured-admissible-rate value), or even if it is well > | > configured, > | > | then it can be possible that CLE measured at the egress > | > cannot reach > | > | 1%. > | > | Note that > | > | CLE =3D marked packets/ (marked packets + unmarked packets). > | > | This is because Rbott will just allow an excess rate to > | > pass through > | > | that is > | > | > | > | equal to: C - configured-admissible-rate. The rest of > the marked > | > | packets, so the rest of the excess rate, will be dropped > | by Rbott, > | > | since this router is preferentially dropping marked packets. > | > | Furthermore, note that due to the ECMP routing flows that are > | > | belonging to the same ingress-egress-aggregate and that > | are passing > | > | through another path, > | > | > | > | than path1, which is not congested, will forward traffic > | > towards the > | > | egress node that will be unmarked. > | > | This will mean that the CLE > 1% will not be triggered, > | > this will mean > | > | that the flow termination will not be triggered and that > | > the operation > | > | of the PCN domain will collapse completely. > | > | > | > | > | > | Situation 2: > | > | Now consider that the router just operates as > currently, i.e., no > | > | preferential drop, randomly dropping marked and > unmarked packets. > | > | Consider also that the two paths described in Situation 1 > | above are > | > | used, ECMP routing is used, and that they are fully utilized. > | > | Assume also that path2 fails and that the path2 traffic is > | > rerouted on > | > | path1. > | > | Now the CLE value will have a higher probability of > reaching the > | > | triggering value of 1%. > | > | > | > | This is because the routers in path1 will drop randomly > | marked and > | > | unmarked packets. > | > | It is more certain that in this case the CLE will reach 1% > | > due to the > | > | following reason. > | > | In this example it is assumed that the maximum > bandwidth capacity > | > | supported by path2 is 15*C. > | > | This means that after rerouting the traffic from path2 into > | > path1, the > | > | ratio between marked packets and unmarked packets that > | are passing > | > | thorugh path1 can be equal or higher than 16. > | > | Note that the routers in path1 will mark the excess rate > | > above C, thus > | > | 16 * C (i.e., the rerouted traffic from path2) as marked. > | > | The above observation holds also for the situation that > | the routers > | > | are preferentially dropping unmarked packets. > | > | > | > | Thus when routers are preferentially dropping marked > packets the > | > | robustness of the PCN domain operation is decreasing and in > | > some cases > | > | it severely decreases, which could cause the complete > | > collapse of the > | > | PCN domain operation. > | > | > | > | Best regards, > | > | Georgios > | > | > | > | > | > | > | > | > | > | > | > | > -----Original Message----- > | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > | > | > Sent: maandag 17 maart 2008 9:42 > | > | > To: karagian@cs.utwente.nl > | > | > Cc: pcn@ietf.org > | > | > Subject: RE: [PCN] Concensus questions from Thursday's > | PCN meeting > | > | > > | > | > Hi Georgios, > | > | > > | > | > PCN is designed for deployment in traffic engineered > networks. > | > | > Please decribe, how to engineer a high performance > | > carrier backbone > | > | > and then review the assumptions your discussion is based on. > | > | > > | > | > Regards, > | > | > > | > | > Rudiger > | > | > > | > | > | -----Original Message----- > | > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | > | > | Sent: Monday, March 17, 2008 9:34 AM > | > | > | To: Geib, R=FCdiger > | > | > | Cc: pcn@ietf.org > | > | > | Subject: RE: [PCN] Concensus questions from Thursday's > | > PCN meeting > | > | > | > | > | > | Hi Ruediger > | > | > | > | > | > | What do you mean? > | > | > | Do you mean that you do not want to discuss corner cases > | > | > (ECMP related > | > | > | cases) that could > | > | > | collapse the PCN domain operation? > | > | > | What I am saying is that if the routers do not > | > | preferentially drop > | > | > | marked packets then the PCN domain operation is more robust > | > | > and more > | > | > | stable than in the situation that the router is > | preferentially > | > | > | dropping marked packets. > | > | > | > | > | > | Are you saying that this statement is not right? > | > | > | > | > | > | > | > | > | Best regards, > | > | > | Georgios > | > | > | > | > | > > | > | > | > | > | > | > | > > | > | > | > _______________________________________________ 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 From pcn-bounces@ietf.org Mon Mar 17 09:39:57 2008 Return-Path: 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 014DD28C503; Mon, 17 Mar 2008 09:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.203 X-Spam-Level: X-Spam-Status: No, score=-100.203 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 UB7VSRkxXdWl; Mon, 17 Mar 2008 09:39:54 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69F4328C4FB; Mon, 17 Mar 2008 09:39:31 -0700 (PDT) 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 101ED28C58B for ; Mon, 17 Mar 2008 09:39:30 -0700 (PDT) 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 5vgJAqrfoX2Y for ; Mon, 17 Mar 2008 09:39:27 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 8931B28C5A0 for ; Mon, 17 Mar 2008 09:38:43 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m2HGaLtu029123; Mon, 17 Mar 2008 17:36:24 +0100 (MET) From: "Georgios Karagiannis" To: "'Geib, Ruediger'" References: <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de> <000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6423C@S4DE8PSAANK.mitte.t-com.de> <001301c88816$114dab60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF644B1@S4DE8PSAANK.mitte.t-com.de> <000001c88835$998bcf60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6451A@S4DE8PSAANK.mitte.t-com.de> <000601c8883b$e3828950$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF64580@S4DE8PSAANK.mitte.t-com.de> <000901c88844$f35c1130$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF645A3@S4DE8PSAANK.mitte.t-com.de> Date: Mon, 17 Mar 2008 17:36:15 +0100 Message-ID: <000a01c8884d$081c9790$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <1B6169C658325341A3B8066E23919E1CF645A3@S4DE8PSAANK.mitte.t-com.de> Thread-Index: AciIBF++zKz17E/GQcib+W/rjB17BgABJ68gAABXALAAAifOMAAH2KywAACjCyAAAJeqgAAA4wtQAAGeymAAAM8HgAAA8S7AAAEXZnA= X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Mon, 17 Mar 2008 17:36:26 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ruediger Please note that what I have described holds also for = the situation that the routers are well configured, but a catastrophic event occur = and at the same time ECMP routing is used. Best regards, Georgios > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] = > Sent: maandag 17 maart 2008 17:10 > To: karagian@cs.utwente.nl > Cc: pcn@ietf.org > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > = > Hi Georgios, > = > what I say is if PCN decides to deal with catastrophic events = > in combination with misconfigured routers, then it will end = > up standardising solutions for academic problems. > = > Regards, > = > Rudiger > = > = > | -----Original Message----- > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | Sent: Monday, March 17, 2008 4:38 PM > | To: Geib, R=FCdiger > | Cc: pcn@ietf.org > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > | = > | Hi Ruediger > | = > | I do not understand what you try to say. Please note that flow = > | termination is used for the below explained reason, see below text = > | taken from the PCN architecture draft: > | = > | o The termination mechanism complements admission control. It > | allows the network to recover from sudden unexpected surges of > | PCN-traffic on some links, thus restoring QoS to the remaining > | flows. Such scenarios are expected to be rare but not = > | impossible. > | They can be caused by large network failures that = > redirect lots = > | of > | admitted PCN-traffic to other links, or by malfunction of the > | measurement-based admission control in the presence = > of admitted > | flows that send for a while with an atypically low = > rate and then > | increase their rates in a correlated way. > | = > | Best regards, > | Georgios > | = > | = > | = > | > -----Original Message----- > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > | > Sent: maandag 17 maart 2008 16:32 > | > To: karagian@cs.utwente.nl > | > Cc: pcn@ietf.org > | > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > | > = > | > Hi Georgios, > | > = > | > QoS on redundant links means, that one link is able to > | carry the QoS > | > traffic of the other. This may not hold for non QoS > | traffic. This is, > | > what typical carrier backbones providing QoS are engineered for = > | > (commonly known as traffic engineering). > | > = > | > Should a misconfiguration occur, things may go wrong. = > | > Operational staff corrects this a soon as the misconfiguration is = > | > identified. > | > = > | > The engineering of carrier backbones is often done with automated = > | > tools, leaving little room for human errors. > | > However maintenance work may result in humanne system > | interference. I > | > doubt that Telekom's engineering department is willing to > | accept extra > | > protocol and router complexitiy to deal with operator = > configuration = > | > errors. While I time and again hear of the worst > | misconfigs, I can't > | > recall that my colleagues try to adapt standardisation afterwards. > | > = > | > Regards, > | > = > | > Rudiger > | > = > | > | -----Original Message----- > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | > | Sent: Monday, March 17, 2008 3:34 PM > | > | To: Geib, R=FCdiger > | > | Cc: pcn@ietf.org > | > | Subject: RE: [PCN] Concensus questions from Thursday's = > PCN meeting > | > | = > | > | Hi Ruediger > | > | = > | > | Please note that typical IP networks (thus not MPLS/GMPLS based > | > | domains) can recover from failures by using rerouting. > | > | Or do you know another standardized mechanism in typical IP > | > networks > | > | (thus not MPLS/GMPLS based) that can provide another kind > | > of recovery > | > | from failures. > | > | = > | > | Furthermore, I will just explain the example again with maximum = > | > | capacity of > | > | pathh2 being equal > | > | to maximum capacity of path1 =3D C. > | > | Please explain what you do not understand in this example! > | > | = > | > | Here are the assumptions: > | > | * In the PCN domain we assume that ECMP routing is possible! > | > | * ingress-eggress-aggregate can contain flows that are > | > passing through > | > | one path or more paths (when ECMP routing is used). > | > | = > | > | * routers are currently dropping packets randomly. Thus > | marked and > | > | unmarked packets will be > | > | dropped randomly > | > | = > | > | * When excess rate measurements are used, the triggering of > | > admission > | > | control and flow > | > | termination are done at the egress by using the CLE. One > | > example of > | > | this trigger is: > | > | CLE > 1%. Note that CLE =3D marked/(unmarked + marked). = > | This means > | > | that if this trigger is not activated while a severe > | > | congestion occurs in the PCN domain, then the operation > | > of the PCN > | > | domain will completely collapse. > | > | = > | > | = > | > | My statement is: > | > | If the routers do not preferentially drop marked packets > | > then the PCN > | > | domain operation, even in corner case and misconfiguration > | > situations, > | > | is more robust and more stable than in the situation that > | > the router > | > | is preferentially dropping marked packets. > | > | = > | > | The below example show such a corner case! > | > | = > | > | = > | > | I will describe two situations: > | > | = > | > | Situation 1: > | > | Consider that an ingress-egress-aggregate due to ECMP = > routing it = > | > | includes flows that are passing from at least two paths. > | > | Assume that path1 supports a maximum bandwidth capacity of C. = > | > | Now consider that the maximum bandwdith capacity of path2 is C. > | > | Consider also that both paths are fully utilized. > | > | = > | > | Consider that preferentially marked packets are dropped and > | > that path2 > | > | fails. > | > | Now assume that all (maximum) traffic passing through > | path2 will be > | > | rerouted through path1. > | > | If a bottleneck router located in path1, say Rbott, is > | > misconfigured > | > | (i.e., from the point of view of having wrongly too high = > | > | configured-admissible-rate value), or even if it is well > | > configured, > | > | then it can be possible that CLE measured at the egress > | > cannot reach > | > | 1%. > | > | Note that > | > | CLE =3D marked packets/ (marked packets + unmarked packets). > | > | This is because Rbott will just allow an excess rate to > | > pass through > | > | that is > | > | = > | > | equal to: C - configured-admissible-rate. The rest of = > the marked = > | > | packets, so the rest of the excess rate, will be dropped > | by Rbott, > | > | since this router is preferentially dropping marked packets. > | > | Furthermore, note that due to the ECMP routing flows that are = > | > | belonging to the same ingress-egress-aggregate and that > | are passing > | > | through another path, > | > | = > | > | than path1, which is not congested, will forward traffic > | > towards the > | > | egress node that will be unmarked. > | > | This will mean that the CLE > 1% will not be triggered, > | > this will mean > | > | that the flow termination will not be triggered and that > | > the operation > | > | of the PCN domain will collapse completely. > | > | = > | > | = > | > | Situation 2: > | > | Now consider that the router just operates as = > currently, i.e., no = > | > | preferential drop, randomly dropping marked and = > unmarked packets. > | > | Consider also that the two paths described in Situation 1 > | above are > | > | used, ECMP routing is used, and that they are fully utilized. > | > | Assume also that path2 fails and that the path2 traffic is > | > rerouted on > | > | path1. > | > | Now the CLE value will have a higher probability of = > reaching the = > | > | triggering value of 1%. > | > | = > | > | This is because the routers in path1 will drop randomly > | marked and > | > | unmarked packets. > | > | It is more certain that in this case the CLE will reach 1% > | > due to the > | > | following reason. > | > | In this example it is assumed that the maximum = > bandwidth capacity = > | > | supported by path2 is C. > | > | This means that after rerouting the traffic from path2 into > | > path1, the > | > | ratio between marked packets and unmarked packets that > | are passing > | > | thorugh path1 can be equal or higher than 100%. > | > | Note that the routers in path1 will mark the excess rate > | > above C, thus > | > | 1*C (i.e., the rerouted traffic from path2) as marked. > | > | The above observation holds also for the situation that > | the routers > | > | are preferentially dropping unmarked packets. > | > | = > | > | Thus when routers are preferentially dropping marked = > packets the = > | > | robustness of the PCN domain operation is decreasing and in > | > some cases > | > | it severely decreases, which could cause the complete > | > collapse of the > | > | PCN domain operation. > | > | = > | > | Best regards, > | > | Georgios > | > | = > | > | = > | > | = > | > | = > | > | > -----Original Message----- > | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > | > | > Sent: maandag 17 maart 2008 15:26 > | > | > To: karagian@cs.utwente.nl > | > | > Cc: pcn@ietf.org > | > | > Subject: RE: [PCN] Concensus questions from Thursday's > | PCN meeting > | > | > = > | > | > Hi Georgios, > | > | > = > | > | > Unfortunately you missed my point. > | > | > = > | > | > No such thing as you describe has been, is or will for the > | > | foreseeable > | > | > future be engineered in the IP backbone of the company > | > I'm working > | > | > for. > | > | > = > | > | > My expectation on the backbone of any carrier offering > | > | transport QoS > | > | > is, that it is engineered to survive probable failures > | > (like single > | > | > link losses) without impact on the performance of QoS > | > | traffic. This is > | > | > where we should start from, if we discuss PCN. From there > | > | on, PCN is > | > | > able to add value. > | > | > = > | > | > Links without traffic engineering followed by > | > misconfigured routers > | > | > aren't the arguments which will convince either product > | > | management or > | > | > backbone engineering of the company I work for to deploy PCN. > | > | > = > | > | > As a general comment: I don't regard PCN as a plug and > | > play toy for > | > | > the operational equivalent of a 'script kiddie'. If others > | > | share that > | > | > view and our documents don't state that, we should add text. > | > | > = > | > | > Regards, > | > | > = > | > | > Rudiger > | > | > = > | > | > | -----Original Message----- > | > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | > | > | Sent: Monday, March 17, 2008 2:49 PM > | > | > | To: Geib, R=FCdiger > | > | > | Cc: pcn@ietf.org > | > | > | Subject: RE: [PCN] Concensus questions from Thursday's > | > PCN meeting > | > | > | = > | > | > | Hi Ruediger > | > | > | = > | > | > | You missed my point! > | > | > | The explanation applies to all types of IP networks. > | > | > | Please note that the problem occurs also when path2 and > | > path1 use > | > | > | exactly the same maximum capacity, say C! > | > | > | = > | > | > | In this case, if pathh2 fails then path1 will see an excess > | > | > rate equal > | > | > | to at least C. > | > | > | The rest of the explanation is identical to the one used > | > | during my > | > | > | previous example! > | > | > | = > | > | > | = > | > | > | = > | > | > | Best regards, > | > | > | Georgios > | > | > | = > | > | > | = > | > | > | = > | > | > | = > | > | > | = > | > | > | > -----Original Message----- > | > | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > | > | > | > Sent: maandag 17 maart 2008 14:34 > | > | > | > To: karagian@cs.utwente.nl > | > | > | > Cc: pcn@ietf.org > | > | > | > Subject: RE: [PCN] Concensus questions from Thursday's > | > | PCN meeting > | > | > | > = > | > | > | > Hi Georgios, > | > | > | > = > | > | > | > What you describe isn't backbone traffic engineering. = > | > What you > | > | > | > describe may happen in corporate VPNs, where a DSL access > | > | > | is used to > | > | > | > back up a WAN Fast Ethernet access or the like. I don't > | > | > | object to have > | > | > | > standards on PCN for VPNs, but I'm not interested in this > | > | > issue for > | > | > | > now. > | > | > | > = > | > | > | > If you know any carrier who's operating his network with a > | > | > | > 16:1 load balancing for QoS traffic on any particular link > | > | > | set, please > | > | > | > publish the name, we are all interested in hearing it. > | > | > | > = > | > | > | > Regards, > | > | > | > = > | > | > | > Rudiger > | > | > | > = > | > | > | > = > | > | > | > = > | > | > | > | -----Original Message----- > | > | > | > | From: Georgios Karagiannis = > [mailto:karagian@cs.utwente.nl] > | > | > | > | Sent: Monday, March 17, 2008 11:03 AM > | > | > | > | To: Geib, R=FCdiger > | > | > | > | Cc: pcn@ietf.org > | > | > | > | Subject: RE: [PCN] Concensus questions from Thursday's > | > | > PCN meeting > | > | > | > | = > | > | > | > | Hi Ruediger > | > | > | > | = > | > | > | > | I will try to explain this more clearly. > | > | > | > | Here are the assumptions: > | > | > | > | * In the PCN domain we assume that ECMP routing > | is possible! > | > | > | > | * ingress-eggress-aggregate can contain flows that are > | > | > | > passing through > | > | > | > | one path or more paths (when ECMP routing is used). > | > | > | > | = > | > | > | > | * routers are currently dropping packets randomly. Thus > | > | > | marked and > | > | > | > | unmarked packets will be > | > | > | > | dropped randomly > | > | > | > | = > | > | > | > | * When excess rate measurements are used, the > | triggering of > | > | > | > admission > | > | > | > | control and flow > | > | > | > | termination are done at the egress by using = > the CLE. One > | > | > | > example of > | > | > | > | this trigger is: > | > | > | > | CLE > 1%. Note that CLE =3D marked/(unmarked + marked). = > | > | > | This means > | > | > | > | that if this trigger is not activated while a severe > | > | > | > | congestion occurs in the PCN domain, then the = > operation > | > | > | > of the PCN > | > | > | > | domain will completely collapse. > | > | > | > | = > | > | > | > | = > | > | > | > | My statement is: > | > | > | > | If the routers do not preferentially drop marked packets > | > | > | > then the PCN > | > | > | > | domain operation, even in corner case and = > misconfiguration > | > | > | > situations, > | > | > | > | is more robust and more stable than in the = > situation that > | > | > | > the router > | > | > | > | is preferentially dropping marked packets. > | > | > | > | = > | > | > | > | The below example show such a corner case! > | > | > | > | = > | > | > | > | = > | > | > | > | I will describe two situations: > | > | > | > | = > | > | > | > | Situation 1: > | > | > | > | Consider that an ingress-egress-aggregate due to ECMP > | > | > routing it > | > | > | > | includes flows that are passing from at least two paths. > | > | > | > | Assume that path1 supports a maximum bandwidth > | > capacity of C. = > | > | > | > | Now consider > | > | > | > | that the maximum bandwdith capacity of path2 is 15*C. > | > | > | > | Consider also that both paths are fully utilized. > | > | > | > | = > | > | > | > | Consider that preferentially marked packets are > | dropped and > | > | > | > that path2 > | > | > | > | fails. > | > | > | > | Now assume that all (maximum) traffic passing through > | > | > | path2 will be > | > | > | > | rerouted through path1. > | > | > | > | If a bottleneck router located in path1, say Rbott, is > | > | > | > misconfigured > | > | > | > | (i.e., from the point of view of having wrongly = > too high = > | > | > | > | configured-admissible-rate value), or even if it is well > | > | > | > configured, > | > | > | > | then it can be possible that CLE measured at the egress > | > | > | > cannot reach > | > | > | > | 1%. > | > | > | > | Note that > | > | > | > | CLE =3D marked packets/ (marked packets + = > unmarked packets). > | > | > | > | This is because Rbott will just allow an excess rate to > | > | > | > pass through > | > | > | > | that is > | > | > | > | = > | > | > | > | equal to: C - configured-admissible-rate. The rest of > | > | > the marked > | > | > | > | packets, so the rest of the excess rate, will be dropped > | > | > | by Rbott, > | > | > | > | since this router is preferentially dropping > | marked packets. > | > | > | > | Furthermore, note that due to the ECMP routing > | > flows that are > | > | > | > | belonging to the same ingress-egress-aggregate and that > | > | > | are passing > | > | > | > | through another path, > | > | > | > | = > | > | > | > | than path1, which is not congested, will forward traffic > | > | > | > towards the > | > | > | > | egress node that will be unmarked. > | > | > | > | This will mean that the CLE > 1% will not be triggered, > | > | > | > this will mean > | > | > | > | that the flow termination will not be triggered and that > | > | > | > the operation > | > | > | > | of the PCN domain will collapse completely. > | > | > | > | = > | > | > | > | = > | > | > | > | Situation 2: > | > | > | > | Now consider that the router just operates as > | > | > currently, i.e., no > | > | > | > | preferential drop, randomly dropping marked and > | > | > unmarked packets. > | > | > | > | Consider also that the two paths described in = > Situation 1 > | > | > | above are > | > | > | > | used, ECMP routing is used, and that they are fully > | > utilized. > | > | > | > | Assume also that path2 fails and that the path2 = > traffic is > | > | > | > rerouted on > | > | > | > | path1. > | > | > | > | Now the CLE value will have a higher probability of > | > | > reaching the > | > | > | > | triggering value of 1%. > | > | > | > | = > | > | > | > | This is because the routers in path1 will drop randomly > | > | > | marked and > | > | > | > | unmarked packets. > | > | > | > | It is more certain that in this case the CLE = > will reach 1% > | > | > | > due to the > | > | > | > | following reason. > | > | > | > | In this example it is assumed that the maximum > | > | > bandwidth capacity > | > | > | > | supported by path2 is 15*C. > | > | > | > | This means that after rerouting the traffic from > | path2 into > | > | > | > path1, the > | > | > | > | ratio between marked packets and unmarked packets that > | > | > | are passing > | > | > | > | thorugh path1 can be equal or higher than 16. > | > | > | > | Note that the routers in path1 will mark the excess rate > | > | > | > above C, thus > | > | > | > | 16 * C (i.e., the rerouted traffic from path2) = > as marked. > | > | > | > | The above observation holds also for the situation that > | > | > | the routers > | > | > | > | are preferentially dropping unmarked packets. > | > | > | > | = > | > | > | > | Thus when routers are preferentially dropping marked > | > | > packets the > | > | > | > | robustness of the PCN domain operation is > | decreasing and in > | > | > | > some cases > | > | > | > | it severely decreases, which could cause the complete > | > | > | > collapse of the > | > | > | > | PCN domain operation. > | > | > | > | = > | > | > | > | Best regards, > | > | > | > | Georgios > | > | > | > | = > | > | > | > | = > | > | > | > | = > | > | > | > | = > | > | > | > | = > | > | > | > | > -----Original Message----- > | > | > | > | > From: Geib, Ruediger > | [mailto:Ruediger.Geib@t-systems.com] > | > | > | > | > Sent: maandag 17 maart 2008 9:42 > | > | > | > | > To: karagian@cs.utwente.nl > | > | > | > | > Cc: pcn@ietf.org > | > | > | > | > Subject: RE: [PCN] Concensus questions from Thursday's > | > | > | PCN meeting > | > | > | > | > = > | > | > | > | > Hi Georgios, > | > | > | > | > = > | > | > | > | > PCN is designed for deployment in traffic engineered > | > | > networks. = > | > | > | > | > Please decribe, how to engineer a high performance > | > | > | > carrier backbone > | > | > | > | > and then review the assumptions your discussion > | > is based on. > | > | > | > | > = > | > | > | > | > Regards, > | > | > | > | > = > | > | > | > | > Rudiger > | > | > | > | > = > | > | > | > | > | -----Original Message----- > | > | > | > | > | From: Georgios Karagiannis > | > [mailto:karagian@cs.utwente.nl] > | > | > | > | > | Sent: Monday, March 17, 2008 9:34 AM > | > | > | > | > | To: Geib, R=FCdiger > | > | > | > | > | Cc: pcn@ietf.org > | > | > | > | > | Subject: RE: [PCN] Concensus questions from = > Thursday's > | > | > | > PCN meeting > | > | > | > | > | = > | > | > | > | > | Hi Ruediger > | > | > | > | > | = > | > | > | > | > | What do you mean? > | > | > | > | > | Do you mean that you do not want to discuss > | corner cases > | > | > | > | > (ECMP related > | > | > | > | > | cases) that could > | > | > | > | > | collapse the PCN domain operation? > | > | > | > | > | What I am saying is that if the routers do not > | > | > | > | preferentially drop > | > | > | > | > | marked packets then the PCN domain operation is > | > | more robust > | > | > | > | > and more > | > | > | > | > | stable than in the situation that the router is > | > | > | preferentially > | > | > | > | > | dropping marked packets. > | > | > | > | > | = > | > | > | > | > | Are you saying that this statement is not right? > | > | > | > | > | = > | > | > | > | > | = > | > | > | > | > | Best regards, > | > | > | > | > | Georgios > | > | > | > | > | = > | > | > | > | > > | > | > | > | = > | > | > | > | = > | > | > | > | = > | > | > | > = > | > | > | = > | > | > | = > | > | > | = > | > | > = > | > | = > | > | = > | > | = > | > = > | = > | = > | = > = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 18 00:30:42 2008 Return-Path: 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 2944D3A6B72; Tue, 18 Mar 2008 00:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[AWL=-0.281, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 muQjsbwLqCFd; Tue, 18 Mar 2008 00:30:40 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25E4B3A6E38; Tue, 18 Mar 2008 00:30:40 -0700 (PDT) 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 D5A4B3A6B72 for ; Tue, 18 Mar 2008 00:30:38 -0700 (PDT) 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 fcpGzdRNtmBO for ; Tue, 18 Mar 2008 00:30:36 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 0BA9A3A6E38 for ; Tue, 18 Mar 2008 00:30:35 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail21.telekom.de with ESMTP; Tue, 18 Mar 2008 08:28:17 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Mar 2008 08:28:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Mar 2008 08:29:40 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CF64645@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <000a01c8884d$081c9790$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciIBF++zKz17E/GQcib+W/rjB17BgABJ68gAABXALAAAifOMAAH2KywAACjCyAAAJeqgAAA4wtQAAGeymAAAM8HgAAA8S7AAAEXZnAAHn88IA== References: <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de> <000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6423C@S4DE8PSAANK.mitte.t-com.de> <001301c88816$114dab60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF644B1@S4DE8PSAANK.mitte.t-com.de> <000001c88835$998bcf60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6451A@S4DE8PSAANK.mitte.t-com.de> <000601c8883b$e3828950$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF64580@S4DE8PSAANK.mitte.t-com.de> <000901c88844$f35c1130$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF645A3@S4DE8PSAANK.mitte.t-com.de> <000a01c8884d$081c9790$810c5982@dynamic.ewi.utwente.nl> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 18 Mar 2008 07:28:17.0549 (UTC) FILETIME=[A275C3D0:01C888C9] Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Georgios, in the situation you describe, packet losses occur. This will result = in bad press, as the customers using PCN based services were promised = another type of service. In this situation it doesn't matter whether or not ECMP is deployed = and it also doesn't matter whether termination is fair or not. The = important event is: packet losses occur (in one of your examples = several routers drop packets). The drops are the only relevant issue. = Whether service resumes after 5 seconds due to extremly well = engineered termination or after 10 seconds after a sufficient number = of customers hang up is not important. = I can't recall having read anytime in the news = "Major network outage - but termination was fair." I can = only recall having seen the first part. I'm sure you're happy in adapting your example, as you do all the = time. I'm having work to do, but maybe someone else is interested = in continuing discusion. I think, I've made my point. Regards, Rudiger | -----Original Message----- | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] = | Sent: Monday, March 17, 2008 5:36 PM | To: Geib, R=FCdiger | Cc: pcn@ietf.org | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | = | Hi Ruediger | = | Please note that what I have described holds also for the = | situation that the routers are well configured, but a = | catastrophic event occur and at the same time ECMP routing is used. | = | Best regards, | Georgios | = | = | > -----Original Message----- | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > Sent: maandag 17 maart 2008 17:10 | > To: karagian@cs.utwente.nl | > Cc: pcn@ietf.org | > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | > = | > Hi Georgios, | > = | > what I say is if PCN decides to deal with catastrophic events in = | > combination with misconfigured routers, then it will end up = | > standardising solutions for academic problems. | > = | > Regards, | > = | > Rudiger | > = | > = | > | -----Original Message----- | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > | Sent: Monday, March 17, 2008 4:38 PM | > | To: Geib, R=FCdiger | > | Cc: pcn@ietf.org | > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | > | = | > | Hi Ruediger | > | = | > | I do not understand what you try to say. Please note that flow = | > | termination is used for the below explained reason, see = | below text = | > | taken from the PCN architecture draft: | > | = | > | o The termination mechanism complements admission control. It | > | allows the network to recover from sudden = | unexpected surges of | > | PCN-traffic on some links, thus restoring QoS to = | the remaining | > | flows. Such scenarios are expected to be rare but not = | > | impossible. | > | They can be caused by large network failures that | > redirect lots | > | of | > | admitted PCN-traffic to other links, or by = | malfunction of the | > | measurement-based admission control in the presence | > of admitted | > | flows that send for a while with an atypically low | > rate and then | > | increase their rates in a correlated way. | > | = | > | Best regards, | > | Georgios | > | = | > | = | > | = | > | > -----Original Message----- | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > | > Sent: maandag 17 maart 2008 16:32 | > | > To: karagian@cs.utwente.nl | > | > Cc: pcn@ietf.org | > | > Subject: RE: [PCN] Concensus questions from Thursday's = | PCN meeting | > | > = | > | > Hi Georgios, | > | > = | > | > QoS on redundant links means, that one link is able to | > | carry the QoS | > | > traffic of the other. This may not hold for non QoS | > | traffic. This is, | > | > what typical carrier backbones providing QoS are engineered for = | > | > (commonly known as traffic engineering). | > | > = | > | > Should a misconfiguration occur, things may go wrong. = | > | > Operational staff corrects this a soon as the = | misconfiguration is = | > | > identified. | > | > = | > | > The engineering of carrier backbones is often done with = | automated = | > | > tools, leaving little room for human errors. | > | > However maintenance work may result in humanne system | > | interference. I | > | > doubt that Telekom's engineering department is willing to | > | accept extra | > | > protocol and router complexitiy to deal with operator | > configuration | > | > errors. While I time and again hear of the worst | > | misconfigs, I can't | > | > recall that my colleagues try to adapt standardisation = | afterwards. | > | > = | > | > Regards, | > | > = | > | > Rudiger | > | > = | > | > | -----Original Message----- | > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > | > | Sent: Monday, March 17, 2008 3:34 PM | > | > | To: Geib, R=FCdiger | > | > | Cc: pcn@ietf.org | > | > | Subject: RE: [PCN] Concensus questions from Thursday's | > PCN meeting | > | > | = | > | > | Hi Ruediger | > | > | = | > | > | Please note that typical IP networks (thus not = | MPLS/GMPLS based | > | > | domains) can recover from failures by using rerouting. | > | > | Or do you know another standardized mechanism in typical IP | > | > networks | > | > | (thus not MPLS/GMPLS based) that can provide another kind | > | > of recovery | > | > | from failures. | > | > | = | > | > | Furthermore, I will just explain the example again = | with maximum = | > | > | capacity of | > | > | pathh2 being equal | > | > | to maximum capacity of path1 =3D C. | > | > | Please explain what you do not understand in this example! | > | > | = | > | > | Here are the assumptions: | > | > | * In the PCN domain we assume that ECMP routing is possible! | > | > | * ingress-eggress-aggregate can contain flows that are | > | > passing through | > | > | one path or more paths (when ECMP routing is used). | > | > | = | > | > | * routers are currently dropping packets randomly. Thus | > | marked and | > | > | unmarked packets will be | > | > | dropped randomly | > | > | = | > | > | * When excess rate measurements are used, the triggering of | > | > admission | > | > | control and flow | > | > | termination are done at the egress by using the CLE. One | > | > example of | > | > | this trigger is: | > | > | CLE > 1%. Note that CLE =3D marked/(unmarked + marked). = | > | This means | > | > | that if this trigger is not activated while a severe | > | > | congestion occurs in the PCN domain, then the operation | > | > of the PCN | > | > | domain will completely collapse. | > | > | = | > | > | = | > | > | My statement is: | > | > | If the routers do not preferentially drop marked packets | > | > then the PCN | > | > | domain operation, even in corner case and misconfiguration | > | > situations, | > | > | is more robust and more stable than in the situation that | > | > the router | > | > | is preferentially dropping marked packets. | > | > | = | > | > | The below example show such a corner case! | > | > | = | > | > | = | > | > | I will describe two situations: | > | > | = | > | > | Situation 1: | > | > | Consider that an ingress-egress-aggregate due to ECMP | > routing it | > | > | includes flows that are passing from at least two paths. | > | > | Assume that path1 supports a maximum bandwidth capacity of C. = | > | > | Now consider that the maximum bandwdith capacity of = | path2 is C. | > | > | Consider also that both paths are fully utilized. | > | > | = | > | > | Consider that preferentially marked packets are dropped and | > | > that path2 | > | > | fails. | > | > | Now assume that all (maximum) traffic passing through | > | path2 will be | > | > | rerouted through path1. | > | > | If a bottleneck router located in path1, say Rbott, is | > | > misconfigured | > | > | (i.e., from the point of view of having wrongly too high = | > | > | configured-admissible-rate value), or even if it is well | > | > configured, | > | > | then it can be possible that CLE measured at the egress | > | > cannot reach | > | > | 1%. | > | > | Note that | > | > | CLE =3D marked packets/ (marked packets + unmarked packets). | > | > | This is because Rbott will just allow an excess rate to | > | > pass through | > | > | that is | > | > | = | > | > | equal to: C - configured-admissible-rate. The rest of | > the marked | > | > | packets, so the rest of the excess rate, will be dropped | > | by Rbott, | > | > | since this router is preferentially dropping marked packets. | > | > | Furthermore, note that due to the ECMP routing flows that are = | > | > | belonging to the same ingress-egress-aggregate and that | > | are passing | > | > | through another path, | > | > | = | > | > | than path1, which is not congested, will forward traffic | > | > towards the | > | > | egress node that will be unmarked. | > | > | This will mean that the CLE > 1% will not be triggered, | > | > this will mean | > | > | that the flow termination will not be triggered and that | > | > the operation | > | > | of the PCN domain will collapse completely. | > | > | = | > | > | = | > | > | Situation 2: | > | > | Now consider that the router just operates as | > currently, i.e., no | > | > | preferential drop, randomly dropping marked and | > unmarked packets. | > | > | Consider also that the two paths described in Situation 1 | > | above are | > | > | used, ECMP routing is used, and that they are fully utilized. | > | > | Assume also that path2 fails and that the path2 traffic is | > | > rerouted on | > | > | path1. | > | > | Now the CLE value will have a higher probability of | > reaching the | > | > | triggering value of 1%. | > | > | = | > | > | This is because the routers in path1 will drop randomly | > | marked and | > | > | unmarked packets. | > | > | It is more certain that in this case the CLE will reach 1% | > | > due to the | > | > | following reason. | > | > | In this example it is assumed that the maximum | > bandwidth capacity | > | > | supported by path2 is C. | > | > | This means that after rerouting the traffic from path2 into | > | > path1, the | > | > | ratio between marked packets and unmarked packets that | > | are passing | > | > | thorugh path1 can be equal or higher than 100%. | > | > | Note that the routers in path1 will mark the excess rate | > | > above C, thus | > | > | 1*C (i.e., the rerouted traffic from path2) as marked. | > | > | The above observation holds also for the situation that | > | the routers | > | > | are preferentially dropping unmarked packets. | > | > | = | > | > | Thus when routers are preferentially dropping marked | > packets the | > | > | robustness of the PCN domain operation is decreasing and in | > | > some cases | > | > | it severely decreases, which could cause the complete | > | > collapse of the | > | > | PCN domain operation. | > | > | = | > | > | Best regards, | > | > | Georgios | > | > | = | > | > | = | > | > | = | > | > | = | > | > | > -----Original Message----- | > | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > | > | > Sent: maandag 17 maart 2008 15:26 | > | > | > To: karagian@cs.utwente.nl | > | > | > Cc: pcn@ietf.org | > | > | > Subject: RE: [PCN] Concensus questions from Thursday's | > | PCN meeting | > | > | > = | > | > | > Hi Georgios, | > | > | > = | > | > | > Unfortunately you missed my point. | > | > | > = | > | > | > No such thing as you describe has been, is or will for the | > | > | foreseeable | > | > | > future be engineered in the IP backbone of the company | > | > I'm working | > | > | > for. | > | > | > = | > | > | > My expectation on the backbone of any carrier offering | > | > | transport QoS | > | > | > is, that it is engineered to survive probable failures | > | > (like single | > | > | > link losses) without impact on the performance of QoS | > | > | traffic. This is | > | > | > where we should start from, if we discuss PCN. From there | > | > | on, PCN is | > | > | > able to add value. | > | > | > = | > | > | > Links without traffic engineering followed by | > | > misconfigured routers | > | > | > aren't the arguments which will convince either product | > | > | management or | > | > | > backbone engineering of the company I work for to = | deploy PCN. | > | > | > = | > | > | > As a general comment: I don't regard PCN as a plug and | > | > play toy for | > | > | > the operational equivalent of a 'script kiddie'. If others | > | > | share that | > | > | > view and our documents don't state that, we should add text. | > | > | > = | > | > | > Regards, | > | > | > = | > | > | > Rudiger | > | > | > = | > | > | > | -----Original Message----- | > | > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > | > | > | Sent: Monday, March 17, 2008 2:49 PM | > | > | > | To: Geib, R=FCdiger | > | > | > | Cc: pcn@ietf.org | > | > | > | Subject: RE: [PCN] Concensus questions from Thursday's | > | > PCN meeting | > | > | > | = | > | > | > | Hi Ruediger | > | > | > | = | > | > | > | You missed my point! | > | > | > | The explanation applies to all types of IP networks. | > | > | > | Please note that the problem occurs also when path2 and | > | > path1 use | > | > | > | exactly the same maximum capacity, say C! | > | > | > | = | > | > | > | In this case, if pathh2 fails then path1 will see = | an excess | > | > | > rate equal | > | > | > | to at least C. | > | > | > | The rest of the explanation is identical to the one used | > | > | during my | > | > | > | previous example! | > | > | > | = | > | > | > | = | > | > | > | = | > | > | > | Best regards, | > | > | > | Georgios | > | > | > | = | > | > | > | = | > | > | > | = | > | > | > | = | > | > | > | = | > | > | > | > -----Original Message----- | > | > | > | > From: Geib, Ruediger = | [mailto:Ruediger.Geib@t-systems.com] | > | > | > | > Sent: maandag 17 maart 2008 14:34 | > | > | > | > To: karagian@cs.utwente.nl | > | > | > | > Cc: pcn@ietf.org | > | > | > | > Subject: RE: [PCN] Concensus questions from Thursday's | > | > | PCN meeting | > | > | > | > = | > | > | > | > Hi Georgios, | > | > | > | > = | > | > | > | > What you describe isn't backbone traffic engineering. = | > | > What you | > | > | > | > describe may happen in corporate VPNs, where a = | DSL access | > | > | > | is used to | > | > | > | > back up a WAN Fast Ethernet access or the like. I don't | > | > | > | object to have | > | > | > | > standards on PCN for VPNs, but I'm not = | interested in this | > | > | > issue for | > | > | > | > now. | > | > | > | > = | > | > | > | > If you know any carrier who's operating his = | network with a | > | > | > | > 16:1 load balancing for QoS traffic on any = | particular link | > | > | > | set, please | > | > | > | > publish the name, we are all interested in hearing it. | > | > | > | > = | > | > | > | > Regards, | > | > | > | > = | > | > | > | > Rudiger | > | > | > | > = | > | > | > | > = | > | > | > | > = | > | > | > | > | -----Original Message----- | > | > | > | > | From: Georgios Karagiannis | > [mailto:karagian@cs.utwente.nl] | > | > | > | > | Sent: Monday, March 17, 2008 11:03 AM | > | > | > | > | To: Geib, R=FCdiger | > | > | > | > | Cc: pcn@ietf.org | > | > | > | > | Subject: RE: [PCN] Concensus questions from Thursday's | > | > | > PCN meeting | > | > | > | > | = | > | > | > | > | Hi Ruediger | > | > | > | > | = | > | > | > | > | I will try to explain this more clearly. | > | > | > | > | Here are the assumptions: | > | > | > | > | * In the PCN domain we assume that ECMP routing | > | is possible! | > | > | > | > | * ingress-eggress-aggregate can contain flows that are | > | > | > | > passing through | > | > | > | > | one path or more paths (when ECMP routing is used). | > | > | > | > | = | > | > | > | > | * routers are currently dropping packets = | randomly. Thus | > | > | > | marked and | > | > | > | > | unmarked packets will be | > | > | > | > | dropped randomly | > | > | > | > | = | > | > | > | > | * When excess rate measurements are used, the | > | triggering of | > | > | > | > admission | > | > | > | > | control and flow | > | > | > | > | termination are done at the egress by using | > the CLE. One | > | > | > | > example of | > | > | > | > | this trigger is: | > | > | > | > | CLE > 1%. Note that CLE =3D marked/(unmarked = | + marked). = | > | > | > | This means | > | > | > | > | that if this trigger is not activated while a severe | > | > | > | > | congestion occurs in the PCN domain, then the | > operation | > | > | > | > of the PCN | > | > | > | > | domain will completely collapse. | > | > | > | > | = | > | > | > | > | = | > | > | > | > | My statement is: | > | > | > | > | If the routers do not preferentially drop = | marked packets | > | > | > | > then the PCN | > | > | > | > | domain operation, even in corner case and | > misconfiguration | > | > | > | > situations, | > | > | > | > | is more robust and more stable than in the | > situation that | > | > | > | > the router | > | > | > | > | is preferentially dropping marked packets. | > | > | > | > | = | > | > | > | > | The below example show such a corner case! | > | > | > | > | = | > | > | > | > | = | > | > | > | > | I will describe two situations: | > | > | > | > | = | > | > | > | > | Situation 1: | > | > | > | > | Consider that an ingress-egress-aggregate due to ECMP | > | > | > routing it | > | > | > | > | includes flows that are passing from at least = | two paths. | > | > | > | > | Assume that path1 supports a maximum bandwidth | > | > capacity of C. = | > | > | > | > | Now consider | > | > | > | > | that the maximum bandwdith capacity of path2 is 15*C. | > | > | > | > | Consider also that both paths are fully utilized. | > | > | > | > | = | > | > | > | > | Consider that preferentially marked packets are | > | dropped and | > | > | > | > that path2 | > | > | > | > | fails. | > | > | > | > | Now assume that all (maximum) traffic passing through | > | > | > | path2 will be | > | > | > | > | rerouted through path1. | > | > | > | > | If a bottleneck router located in path1, say Rbott, is | > | > | > | > misconfigured | > | > | > | > | (i.e., from the point of view of having wrongly | > too high | > | > | > | > | configured-admissible-rate value), or even if = | it is well | > | > | > | > configured, | > | > | > | > | then it can be possible that CLE measured at = | the egress | > | > | > | > cannot reach | > | > | > | > | 1%. | > | > | > | > | Note that | > | > | > | > | CLE =3D marked packets/ (marked packets + | > unmarked packets). | > | > | > | > | This is because Rbott will just allow an = | excess rate to | > | > | > | > pass through | > | > | > | > | that is | > | > | > | > | = | > | > | > | > | equal to: C - configured-admissible-rate. The rest of | > | > | > the marked | > | > | > | > | packets, so the rest of the excess rate, will = | be dropped | > | > | > | by Rbott, | > | > | > | > | since this router is preferentially dropping | > | marked packets. | > | > | > | > | Furthermore, note that due to the ECMP routing | > | > flows that are | > | > | > | > | belonging to the same = | ingress-egress-aggregate and that | > | > | > | are passing | > | > | > | > | through another path, | > | > | > | > | = | > | > | > | > | than path1, which is not congested, will = | forward traffic | > | > | > | > towards the | > | > | > | > | egress node that will be unmarked. | > | > | > | > | This will mean that the CLE > 1% will not be = | triggered, | > | > | > | > this will mean | > | > | > | > | that the flow termination will not be = | triggered and that | > | > | > | > the operation | > | > | > | > | of the PCN domain will collapse completely. | > | > | > | > | = | > | > | > | > | = | > | > | > | > | Situation 2: | > | > | > | > | Now consider that the router just operates as | > | > | > currently, i.e., no | > | > | > | > | preferential drop, randomly dropping marked and | > | > | > unmarked packets. | > | > | > | > | Consider also that the two paths described in | > Situation 1 | > | > | > | above are | > | > | > | > | used, ECMP routing is used, and that they are fully | > | > utilized. | > | > | > | > | Assume also that path2 fails and that the path2 | > traffic is | > | > | > | > rerouted on | > | > | > | > | path1. | > | > | > | > | Now the CLE value will have a higher probability of | > | > | > reaching the | > | > | > | > | triggering value of 1%. | > | > | > | > | = | > | > | > | > | This is because the routers in path1 will = | drop randomly | > | > | > | marked and | > | > | > | > | unmarked packets. | > | > | > | > | It is more certain that in this case the CLE | > will reach 1% | > | > | > | > due to the | > | > | > | > | following reason. | > | > | > | > | In this example it is assumed that the maximum | > | > | > bandwidth capacity | > | > | > | > | supported by path2 is 15*C. | > | > | > | > | This means that after rerouting the traffic from | > | path2 into | > | > | > | > path1, the | > | > | > | > | ratio between marked packets and unmarked packets that | > | > | > | are passing | > | > | > | > | thorugh path1 can be equal or higher than 16. | > | > | > | > | Note that the routers in path1 will mark the = | excess rate | > | > | > | > above C, thus | > | > | > | > | 16 * C (i.e., the rerouted traffic from path2) | > as marked. | > | > | > | > | The above observation holds also for the = | situation that | > | > | > | the routers | > | > | > | > | are preferentially dropping unmarked packets. | > | > | > | > | = | > | > | > | > | Thus when routers are preferentially dropping marked | > | > | > packets the | > | > | > | > | robustness of the PCN domain operation is | > | decreasing and in | > | > | > | > some cases | > | > | > | > | it severely decreases, which could cause the complete | > | > | > | > collapse of the | > | > | > | > | PCN domain operation. | > | > | > | > | = | > | > | > | > | Best regards, | > | > | > | > | Georgios | > | > | > | > | = | > | > | > | > | = | > | > | > | > | = | > | > | > | > | = | > | > | > | > | = | > | > | > | > | > -----Original Message----- | > | > | > | > | > From: Geib, Ruediger | > | [mailto:Ruediger.Geib@t-systems.com] | > | > | > | > | > Sent: maandag 17 maart 2008 9:42 | > | > | > | > | > To: karagian@cs.utwente.nl | > | > | > | > | > Cc: pcn@ietf.org | > | > | > | > | > Subject: RE: [PCN] Concensus questions from = | Thursday's | > | > | > | PCN meeting | > | > | > | > | > = | > | > | > | > | > Hi Georgios, | > | > | > | > | > = | > | > | > | > | > PCN is designed for deployment in traffic engineered | > | > | > networks. = | > | > | > | > | > Please decribe, how to engineer a high performance | > | > | > | > carrier backbone | > | > | > | > | > and then review the assumptions your discussion | > | > is based on. | > | > | > | > | > = | > | > | > | > | > Regards, | > | > | > | > | > = | > | > | > | > | > Rudiger | > | > | > | > | > = | > | > | > | > | > | -----Original Message----- | > | > | > | > | > | From: Georgios Karagiannis | > | > [mailto:karagian@cs.utwente.nl] | > | > | > | > | > | Sent: Monday, March 17, 2008 9:34 AM | > | > | > | > | > | To: Geib, R=FCdiger | > | > | > | > | > | Cc: pcn@ietf.org | > | > | > | > | > | Subject: RE: [PCN] Concensus questions from | > Thursday's | > | > | > | > PCN meeting | > | > | > | > | > | = | > | > | > | > | > | Hi Ruediger | > | > | > | > | > | = | > | > | > | > | > | What do you mean? | > | > | > | > | > | Do you mean that you do not want to discuss | > | corner cases | > | > | > | > | > (ECMP related | > | > | > | > | > | cases) that could | > | > | > | > | > | collapse the PCN domain operation? | > | > | > | > | > | What I am saying is that if the routers do not | > | > | > | > | preferentially drop | > | > | > | > | > | marked packets then the PCN domain operation is | > | > | more robust | > | > | > | > | > and more | > | > | > | > | > | stable than in the situation that the router is | > | > | > | preferentially | > | > | > | > | > | dropping marked packets. | > | > | > | > | > | = | > | > | > | > | > | Are you saying that this statement is not right? | > | > | > | > | > | = | > | > | > | > | > | = | > | > | > | > | > | Best regards, | > | > | > | > | > | Georgios | > | > | > | > | > | = | > | > | > | > | > | > | > | > | > | = | > | > | > | > | = | > | > | > | > | = | > | > | > | > = | > | > | > | = | > | > | > | = | > | > | > | = | > | > | > = | > | > | = | > | > | = | > | > | = | > | > = | > | = | > | = | > | = | > = | = | = | = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 18 03:19:36 2008 Return-Path: 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 52AD328C4DD; Tue, 18 Mar 2008 03:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.243 X-Spam-Level: X-Spam-Status: No, score=-100.243 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 WEOO-L9qfc7N; Tue, 18 Mar 2008 03:19:34 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00F6C3A6F03; Tue, 18 Mar 2008 03:19:34 -0700 (PDT) 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 9C0C628C2F8 for ; Tue, 18 Mar 2008 03:19:32 -0700 (PDT) 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 zG7-OgX1DxJY for ; Tue, 18 Mar 2008 03:19:30 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id EB9323A6EFC for ; Tue, 18 Mar 2008 03:19:29 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m2IAH66F001680; Tue, 18 Mar 2008 11:17:09 +0100 (MET) From: "Georgios Karagiannis" To: "'Geib, Ruediger'" References: <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de> <000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6423C@S4DE8PSAANK.mitte.t-com.de> <001301c88816$114dab60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF644B1@S4DE8PSAANK.mitte.t-com.de> <000001c88835$998bcf60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6451A@S4DE8PSAANK.mitte.t-com.de> <000601c8883b$e3828950$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF64580@S4DE8PSAANK.mitte.t-com.de> <000901c88844$f35c1130$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF645A3@S4DE8PSAANK.mitte.t-com.de> <000a01c8884d$081c9790$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF64645@S4DE8PSAANK.mitte.t-com.de> Date: Tue, 18 Mar 2008 11:17:01 +0100 Message-ID: <000701c888e1$37a68c20$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <1B6169C658325341A3B8066E23919E1CF64645@S4DE8PSAANK.mitte.t-com.de> Thread-Index: AciIBF++zKz17E/GQcib+W/rjB17BgABJ68gAABXALAAAifOMAAH2KywAACjCyAAAJeqgAAA4wtQAAGeymAAAM8HgAAA8S7AAAEXZnAAHn88IAAGS18A X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Tue, 18 Mar 2008 11:17:12 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ruediger The problem that I have explained it does not have to do with slow reaction time = but it has to do with complete collapse of the PCN domain operation. = This occurs when the admission control/flow termination triggers at the = egress are not activated when they should be activated. Here is a more concrete example: When ECMP routing is used, it means that flows that are associated with the same = ingress-egress-aggregate can follow different paths. = Assume that there are 5 such paths that are carrying flows = associated with the same ingress-egress-aggregate. Consider now that one of the 5 paths fails and it is rerouted to one of the other paths. Assume that path1 is becoming congested and the other 3 remaining paths are not congested. I am also assuming in this case that the thresholds are well configured. The egress will calculate CLE in the following way: CLE =3D marked_1 /(unmarked_1 + unmarked_2 + unmarked_3 + unmarked_4 + marked_1) I think that typcially the above calculated CLE will not reach 1% when marked = packets are preferentially dropped. This problem is due to the fact that ECMP routing is used and = flows that are not participating at the congestion are contributing = to the calculation of the CLE. The flows that are not = passing through congested nodes will actually forward unmarked = packets to the egress node. When marked packets are preferentially dropped than marked_1 can easily be = smaller than 1% * (unmarked_1 + unmarked_2 + unmarked_3 + unmarled_4 + marked_1). = In this case the admission control situation is not triggered and a = complete collapse of the PCN domain operation can occur! Thus: If no ECMP routing would have been used than for the same situation = CLE =3D marked_1/unmarked_1 + marked_1), which can go easily to 1%, if the C-A-R is well configured. But when ECMP routing is used and the above scenario is applied = then CLE =3D marked_1 /(unmarked_1 + unmarked_2 + unmarked_3 + unmarled_4 + marked_1), = which probaly will not reach 1% when marked packets are preferentially dropped, = since marked_1 can be = smaller than 1% * (unmarked_1 + unmarked_2 + unmarked_3 + unmarled_4 + marked_1) I hope that you now understand the problem! Best regards, Georgios = > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] = > Sent: dinsdag 18 maart 2008 8:30 > To: karagian@cs.utwente.nl > Cc: pcn@ietf.org > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > = > Hi Georgios, > = > in the situation you describe, packet losses occur. This will = > result in bad press, as the customers using PCN based = > services were promised another type of service. > = > In this situation it doesn't matter whether or not ECMP is = > deployed and it also doesn't matter whether termination is = > fair or not. The important event is: packet losses occur (in = > one of your examples several routers drop packets). The drops = > are the only relevant issue. = > Whether service resumes after 5 seconds due to extremly well = > engineered termination or after 10 seconds after a sufficient = > number of customers hang up is not important. = > I can't recall having read anytime in the news "Major network = > outage - but termination was fair." I can only recall having = > seen the first part. > = > I'm sure you're happy in adapting your example, as you do all = > the time. I'm having work to do, but maybe someone else is = > interested in continuing discusion. I think, I've made my point. > = > Regards, > = > Rudiger > = > | -----Original Message----- > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | Sent: Monday, March 17, 2008 5:36 PM > | To: Geib, R=FCdiger > | Cc: pcn@ietf.org > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > | = > | Hi Ruediger > | = > | Please note that what I have described holds also for the situation = > | that the routers are well configured, but a catastrophic = > event occur = > | and at the same time ECMP routing is used. > | = > | Best regards, > | Georgios > | = > | = > | > -----Original Message----- > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > | > Sent: maandag 17 maart 2008 17:10 > | > To: karagian@cs.utwente.nl > | > Cc: pcn@ietf.org > | > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > | > = > | > Hi Georgios, > | > = > | > what I say is if PCN decides to deal with catastrophic events in = > | > combination with misconfigured routers, then it will end up = > | > standardising solutions for academic problems. > | > = > | > Regards, > | > = > | > Rudiger > | > = > | > = > | > | -----Original Message----- > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | > | Sent: Monday, March 17, 2008 4:38 PM > | > | To: Geib, R=FCdiger > | > | Cc: pcn@ietf.org > | > | Subject: RE: [PCN] Concensus questions from Thursday's = > PCN meeting > | > | = > | > | Hi Ruediger > | > | = > | > | I do not understand what you try to say. Please note that flow = > | > | termination is used for the below explained reason, see > | below text > | > | taken from the PCN architecture draft: > | > | = > | > | o The termination mechanism complements admission control. It > | > | allows the network to recover from sudden > | unexpected surges of > | > | PCN-traffic on some links, thus restoring QoS to > | the remaining > | > | flows. Such scenarios are expected to be rare but not = > | > | impossible. > | > | They can be caused by large network failures that > | > redirect lots > | > | of > | > | admitted PCN-traffic to other links, or by > | malfunction of the > | > | measurement-based admission control in the presence > | > of admitted > | > | flows that send for a while with an atypically low > | > rate and then > | > | increase their rates in a correlated way. > | > | = > | > | Best regards, > | > | Georgios > | > | = > | > | = > | > | = > | > | > -----Original Message----- > | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > | > | > Sent: maandag 17 maart 2008 16:32 > | > | > To: karagian@cs.utwente.nl > | > | > Cc: pcn@ietf.org > | > | > Subject: RE: [PCN] Concensus questions from Thursday's > | PCN meeting > | > | > = > | > | > Hi Georgios, > | > | > = > | > | > QoS on redundant links means, that one link is able to > | > | carry the QoS > | > | > traffic of the other. This may not hold for non QoS > | > | traffic. This is, > | > | > what typical carrier backbones providing QoS are = > engineered for = > | > | > (commonly known as traffic engineering). > | > | > = > | > | > Should a misconfiguration occur, things may go wrong. = > | > | > Operational staff corrects this a soon as the > | misconfiguration is > | > | > identified. > | > | > = > | > | > The engineering of carrier backbones is often done with > | automated > | > | > tools, leaving little room for human errors. > | > | > However maintenance work may result in humanne system > | > | interference. I > | > | > doubt that Telekom's engineering department is willing to > | > | accept extra > | > | > protocol and router complexitiy to deal with operator > | > configuration > | > | > errors. While I time and again hear of the worst > | > | misconfigs, I can't > | > | > recall that my colleagues try to adapt standardisation > | afterwards. > | > | > = > | > | > Regards, > | > | > = > | > | > Rudiger > | > | > = > | > | > | -----Original Message----- > | > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | > | > | Sent: Monday, March 17, 2008 3:34 PM > | > | > | To: Geib, R=FCdiger > | > | > | Cc: pcn@ietf.org > | > | > | Subject: RE: [PCN] Concensus questions from Thursday's > | > PCN meeting > | > | > | = > | > | > | Hi Ruediger > | > | > | = > | > | > | Please note that typical IP networks (thus not > | MPLS/GMPLS based > | > | > | domains) can recover from failures by using rerouting. > | > | > | Or do you know another standardized mechanism in typical IP > | > | > networks > | > | > | (thus not MPLS/GMPLS based) that can provide another kind > | > | > of recovery > | > | > | from failures. > | > | > | = > | > | > | Furthermore, I will just explain the example again > | with maximum > | > | > | capacity of > | > | > | pathh2 being equal > | > | > | to maximum capacity of path1 =3D C. > | > | > | Please explain what you do not understand in this example! > | > | > | = > | > | > | Here are the assumptions: > | > | > | * In the PCN domain we assume that ECMP routing is possible! > | > | > | * ingress-eggress-aggregate can contain flows that are > | > | > passing through > | > | > | one path or more paths (when ECMP routing is used). > | > | > | = > | > | > | * routers are currently dropping packets randomly. Thus > | > | marked and > | > | > | unmarked packets will be > | > | > | dropped randomly > | > | > | = > | > | > | * When excess rate measurements are used, the triggering of > | > | > admission > | > | > | control and flow > | > | > | termination are done at the egress by using the CLE. One > | > | > example of > | > | > | this trigger is: > | > | > | CLE > 1%. Note that CLE =3D marked/(unmarked + marked). = > | > | This means > | > | > | that if this trigger is not activated while a severe > | > | > | congestion occurs in the PCN domain, then the operation > | > | > of the PCN > | > | > | domain will completely collapse. > | > | > | = > | > | > | = > | > | > | My statement is: > | > | > | If the routers do not preferentially drop marked packets > | > | > then the PCN > | > | > | domain operation, even in corner case and misconfiguration > | > | > situations, > | > | > | is more robust and more stable than in the situation that > | > | > the router > | > | > | is preferentially dropping marked packets. > | > | > | = > | > | > | The below example show such a corner case! > | > | > | = > | > | > | = > | > | > | I will describe two situations: > | > | > | = > | > | > | Situation 1: > | > | > | Consider that an ingress-egress-aggregate due to ECMP > | > routing it > | > | > | includes flows that are passing from at least two paths. > | > | > | Assume that path1 supports a maximum bandwidth = > capacity of C. = > | > | > | Now consider that the maximum bandwdith capacity of > | path2 is C. > | > | > | Consider also that both paths are fully utilized. > | > | > | = > | > | > | Consider that preferentially marked packets are dropped and > | > | > that path2 > | > | > | fails. > | > | > | Now assume that all (maximum) traffic passing through > | > | path2 will be > | > | > | rerouted through path1. > | > | > | If a bottleneck router located in path1, say Rbott, is > | > | > misconfigured > | > | > | (i.e., from the point of view of having wrongly too high = > | > | > | configured-admissible-rate value), or even if it is well > | > | > configured, > | > | > | then it can be possible that CLE measured at the egress > | > | > cannot reach > | > | > | 1%. > | > | > | Note that > | > | > | CLE =3D marked packets/ (marked packets + unmarked packets). > | > | > | This is because Rbott will just allow an excess rate to > | > | > pass through > | > | > | that is > | > | > | = > | > | > | equal to: C - configured-admissible-rate. The rest of > | > the marked > | > | > | packets, so the rest of the excess rate, will be dropped > | > | by Rbott, > | > | > | since this router is preferentially dropping marked packets. > | > | > | Furthermore, note that due to the ECMP routing = > flows that are = > | > | > | belonging to the same ingress-egress-aggregate and that > | > | are passing > | > | > | through another path, > | > | > | = > | > | > | than path1, which is not congested, will forward traffic > | > | > towards the > | > | > | egress node that will be unmarked. > | > | > | This will mean that the CLE > 1% will not be triggered, > | > | > this will mean > | > | > | that the flow termination will not be triggered and that > | > | > the operation > | > | > | of the PCN domain will collapse completely. > | > | > | = > | > | > | = > | > | > | Situation 2: > | > | > | Now consider that the router just operates as > | > currently, i.e., no > | > | > | preferential drop, randomly dropping marked and > | > unmarked packets. > | > | > | Consider also that the two paths described in Situation 1 > | > | above are > | > | > | used, ECMP routing is used, and that they are fully = > utilized. > | > | > | Assume also that path2 fails and that the path2 traffic is > | > | > rerouted on > | > | > | path1. > | > | > | Now the CLE value will have a higher probability of > | > reaching the > | > | > | triggering value of 1%. > | > | > | = > | > | > | This is because the routers in path1 will drop randomly > | > | marked and > | > | > | unmarked packets. > | > | > | It is more certain that in this case the CLE will reach 1% > | > | > due to the > | > | > | following reason. > | > | > | In this example it is assumed that the maximum > | > bandwidth capacity > | > | > | supported by path2 is C. > | > | > | This means that after rerouting the traffic from path2 into > | > | > path1, the > | > | > | ratio between marked packets and unmarked packets that > | > | are passing > | > | > | thorugh path1 can be equal or higher than 100%. > | > | > | Note that the routers in path1 will mark the excess rate > | > | > above C, thus > | > | > | 1*C (i.e., the rerouted traffic from path2) as marked. > | > | > | The above observation holds also for the situation that > | > | the routers > | > | > | are preferentially dropping unmarked packets. > | > | > | = > | > | > | Thus when routers are preferentially dropping marked > | > packets the > | > | > | robustness of the PCN domain operation is decreasing and in > | > | > some cases > | > | > | it severely decreases, which could cause the complete > | > | > collapse of the > | > | > | PCN domain operation. > | > | > | = > | > | > | Best regards, > | > | > | Georgios > | > | > | = > | > | > | = > | > | > | = > | > | > | = > | > | > | > -----Original Message----- > | > | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > | > | > | > Sent: maandag 17 maart 2008 15:26 > | > | > | > To: karagian@cs.utwente.nl > | > | > | > Cc: pcn@ietf.org > | > | > | > Subject: RE: [PCN] Concensus questions from Thursday's > | > | PCN meeting > | > | > | > = > | > | > | > Hi Georgios, > | > | > | > = > | > | > | > Unfortunately you missed my point. > | > | > | > = > | > | > | > No such thing as you describe has been, is or will for the > | > | > | foreseeable > | > | > | > future be engineered in the IP backbone of the company > | > | > I'm working > | > | > | > for. > | > | > | > = > | > | > | > My expectation on the backbone of any carrier offering > | > | > | transport QoS > | > | > | > is, that it is engineered to survive probable failures > | > | > (like single > | > | > | > link losses) without impact on the performance of QoS > | > | > | traffic. This is > | > | > | > where we should start from, if we discuss PCN. From there > | > | > | on, PCN is > | > | > | > able to add value. > | > | > | > = > | > | > | > Links without traffic engineering followed by > | > | > misconfigured routers > | > | > | > aren't the arguments which will convince either product > | > | > | management or > | > | > | > backbone engineering of the company I work for to > | deploy PCN. > | > | > | > = > | > | > | > As a general comment: I don't regard PCN as a plug and > | > | > play toy for > | > | > | > the operational equivalent of a 'script kiddie'. If others > | > | > | share that > | > | > | > view and our documents don't state that, we = > should add text. > | > | > | > = > | > | > | > Regards, > | > | > | > = > | > | > | > Rudiger > | > | > | > = > | > | > | > | -----Original Message----- > | > | > | > | From: Georgios Karagiannis = > [mailto:karagian@cs.utwente.nl] > | > | > | > | Sent: Monday, March 17, 2008 2:49 PM > | > | > | > | To: Geib, R=FCdiger > | > | > | > | Cc: pcn@ietf.org > | > | > | > | Subject: RE: [PCN] Concensus questions from Thursday's > | > | > PCN meeting > | > | > | > | = > | > | > | > | Hi Ruediger > | > | > | > | = > | > | > | > | You missed my point! > | > | > | > | The explanation applies to all types of IP networks. > | > | > | > | Please note that the problem occurs also when path2 and > | > | > path1 use > | > | > | > | exactly the same maximum capacity, say C! > | > | > | > | = > | > | > | > | In this case, if pathh2 fails then path1 will see > | an excess > | > | > | > rate equal > | > | > | > | to at least C. > | > | > | > | The rest of the explanation is identical to the one used > | > | > | during my > | > | > | > | previous example! > | > | > | > | = > | > | > | > | = > | > | > | > | = > | > | > | > | Best regards, > | > | > | > | Georgios > | > | > | > | = > | > | > | > | = > | > | > | > | = > | > | > | > | = > | > | > | > | = > | > | > | > | > -----Original Message----- > | > | > | > | > From: Geib, Ruediger > | [mailto:Ruediger.Geib@t-systems.com] > | > | > | > | > Sent: maandag 17 maart 2008 14:34 > | > | > | > | > To: karagian@cs.utwente.nl > | > | > | > | > Cc: pcn@ietf.org > | > | > | > | > Subject: RE: [PCN] Concensus questions from Thursday's > | > | > | PCN meeting > | > | > | > | > = > | > | > | > | > Hi Georgios, > | > | > | > | > = > | > | > | > | > What you describe isn't backbone traffic engineering. = > | > | > What you > | > | > | > | > describe may happen in corporate VPNs, where a > | DSL access > | > | > | > | is used to > | > | > | > | > back up a WAN Fast Ethernet access or the = > like. I don't > | > | > | > | object to have > | > | > | > | > standards on PCN for VPNs, but I'm not > | interested in this > | > | > | > issue for > | > | > | > | > now. > | > | > | > | > = > | > | > | > | > If you know any carrier who's operating his > | network with a > | > | > | > | > 16:1 load balancing for QoS traffic on any > | particular link > | > | > | > | set, please > | > | > | > | > publish the name, we are all interested in hearing it. > | > | > | > | > = > | > | > | > | > Regards, > | > | > | > | > = > | > | > | > | > Rudiger > | > | > | > | > = > | > | > | > | > = > | > | > | > | > = > | > | > | > | > | -----Original Message----- > | > | > | > | > | From: Georgios Karagiannis > | > [mailto:karagian@cs.utwente.nl] > | > | > | > | > | Sent: Monday, March 17, 2008 11:03 AM > | > | > | > | > | To: Geib, R=FCdiger > | > | > | > | > | Cc: pcn@ietf.org > | > | > | > | > | Subject: RE: [PCN] Concensus questions from = > Thursday's > | > | > | > PCN meeting > | > | > | > | > | = > | > | > | > | > | Hi Ruediger > | > | > | > | > | = > | > | > | > | > | I will try to explain this more clearly. > | > | > | > | > | Here are the assumptions: > | > | > | > | > | * In the PCN domain we assume that ECMP routing > | > | is possible! > | > | > | > | > | * ingress-eggress-aggregate can contain = > flows that are > | > | > | > | > passing through > | > | > | > | > | one path or more paths (when ECMP routing is used). > | > | > | > | > | = > | > | > | > | > | * routers are currently dropping packets > | randomly. Thus > | > | > | > | marked and > | > | > | > | > | unmarked packets will be > | > | > | > | > | dropped randomly > | > | > | > | > | = > | > | > | > | > | * When excess rate measurements are used, the > | > | triggering of > | > | > | > | > admission > | > | > | > | > | control and flow > | > | > | > | > | termination are done at the egress by using > | > the CLE. One > | > | > | > | > example of > | > | > | > | > | this trigger is: > | > | > | > | > | CLE > 1%. Note that CLE =3D marked/(unmarked > | + marked). = > | > | > | > | This means > | > | > | > | > | that if this trigger is not activated while a severe > | > | > | > | > | congestion occurs in the PCN domain, then the > | > operation > | > | > | > | > of the PCN > | > | > | > | > | domain will completely collapse. > | > | > | > | > | = > | > | > | > | > | = > | > | > | > | > | My statement is: > | > | > | > | > | If the routers do not preferentially drop > | marked packets > | > | > | > | > then the PCN > | > | > | > | > | domain operation, even in corner case and > | > misconfiguration > | > | > | > | > situations, > | > | > | > | > | is more robust and more stable than in the > | > situation that > | > | > | > | > the router > | > | > | > | > | is preferentially dropping marked packets. > | > | > | > | > | = > | > | > | > | > | The below example show such a corner case! > | > | > | > | > | = > | > | > | > | > | = > | > | > | > | > | I will describe two situations: > | > | > | > | > | = > | > | > | > | > | Situation 1: > | > | > | > | > | Consider that an ingress-egress-aggregate = > due to ECMP > | > | > | > routing it > | > | > | > | > | includes flows that are passing from at least > | two paths. > | > | > | > | > | Assume that path1 supports a maximum bandwidth > | > | > capacity of C. = > | > | > | > | > | Now consider > | > | > | > | > | that the maximum bandwdith capacity of = > path2 is 15*C. > | > | > | > | > | Consider also that both paths are fully utilized. > | > | > | > | > | = > | > | > | > | > | Consider that preferentially marked packets are > | > | dropped and > | > | > | > | > that path2 > | > | > | > | > | fails. > | > | > | > | > | Now assume that all (maximum) traffic = > passing through > | > | > | > | path2 will be > | > | > | > | > | rerouted through path1. > | > | > | > | > | If a bottleneck router located in path1, = > say Rbott, is > | > | > | > | > misconfigured > | > | > | > | > | (i.e., from the point of view of having wrongly > | > too high > | > | > | > | > | configured-admissible-rate value), or even if > | it is well > | > | > | > | > configured, > | > | > | > | > | then it can be possible that CLE measured at > | the egress > | > | > | > | > cannot reach > | > | > | > | > | 1%. > | > | > | > | > | Note that > | > | > | > | > | CLE =3D marked packets/ (marked packets + > | > unmarked packets). > | > | > | > | > | This is because Rbott will just allow an > | excess rate to > | > | > | > | > pass through > | > | > | > | > | that is > | > | > | > | > | = > | > | > | > | > | equal to: C - configured-admissible-rate. = > The rest of > | > | > | > the marked > | > | > | > | > | packets, so the rest of the excess rate, will > | be dropped > | > | > | > | by Rbott, > | > | > | > | > | since this router is preferentially dropping > | > | marked packets. > | > | > | > | > | Furthermore, note that due to the ECMP routing > | > | > flows that are > | > | > | > | > | belonging to the same > | ingress-egress-aggregate and that > | > | > | > | are passing > | > | > | > | > | through another path, > | > | > | > | > | = > | > | > | > | > | than path1, which is not congested, will > | forward traffic > | > | > | > | > towards the > | > | > | > | > | egress node that will be unmarked. > | > | > | > | > | This will mean that the CLE > 1% will not be > | triggered, > | > | > | > | > this will mean > | > | > | > | > | that the flow termination will not be > | triggered and that > | > | > | > | > the operation > | > | > | > | > | of the PCN domain will collapse completely. > | > | > | > | > | = > | > | > | > | > | = > | > | > | > | > | Situation 2: > | > | > | > | > | Now consider that the router just operates as > | > | > | > currently, i.e., no > | > | > | > | > | preferential drop, randomly dropping marked and > | > | > | > unmarked packets. > | > | > | > | > | Consider also that the two paths described in > | > Situation 1 > | > | > | > | above are > | > | > | > | > | used, ECMP routing is used, and that they are fully > | > | > utilized. > | > | > | > | > | Assume also that path2 fails and that the path2 > | > traffic is > | > | > | > | > rerouted on > | > | > | > | > | path1. > | > | > | > | > | Now the CLE value will have a higher probability of > | > | > | > reaching the > | > | > | > | > | triggering value of 1%. > | > | > | > | > | = > | > | > | > | > | This is because the routers in path1 will > | drop randomly > | > | > | > | marked and > | > | > | > | > | unmarked packets. > | > | > | > | > | It is more certain that in this case the CLE > | > will reach 1% > | > | > | > | > due to the > | > | > | > | > | following reason. > | > | > | > | > | In this example it is assumed that the maximum > | > | > | > bandwidth capacity > | > | > | > | > | supported by path2 is 15*C. > | > | > | > | > | This means that after rerouting the traffic from > | > | path2 into > | > | > | > | > path1, the > | > | > | > | > | ratio between marked packets and unmarked = > packets that > | > | > | > | are passing > | > | > | > | > | thorugh path1 can be equal or higher than 16. > | > | > | > | > | Note that the routers in path1 will mark the > | excess rate > | > | > | > | > above C, thus > | > | > | > | > | 16 * C (i.e., the rerouted traffic from path2) > | > as marked. > | > | > | > | > | The above observation holds also for the > | situation that > | > | > | > | the routers > | > | > | > | > | are preferentially dropping unmarked packets. > | > | > | > | > | = > | > | > | > | > | Thus when routers are preferentially dropping marked > | > | > | > packets the > | > | > | > | > | robustness of the PCN domain operation is > | > | decreasing and in > | > | > | > | > some cases > | > | > | > | > | it severely decreases, which could cause = > the complete > | > | > | > | > collapse of the > | > | > | > | > | PCN domain operation. > | > | > | > | > | = > | > | > | > | > | Best regards, > | > | > | > | > | Georgios > | > | > | > | > | = > | > | > | > | > | = > | > | > | > | > | = > | > | > | > | > | = > | > | > | > | > | = > | > | > | > | > | > -----Original Message----- > | > | > | > | > | > From: Geib, Ruediger > | > | [mailto:Ruediger.Geib@t-systems.com] > | > | > | > | > | > Sent: maandag 17 maart 2008 9:42 > | > | > | > | > | > To: karagian@cs.utwente.nl > | > | > | > | > | > Cc: pcn@ietf.org > | > | > | > | > | > Subject: RE: [PCN] Concensus questions from > | Thursday's > | > | > | > | PCN meeting > | > | > | > | > | > = > | > | > | > | > | > Hi Georgios, > | > | > | > | > | > = > | > | > | > | > | > PCN is designed for deployment in traffic = > engineered > | > | > | > networks. = > | > | > | > | > | > Please decribe, how to engineer a high performance > | > | > | > | > carrier backbone > | > | > | > | > | > and then review the assumptions your discussion > | > | > is based on. > | > | > | > | > | > = > | > | > | > | > | > Regards, > | > | > | > | > | > = > | > | > | > | > | > Rudiger > | > | > | > | > | > = > | > | > | > | > | > | -----Original Message----- > | > | > | > | > | > | From: Georgios Karagiannis > | > | > [mailto:karagian@cs.utwente.nl] > | > | > | > | > | > | Sent: Monday, March 17, 2008 9:34 AM > | > | > | > | > | > | To: Geib, R=FCdiger > | > | > | > | > | > | Cc: pcn@ietf.org > | > | > | > | > | > | Subject: RE: [PCN] Concensus questions from > | > Thursday's > | > | > | > | > PCN meeting > | > | > | > | > | > | = > | > | > | > | > | > | Hi Ruediger > | > | > | > | > | > | = > | > | > | > | > | > | What do you mean? > | > | > | > | > | > | Do you mean that you do not want to discuss > | > | corner cases > | > | > | > | > | > (ECMP related > | > | > | > | > | > | cases) that could > | > | > | > | > | > | collapse the PCN domain operation? > | > | > | > | > | > | What I am saying is that if the routers do not > | > | > | > | > | preferentially drop > | > | > | > | > | > | marked packets then the PCN domain operation is > | > | > | more robust > | > | > | > | > | > and more > | > | > | > | > | > | stable than in the situation that the router is > | > | > | > | preferentially > | > | > | > | > | > | dropping marked packets. > | > | > | > | > | > | = > | > | > | > | > | > | Are you saying that this statement is not right? > | > | > | > | > | > | = > | > | > | > | > | > | = > | > | > | > | > | > | Best regards, > | > | > | > | > | > | Georgios > | > | > | > | > | > | = > | > | > | > | > | > > | > | > | > | > | = > | > | > | > | > | = > | > | > | > | > | = > | > | > | > | > = > | > | > | > | = > | > | > | > | = > | > | > | > | = > | > | > | > = > | > | > | = > | > | > | = > | > | > | = > | > | > = > | > | = > | > | = > | > | = > | > = > | = > | = > | = > = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 18 03:37:07 2008 Return-Path: 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 03BDB28C2C1; Tue, 18 Mar 2008 03:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.693 X-Spam-Level: X-Spam-Status: No, score=-100.693 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 7SJnxppWA5Vj; Tue, 18 Mar 2008 03:37:02 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F86B28C475; Tue, 18 Mar 2008 03:37:02 -0700 (PDT) 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 2248828C475 for ; Tue, 18 Mar 2008 03:37:02 -0700 (PDT) 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 1ffRIeIQkmn1 for ; Tue, 18 Mar 2008 03:36:59 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id CF02E28C2C1 for ; Tue, 18 Mar 2008 03:36:58 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Tue, 18 Mar 2008 11:34:40 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Mar 2008 11:34:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Mar 2008 11:36:02 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CF647C5@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <000701c888e1$37a68c20$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciIBF++zKz17E/GQcib+W/rjB17BgABJ68gAABXALAAAifOMAAH2KywAACjCyAAAJeqgAAA4wtQAAGeymAAAM8HgAAA8S7AAAEXZnAAHn88IAAGS18AAADxzSA= References: <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de> <000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6423C@S4DE8PSAANK.mitte.t-com.de> <001301c88816$114dab60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF644B1@S4DE8PSAANK.mitte.t-com.de> <000001c88835$998bcf60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6451A@S4DE8PSAANK.mitte.t-com.de> <000601c8883b$e3828950$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF64580@S4DE8PSAANK.mitte.t-com.de> <000901c88844$f35c1130$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF645A3@S4DE8PSAANK.mitte.t-com.de> <000a01c8884d$081c9790$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF64645@S4DE8PSAANK.mitte.t-com.de> <000701c888e1$37a68c20$810c5982@dynamic.ew i.utwent e.nl> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 18 Mar 2008 10:34:40.0458 (UTC) FILETIME=[ABFE42A0:01C888E3] Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Georgios = see in line. Regards, Rudiger | -----Original Message----- | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] = | Sent: Tuesday, March 18, 2008 11:17 AM | To: Geib, R=FCdiger | Cc: pcn@ietf.org | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | = | Hi Ruediger | = | The problem that I have explained it does not have to do with = | slow reaction time but it has to do with complete collapse of = | the PCN domain operation. = | This occurs when the admission control/flow termination = | triggers at the egress are not activated when they should be = | activated. | = | = | Here is a more concrete example: | = | When ECMP routing is used, it means that flows that are = | associated with the same ingress-egress-aggregate can follow = | different paths. = | Assume that there are 5 such paths that are carrying flows = | associated with the same ingress-egress-aggregate. | = | Consider now that one of the 5 paths fails and it is rerouted = | to one of the other paths. | Assume that path1 is becoming congested and the other 3 = | remaining paths are not congested. | I am also assuming in this case that the thresholds are well = | configured. This is not realistic. | The egress will calculate CLE in the following way: | CLE =3D marked_1 /(unmarked_1 + unmarked_2 + unmarked_3 + unmarked_4 + | marked_1) | = | I think that typcially the above calculated CLE will not = | reach 1% when marked packets are preferentially dropped. | This problem is due to the fact that ECMP routing is used and = | flows that are not participating at the congestion are = | contributing to the calculation of the CLE. The flows that = | are not passing through congested nodes will actually forward = | unmarked packets to the egress node. | = | When marked packets are preferentially dropped than marked_1 = | can easily be smaller than 1% * (unmarked_1 + unmarked_2 + = | unmarked_3 + unmarled_4 + marked_1). = | In this case the admission control situation is not triggered = | and a complete collapse of the PCN domain operation can occur! | = | Thus: | If no ECMP routing would have been used than for the same = | situation CLE =3D marked_1/unmarked_1 + marked_1), which can go = | easily to 1%, if the C-A-R is well configured. | = | But when ECMP routing is used and the above scenario is = | applied then CLE =3D marked_1 /(unmarked_1 + unmarked_2 + = | unmarked_3 + unmarled_4 + marked_1), which probaly will not = | reach 1% when marked packets are preferentially dropped, = | since marked_1 can be smaller than 1% * (unmarked_1 + = | unmarked_2 + unmarked_3 + unmarled_4 + | marked_1) | = | I hope that you now understand the problem! | = | Best regards, | Georgios = | = | > -----Original Message----- | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > Sent: dinsdag 18 maart 2008 8:30 | > To: karagian@cs.utwente.nl | > Cc: pcn@ietf.org | > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | > = | > Hi Georgios, | > = | > in the situation you describe, packet losses occur. This = | will result = | > in bad press, as the customers using PCN based services = | were promised = | > another type of service. | > = | > In this situation it doesn't matter whether or not ECMP is deployed = | > and it also doesn't matter whether termination is fair or not. The = | > important event is: packet losses occur (in one of your examples = | > several routers drop packets). The drops are the only = | relevant issue. | > Whether service resumes after 5 seconds due to extremly well = | > engineered termination or after 10 seconds after a = | sufficient number = | > of customers hang up is not important. | > I can't recall having read anytime in the news "Major = | network outage - = | > but termination was fair." I can only recall having seen the first = | > part. | > = | > I'm sure you're happy in adapting your example, as you do all the = | > time. I'm having work to do, but maybe someone else is = | interested in = | > continuing discusion. I think, I've made my point. | > = | > Regards, | > = | > Rudiger | > = | > | -----Original Message----- | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > | Sent: Monday, March 17, 2008 5:36 PM | > | To: Geib, R=FCdiger | > | Cc: pcn@ietf.org | > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | > | = | > | Hi Ruediger | > | = | > | Please note that what I have described holds also for the = | situation = | > | that the routers are well configured, but a catastrophic | > event occur | > | and at the same time ECMP routing is used. | > | = | > | Best regards, | > | Georgios | > | = | > | = | > | > -----Original Message----- | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > | > Sent: maandag 17 maart 2008 17:10 | > | > To: karagian@cs.utwente.nl | > | > Cc: pcn@ietf.org | > | > Subject: RE: [PCN] Concensus questions from Thursday's = | PCN meeting | > | > = | > | > Hi Georgios, | > | > = | > | > what I say is if PCN decides to deal with catastrophic = | events in = | > | > combination with misconfigured routers, then it will end up = | > | > standardising solutions for academic problems. | > | > = | > | > Regards, | > | > = | > | > Rudiger | > | > = | > | > = | > | > | -----Original Message----- | > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > | > | Sent: Monday, March 17, 2008 4:38 PM | > | > | To: Geib, R=FCdiger | > | > | Cc: pcn@ietf.org | > | > | Subject: RE: [PCN] Concensus questions from Thursday's | > PCN meeting | > | > | = | > | > | Hi Ruediger | > | > | = | > | > | I do not understand what you try to say. Please note = | that flow = | > | > | termination is used for the below explained reason, see | > | below text | > | > | taken from the PCN architecture draft: | > | > | = | > | > | o The termination mechanism complements admission = | control. It | > | > | allows the network to recover from sudden | > | unexpected surges of | > | > | PCN-traffic on some links, thus restoring QoS to | > | the remaining | > | > | flows. Such scenarios are expected to be rare but not = | > | > | impossible. | > | > | They can be caused by large network failures that | > | > redirect lots | > | > | of | > | > | admitted PCN-traffic to other links, or by | > | malfunction of the | > | > | measurement-based admission control in the presence | > | > of admitted | > | > | flows that send for a while with an atypically low | > | > rate and then | > | > | increase their rates in a correlated way. | > | > | = | > | > | Best regards, | > | > | Georgios | > | > | = | > | > | = | > | > | = | > | > | > -----Original Message----- | > | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > | > | > Sent: maandag 17 maart 2008 16:32 | > | > | > To: karagian@cs.utwente.nl | > | > | > Cc: pcn@ietf.org | > | > | > Subject: RE: [PCN] Concensus questions from Thursday's | > | PCN meeting | > | > | > = | > | > | > Hi Georgios, | > | > | > = | > | > | > QoS on redundant links means, that one link is able to | > | > | carry the QoS | > | > | > traffic of the other. This may not hold for non QoS | > | > | traffic. This is, | > | > | > what typical carrier backbones providing QoS are | > engineered for | > | > | > (commonly known as traffic engineering). | > | > | > = | > | > | > Should a misconfiguration occur, things may go wrong. = | > | > | > Operational staff corrects this a soon as the | > | misconfiguration is | > | > | > identified. | > | > | > = | > | > | > The engineering of carrier backbones is often done with | > | automated | > | > | > tools, leaving little room for human errors. | > | > | > However maintenance work may result in humanne system | > | > | interference. I | > | > | > doubt that Telekom's engineering department is willing to | > | > | accept extra | > | > | > protocol and router complexitiy to deal with operator | > | > configuration | > | > | > errors. While I time and again hear of the worst | > | > | misconfigs, I can't | > | > | > recall that my colleagues try to adapt standardisation | > | afterwards. | > | > | > = | > | > | > Regards, | > | > | > = | > | > | > Rudiger | > | > | > = | > | > | > | -----Original Message----- | > | > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > | > | > | Sent: Monday, March 17, 2008 3:34 PM | > | > | > | To: Geib, R=FCdiger | > | > | > | Cc: pcn@ietf.org | > | > | > | Subject: RE: [PCN] Concensus questions from Thursday's | > | > PCN meeting | > | > | > | = | > | > | > | Hi Ruediger | > | > | > | = | > | > | > | Please note that typical IP networks (thus not | > | MPLS/GMPLS based | > | > | > | domains) can recover from failures by using rerouting. | > | > | > | Or do you know another standardized mechanism in = | typical IP | > | > | > networks | > | > | > | (thus not MPLS/GMPLS based) that can provide another kind | > | > | > of recovery | > | > | > | from failures. | > | > | > | = | > | > | > | Furthermore, I will just explain the example again | > | with maximum | > | > | > | capacity of | > | > | > | pathh2 being equal | > | > | > | to maximum capacity of path1 =3D C. | > | > | > | Please explain what you do not understand in this example! | > | > | > | = | > | > | > | Here are the assumptions: | > | > | > | * In the PCN domain we assume that ECMP routing = | is possible! | > | > | > | * ingress-eggress-aggregate can contain flows that are | > | > | > passing through | > | > | > | one path or more paths (when ECMP routing is used). | > | > | > | = | > | > | > | * routers are currently dropping packets randomly. Thus | > | > | marked and | > | > | > | unmarked packets will be | > | > | > | dropped randomly | > | > | > | = | > | > | > | * When excess rate measurements are used, the = | triggering of | > | > | > admission | > | > | > | control and flow | > | > | > | termination are done at the egress by using the CLE. One | > | > | > example of | > | > | > | this trigger is: | > | > | > | CLE > 1%. Note that CLE =3D marked/(unmarked + marked). = | > | > | This means | > | > | > | that if this trigger is not activated while a severe | > | > | > | congestion occurs in the PCN domain, then the operation | > | > | > of the PCN | > | > | > | domain will completely collapse. | > | > | > | = | > | > | > | = | > | > | > | My statement is: | > | > | > | If the routers do not preferentially drop marked packets | > | > | > then the PCN | > | > | > | domain operation, even in corner case and misconfiguration | > | > | > situations, | > | > | > | is more robust and more stable than in the situation that | > | > | > the router | > | > | > | is preferentially dropping marked packets. | > | > | > | = | > | > | > | The below example show such a corner case! | > | > | > | = | > | > | > | = | > | > | > | I will describe two situations: | > | > | > | = | > | > | > | Situation 1: | > | > | > | Consider that an ingress-egress-aggregate due to ECMP | > | > routing it | > | > | > | includes flows that are passing from at least two paths. | > | > | > | Assume that path1 supports a maximum bandwidth | > capacity of C. = | > | > | > | Now consider that the maximum bandwdith capacity of | > | path2 is C. | > | > | > | Consider also that both paths are fully utilized. | > | > | > | = | > | > | > | Consider that preferentially marked packets are = | dropped and | > | > | > that path2 | > | > | > | fails. | > | > | > | Now assume that all (maximum) traffic passing through | > | > | path2 will be | > | > | > | rerouted through path1. | > | > | > | If a bottleneck router located in path1, say Rbott, is | > | > | > misconfigured | > | > | > | (i.e., from the point of view of having wrongly too high = | > | > | > | configured-admissible-rate value), or even if it is well | > | > | > configured, | > | > | > | then it can be possible that CLE measured at the egress | > | > | > cannot reach | > | > | > | 1%. | > | > | > | Note that | > | > | > | CLE =3D marked packets/ (marked packets + unmarked packets). | > | > | > | This is because Rbott will just allow an excess rate to | > | > | > pass through | > | > | > | that is | > | > | > | = | > | > | > | equal to: C - configured-admissible-rate. The rest of | > | > the marked | > | > | > | packets, so the rest of the excess rate, will be dropped | > | > | by Rbott, | > | > | > | since this router is preferentially dropping = | marked packets. | > | > | > | Furthermore, note that due to the ECMP routing | > flows that are | > | > | > | belonging to the same ingress-egress-aggregate and that | > | > | are passing | > | > | > | through another path, | > | > | > | = | > | > | > | than path1, which is not congested, will forward traffic | > | > | > towards the | > | > | > | egress node that will be unmarked. | > | > | > | This will mean that the CLE > 1% will not be triggered, | > | > | > this will mean | > | > | > | that the flow termination will not be triggered and that | > | > | > the operation | > | > | > | of the PCN domain will collapse completely. | > | > | > | = | > | > | > | = | > | > | > | Situation 2: | > | > | > | Now consider that the router just operates as | > | > currently, i.e., no | > | > | > | preferential drop, randomly dropping marked and | > | > unmarked packets. | > | > | > | Consider also that the two paths described in Situation 1 | > | > | above are | > | > | > | used, ECMP routing is used, and that they are fully | > utilized. | > | > | > | Assume also that path2 fails and that the path2 traffic is | > | > | > rerouted on | > | > | > | path1. | > | > | > | Now the CLE value will have a higher probability of | > | > reaching the | > | > | > | triggering value of 1%. | > | > | > | = | > | > | > | This is because the routers in path1 will drop randomly | > | > | marked and | > | > | > | unmarked packets. | > | > | > | It is more certain that in this case the CLE will reach 1% | > | > | > due to the | > | > | > | following reason. | > | > | > | In this example it is assumed that the maximum | > | > bandwidth capacity | > | > | > | supported by path2 is C. | > | > | > | This means that after rerouting the traffic from = | path2 into | > | > | > path1, the | > | > | > | ratio between marked packets and unmarked packets that | > | > | are passing | > | > | > | thorugh path1 can be equal or higher than 100%. | > | > | > | Note that the routers in path1 will mark the excess rate | > | > | > above C, thus | > | > | > | 1*C (i.e., the rerouted traffic from path2) as marked. | > | > | > | The above observation holds also for the situation that | > | > | the routers | > | > | > | are preferentially dropping unmarked packets. | > | > | > | = | > | > | > | Thus when routers are preferentially dropping marked | > | > packets the | > | > | > | robustness of the PCN domain operation is = | decreasing and in | > | > | > some cases | > | > | > | it severely decreases, which could cause the complete | > | > | > collapse of the | > | > | > | PCN domain operation. | > | > | > | = | > | > | > | Best regards, | > | > | > | Georgios | > | > | > | = | > | > | > | = | > | > | > | = | > | > | > | = | > | > | > | > -----Original Message----- | > | > | > | > From: Geib, Ruediger = | [mailto:Ruediger.Geib@t-systems.com] | > | > | > | > Sent: maandag 17 maart 2008 15:26 | > | > | > | > To: karagian@cs.utwente.nl | > | > | > | > Cc: pcn@ietf.org | > | > | > | > Subject: RE: [PCN] Concensus questions from Thursday's | > | > | PCN meeting | > | > | > | > = | > | > | > | > Hi Georgios, | > | > | > | > = | > | > | > | > Unfortunately you missed my point. | > | > | > | > = | > | > | > | > No such thing as you describe has been, is or = | will for the | > | > | > | foreseeable | > | > | > | > future be engineered in the IP backbone of the company | > | > | > I'm working | > | > | > | > for. | > | > | > | > = | > | > | > | > My expectation on the backbone of any carrier offering | > | > | > | transport QoS | > | > | > | > is, that it is engineered to survive probable failures | > | > | > (like single | > | > | > | > link losses) without impact on the performance of QoS | > | > | > | traffic. This is | > | > | > | > where we should start from, if we discuss PCN. = | From there | > | > | > | on, PCN is | > | > | > | > able to add value. | > | > | > | > = | > | > | > | > Links without traffic engineering followed by | > | > | > misconfigured routers | > | > | > | > aren't the arguments which will convince either product | > | > | > | management or | > | > | > | > backbone engineering of the company I work for to | > | deploy PCN. | > | > | > | > = | > | > | > | > As a general comment: I don't regard PCN as a plug and | > | > | > play toy for | > | > | > | > the operational equivalent of a 'script = | kiddie'. If others | > | > | > | share that | > | > | > | > view and our documents don't state that, we | > should add text. | > | > | > | > = | > | > | > | > Regards, | > | > | > | > = | > | > | > | > Rudiger | > | > | > | > = | > | > | > | > | -----Original Message----- | > | > | > | > | From: Georgios Karagiannis | > [mailto:karagian@cs.utwente.nl] | > | > | > | > | Sent: Monday, March 17, 2008 2:49 PM | > | > | > | > | To: Geib, R=FCdiger | > | > | > | > | Cc: pcn@ietf.org | > | > | > | > | Subject: RE: [PCN] Concensus questions from Thursday's | > | > | > PCN meeting | > | > | > | > | = | > | > | > | > | Hi Ruediger | > | > | > | > | = | > | > | > | > | You missed my point! | > | > | > | > | The explanation applies to all types of IP networks. | > | > | > | > | Please note that the problem occurs also when = | path2 and | > | > | > path1 use | > | > | > | > | exactly the same maximum capacity, say C! | > | > | > | > | = | > | > | > | > | In this case, if pathh2 fails then path1 will see | > | an excess | > | > | > | > rate equal | > | > | > | > | to at least C. | > | > | > | > | The rest of the explanation is identical to = | the one used | > | > | > | during my | > | > | > | > | previous example! | > | > | > | > | = | > | > | > | > | = | > | > | > | > | = | > | > | > | > | Best regards, | > | > | > | > | Georgios | > | > | > | > | = | > | > | > | > | = | > | > | > | > | = | > | > | > | > | = | > | > | > | > | = | > | > | > | > | > -----Original Message----- | > | > | > | > | > From: Geib, Ruediger | > | [mailto:Ruediger.Geib@t-systems.com] | > | > | > | > | > Sent: maandag 17 maart 2008 14:34 | > | > | > | > | > To: karagian@cs.utwente.nl | > | > | > | > | > Cc: pcn@ietf.org | > | > | > | > | > Subject: RE: [PCN] Concensus questions from = | Thursday's | > | > | > | PCN meeting | > | > | > | > | > = | > | > | > | > | > Hi Georgios, | > | > | > | > | > = | > | > | > | > | > What you describe isn't backbone traffic = | engineering. = | > | > | > What you | > | > | > | > | > describe may happen in corporate VPNs, where a | > | DSL access | > | > | > | > | is used to | > | > | > | > | > back up a WAN Fast Ethernet access or the | > like. I don't | > | > | > | > | object to have | > | > | > | > | > standards on PCN for VPNs, but I'm not | > | interested in this | > | > | > | > issue for | > | > | > | > | > now. | > | > | > | > | > = | > | > | > | > | > If you know any carrier who's operating his | > | network with a | > | > | > | > | > 16:1 load balancing for QoS traffic on any | > | particular link | > | > | > | > | set, please | > | > | > | > | > publish the name, we are all interested in = | hearing it. | > | > | > | > | > = | > | > | > | > | > Regards, | > | > | > | > | > = | > | > | > | > | > Rudiger | > | > | > | > | > = | > | > | > | > | > = | > | > | > | > | > = | > | > | > | > | > | -----Original Message----- | > | > | > | > | > | From: Georgios Karagiannis | > | > [mailto:karagian@cs.utwente.nl] | > | > | > | > | > | Sent: Monday, March 17, 2008 11:03 AM | > | > | > | > | > | To: Geib, R=FCdiger | > | > | > | > | > | Cc: pcn@ietf.org | > | > | > | > | > | Subject: RE: [PCN] Concensus questions from | > Thursday's | > | > | > | > PCN meeting | > | > | > | > | > | = | > | > | > | > | > | Hi Ruediger | > | > | > | > | > | = | > | > | > | > | > | I will try to explain this more clearly. | > | > | > | > | > | Here are the assumptions: | > | > | > | > | > | * In the PCN domain we assume that ECMP routing | > | > | is possible! | > | > | > | > | > | * ingress-eggress-aggregate can contain | > flows that are | > | > | > | > | > passing through | > | > | > | > | > | one path or more paths (when ECMP routing = | is used). | > | > | > | > | > | = | > | > | > | > | > | * routers are currently dropping packets | > | randomly. Thus | > | > | > | > | marked and | > | > | > | > | > | unmarked packets will be | > | > | > | > | > | dropped randomly | > | > | > | > | > | = | > | > | > | > | > | * When excess rate measurements are used, the | > | > | triggering of | > | > | > | > | > admission | > | > | > | > | > | control and flow | > | > | > | > | > | termination are done at the egress by using | > | > the CLE. One | > | > | > | > | > example of | > | > | > | > | > | this trigger is: | > | > | > | > | > | CLE > 1%. Note that CLE =3D marked/(unmarked | > | + marked). = | > | > | > | > | This means | > | > | > | > | > | that if this trigger is not activated = | while a severe | > | > | > | > | > | congestion occurs in the PCN domain, then the | > | > operation | > | > | > | > | > of the PCN | > | > | > | > | > | domain will completely collapse. | > | > | > | > | > | = | > | > | > | > | > | = | > | > | > | > | > | My statement is: | > | > | > | > | > | If the routers do not preferentially drop | > | marked packets | > | > | > | > | > then the PCN | > | > | > | > | > | domain operation, even in corner case and | > | > misconfiguration | > | > | > | > | > situations, | > | > | > | > | > | is more robust and more stable than in the | > | > situation that | > | > | > | > | > the router | > | > | > | > | > | is preferentially dropping marked packets. | > | > | > | > | > | = | > | > | > | > | > | The below example show such a corner case! | > | > | > | > | > | = | > | > | > | > | > | = | > | > | > | > | > | I will describe two situations: | > | > | > | > | > | = | > | > | > | > | > | Situation 1: | > | > | > | > | > | Consider that an ingress-egress-aggregate | > due to ECMP | > | > | > | > routing it | > | > | > | > | > | includes flows that are passing from at least | > | two paths. | > | > | > | > | > | Assume that path1 supports a maximum bandwidth | > | > | > capacity of C. = | > | > | > | > | > | Now consider | > | > | > | > | > | that the maximum bandwdith capacity of | > path2 is 15*C. | > | > | > | > | > | Consider also that both paths are fully utilized. | > | > | > | > | > | = | > | > | > | > | > | Consider that preferentially marked packets are | > | > | dropped and | > | > | > | > | > that path2 | > | > | > | > | > | fails. | > | > | > | > | > | Now assume that all (maximum) traffic | > passing through | > | > | > | > | path2 will be | > | > | > | > | > | rerouted through path1. | > | > | > | > | > | If a bottleneck router located in path1, | > say Rbott, is | > | > | > | > | > misconfigured | > | > | > | > | > | (i.e., from the point of view of having wrongly | > | > too high | > | > | > | > | > | configured-admissible-rate value), or even if | > | it is well | > | > | > | > | > configured, | > | > | > | > | > | then it can be possible that CLE measured at | > | the egress | > | > | > | > | > cannot reach | > | > | > | > | > | 1%. | > | > | > | > | > | Note that | > | > | > | > | > | CLE =3D marked packets/ (marked packets + | > | > unmarked packets). | > | > | > | > | > | This is because Rbott will just allow an | > | excess rate to | > | > | > | > | > pass through | > | > | > | > | > | that is | > | > | > | > | > | = | > | > | > | > | > | equal to: C - configured-admissible-rate. = | > The rest of | > | > | > | > the marked | > | > | > | > | > | packets, so the rest of the excess rate, will | > | be dropped | > | > | > | > | by Rbott, | > | > | > | > | > | since this router is preferentially dropping | > | > | marked packets. | > | > | > | > | > | Furthermore, note that due to the ECMP routing | > | > | > flows that are | > | > | > | > | > | belonging to the same | > | ingress-egress-aggregate and that | > | > | > | > | are passing | > | > | > | > | > | through another path, | > | > | > | > | > | = | > | > | > | > | > | than path1, which is not congested, will | > | forward traffic | > | > | > | > | > towards the | > | > | > | > | > | egress node that will be unmarked. | > | > | > | > | > | This will mean that the CLE > 1% will not be | > | triggered, | > | > | > | > | > this will mean | > | > | > | > | > | that the flow termination will not be | > | triggered and that | > | > | > | > | > the operation | > | > | > | > | > | of the PCN domain will collapse completely. | > | > | > | > | > | = | > | > | > | > | > | = | > | > | > | > | > | Situation 2: | > | > | > | > | > | Now consider that the router just operates as | > | > | > | > currently, i.e., no | > | > | > | > | > | preferential drop, randomly dropping marked and | > | > | > | > unmarked packets. | > | > | > | > | > | Consider also that the two paths described in | > | > Situation 1 | > | > | > | > | above are | > | > | > | > | > | used, ECMP routing is used, and that they = | are fully | > | > | > utilized. | > | > | > | > | > | Assume also that path2 fails and that the path2 | > | > traffic is | > | > | > | > | > rerouted on | > | > | > | > | > | path1. | > | > | > | > | > | Now the CLE value will have a higher = | probability of | > | > | > | > reaching the | > | > | > | > | > | triggering value of 1%. | > | > | > | > | > | = | > | > | > | > | > | This is because the routers in path1 will | > | drop randomly | > | > | > | > | marked and | > | > | > | > | > | unmarked packets. | > | > | > | > | > | It is more certain that in this case the CLE | > | > will reach 1% | > | > | > | > | > due to the | > | > | > | > | > | following reason. | > | > | > | > | > | In this example it is assumed that the maximum | > | > | > | > bandwidth capacity | > | > | > | > | > | supported by path2 is 15*C. | > | > | > | > | > | This means that after rerouting the traffic from | > | > | path2 into | > | > | > | > | > path1, the | > | > | > | > | > | ratio between marked packets and unmarked | > packets that | > | > | > | > | are passing | > | > | > | > | > | thorugh path1 can be equal or higher than 16. | > | > | > | > | > | Note that the routers in path1 will mark the | > | excess rate | > | > | > | > | > above C, thus | > | > | > | > | > | 16 * C (i.e., the rerouted traffic from path2) | > | > as marked. | > | > | > | > | > | The above observation holds also for the | > | situation that | > | > | > | > | the routers | > | > | > | > | > | are preferentially dropping unmarked packets. | > | > | > | > | > | = | > | > | > | > | > | Thus when routers are preferentially = | dropping marked | > | > | > | > packets the | > | > | > | > | > | robustness of the PCN domain operation is | > | > | decreasing and in | > | > | > | > | > some cases | > | > | > | > | > | it severely decreases, which could cause | > the complete | > | > | > | > | > collapse of the | > | > | > | > | > | PCN domain operation. | > | > | > | > | > | = | > | > | > | > | > | Best regards, | > | > | > | > | > | Georgios | > | > | > | > | > | = | > | > | > | > | > | = | > | > | > | > | > | = | > | > | > | > | > | = | > | > | > | > | > | = | > | > | > | > | > | > -----Original Message----- | > | > | > | > | > | > From: Geib, Ruediger | > | > | [mailto:Ruediger.Geib@t-systems.com] | > | > | > | > | > | > Sent: maandag 17 maart 2008 9:42 | > | > | > | > | > | > To: karagian@cs.utwente.nl | > | > | > | > | > | > Cc: pcn@ietf.org | > | > | > | > | > | > Subject: RE: [PCN] Concensus questions from | > | Thursday's | > | > | > | > | PCN meeting | > | > | > | > | > | > = | > | > | > | > | > | > Hi Georgios, | > | > | > | > | > | > = | > | > | > | > | > | > PCN is designed for deployment in traffic | > engineered | > | > | > | > networks. = | > | > | > | > | > | > Please decribe, how to engineer a high = | performance | > | > | > | > | > carrier backbone | > | > | > | > | > | > and then review the assumptions your discussion | > | > | > is based on. | > | > | > | > | > | > = | > | > | > | > | > | > Regards, | > | > | > | > | > | > = | > | > | > | > | > | > Rudiger | > | > | > | > | > | > = | > | > | > | > | > | > | -----Original Message----- | > | > | > | > | > | > | From: Georgios Karagiannis | > | > | > [mailto:karagian@cs.utwente.nl] | > | > | > | > | > | > | Sent: Monday, March 17, 2008 9:34 AM | > | > | > | > | > | > | To: Geib, R=FCdiger | > | > | > | > | > | > | Cc: pcn@ietf.org | > | > | > | > | > | > | Subject: RE: [PCN] Concensus questions from | > | > Thursday's | > | > | > | > | > PCN meeting | > | > | > | > | > | > | = | > | > | > | > | > | > | Hi Ruediger | > | > | > | > | > | > | = | > | > | > | > | > | > | What do you mean? | > | > | > | > | > | > | Do you mean that you do not want to discuss | > | > | corner cases | > | > | > | > | > | > (ECMP related | > | > | > | > | > | > | cases) that could collapse the PCN domain = | > | > | > | > | > | > | operation? | > | > | > | > | > | > | What I am saying is that if the routers do not | > | > | > | > | > | preferentially drop | > | > | > | > | > | > | marked packets then the PCN domain = | operation is | > | > | > | more robust | > | > | > | > | > | > and more | > | > | > | > | > | > | stable than in the situation that the = | router is | > | > | > | > | preferentially | > | > | > | > | > | > | dropping marked packets. | > | > | > | > | > | > | = | > | > | > | > | > | > | Are you saying that this statement is = | not right? | > | > | > | > | > | > | = | > | > | > | > | > | > | = | > | > | > | > | > | > | Best regards, | > | > | > | > | > | > | Georgios | > | > | > | > | > | > | = | > | > | > | > | > | > | > | > | > | > | > | = | > | > | > | > | > | = | > | > | > | > | > | = | > | > | > | > | > = | > | > | > | > | = | > | > | > | > | = | > | > | > | > | = | > | > | > | > = | > | > | > | = | > | > | > | = | > | > | > | = | > | > | > = | > | > | = | > | > | = | > | > | = | > | > = | > | = | > | = | > | = | > = | = | = | = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 18 03:45:40 2008 Return-Path: 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 36D7C28C340; Tue, 18 Mar 2008 03:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.284 X-Spam-Level: X-Spam-Status: No, score=-100.284 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 lvlpVHtIGVL5; Tue, 18 Mar 2008 03:45:34 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BEAB28C4F6; Tue, 18 Mar 2008 03:45:34 -0700 (PDT) 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 C6C293A6B60 for ; Tue, 18 Mar 2008 03:45:33 -0700 (PDT) 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 yWFms8ZHF-84 for ; Tue, 18 Mar 2008 03:45:25 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id BBC2F28C47C for ; Tue, 18 Mar 2008 03:45:24 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m2IAgv3R003420; Tue, 18 Mar 2008 11:43:01 +0100 (MET) From: "Georgios Karagiannis" To: "'Geib, Ruediger'" References: <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de> <000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6423C@S4DE8PSAANK.mitte.t-com.de> <001301c88816$114dab60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF644B1@S4DE8PSAANK.mitte.t-com.de> <000001c88835$998bcf60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6451A@S4DE8PSAANK.mitte.t-com.de> <000601c8883b$e3828950$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF64580@S4DE8PSAANK.mitte.t-com.de> <000901c88844$f35c1130$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF645A3@S4DE8PSAANK.mitte.t-com.de> <000a01c8884d$081c9790$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF64645@S4DE8PSAANK.mitte.t-com.de> <000701c888e1$37a68c20$810c5982@dynamic.e! ! wi.utwente.nl> <1B6 169C658325341A3B8066E23919E1CF647C5@S4DE8PSAANK.mitte.t-com.de> Date: Tue, 18 Mar 2008 11:42:53 +0100 Message-ID: <001001c888e4$d4e927b0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <1B6169C658325341A3B8066E23919E1CF647C5@S4DE8PSAANK.mitte.t-com.de> Thread-Index: AciIBF++zKz17E/GQcib+W/rjB17BgABJ68gAABXALAAAifOMAAH2KywAACjCyAAAJeqgAAA4wtQAAGeymAAAM8HgAAA8S7AAAEXZnAAHn88IAAGS18AAADxzSAAABaRIA== X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Tue, 18 Mar 2008 11:43:05 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ruediger What is not realistic? Is it not realistic to use ECMP routing? Is it not realistic that one path fails and its = traffic is rerouted to another path? Best regards, Georgios = > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] = > Sent: dinsdag 18 maart 2008 11:36 > To: karagian@cs.utwente.nl > Cc: pcn@ietf.org > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > = > Hi Georgios = > = > see in line. > = > Regards, Rudiger > = > | -----Original Message----- > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | Sent: Tuesday, March 18, 2008 11:17 AM > | To: Geib, R=FCdiger > | Cc: pcn@ietf.org > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > | = > | Hi Ruediger > | = > | The problem that I have explained it does not have to do with slow = > | reaction time but it has to do with complete collapse of the PCN = > | domain operation. > | This occurs when the admission control/flow termination triggers at = > | the egress are not activated when they should be activated. > | = > | = > | Here is a more concrete example: > | = > | When ECMP routing is used, it means that flows that are associated = > | with the same ingress-egress-aggregate can follow different paths. > | Assume that there are 5 such paths that are carrying flows = > associated = > | with the same ingress-egress-aggregate. > | = > | Consider now that one of the 5 paths fails and it is = > rerouted to one = > | of the other paths. > | Assume that path1 is becoming congested and the other 3 remaining = > | paths are not congested. > | I am also assuming in this case that the thresholds are well = > | configured. > = > This is not realistic. > = > = > | The egress will calculate CLE in the following way: > | CLE =3D marked_1 /(unmarked_1 + unmarked_2 + unmarked_3 + unmarked_4 + > | marked_1) > | = > | I think that typcially the above calculated CLE will not = > reach 1% when = > | marked packets are preferentially dropped. > | This problem is due to the fact that ECMP routing is used and flows = > | that are not participating at the congestion are = > contributing to the = > | calculation of the CLE. The flows that are not passing through = > | congested nodes will actually forward unmarked packets to = > the egress = > | node. > | = > | When marked packets are preferentially dropped than marked_1 can = > | easily be smaller than 1% * (unmarked_1 + unmarked_2 + > | unmarked_3 + unmarled_4 + marked_1). = > | In this case the admission control situation is not triggered and a = > | complete collapse of the PCN domain operation can occur! > | = > | Thus: > | If no ECMP routing would have been used than for the same situation = > | CLE =3D marked_1/unmarked_1 + marked_1), which can go easily = > to 1%, if = > | the C-A-R is well configured. > | = > | But when ECMP routing is used and the above scenario is = > applied then = > | CLE =3D marked_1 /(unmarked_1 + unmarked_2 + > | unmarked_3 + unmarled_4 + marked_1), which probaly will not = > reach 1% = > | when marked packets are preferentially dropped, since = > marked_1 can be = > | smaller than 1% * (unmarked_1 + > | unmarked_2 + unmarked_3 + unmarled_4 + > | marked_1) > | = > | I hope that you now understand the problem! > | = > | Best regards, > | Georgios > | = > | > -----Original Message----- > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > | > Sent: dinsdag 18 maart 2008 8:30 > | > To: karagian@cs.utwente.nl > | > Cc: pcn@ietf.org > | > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > | > = > | > Hi Georgios, > | > = > | > in the situation you describe, packet losses occur. This > | will result > | > in bad press, as the customers using PCN based services > | were promised > | > another type of service. > | > = > | > In this situation it doesn't matter whether or not ECMP = > is deployed = > | > and it also doesn't matter whether termination is fair or = > not. The = > | > important event is: packet losses occur (in one of your examples = > | > several routers drop packets). The drops are the only > | relevant issue. > | > Whether service resumes after 5 seconds due to extremly well = > | > engineered termination or after 10 seconds after a > | sufficient number > | > of customers hang up is not important. > | > I can't recall having read anytime in the news "Major > | network outage - > | > but termination was fair." I can only recall having seen = > the first = > | > part. > | > = > | > I'm sure you're happy in adapting your example, as you do all the = > | > time. I'm having work to do, but maybe someone else is > | interested in > | > continuing discusion. I think, I've made my point. > | > = > | > Regards, > | > = > | > Rudiger > | > = > | > | -----Original Message----- > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | > | Sent: Monday, March 17, 2008 5:36 PM > | > | To: Geib, R=FCdiger > | > | Cc: pcn@ietf.org > | > | Subject: RE: [PCN] Concensus questions from Thursday's = > PCN meeting > | > | = > | > | Hi Ruediger > | > | = > | > | Please note that what I have described holds also for the > | situation > | > | that the routers are well configured, but a catastrophic > | > event occur > | > | and at the same time ECMP routing is used. > | > | = > | > | Best regards, > | > | Georgios > | > | = > | > | = > | > | > -----Original Message----- > | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > | > | > Sent: maandag 17 maart 2008 17:10 > | > | > To: karagian@cs.utwente.nl > | > | > Cc: pcn@ietf.org > | > | > Subject: RE: [PCN] Concensus questions from Thursday's > | PCN meeting > | > | > = > | > | > Hi Georgios, > | > | > = > | > | > what I say is if PCN decides to deal with catastrophic > | events in > | > | > combination with misconfigured routers, then it will end up = > | > | > standardising solutions for academic problems. > | > | > = > | > | > Regards, > | > | > = > | > | > Rudiger > | > | > = > | > | > = > | > | > | -----Original Message----- > | > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | > | > | Sent: Monday, March 17, 2008 4:38 PM > | > | > | To: Geib, R=FCdiger > | > | > | Cc: pcn@ietf.org > | > | > | Subject: RE: [PCN] Concensus questions from Thursday's > | > PCN meeting > | > | > | = > | > | > | Hi Ruediger > | > | > | = > | > | > | I do not understand what you try to say. Please note > | that flow > | > | > | termination is used for the below explained reason, see > | > | below text > | > | > | taken from the PCN architecture draft: > | > | > | = > | > | > | o The termination mechanism complements admission > | control. It > | > | > | allows the network to recover from sudden > | > | unexpected surges of > | > | > | PCN-traffic on some links, thus restoring QoS to > | > | the remaining > | > | > | flows. Such scenarios are expected to be = > rare but not = > | > | > | impossible. > | > | > | They can be caused by large network failures that > | > | > redirect lots > | > | > | of > | > | > | admitted PCN-traffic to other links, or by > | > | malfunction of the > | > | > | measurement-based admission control in the presence > | > | > of admitted > | > | > | flows that send for a while with an atypically low > | > | > rate and then > | > | > | increase their rates in a correlated way. > | > | > | = > | > | > | Best regards, > | > | > | Georgios > | > | > | = > | > | > | = > | > | > | = > | > | > | > -----Original Message----- > | > | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > | > | > | > Sent: maandag 17 maart 2008 16:32 > | > | > | > To: karagian@cs.utwente.nl > | > | > | > Cc: pcn@ietf.org > | > | > | > Subject: RE: [PCN] Concensus questions from Thursday's > | > | PCN meeting > | > | > | > = > | > | > | > Hi Georgios, > | > | > | > = > | > | > | > QoS on redundant links means, that one link is able to > | > | > | carry the QoS > | > | > | > traffic of the other. This may not hold for non QoS > | > | > | traffic. This is, > | > | > | > what typical carrier backbones providing QoS are > | > engineered for > | > | > | > (commonly known as traffic engineering). > | > | > | > = > | > | > | > Should a misconfiguration occur, things may go wrong. = > | > | > | > Operational staff corrects this a soon as the > | > | misconfiguration is > | > | > | > identified. > | > | > | > = > | > | > | > The engineering of carrier backbones is often done with > | > | automated > | > | > | > tools, leaving little room for human errors. > | > | > | > However maintenance work may result in humanne system > | > | > | interference. I > | > | > | > doubt that Telekom's engineering department is willing to > | > | > | accept extra > | > | > | > protocol and router complexitiy to deal with operator > | > | > configuration > | > | > | > errors. While I time and again hear of the worst > | > | > | misconfigs, I can't > | > | > | > recall that my colleagues try to adapt standardisation > | > | afterwards. > | > | > | > = > | > | > | > Regards, > | > | > | > = > | > | > | > Rudiger > | > | > | > = > | > | > | > | -----Original Message----- > | > | > | > | From: Georgios Karagiannis = > [mailto:karagian@cs.utwente.nl] > | > | > | > | Sent: Monday, March 17, 2008 3:34 PM > | > | > | > | To: Geib, R=FCdiger > | > | > | > | Cc: pcn@ietf.org > | > | > | > | Subject: RE: [PCN] Concensus questions from Thursday's > | > | > PCN meeting > | > | > | > | = > | > | > | > | Hi Ruediger > | > | > | > | = > | > | > | > | Please note that typical IP networks (thus not > | > | MPLS/GMPLS based > | > | > | > | domains) can recover from failures by using rerouting. > | > | > | > | Or do you know another standardized mechanism in > | typical IP > | > | > | > networks > | > | > | > | (thus not MPLS/GMPLS based) that can provide = > another kind > | > | > | > of recovery > | > | > | > | from failures. > | > | > | > | = > | > | > | > | Furthermore, I will just explain the example again > | > | with maximum > | > | > | > | capacity of > | > | > | > | pathh2 being equal > | > | > | > | to maximum capacity of path1 =3D C. > | > | > | > | Please explain what you do not understand in = > this example! > | > | > | > | = > | > | > | > | Here are the assumptions: > | > | > | > | * In the PCN domain we assume that ECMP routing > | is possible! > | > | > | > | * ingress-eggress-aggregate can contain flows that are > | > | > | > passing through > | > | > | > | one path or more paths (when ECMP routing is used). > | > | > | > | = > | > | > | > | * routers are currently dropping packets randomly. Thus > | > | > | marked and > | > | > | > | unmarked packets will be > | > | > | > | dropped randomly > | > | > | > | = > | > | > | > | * When excess rate measurements are used, the > | triggering of > | > | > | > admission > | > | > | > | control and flow > | > | > | > | termination are done at the egress by using = > the CLE. One > | > | > | > example of > | > | > | > | this trigger is: > | > | > | > | CLE > 1%. Note that CLE =3D marked/(unmarked + marked). = > | > | > | This means > | > | > | > | that if this trigger is not activated while a severe > | > | > | > | congestion occurs in the PCN domain, then the = > operation > | > | > | > of the PCN > | > | > | > | domain will completely collapse. > | > | > | > | = > | > | > | > | = > | > | > | > | My statement is: > | > | > | > | If the routers do not preferentially drop marked packets > | > | > | > then the PCN > | > | > | > | domain operation, even in corner case and = > misconfiguration > | > | > | > situations, > | > | > | > | is more robust and more stable than in the = > situation that > | > | > | > the router > | > | > | > | is preferentially dropping marked packets. > | > | > | > | = > | > | > | > | The below example show such a corner case! > | > | > | > | = > | > | > | > | = > | > | > | > | I will describe two situations: > | > | > | > | = > | > | > | > | Situation 1: > | > | > | > | Consider that an ingress-egress-aggregate due to ECMP > | > | > routing it > | > | > | > | includes flows that are passing from at least two paths. > | > | > | > | Assume that path1 supports a maximum bandwidth > | > capacity of C. = > | > | > | > | Now consider that the maximum bandwdith capacity of > | > | path2 is C. > | > | > | > | Consider also that both paths are fully utilized. > | > | > | > | = > | > | > | > | Consider that preferentially marked packets are > | dropped and > | > | > | > that path2 > | > | > | > | fails. > | > | > | > | Now assume that all (maximum) traffic passing through > | > | > | path2 will be > | > | > | > | rerouted through path1. > | > | > | > | If a bottleneck router located in path1, say Rbott, is > | > | > | > misconfigured > | > | > | > | (i.e., from the point of view of having wrongly = > too high = > | > | > | > | configured-admissible-rate value), or even if it is well > | > | > | > configured, > | > | > | > | then it can be possible that CLE measured at the egress > | > | > | > cannot reach > | > | > | > | 1%. > | > | > | > | Note that > | > | > | > | CLE =3D marked packets/ (marked packets + = > unmarked packets). > | > | > | > | This is because Rbott will just allow an excess rate to > | > | > | > pass through > | > | > | > | that is > | > | > | > | = > | > | > | > | equal to: C - configured-admissible-rate. The rest of > | > | > the marked > | > | > | > | packets, so the rest of the excess rate, will be dropped > | > | > | by Rbott, > | > | > | > | since this router is preferentially dropping > | marked packets. > | > | > | > | Furthermore, note that due to the ECMP routing > | > flows that are > | > | > | > | belonging to the same ingress-egress-aggregate and that > | > | > | are passing > | > | > | > | through another path, > | > | > | > | = > | > | > | > | than path1, which is not congested, will forward traffic > | > | > | > towards the > | > | > | > | egress node that will be unmarked. > | > | > | > | This will mean that the CLE > 1% will not be triggered, > | > | > | > this will mean > | > | > | > | that the flow termination will not be triggered and that > | > | > | > the operation > | > | > | > | of the PCN domain will collapse completely. > | > | > | > | = > | > | > | > | = > | > | > | > | Situation 2: > | > | > | > | Now consider that the router just operates as > | > | > currently, i.e., no > | > | > | > | preferential drop, randomly dropping marked and > | > | > unmarked packets. > | > | > | > | Consider also that the two paths described in = > Situation 1 > | > | > | above are > | > | > | > | used, ECMP routing is used, and that they are fully > | > utilized. > | > | > | > | Assume also that path2 fails and that the path2 = > traffic is > | > | > | > rerouted on > | > | > | > | path1. > | > | > | > | Now the CLE value will have a higher probability of > | > | > reaching the > | > | > | > | triggering value of 1%. > | > | > | > | = > | > | > | > | This is because the routers in path1 will drop randomly > | > | > | marked and > | > | > | > | unmarked packets. > | > | > | > | It is more certain that in this case the CLE = > will reach 1% > | > | > | > due to the > | > | > | > | following reason. > | > | > | > | In this example it is assumed that the maximum > | > | > bandwidth capacity > | > | > | > | supported by path2 is C. > | > | > | > | This means that after rerouting the traffic from > | path2 into > | > | > | > path1, the > | > | > | > | ratio between marked packets and unmarked packets that > | > | > | are passing > | > | > | > | thorugh path1 can be equal or higher than 100%. > | > | > | > | Note that the routers in path1 will mark the excess rate > | > | > | > above C, thus > | > | > | > | 1*C (i.e., the rerouted traffic from path2) as marked. > | > | > | > | The above observation holds also for the situation that > | > | > | the routers > | > | > | > | are preferentially dropping unmarked packets. > | > | > | > | = > | > | > | > | Thus when routers are preferentially dropping marked > | > | > packets the > | > | > | > | robustness of the PCN domain operation is > | decreasing and in > | > | > | > some cases > | > | > | > | it severely decreases, which could cause the complete > | > | > | > collapse of the > | > | > | > | PCN domain operation. > | > | > | > | = > | > | > | > | Best regards, > | > | > | > | Georgios > | > | > | > | = > | > | > | > | = > | > | > | > | = > | > | > | > | = > | > | > | > | > -----Original Message----- > | > | > | > | > From: Geib, Ruediger > | [mailto:Ruediger.Geib@t-systems.com] > | > | > | > | > Sent: maandag 17 maart 2008 15:26 > | > | > | > | > To: karagian@cs.utwente.nl > | > | > | > | > Cc: pcn@ietf.org > | > | > | > | > Subject: RE: [PCN] Concensus questions from Thursday's > | > | > | PCN meeting > | > | > | > | > = > | > | > | > | > Hi Georgios, > | > | > | > | > = > | > | > | > | > Unfortunately you missed my point. > | > | > | > | > = > | > | > | > | > No such thing as you describe has been, is or > | will for the > | > | > | > | foreseeable > | > | > | > | > future be engineered in the IP backbone of the company > | > | > | > I'm working > | > | > | > | > for. > | > | > | > | > = > | > | > | > | > My expectation on the backbone of any carrier offering > | > | > | > | transport QoS > | > | > | > | > is, that it is engineered to survive probable failures > | > | > | > (like single > | > | > | > | > link losses) without impact on the performance of QoS > | > | > | > | traffic. This is > | > | > | > | > where we should start from, if we discuss PCN. = > | From there > | > | > | > | on, PCN is > | > | > | > | > able to add value. > | > | > | > | > = > | > | > | > | > Links without traffic engineering followed by > | > | > | > misconfigured routers > | > | > | > | > aren't the arguments which will convince = > either product > | > | > | > | management or > | > | > | > | > backbone engineering of the company I work for to > | > | deploy PCN. > | > | > | > | > = > | > | > | > | > As a general comment: I don't regard PCN as a plug and > | > | > | > play toy for > | > | > | > | > the operational equivalent of a 'script > | kiddie'. If others > | > | > | > | share that > | > | > | > | > view and our documents don't state that, we > | > should add text. > | > | > | > | > = > | > | > | > | > Regards, > | > | > | > | > = > | > | > | > | > Rudiger > | > | > | > | > = > | > | > | > | > | -----Original Message----- > | > | > | > | > | From: Georgios Karagiannis > | > [mailto:karagian@cs.utwente.nl] > | > | > | > | > | Sent: Monday, March 17, 2008 2:49 PM > | > | > | > | > | To: Geib, R=FCdiger > | > | > | > | > | Cc: pcn@ietf.org > | > | > | > | > | Subject: RE: [PCN] Concensus questions from = > Thursday's > | > | > | > PCN meeting > | > | > | > | > | = > | > | > | > | > | Hi Ruediger > | > | > | > | > | = > | > | > | > | > | You missed my point! > | > | > | > | > | The explanation applies to all types of IP networks. > | > | > | > | > | Please note that the problem occurs also when > | path2 and > | > | > | > path1 use > | > | > | > | > | exactly the same maximum capacity, say C! > | > | > | > | > | = > | > | > | > | > | In this case, if pathh2 fails then path1 will see > | > | an excess > | > | > | > | > rate equal > | > | > | > | > | to at least C. > | > | > | > | > | The rest of the explanation is identical to > | the one used > | > | > | > | during my > | > | > | > | > | previous example! > | > | > | > | > | = > | > | > | > | > | = > | > | > | > | > | = > | > | > | > | > | Best regards, > | > | > | > | > | Georgios > | > | > | > | > | = > | > | > | > | > | = > | > | > | > | > | = > | > | > | > | > | = > | > | > | > | > | = > | > | > | > | > | > -----Original Message----- > | > | > | > | > | > From: Geib, Ruediger > | > | [mailto:Ruediger.Geib@t-systems.com] > | > | > | > | > | > Sent: maandag 17 maart 2008 14:34 > | > | > | > | > | > To: karagian@cs.utwente.nl > | > | > | > | > | > Cc: pcn@ietf.org > | > | > | > | > | > Subject: RE: [PCN] Concensus questions from > | Thursday's > | > | > | > | PCN meeting > | > | > | > | > | > = > | > | > | > | > | > Hi Georgios, > | > | > | > | > | > = > | > | > | > | > | > What you describe isn't backbone traffic > | engineering. = > | > | > | > What you > | > | > | > | > | > describe may happen in corporate VPNs, where a > | > | DSL access > | > | > | > | > | is used to > | > | > | > | > | > back up a WAN Fast Ethernet access or the > | > like. I don't > | > | > | > | > | object to have > | > | > | > | > | > standards on PCN for VPNs, but I'm not > | > | interested in this > | > | > | > | > issue for > | > | > | > | > | > now. > | > | > | > | > | > = > | > | > | > | > | > If you know any carrier who's operating his > | > | network with a > | > | > | > | > | > 16:1 load balancing for QoS traffic on any > | > | particular link > | > | > | > | > | set, please > | > | > | > | > | > publish the name, we are all interested in > | hearing it. > | > | > | > | > | > = > | > | > | > | > | > Regards, > | > | > | > | > | > = > | > | > | > | > | > Rudiger > | > | > | > | > | > = > | > | > | > | > | > = > | > | > | > | > | > = > | > | > | > | > | > | -----Original Message----- > | > | > | > | > | > | From: Georgios Karagiannis > | > | > [mailto:karagian@cs.utwente.nl] > | > | > | > | > | > | Sent: Monday, March 17, 2008 11:03 AM > | > | > | > | > | > | To: Geib, R=FCdiger > | > | > | > | > | > | Cc: pcn@ietf.org > | > | > | > | > | > | Subject: RE: [PCN] Concensus questions from > | > Thursday's > | > | > | > | > PCN meeting > | > | > | > | > | > | = > | > | > | > | > | > | Hi Ruediger > | > | > | > | > | > | = > | > | > | > | > | > | I will try to explain this more clearly. > | > | > | > | > | > | Here are the assumptions: > | > | > | > | > | > | * In the PCN domain we assume that ECMP routing > | > | > | is possible! > | > | > | > | > | > | * ingress-eggress-aggregate can contain > | > flows that are > | > | > | > | > | > passing through > | > | > | > | > | > | one path or more paths (when ECMP routing > | is used). > | > | > | > | > | > | = > | > | > | > | > | > | * routers are currently dropping packets > | > | randomly. Thus > | > | > | > | > | marked and > | > | > | > | > | > | unmarked packets will be > | > | > | > | > | > | dropped randomly > | > | > | > | > | > | = > | > | > | > | > | > | * When excess rate measurements are used, the > | > | > | triggering of > | > | > | > | > | > admission > | > | > | > | > | > | control and flow > | > | > | > | > | > | termination are done at the egress by using > | > | > the CLE. One > | > | > | > | > | > example of > | > | > | > | > | > | this trigger is: > | > | > | > | > | > | CLE > 1%. Note that CLE =3D marked/(unmarked > | > | + marked). = > | > | > | > | > | This means > | > | > | > | > | > | that if this trigger is not activated > | while a severe > | > | > | > | > | > | congestion occurs in the PCN domain, then the > | > | > operation > | > | > | > | > | > of the PCN > | > | > | > | > | > | domain will completely collapse. > | > | > | > | > | > | = > | > | > | > | > | > | = > | > | > | > | > | > | My statement is: > | > | > | > | > | > | If the routers do not preferentially drop > | > | marked packets > | > | > | > | > | > then the PCN > | > | > | > | > | > | domain operation, even in corner case and > | > | > misconfiguration > | > | > | > | > | > situations, > | > | > | > | > | > | is more robust and more stable than in the > | > | > situation that > | > | > | > | > | > the router > | > | > | > | > | > | is preferentially dropping marked packets. > | > | > | > | > | > | = > | > | > | > | > | > | The below example show such a corner case! > | > | > | > | > | > | = > | > | > | > | > | > | = > | > | > | > | > | > | I will describe two situations: > | > | > | > | > | > | = > | > | > | > | > | > | Situation 1: > | > | > | > | > | > | Consider that an ingress-egress-aggregate > | > due to ECMP > | > | > | > | > routing it > | > | > | > | > | > | includes flows that are passing from at least > | > | two paths. > | > | > | > | > | > | Assume that path1 supports a maximum bandwidth > | > | > | > capacity of C. = > | > | > | > | > | > | Now consider > | > | > | > | > | > | that the maximum bandwdith capacity of > | > path2 is 15*C. > | > | > | > | > | > | Consider also that both paths are fully = > utilized. > | > | > | > | > | > | = > | > | > | > | > | > | Consider that preferentially marked packets are > | > | > | dropped and > | > | > | > | > | > that path2 > | > | > | > | > | > | fails. > | > | > | > | > | > | Now assume that all (maximum) traffic > | > passing through > | > | > | > | > | path2 will be > | > | > | > | > | > | rerouted through path1. > | > | > | > | > | > | If a bottleneck router located in path1, > | > say Rbott, is > | > | > | > | > | > misconfigured > | > | > | > | > | > | (i.e., from the point of view of having wrongly > | > | > too high > | > | > | > | > | > | configured-admissible-rate value), or even if > | > | it is well > | > | > | > | > | > configured, > | > | > | > | > | > | then it can be possible that CLE measured at > | > | the egress > | > | > | > | > | > cannot reach > | > | > | > | > | > | 1%. > | > | > | > | > | > | Note that > | > | > | > | > | > | CLE =3D marked packets/ (marked packets + > | > | > unmarked packets). > | > | > | > | > | > | This is because Rbott will just allow an > | > | excess rate to > | > | > | > | > | > pass through > | > | > | > | > | > | that is > | > | > | > | > | > | = > | > | > | > | > | > | equal to: C - configured-admissible-rate. = > | > The rest of > | > | > | > | > the marked > | > | > | > | > | > | packets, so the rest of the excess rate, will > | > | be dropped > | > | > | > | > | by Rbott, > | > | > | > | > | > | since this router is preferentially dropping > | > | > | marked packets. > | > | > | > | > | > | Furthermore, note that due to the ECMP routing > | > | > | > flows that are > | > | > | > | > | > | belonging to the same > | > | ingress-egress-aggregate and that > | > | > | > | > | are passing > | > | > | > | > | > | through another path, > | > | > | > | > | > | = > | > | > | > | > | > | than path1, which is not congested, will > | > | forward traffic > | > | > | > | > | > towards the > | > | > | > | > | > | egress node that will be unmarked. > | > | > | > | > | > | This will mean that the CLE > 1% will not be > | > | triggered, > | > | > | > | > | > this will mean > | > | > | > | > | > | that the flow termination will not be > | > | triggered and that > | > | > | > | > | > the operation > | > | > | > | > | > | of the PCN domain will collapse completely. > | > | > | > | > | > | = > | > | > | > | > | > | = > | > | > | > | > | > | Situation 2: > | > | > | > | > | > | Now consider that the router just operates as > | > | > | > | > currently, i.e., no > | > | > | > | > | > | preferential drop, randomly dropping marked and > | > | > | > | > unmarked packets. > | > | > | > | > | > | Consider also that the two paths described in > | > | > Situation 1 > | > | > | > | > | above are > | > | > | > | > | > | used, ECMP routing is used, and that they > | are fully > | > | > | > utilized. > | > | > | > | > | > | Assume also that path2 fails and that the path2 > | > | > traffic is > | > | > | > | > | > rerouted on > | > | > | > | > | > | path1. > | > | > | > | > | > | Now the CLE value will have a higher > | probability of > | > | > | > | > reaching the > | > | > | > | > | > | triggering value of 1%. > | > | > | > | > | > | = > | > | > | > | > | > | This is because the routers in path1 will > | > | drop randomly > | > | > | > | > | marked and > | > | > | > | > | > | unmarked packets. > | > | > | > | > | > | It is more certain that in this case the CLE > | > | > will reach 1% > | > | > | > | > | > due to the > | > | > | > | > | > | following reason. > | > | > | > | > | > | In this example it is assumed that the maximum > | > | > | > | > bandwidth capacity > | > | > | > | > | > | supported by path2 is 15*C. > | > | > | > | > | > | This means that after rerouting the traffic from > | > | > | path2 into > | > | > | > | > | > path1, the > | > | > | > | > | > | ratio between marked packets and unmarked > | > packets that > | > | > | > | > | are passing > | > | > | > | > | > | thorugh path1 can be equal or higher than 16. > | > | > | > | > | > | Note that the routers in path1 will mark the > | > | excess rate > | > | > | > | > | > above C, thus > | > | > | > | > | > | 16 * C (i.e., the rerouted traffic from path2) > | > | > as marked. > | > | > | > | > | > | The above observation holds also for the > | > | situation that > | > | > | > | > | the routers > | > | > | > | > | > | are preferentially dropping unmarked packets. > | > | > | > | > | > | = > | > | > | > | > | > | Thus when routers are preferentially > | dropping marked > | > | > | > | > packets the > | > | > | > | > | > | robustness of the PCN domain operation is > | > | > | decreasing and in > | > | > | > | > | > some cases > | > | > | > | > | > | it severely decreases, which could cause > | > the complete > | > | > | > | > | > collapse of the > | > | > | > | > | > | PCN domain operation. > | > | > | > | > | > | = > | > | > | > | > | > | Best regards, > | > | > | > | > | > | Georgios > | > | > | > | > | > | = > | > | > | > | > | > | = > | > | > | > | > | > | = > | > | > | > | > | > | = > | > | > | > | > | > | = > | > | > | > | > | > | > -----Original Message----- > | > | > | > | > | > | > From: Geib, Ruediger > | > | > | [mailto:Ruediger.Geib@t-systems.com] > | > | > | > | > | > | > Sent: maandag 17 maart 2008 9:42 > | > | > | > | > | > | > To: karagian@cs.utwente.nl > | > | > | > | > | > | > Cc: pcn@ietf.org > | > | > | > | > | > | > Subject: RE: [PCN] Concensus questions from > | > | Thursday's > | > | > | > | > | PCN meeting > | > | > | > | > | > | > = > | > | > | > | > | > | > Hi Georgios, > | > | > | > | > | > | > = > | > | > | > | > | > | > PCN is designed for deployment in traffic > | > engineered > | > | > | > | > networks. = > | > | > | > | > | > | > Please decribe, how to engineer a high > | performance > | > | > | > | > | > carrier backbone > | > | > | > | > | > | > and then review the assumptions your = > discussion > | > | > | > is based on. > | > | > | > | > | > | > = > | > | > | > | > | > | > Regards, > | > | > | > | > | > | > = > | > | > | > | > | > | > Rudiger > | > | > | > | > | > | > = > | > | > | > | > | > | > | -----Original Message----- > | > | > | > | > | > | > | From: Georgios Karagiannis > | > | > | > [mailto:karagian@cs.utwente.nl] > | > | > | > | > | > | > | Sent: Monday, March 17, 2008 9:34 AM > | > | > | > | > | > | > | To: Geib, R=FCdiger > | > | > | > | > | > | > | Cc: pcn@ietf.org > | > | > | > | > | > | > | Subject: RE: [PCN] Concensus questions from > | > | > Thursday's > | > | > | > | > | > PCN meeting > | > | > | > | > | > | > | = > | > | > | > | > | > | > | Hi Ruediger > | > | > | > | > | > | > | = > | > | > | > | > | > | > | What do you mean? > | > | > | > | > | > | > | Do you mean that you do not want to discuss > | > | > | corner cases > | > | > | > | > | > | > (ECMP related > | > | > | > | > | > | > | cases) that could collapse the PCN domain = > | > | > | > | > | > | > | operation? > | > | > | > | > | > | > | What I am saying is that if the = > routers do not > | > | > | > | > | > | preferentially drop > | > | > | > | > | > | > | marked packets then the PCN domain > | operation is > | > | > | > | more robust > | > | > | > | > | > | > and more > | > | > | > | > | > | > | stable than in the situation that the > | router is > | > | > | > | > | preferentially > | > | > | > | > | > | > | dropping marked packets. > | > | > | > | > | > | > | = > | > | > | > | > | > | > | Are you saying that this statement is > | not right? > | > | > | > | > | > | > | = > | > | > | > | > | > | > | = > | > | > | > | > | > | > | Best regards, > | > | > | > | > | > | > | Georgios > | > | > | > | > | > | > | = > | > | > | > | > | > | > > | > | > | > | > | > | = > | > | > | > | > | > | = > | > | > | > | > | > | = > | > | > | > | > | > = > | > | > | > | > | = > | > | > | > | > | = > | > | > | > | > | = > | > | > | > | > = > | > | > | > | = > | > | > | > | = > | > | > | > | = > | > | > | > = > | > | > | = > | > | > | = > | > | > | = > | > | > = > | > | = > | > | = > | > | = > | > = > | = > | = > | = > = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 18 03:58:59 2008 Return-Path: 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 D3CDE28C456; Tue, 18 Mar 2008 03:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.679 X-Spam-Level: X-Spam-Status: No, score=-100.679 tagged_above=-999 required=5 tests=[AWL=-0.242, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 nZxUcmNhKVvK; Tue, 18 Mar 2008 03:58:57 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42B2228C519; Tue, 18 Mar 2008 03:58:57 -0700 (PDT) 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 41E0228C456 for ; Tue, 18 Mar 2008 03:58:56 -0700 (PDT) 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 aOeis3eUSnYN for ; Tue, 18 Mar 2008 03:58:53 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id CE1CD28C408 for ; Tue, 18 Mar 2008 03:58:52 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Tue, 18 Mar 2008 11:56:34 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Mar 2008 11:56:34 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Mar 2008 11:57:54 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CF647F3@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <001001c888e4$d4e927b0$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciIBF++zKz17E/GQcib+W/rjB17BgABJ68gAABXALAAAifOMAAH2KywAACjCyAAAJeqgAAA4wtQAAGeymAAAM8HgAAA8S7AAAEXZnAAHn88IAAGS18AAADxzSAAABaRIAAAqNiw References: <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de> <000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6423C@S4DE8PSAANK.mitte.t-com.de> <001301c88816$114dab60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF644B1@S4DE8PSAANK.mitte.t-com.de> <000001c88835$998bcf60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6451A@S4DE8PSAANK.mitte.t-com.de> <000601c8883b$e3828950$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF64580@S4DE8PSAANK.mitte.t-com.de> <000901c88844$f35c1130$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF645A3@S4DE8PSAANK.mitte.t-com.de> <000a01c8884d$081c9790$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF64645@S4DE8PSAANK.mitte.t-com.de> <000701c888e1$37a68c20$810c5982@dynamic.e! ! wi.ut wente.nl> <1 B6169C658325341A3B8066E23919E1CF647C5@S4DE8PSAANK.mitte.t-com.de> <001001c888e4$d4e927b0$810c5982@dynamic.ewi.utwente.nl> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 18 Mar 2008 10:56:34.0392 (UTC) FILETIME=[BB28AD80:01C888E6] Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Georgios, on the configuration and operation of ECMP you may want to read = the documentation provided by backbone router vendors or = other publications. Regards, Rudiger = | -----Original Message----- | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] = | Sent: Tuesday, March 18, 2008 11:43 AM | To: Geib, R=FCdiger | Cc: pcn@ietf.org | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | = | Hi Ruediger | = | What is not realistic? | Is it not realistic to use ECMP routing? | Is it not realistic that one path fails and its traffic is = | rerouted to another path? | = | Best regards, | Georgios | = | = | = | = | = | > -----Original Message----- | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > Sent: dinsdag 18 maart 2008 11:36 | > To: karagian@cs.utwente.nl | > Cc: pcn@ietf.org | > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | > = | > Hi Georgios | > = | > see in line. | > = | > Regards, Rudiger | > = | > | -----Original Message----- | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > | Sent: Tuesday, March 18, 2008 11:17 AM | > | To: Geib, R=FCdiger | > | Cc: pcn@ietf.org | > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | > | = | > | Hi Ruediger | > | = | > | The problem that I have explained it does not have to do = | with slow = | > | reaction time but it has to do with complete collapse of the PCN = | > | domain operation. | > | This occurs when the admission control/flow termination = | triggers at = | > | the egress are not activated when they should be activated. | > | = | > | = | > | Here is a more concrete example: | > | = | > | When ECMP routing is used, it means that flows that are = | associated = | > | with the same ingress-egress-aggregate can follow different paths. | > | Assume that there are 5 such paths that are carrying flows | > associated | > | with the same ingress-egress-aggregate. | > | = | > | Consider now that one of the 5 paths fails and it is | > rerouted to one | > | of the other paths. | > | Assume that path1 is becoming congested and the other 3 remaining = | > | paths are not congested. | > | I am also assuming in this case that the thresholds are well = | > | configured. | > = | > This is not realistic. | > = | > = | > | The egress will calculate CLE in the following way: | > | CLE =3D marked_1 /(unmarked_1 + unmarked_2 + unmarked_3 + = | unmarked_4 + | > | marked_1) | > | = | > | I think that typcially the above calculated CLE will not | > reach 1% when | > | marked packets are preferentially dropped. | > | This problem is due to the fact that ECMP routing is used = | and flows = | > | that are not participating at the congestion are | > contributing to the | > | calculation of the CLE. The flows that are not passing through = | > | congested nodes will actually forward unmarked packets to | > the egress | > | node. | > | = | > | When marked packets are preferentially dropped than marked_1 can = | > | easily be smaller than 1% * (unmarked_1 + unmarked_2 + | > | unmarked_3 + unmarled_4 + marked_1). = | > | In this case the admission control situation is not = | triggered and a = | > | complete collapse of the PCN domain operation can occur! | > | = | > | Thus: | > | If no ECMP routing would have been used than for the same = | situation = | > | CLE =3D marked_1/unmarked_1 + marked_1), which can go easily | > to 1%, if | > | the C-A-R is well configured. | > | = | > | But when ECMP routing is used and the above scenario is | > applied then | > | CLE =3D marked_1 /(unmarked_1 + unmarked_2 + | > | unmarked_3 + unmarled_4 + marked_1), which probaly will not | > reach 1% | > | when marked packets are preferentially dropped, since | > marked_1 can be | > | smaller than 1% * (unmarked_1 + | > | unmarked_2 + unmarked_3 + unmarled_4 + | > | marked_1) | > | = | > | I hope that you now understand the problem! | > | = | > | Best regards, | > | Georgios | > | = | > | > -----Original Message----- | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > | > Sent: dinsdag 18 maart 2008 8:30 | > | > To: karagian@cs.utwente.nl | > | > Cc: pcn@ietf.org | > | > Subject: RE: [PCN] Concensus questions from Thursday's = | PCN meeting | > | > = | > | > Hi Georgios, | > | > = | > | > in the situation you describe, packet losses occur. This | > | will result | > | > in bad press, as the customers using PCN based services | > | were promised | > | > another type of service. | > | > = | > | > In this situation it doesn't matter whether or not ECMP | > is deployed | > | > and it also doesn't matter whether termination is fair or | > not. The | > | > important event is: packet losses occur (in one of your = | examples = | > | > several routers drop packets). The drops are the only | > | relevant issue. | > | > Whether service resumes after 5 seconds due to extremly well = | > | > engineered termination or after 10 seconds after a | > | sufficient number | > | > of customers hang up is not important. | > | > I can't recall having read anytime in the news "Major | > | network outage - | > | > but termination was fair." I can only recall having seen | > the first | > | > part. | > | > = | > | > I'm sure you're happy in adapting your example, as you = | do all the = | > | > time. I'm having work to do, but maybe someone else is | > | interested in | > | > continuing discusion. I think, I've made my point. | > | > = | > | > Regards, | > | > = | > | > Rudiger | > | > = | > | > | -----Original Message----- | > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > | > | Sent: Monday, March 17, 2008 5:36 PM | > | > | To: Geib, R=FCdiger | > | > | Cc: pcn@ietf.org | > | > | Subject: RE: [PCN] Concensus questions from Thursday's | > PCN meeting | > | > | = | > | > | Hi Ruediger | > | > | = | > | > | Please note that what I have described holds also for the | > | situation | > | > | that the routers are well configured, but a catastrophic | > | > event occur | > | > | and at the same time ECMP routing is used. | > | > | = | > | > | Best regards, | > | > | Georgios | > | > | = | > | > | = | > | > | > -----Original Message----- | > | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > | > | > Sent: maandag 17 maart 2008 17:10 | > | > | > To: karagian@cs.utwente.nl | > | > | > Cc: pcn@ietf.org | > | > | > Subject: RE: [PCN] Concensus questions from Thursday's | > | PCN meeting | > | > | > = | > | > | > Hi Georgios, | > | > | > = | > | > | > what I say is if PCN decides to deal with catastrophic | > | events in | > | > | > combination with misconfigured routers, then it will end up = | > | > | > standardising solutions for academic problems. | > | > | > = | > | > | > Regards, | > | > | > = | > | > | > Rudiger | > | > | > = | > | > | > = | > | > | > | -----Original Message----- | > | > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > | > | > | Sent: Monday, March 17, 2008 4:38 PM | > | > | > | To: Geib, R=FCdiger | > | > | > | Cc: pcn@ietf.org | > | > | > | Subject: RE: [PCN] Concensus questions from Thursday's | > | > PCN meeting | > | > | > | = | > | > | > | Hi Ruediger | > | > | > | = | > | > | > | I do not understand what you try to say. Please note | > | that flow | > | > | > | termination is used for the below explained reason, see | > | > | below text | > | > | > | taken from the PCN architecture draft: | > | > | > | = | > | > | > | o The termination mechanism complements admission | > | control. It | > | > | > | allows the network to recover from sudden | > | > | unexpected surges of | > | > | > | PCN-traffic on some links, thus restoring QoS to | > | > | the remaining | > | > | > | flows. Such scenarios are expected to be | > rare but not | > | > | > | impossible. | > | > | > | They can be caused by large network failures that | > | > | > redirect lots | > | > | > | of | > | > | > | admitted PCN-traffic to other links, or by | > | > | malfunction of the | > | > | > | measurement-based admission control in the presence | > | > | > of admitted | > | > | > | flows that send for a while with an atypically low | > | > | > rate and then | > | > | > | increase their rates in a correlated way. | > | > | > | = | > | > | > | Best regards, | > | > | > | Georgios | > | > | > | = | > | > | > | = | > | > | > | = | > | > | > | > -----Original Message----- | > | > | > | > From: Geib, Ruediger = | [mailto:Ruediger.Geib@t-systems.com] | > | > | > | > Sent: maandag 17 maart 2008 16:32 | > | > | > | > To: karagian@cs.utwente.nl | > | > | > | > Cc: pcn@ietf.org | > | > | > | > Subject: RE: [PCN] Concensus questions from Thursday's | > | > | PCN meeting | > | > | > | > = | > | > | > | > Hi Georgios, | > | > | > | > = | > | > | > | > QoS on redundant links means, that one link is able to | > | > | > | carry the QoS | > | > | > | > traffic of the other. This may not hold for non QoS | > | > | > | traffic. This is, | > | > | > | > what typical carrier backbones providing QoS are | > | > engineered for | > | > | > | > (commonly known as traffic engineering). | > | > | > | > = | > | > | > | > Should a misconfiguration occur, things may go wrong. = | > | > | > | > Operational staff corrects this a soon as the | > | > | misconfiguration is | > | > | > | > identified. | > | > | > | > = | > | > | > | > The engineering of carrier backbones is often done with | > | > | automated | > | > | > | > tools, leaving little room for human errors. | > | > | > | > However maintenance work may result in humanne system | > | > | > | interference. I | > | > | > | > doubt that Telekom's engineering department is = | willing to | > | > | > | accept extra | > | > | > | > protocol and router complexitiy to deal with operator | > | > | > configuration | > | > | > | > errors. While I time and again hear of the worst | > | > | > | misconfigs, I can't | > | > | > | > recall that my colleagues try to adapt standardisation | > | > | afterwards. | > | > | > | > = | > | > | > | > Regards, | > | > | > | > = | > | > | > | > Rudiger | > | > | > | > = | > | > | > | > | -----Original Message----- | > | > | > | > | From: Georgios Karagiannis | > [mailto:karagian@cs.utwente.nl] | > | > | > | > | Sent: Monday, March 17, 2008 3:34 PM | > | > | > | > | To: Geib, R=FCdiger | > | > | > | > | Cc: pcn@ietf.org | > | > | > | > | Subject: RE: [PCN] Concensus questions from Thursday's | > | > | > PCN meeting | > | > | > | > | = | > | > | > | > | Hi Ruediger | > | > | > | > | = | > | > | > | > | Please note that typical IP networks (thus not | > | > | MPLS/GMPLS based | > | > | > | > | domains) can recover from failures by using rerouting. | > | > | > | > | Or do you know another standardized mechanism in | > | typical IP | > | > | > | > networks | > | > | > | > | (thus not MPLS/GMPLS based) that can provide | > another kind | > | > | > | > of recovery | > | > | > | > | from failures. | > | > | > | > | = | > | > | > | > | Furthermore, I will just explain the example again | > | > | with maximum | > | > | > | > | capacity of | > | > | > | > | pathh2 being equal | > | > | > | > | to maximum capacity of path1 =3D C. | > | > | > | > | Please explain what you do not understand in | > this example! | > | > | > | > | = | > | > | > | > | Here are the assumptions: | > | > | > | > | * In the PCN domain we assume that ECMP routing | > | is possible! | > | > | > | > | * ingress-eggress-aggregate can contain flows that are | > | > | > | > passing through | > | > | > | > | one path or more paths (when ECMP routing is used). | > | > | > | > | = | > | > | > | > | * routers are currently dropping packets = | randomly. Thus | > | > | > | marked and | > | > | > | > | unmarked packets will be | > | > | > | > | dropped randomly | > | > | > | > | = | > | > | > | > | * When excess rate measurements are used, the | > | triggering of | > | > | > | > admission | > | > | > | > | control and flow | > | > | > | > | termination are done at the egress by using | > the CLE. One | > | > | > | > example of | > | > | > | > | this trigger is: | > | > | > | > | CLE > 1%. Note that CLE =3D marked/(unmarked = | + marked). = | > | > | > | This means | > | > | > | > | that if this trigger is not activated while a severe | > | > | > | > | congestion occurs in the PCN domain, then the | > operation | > | > | > | > of the PCN | > | > | > | > | domain will completely collapse. | > | > | > | > | = | > | > | > | > | = | > | > | > | > | My statement is: | > | > | > | > | If the routers do not preferentially drop = | marked packets | > | > | > | > then the PCN | > | > | > | > | domain operation, even in corner case and | > misconfiguration | > | > | > | > situations, | > | > | > | > | is more robust and more stable than in the | > situation that | > | > | > | > the router | > | > | > | > | is preferentially dropping marked packets. | > | > | > | > | = | > | > | > | > | The below example show such a corner case! | > | > | > | > | = | > | > | > | > | = | > | > | > | > | I will describe two situations: | > | > | > | > | = | > | > | > | > | Situation 1: | > | > | > | > | Consider that an ingress-egress-aggregate due to ECMP | > | > | > routing it | > | > | > | > | includes flows that are passing from at least = | two paths. | > | > | > | > | Assume that path1 supports a maximum bandwidth | > | > capacity of C. = | > | > | > | > | Now consider that the maximum bandwdith capacity of | > | > | path2 is C. | > | > | > | > | Consider also that both paths are fully utilized. | > | > | > | > | = | > | > | > | > | Consider that preferentially marked packets are | > | dropped and | > | > | > | > that path2 | > | > | > | > | fails. | > | > | > | > | Now assume that all (maximum) traffic passing through | > | > | > | path2 will be | > | > | > | > | rerouted through path1. | > | > | > | > | If a bottleneck router located in path1, say Rbott, is | > | > | > | > misconfigured | > | > | > | > | (i.e., from the point of view of having wrongly | > too high | > | > | > | > | configured-admissible-rate value), or even if = | it is well | > | > | > | > configured, | > | > | > | > | then it can be possible that CLE measured at = | the egress | > | > | > | > cannot reach | > | > | > | > | 1%. | > | > | > | > | Note that | > | > | > | > | CLE =3D marked packets/ (marked packets + | > unmarked packets). | > | > | > | > | This is because Rbott will just allow an = | excess rate to | > | > | > | > pass through | > | > | > | > | that is | > | > | > | > | = | > | > | > | > | equal to: C - configured-admissible-rate. The rest of | > | > | > the marked | > | > | > | > | packets, so the rest of the excess rate, will = | be dropped | > | > | > | by Rbott, | > | > | > | > | since this router is preferentially dropping | > | marked packets. | > | > | > | > | Furthermore, note that due to the ECMP routing | > | > flows that are | > | > | > | > | belonging to the same = | ingress-egress-aggregate and that | > | > | > | are passing | > | > | > | > | through another path, | > | > | > | > | = | > | > | > | > | than path1, which is not congested, will = | forward traffic | > | > | > | > towards the | > | > | > | > | egress node that will be unmarked. | > | > | > | > | This will mean that the CLE > 1% will not be = | triggered, | > | > | > | > this will mean | > | > | > | > | that the flow termination will not be = | triggered and that | > | > | > | > the operation | > | > | > | > | of the PCN domain will collapse completely. | > | > | > | > | = | > | > | > | > | = | > | > | > | > | Situation 2: | > | > | > | > | Now consider that the router just operates as | > | > | > currently, i.e., no | > | > | > | > | preferential drop, randomly dropping marked and | > | > | > unmarked packets. | > | > | > | > | Consider also that the two paths described in | > Situation 1 | > | > | > | above are | > | > | > | > | used, ECMP routing is used, and that they are fully | > | > utilized. | > | > | > | > | Assume also that path2 fails and that the path2 | > traffic is | > | > | > | > rerouted on | > | > | > | > | path1. | > | > | > | > | Now the CLE value will have a higher probability of | > | > | > reaching the | > | > | > | > | triggering value of 1%. | > | > | > | > | = | > | > | > | > | This is because the routers in path1 will = | drop randomly | > | > | > | marked and | > | > | > | > | unmarked packets. | > | > | > | > | It is more certain that in this case the CLE | > will reach 1% | > | > | > | > due to the | > | > | > | > | following reason. | > | > | > | > | In this example it is assumed that the maximum | > | > | > bandwidth capacity | > | > | > | > | supported by path2 is C. | > | > | > | > | This means that after rerouting the traffic from | > | path2 into | > | > | > | > path1, the | > | > | > | > | ratio between marked packets and unmarked packets that | > | > | > | are passing | > | > | > | > | thorugh path1 can be equal or higher than 100%. | > | > | > | > | Note that the routers in path1 will mark the = | excess rate | > | > | > | > above C, thus | > | > | > | > | 1*C (i.e., the rerouted traffic from path2) as marked. | > | > | > | > | The above observation holds also for the = | situation that | > | > | > | the routers | > | > | > | > | are preferentially dropping unmarked packets. | > | > | > | > | = | > | > | > | > | Thus when routers are preferentially dropping marked | > | > | > packets the | > | > | > | > | robustness of the PCN domain operation is | > | decreasing and in | > | > | > | > some cases | > | > | > | > | it severely decreases, which could cause the complete | > | > | > | > collapse of the | > | > | > | > | PCN domain operation. | > | > | > | > | = | > | > | > | > | Best regards, | > | > | > | > | Georgios | > | > | > | > | = | > | > | > | > | = | > | > | > | > | = | > | > | > | > | = | > | > | > | > | > -----Original Message----- | > | > | > | > | > From: Geib, Ruediger | > | [mailto:Ruediger.Geib@t-systems.com] | > | > | > | > | > Sent: maandag 17 maart 2008 15:26 | > | > | > | > | > To: karagian@cs.utwente.nl | > | > | > | > | > Cc: pcn@ietf.org | > | > | > | > | > Subject: RE: [PCN] Concensus questions from = | Thursday's | > | > | > | PCN meeting | > | > | > | > | > = | > | > | > | > | > Hi Georgios, | > | > | > | > | > = | > | > | > | > | > Unfortunately you missed my point. | > | > | > | > | > = | > | > | > | > | > No such thing as you describe has been, is or | > | will for the | > | > | > | > | foreseeable | > | > | > | > | > future be engineered in the IP backbone of = | the company | > | > | > | > I'm working | > | > | > | > | > for. | > | > | > | > | > = | > | > | > | > | > My expectation on the backbone of any = | carrier offering | > | > | > | > | transport QoS | > | > | > | > | > is, that it is engineered to survive = | probable failures | > | > | > | > (like single | > | > | > | > | > link losses) without impact on the = | performance of QoS | > | > | > | > | traffic. This is | > | > | > | > | > where we should start from, if we discuss PCN. = | > | From there | > | > | > | > | on, PCN is | > | > | > | > | > able to add value. | > | > | > | > | > = | > | > | > | > | > Links without traffic engineering followed by | > | > | > | > misconfigured routers | > | > | > | > | > aren't the arguments which will convince | > either product | > | > | > | > | management or | > | > | > | > | > backbone engineering of the company I work for to | > | > | deploy PCN. | > | > | > | > | > = | > | > | > | > | > As a general comment: I don't regard PCN as = | a plug and | > | > | > | > play toy for | > | > | > | > | > the operational equivalent of a 'script | > | kiddie'. If others | > | > | > | > | share that | > | > | > | > | > view and our documents don't state that, we | > | > should add text. | > | > | > | > | > = | > | > | > | > | > Regards, | > | > | > | > | > = | > | > | > | > | > Rudiger | > | > | > | > | > = | > | > | > | > | > | -----Original Message----- | > | > | > | > | > | From: Georgios Karagiannis | > | > [mailto:karagian@cs.utwente.nl] | > | > | > | > | > | Sent: Monday, March 17, 2008 2:49 PM | > | > | > | > | > | To: Geib, R=FCdiger | > | > | > | > | > | Cc: pcn@ietf.org | > | > | > | > | > | Subject: RE: [PCN] Concensus questions from | > Thursday's | > | > | > | > PCN meeting | > | > | > | > | > | = | > | > | > | > | > | Hi Ruediger | > | > | > | > | > | = | > | > | > | > | > | You missed my point! | > | > | > | > | > | The explanation applies to all types of = | IP networks. | > | > | > | > | > | Please note that the problem occurs also when | > | path2 and | > | > | > | > path1 use | > | > | > | > | > | exactly the same maximum capacity, say C! | > | > | > | > | > | = | > | > | > | > | > | In this case, if pathh2 fails then path1 will see | > | > | an excess | > | > | > | > | > rate equal | > | > | > | > | > | to at least C. | > | > | > | > | > | The rest of the explanation is identical to | > | the one used | > | > | > | > | during my | > | > | > | > | > | previous example! | > | > | > | > | > | = | > | > | > | > | > | = | > | > | > | > | > | = | > | > | > | > | > | Best regards, | > | > | > | > | > | Georgios | > | > | > | > | > | = | > | > | > | > | > | = | > | > | > | > | > | = | > | > | > | > | > | = | > | > | > | > | > | = | > | > | > | > | > | > -----Original Message----- | > | > | > | > | > | > From: Geib, Ruediger | > | > | [mailto:Ruediger.Geib@t-systems.com] | > | > | > | > | > | > Sent: maandag 17 maart 2008 14:34 | > | > | > | > | > | > To: karagian@cs.utwente.nl | > | > | > | > | > | > Cc: pcn@ietf.org | > | > | > | > | > | > Subject: RE: [PCN] Concensus questions from | > | Thursday's | > | > | > | > | PCN meeting | > | > | > | > | > | > = | > | > | > | > | > | > Hi Georgios, | > | > | > | > | > | > = | > | > | > | > | > | > What you describe isn't backbone traffic | > | engineering. = | > | > | > | > What you | > | > | > | > | > | > describe may happen in corporate VPNs, where a | > | > | DSL access | > | > | > | > | > | is used to | > | > | > | > | > | > back up a WAN Fast Ethernet access or the | > | > like. I don't | > | > | > | > | > | object to have | > | > | > | > | > | > standards on PCN for VPNs, but I'm not | > | > | interested in this | > | > | > | > | > issue for | > | > | > | > | > | > now. | > | > | > | > | > | > = | > | > | > | > | > | > If you know any carrier who's operating his | > | > | network with a | > | > | > | > | > | > 16:1 load balancing for QoS traffic on any | > | > | particular link | > | > | > | > | > | set, please | > | > | > | > | > | > publish the name, we are all interested in | > | hearing it. | > | > | > | > | > | > = | > | > | > | > | > | > Regards, | > | > | > | > | > | > = | > | > | > | > | > | > Rudiger | > | > | > | > | > | > = | > | > | > | > | > | > = | > | > | > | > | > | > = | > | > | > | > | > | > | -----Original Message----- | > | > | > | > | > | > | From: Georgios Karagiannis | > | > | > [mailto:karagian@cs.utwente.nl] | > | > | > | > | > | > | Sent: Monday, March 17, 2008 11:03 AM | > | > | > | > | > | > | To: Geib, R=FCdiger | > | > | > | > | > | > | Cc: pcn@ietf.org | > | > | > | > | > | > | Subject: RE: [PCN] Concensus questions from | > | > Thursday's | > | > | > | > | > PCN meeting | > | > | > | > | > | > | = | > | > | > | > | > | > | Hi Ruediger | > | > | > | > | > | > | = | > | > | > | > | > | > | I will try to explain this more clearly. | > | > | > | > | > | > | Here are the assumptions: | > | > | > | > | > | > | * In the PCN domain we assume that = | ECMP routing | > | > | > | is possible! | > | > | > | > | > | > | * ingress-eggress-aggregate can contain | > | > flows that are | > | > | > | > | > | > passing through | > | > | > | > | > | > | one path or more paths (when ECMP routing | > | is used). | > | > | > | > | > | > | = | > | > | > | > | > | > | * routers are currently dropping packets | > | > | randomly. Thus | > | > | > | > | > | marked and | > | > | > | > | > | > | unmarked packets will be | > | > | > | > | > | > | dropped randomly | > | > | > | > | > | > | = | > | > | > | > | > | > | * When excess rate measurements are used, the | > | > | > | triggering of | > | > | > | > | > | > admission | > | > | > | > | > | > | control and flow | > | > | > | > | > | > | termination are done at the egress by using | > | > | > the CLE. One | > | > | > | > | > | > example of | > | > | > | > | > | > | this trigger is: | > | > | > | > | > | > | CLE > 1%. Note that CLE =3D marked/(unmarked | > | > | + marked). = | > | > | > | > | > | This means | > | > | > | > | > | > | that if this trigger is not activated | > | while a severe | > | > | > | > | > | > | congestion occurs in the PCN = | domain, then the | > | > | > operation | > | > | > | > | > | > of the PCN | > | > | > | > | > | > | domain will completely collapse. | > | > | > | > | > | > | = | > | > | > | > | > | > | = | > | > | > | > | > | > | My statement is: | > | > | > | > | > | > | If the routers do not preferentially drop | > | > | marked packets | > | > | > | > | > | > then the PCN | > | > | > | > | > | > | domain operation, even in corner case and | > | > | > misconfiguration | > | > | > | > | > | > situations, | > | > | > | > | > | > | is more robust and more stable than in the | > | > | > situation that | > | > | > | > | > | > the router | > | > | > | > | > | > | is preferentially dropping marked packets. | > | > | > | > | > | > | = | > | > | > | > | > | > | The below example show such a corner case! | > | > | > | > | > | > | = | > | > | > | > | > | > | = | > | > | > | > | > | > | I will describe two situations: | > | > | > | > | > | > | = | > | > | > | > | > | > | Situation 1: | > | > | > | > | > | > | Consider that an ingress-egress-aggregate | > | > due to ECMP | > | > | > | > | > routing it | > | > | > | > | > | > | includes flows that are passing from at least | > | > | two paths. | > | > | > | > | > | > | Assume that path1 supports a maximum bandwidth | > | > | > | > capacity of C. = | > | > | > | > | > | > | Now consider | > | > | > | > | > | > | that the maximum bandwdith capacity of | > | > path2 is 15*C. | > | > | > | > | > | > | Consider also that both paths are fully | > utilized. | > | > | > | > | > | > | = | > | > | > | > | > | > | Consider that preferentially marked = | packets are | > | > | > | dropped and | > | > | > | > | > | > that path2 | > | > | > | > | > | > | fails. | > | > | > | > | > | > | Now assume that all (maximum) traffic | > | > passing through | > | > | > | > | > | path2 will be | > | > | > | > | > | > | rerouted through path1. | > | > | > | > | > | > | If a bottleneck router located in path1, | > | > say Rbott, is | > | > | > | > | > | > misconfigured | > | > | > | > | > | > | (i.e., from the point of view of = | having wrongly | > | > | > too high | > | > | > | > | > | > | configured-admissible-rate value), or even if | > | > | it is well | > | > | > | > | > | > configured, | > | > | > | > | > | > | then it can be possible that CLE measured at | > | > | the egress | > | > | > | > | > | > cannot reach | > | > | > | > | > | > | 1%. | > | > | > | > | > | > | Note that | > | > | > | > | > | > | CLE =3D marked packets/ (marked packets + | > | > | > unmarked packets). | > | > | > | > | > | > | This is because Rbott will just allow an | > | > | excess rate to | > | > | > | > | > | > pass through | > | > | > | > | > | > | that is | > | > | > | > | > | > | = | > | > | > | > | > | > | equal to: C - configured-admissible-rate. = | > | > The rest of | > | > | > | > | > the marked | > | > | > | > | > | > | packets, so the rest of the excess rate, will | > | > | be dropped | > | > | > | > | > | by Rbott, | > | > | > | > | > | > | since this router is preferentially dropping | > | > | > | marked packets. | > | > | > | > | > | > | Furthermore, note that due to the ECMP routing | > | > | > | > flows that are | > | > | > | > | > | > | belonging to the same | > | > | ingress-egress-aggregate and that | > | > | > | > | > | are passing | > | > | > | > | > | > | through another path, | > | > | > | > | > | > | = | > | > | > | > | > | > | than path1, which is not congested, will | > | > | forward traffic | > | > | > | > | > | > towards the | > | > | > | > | > | > | egress node that will be unmarked. | > | > | > | > | > | > | This will mean that the CLE > 1% will not be | > | > | triggered, | > | > | > | > | > | > this will mean | > | > | > | > | > | > | that the flow termination will not be | > | > | triggered and that | > | > | > | > | > | > the operation | > | > | > | > | > | > | of the PCN domain will collapse completely. | > | > | > | > | > | > | = | > | > | > | > | > | > | = | > | > | > | > | > | > | Situation 2: | > | > | > | > | > | > | Now consider that the router just operates as | > | > | > | > | > currently, i.e., no | > | > | > | > | > | > | preferential drop, randomly dropping = | marked and | > | > | > | > | > unmarked packets. | > | > | > | > | > | > | Consider also that the two paths described in | > | > | > Situation 1 | > | > | > | > | > | above are | > | > | > | > | > | > | used, ECMP routing is used, and that they | > | are fully | > | > | > | > utilized. | > | > | > | > | > | > | Assume also that path2 fails and that = | the path2 | > | > | > traffic is | > | > | > | > | > | > rerouted on | > | > | > | > | > | > | path1. | > | > | > | > | > | > | Now the CLE value will have a higher | > | probability of | > | > | > | > | > reaching the | > | > | > | > | > | > | triggering value of 1%. | > | > | > | > | > | > | = | > | > | > | > | > | > | This is because the routers in path1 will | > | > | drop randomly | > | > | > | > | > | marked and | > | > | > | > | > | > | unmarked packets. | > | > | > | > | > | > | It is more certain that in this case the CLE | > | > | > will reach 1% | > | > | > | > | > | > due to the | > | > | > | > | > | > | following reason. | > | > | > | > | > | > | In this example it is assumed that the maximum | > | > | > | > | > bandwidth capacity | > | > | > | > | > | > | supported by path2 is 15*C. | > | > | > | > | > | > | This means that after rerouting the = | traffic from | > | > | > | path2 into | > | > | > | > | > | > path1, the | > | > | > | > | > | > | ratio between marked packets and unmarked | > | > packets that | > | > | > | > | > | are passing | > | > | > | > | > | > | thorugh path1 can be equal or higher than 16. | > | > | > | > | > | > | Note that the routers in path1 will mark the | > | > | excess rate | > | > | > | > | > | > above C, thus | > | > | > | > | > | > | 16 * C (i.e., the rerouted traffic from path2) | > | > | > as marked. | > | > | > | > | > | > | The above observation holds also for the | > | > | situation that | > | > | > | > | > | the routers | > | > | > | > | > | > | are preferentially dropping unmarked packets. | > | > | > | > | > | > | = | > | > | > | > | > | > | Thus when routers are preferentially | > | dropping marked | > | > | > | > | > packets the | > | > | > | > | > | > | robustness of the PCN domain operation is | > | > | > | decreasing and in | > | > | > | > | > | > some cases | > | > | > | > | > | > | it severely decreases, which could cause | > | > the complete | > | > | > | > | > | > collapse of the | > | > | > | > | > | > | PCN domain operation. | > | > | > | > | > | > | = | > | > | > | > | > | > | Best regards, | > | > | > | > | > | > | Georgios | > | > | > | > | > | > | = | > | > | > | > | > | > | = | > | > | > | > | > | > | = | > | > | > | > | > | > | = | > | > | > | > | > | > | = | > | > | > | > | > | > | > -----Original Message----- | > | > | > | > | > | > | > From: Geib, Ruediger | > | > | > | [mailto:Ruediger.Geib@t-systems.com] | > | > | > | > | > | > | > Sent: maandag 17 maart 2008 9:42 | > | > | > | > | > | > | > To: karagian@cs.utwente.nl | > | > | > | > | > | > | > Cc: pcn@ietf.org | > | > | > | > | > | > | > Subject: RE: [PCN] Concensus questions from | > | > | Thursday's | > | > | > | > | > | PCN meeting | > | > | > | > | > | > | > = | > | > | > | > | > | > | > Hi Georgios, | > | > | > | > | > | > | > = | > | > | > | > | > | > | > PCN is designed for deployment in traffic | > | > engineered | > | > | > | > | > networks. = | > | > | > | > | > | > | > Please decribe, how to engineer a high | > | performance | > | > | > | > | > | > carrier backbone | > | > | > | > | > | > | > and then review the assumptions your | > discussion | > | > | > | > is based on. | > | > | > | > | > | > | > = | > | > | > | > | > | > | > Regards, | > | > | > | > | > | > | > = | > | > | > | > | > | > | > Rudiger | > | > | > | > | > | > | > = | > | > | > | > | > | > | > | -----Original Message----- | > | > | > | > | > | > | > | From: Georgios Karagiannis | > | > | > | > [mailto:karagian@cs.utwente.nl] | > | > | > | > | > | > | > | Sent: Monday, March 17, 2008 9:34 AM | > | > | > | > | > | > | > | To: Geib, R=FCdiger | > | > | > | > | > | > | > | Cc: pcn@ietf.org | > | > | > | > | > | > | > | Subject: RE: [PCN] Concensus = | questions from | > | > | > Thursday's | > | > | > | > | > | > PCN meeting | > | > | > | > | > | > | > | = | > | > | > | > | > | > | > | Hi Ruediger | > | > | > | > | > | > | > | = | > | > | > | > | > | > | > | What do you mean? | > | > | > | > | > | > | > | Do you mean that you do not want = | to discuss | > | > | > | corner cases | > | > | > | > | > | > | > (ECMP related | > | > | > | > | > | > | > | cases) that could collapse the PCN domain = | > | > | > | > | > | > | > | operation? | > | > | > | > | > | > | > | What I am saying is that if the | > routers do not | > | > | > | > | > | > | preferentially drop | > | > | > | > | > | > | > | marked packets then the PCN domain | > | operation is | > | > | > | > | more robust | > | > | > | > | > | > | > and more | > | > | > | > | > | > | > | stable than in the situation that the | > | router is | > | > | > | > | > | preferentially | > | > | > | > | > | > | > | dropping marked packets. | > | > | > | > | > | > | > | = | > | > | > | > | > | > | > | Are you saying that this statement is | > | not right? | > | > | > | > | > | > | > | = | > | > | > | > | > | > | > | = | > | > | > | > | > | > | > | Best regards, Georgios | > | > | > | > | > | > | > | = | > | > | > | > | > | > | > | > | > | > | > | > | > | = | > | > | > | > | > | > | = | > | > | > | > | > | > | = | > | > | > | > | > | > = | > | > | > | > | > | = | > | > | > | > | > | = | > | > | > | > | > | = | > | > | > | > | > = | > | > | > | > | = | > | > | > | > | = | > | > | > | > | = | > | > | > | > = | > | > | > | = | > | > | > | = | > | > | > | = | > | > | > = | > | > | = | > | > | = | > | > | = | > | > = | > | = | > | = | > | = | > = | = | = | = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 18 07:21:18 2008 Return-Path: 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 581E028C5E2; Tue, 18 Mar 2008 07:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.136 X-Spam-Level: X-Spam-Status: No, score=-100.136 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 K95TELKQ7iZi; Tue, 18 Mar 2008 07:21:07 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7668E3A6F19; Tue, 18 Mar 2008 07:21:07 -0700 (PDT) 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 CFF283A6F12 for ; Tue, 18 Mar 2008 07:21:06 -0700 (PDT) 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 pwvRG-Sr9P-c for ; Tue, 18 Mar 2008 07:20:59 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id EDDC128C5A8 for ; Tue, 18 Mar 2008 07:20:58 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m2IEIfXa026603; Tue, 18 Mar 2008 09:18:41 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Mar 2008 09:18:40 -0500 Received: from [147.117.169.77] ([147.117.169.77]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Mar 2008 09:18:40 -0500 From: Steven Blake To: "Geib, Ruediger" In-Reply-To: <1B6169C658325341A3B8066E23919E1CF64645@S4DE8PSAANK.mitte.t-com.de> References: <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de> <000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6423C@S4DE8PSAANK.mitte.t-com.de> <001301c88816$114dab60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF644B1@S4DE8PSAANK.mitte.t-com.de> <000001c88835$998bcf60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6451A@S4DE8PSAANK.mitte.t-com.de> <000601c8883b$e3828950$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF64580@S4DE8PSAANK.mitte.t-com.de> <000901c88844$f35c1130$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF645A3@S4DE8PSAANK.mitte.t-com.de> <000a01c8884d$081c9790$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF64645@S4DE8PSAANK.mitte.t-com.de> Organization: Ericsson IP Infrastructure Date: Tue, 18 Mar 2008 10:18:39 -0400 Message-Id: <1205849919.9521.7.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) X-OriginalArrivalTime: 18 Mar 2008 14:18:40.0687 (UTC) FILETIME=[F6FE73F0:01C88902] Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org On Tue, 2008-03-18 at 08:29 +0100, Geib, Ruediger wrote: > Hi Georgios, > > in the situation you describe, packet losses occur. This will result > in bad press, as the customers using PCN based services were promised > another type of service. > > In this situation it doesn't matter whether or not ECMP is deployed > and it also doesn't matter whether termination is fair or not. The > important event is: packet losses occur (in one of your examples > several routers drop packets). The drops are the only relevant issue. > Whether service resumes after 5 seconds due to extremly well > engineered termination or after 10 seconds after a sufficient number > of customers hang up is not important. > I can't recall having read anytime in the news > "Major network outage - but termination was fair." I can > only recall having seen the first part. > > I'm sure you're happy in adapting your example, as you do all the > time. I'm having work to do, but maybe someone else is interested > in continuing discusion. I think, I've made my point. Ruediger, If I follow this comment to its logical conclusion, then PCN is superfluous in this network. Is that what you are trying to say? Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 18 10:11:01 2008 Return-Path: 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 48C143A6F36; Tue, 18 Mar 2008 10:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.335 X-Spam-Level: X-Spam-Status: No, score=-100.335 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 5oZtCttAgEz7; Tue, 18 Mar 2008 10:10:53 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A25C93A6B5A; Tue, 18 Mar 2008 10:10:50 -0700 (PDT) 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 285CD3A6996 for ; Tue, 18 Mar 2008 10:10:49 -0700 (PDT) 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 5UmqCeaionuP for ; Tue, 18 Mar 2008 10:10:41 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 5B2653A6800 for ; Tue, 18 Mar 2008 10:10:41 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m2IH8NTC027886; Tue, 18 Mar 2008 12:08:23 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Mar 2008 12:08:23 -0500 Received: from [147.117.169.77] ([147.117.169.77]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Mar 2008 12:08:22 -0500 From: Steven Blake To: pcn Organization: Ericsson IP Infrastructure Date: Tue, 18 Mar 2008 13:08:22 -0400 Message-Id: <1205860102.9521.27.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) X-OriginalArrivalTime: 18 Mar 2008 17:08:22.0918 (UTC) FILETIME=[AC139A60:01C8891A] Subject: [PCN] Concensus questions: Q1, Q2, and Q3. X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Six consensus questions were taken during the IETF 71 meeting. I would now like to raise them on the list. I will do this in step-wise fashion. Q1: As an initial standardization activity, should the PCN wg produce a standards-track PCN scheme that requires only two encoding states? (Note: this question does not presume that the solution is Single Marking). Q2: Presuming consensus in favor of Q1, should the PCN wg produce one or more experimental-track extensions to the standards-track PCN scheme that require another encoding state (for a total of three encoding states)? Q3: Does the PCN working group have enough information to make a decision about the way forward for the standards-track PCN scheme? By my notes, Q1 was accepted in the meeting 8-0, Q2 was accepted 9-0, and Q3 was accepted 6-1 (but my notes are fuzzy on Q3's result). Please send comments to the list during the next few days. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 18 10:13:28 2008 Return-Path: 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 B25003A6C92; Tue, 18 Mar 2008 10:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.418 X-Spam-Level: X-Spam-Status: No, score=-101.418 tagged_above=-999 required=5 tests=[AWL=-1.581, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 hafPixa2dPzp; Tue, 18 Mar 2008 10:13:27 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93B7C3A6B19; Tue, 18 Mar 2008 10:13:27 -0700 (PDT) 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 344E73A6B19 for ; Tue, 18 Mar 2008 10:13:27 -0700 (PDT) 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 cydUCrWwAN6i for ; Tue, 18 Mar 2008 10:13:21 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 857B63A69AB for ; Tue, 18 Mar 2008 10:13:20 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Mar 2008 17:11:01 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Mar 2008 17:11:01 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1205860260915; Tue, 18 Mar 2008 17:11:00 +0000 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m2IHAum9016442; Tue, 18 Mar 2008 17:10:57 GMT Message-Id: <200803181710.m2IHAum9016442@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 18 Mar 2008 17:11:01 +0000 To: "EGGERT, Lars" From: Bob Briscoe Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 18 Mar 2008 17:11:01.0182 (UTC) FILETIME=[0A68C5E0:01C8891B] Cc: PCN IETF list Subject: [PCN] Should interior Diffserv nodes remark the DSCP? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Lars, I have never liked the idea of using multiple DSCPs for different congestion markings but the same scheduling PHB... But constraints I recently identified on use of the ECN field through tunnels (see posting a week ago) force us to switch DSCPs if we want more than one level of congestion marking - unless we get the tunnelling behaviour changed. You've also been advising against interior nodes switching DSCPs for congestion marking if at all possible, saying this may not be disallowed by the DS specs, but it is certainly not common practice. So, before embarking on an experiment where we use at least two DSCPs for PCN marking, I have been checking what the DS specs say. All the relevant quotes I've found so far are pasted at the end. Summary of my interpretation: Re-marking DSCPs for congestion marking on interior nodes is a way of using DSCPs to indicate a change in network state, which is explicitly envisaged by the Diffserv architecture [RFC2475]. Re-marking DSCPs at interior nodes to demote traffic to a 'lower' PHB is also envisaged [RFC2474]. So everyone has to assume that interior nodes might re-mark DSCPs. However, there are other cases, even in IETF RFCs, where it is assumed that interior nodes will not re-mark DSCPs. In summary, pre-congestion is a perfectly legitimate reason for interior nodes to re-mark DSCPs, but we should expect possible feature interactions with other stuff, even though that other stuff shouldn't assume DSCPs are immutable. Bob =============================================================================== RFC2474 (Stds track) DS Field -------------------- 3. Differentiated Services Field Definition ... Operators may choose to use different codepoints for a PHB, either in addition to or in place of the recommended default. Note that if operators do so choose, re- marking of DS fields may be necessary at administrative boundaries even if the same PHBs are implemented on both sides of the boundary. ... {This sentence implies multiple DSCPs may map to the same PHB.} 5. Per-Hop Behavior Standardization Guidelines ... A PHB group specification SHOULD describe conditions under which a packet might be re-marked to select another PHB within the group. It is RECOMMENDED that PHB implementations do not introduce any packet re-ordering within a microflow. PHB group specifications MUST identify any possible packet re-ordering implications which may occur for each individual PHB, and which may occur if different packets within a microflow are marked for different PHBs within the group. ... {A PHB group specification is the behaviour of an interior node, so this sentence shows that interior node remarking is expected. However, only remarking to another PHB is mentioned. Remarking to another DSCP within the same PHB is neither mentioned nor precluded.} RFC2475 (Informational) DS Architecture ------- 2. Differentiated Services Architectural Model ... Each behavior aggregate is identified by a single DS codepoint. ...{Contradicts S.3 of RFC2474 above} 2.1.1 DS Boundary Nodes and Interior Nodes Interior nodes may be able to perform limited traffic conditioning functions such as DS codepoint re-marking. {Clear-cut evidence that interior DSCP re-marking is expected.} 2.4 Per-Hop Behaviors ... A codepoint->PHB mapping table may contain both 1->1 and N->1 mappings. ... 3. Per-Hop Behavior Specification Guidelines ... G.6: It may be possible or appropriate for a packet marked for a PHB within a PHB group to be re-marked to select another PHB within the group; either within a domain or across a domain boundary. Typically there are three reasons for such PHB modification: a. The codepoints associated with the PHB group are collectively intended to carry state about the network, b. ... ... A PHB specification should clearly state the circumstances under which packets marked for a PHB within a PHB group may, or should be modified (e.g., promoted or demoted) to another PHB within the group. If it is undesirable for a packet's PHB to be modified, the specification should clearly state the consequent risks when the PHB is modified. A possible risk to changing a packet's PHB, either within or outside a PHB group, is a higher probability of packet re- ordering within a microflow. PHBs within a group may carry some host-to-host, WAN edge-to-WAN edge, and/or domain edge-to-domain edge semantics which may be difficult to duplicate if packets are re- marked to select another PHB from the group (or otherwise). For certain PHB groups, it may be appropriate to reflect a state change in the node by re-marking packets to specify another PHB from within the group. If a PHB group is designed to reflect the state of a network, the PHB definition must adequately describe the relationship between the PHBs and the states they reflect. Further, if these PHBs limit the forwarding actions a node can perform in some way, these constraints may be specified as actions the node should, or must perform. {The ability to reflect a state change in an interior node by re-marking is precisely what PCN is doing - to notify a change in state from not pre-congested to pre-congested, and back again.} RFC2597 (Standards Track) AF PHB Group ------- {No mention of interior node re-marking of DSCPs} RFC3086 (Informational) Specification of PDBs ------- 4.1.2 Crossing the DS domain: transit effects ... DSCPs should not change in the interior of a DS domain as there is no traffic conditioning being applied. If it is necessary to reapply the kind of traffic conditioning that could result in remarking, there should be a DS domain boundary at that point, though such an "interior" boundary can have "lighter weight" rules in its TCA. Thus, when measuring attributes between locations as indicated in figure 3, the DSCP at the egress side can be assumed to have held throughout the domain. ...{This implies there is an assumption that DSCPs don't change across a domain, contradicting RFC2474 & RFC2475 above.} Hope this helps Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 19 03:39:15 2008 Return-Path: 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 DDD4828C2E7; Wed, 19 Mar 2008 03:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.707 X-Spam-Level: X-Spam-Status: No, score=-100.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 StZFVQGcImU6; Wed, 19 Mar 2008 03:39:07 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF55B28C110; Wed, 19 Mar 2008 03:38:57 -0700 (PDT) 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 13F343A6D54 for ; Wed, 19 Mar 2008 03:38:56 -0700 (PDT) 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 hgUHkbY56Dk6 for ; Wed, 19 Mar 2008 03:38:49 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 1F1523A6C8A for ; Wed, 19 Mar 2008 03:38:21 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail21.telekom.de with ESMTP; Wed, 19 Mar 2008 11:36:00 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Mar 2008 11:36:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Mar 2008 11:37:24 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CF64B8A@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1205849919.9521.7.camel@neutrino> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciJAvohbA2GphQvQLWjFvOYYSGt+QAo6Jrg References: <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de> <000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6423C@S4DE8PSAANK.mitte.t-com.de> <001301c88816$114dab60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF644B1@S4DE8PSAANK.mitte.t-com.de> <000001c88835$998bcf60$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF6451A@S4DE8PSAANK.mitte.t-com.de> <000601c8883b$e3828950$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF64580@S4DE8PSAANK.mitte.t-com.de> <000901c88844$f35c1130$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF645A3@S4DE8PSAANK.mitte.t-com.de> <000a01c8884d$081c9790$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF64645@S4DE8PSAANK.mitte.t-com.de> <1205849919.9521.7.camel@neutrino> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 19 Mar 2008 10:36:00.0236 (UTC) FILETIME=[05F52AC0:01C889AD] Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Steven, what Georgios is proposing is to optimise PCN so that it works = properly if a catastrophic event coincides with a = misconfigured router. = If this is the main or even an important task of PCN, then I = waste my time here. The salary I obtain monthly depends on my companies backbone = network providing good service to customers under regular = operational conditions (which cover planned outages = and expectable failures). The telephony or streaming services = offered to our customers should experience a minimised network = impact on the Quality of Experience perceived by the consumers = under regular operational conditions. This includes the = creation of a "Network Busy Indication", which however is a = rare event. So my position on what PCN should be optimised = for is to create this "network busy indication" for regular = operational conditions, reliably and only if it is required. = This should be done with the least possible complexity (like = the least possible flow awareness, the least codepoint = consumption, simple queuing/policing and measurement = functions, utmost re-use of allready implemented features). = To clarify what I mean by a rare event: a well engineered = backbone creating a PCN network busy indication either during = a main traffic hour or after a re-routing event. During ISDN = times, engineering resulted in what Americans called 5ESS = switches, aiming on a network busy indication probability of = (100 - 99,999%, the 5 nines). We may see that a bit more = relaxed for IP networks, but I don't think the customers = of my company should experience the consequences of PCN = behaviour more often than in (100 - 99,x)%. I don't look at PCN as a replacement of network engineering, = it is rather an add on to guarantee service quality of = admitted users by stopping admission of new traffic once = engineering reaches its limits. Under regular operational = conditions. If someone now answers to this mail: uhh, just that - easy! Then lets move this easy thing to WGLC. Now. I can't see = that. If the PCN WG indeed has completely different aims, then = I'm sorry for bothering you with my mails (but I wonder = whether I'm the one having gotten things wrong). By the way, I'm happy with the progress visible in the = questions you / the WG has formulated. That looks like a = constructive approach. Regards, Rudiger | -----Original Message----- | From: Steven Blake [mailto:steven.blake@ericsson.com] = | Sent: Tuesday, March 18, 2008 3:19 PM | To: Geib, R=FCdiger | Cc: pcn@ietf.org | Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting | = | On Tue, 2008-03-18 at 08:29 +0100, Geib, Ruediger wrote: | = | > Hi Georgios, | > = | > in the situation you describe, packet losses occur. This = | will result = | > in bad press, as the customers using PCN based services = | were promised = | > another type of service. | > = | > In this situation it doesn't matter whether or not ECMP is deployed = | > and it also doesn't matter whether termination is fair or not. The = | > important event is: packet losses occur (in one of your examples = | > several routers drop packets). The drops are the only = | relevant issue. | > Whether service resumes after 5 seconds due to extremly well = | > engineered termination or after 10 seconds after a = | sufficient number = | > of customers hang up is not important. | > I can't recall having read anytime in the news "Major = | network outage - = | > but termination was fair." I can only recall having seen the first = | > part. | > = | > I'm sure you're happy in adapting your example, as you do all the = | > time. I'm having work to do, but maybe someone else is = | interested in = | > continuing discusion. I think, I've made my point. | = | Ruediger, | = | If I follow this comment to its logical conclusion, then PCN = | is superfluous in this network. Is that what you are trying to say? | = | = | Regards, | = | =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D | Steven Blake | Ericsson/Redback Networks +1 919-472-9913 | = | = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 19 04:40:37 2008 Return-Path: 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 18F0228C49D; Wed, 19 Mar 2008 04:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.29 X-Spam-Level: X-Spam-Status: No, score=-100.29 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 9nl2Hg6WfG3U; Wed, 19 Mar 2008 04:40:35 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA82228C45F; Wed, 19 Mar 2008 04:40:35 -0700 (PDT) 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 95DE428C3A7 for ; Wed, 19 Mar 2008 04:40:34 -0700 (PDT) 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 KTZQP1beQPDU for ; Wed, 19 Mar 2008 04:40:33 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id E4A9428C441 for ; Wed, 19 Mar 2008 04:40:30 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m2JBbudI016282; Wed, 19 Mar 2008 12:37:59 +0100 (MET) From: "Georgios Karagiannis" To: "'Geib, Ruediger'" , References: <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de><000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF6423C@S4DE8PSAANK.mitte.t-com.de><001301c88816$114dab60$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF644B1@S4DE8PSAANK.mitte.t-com.de><000001c88835$998bcf60$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF6451A@S4DE8PSAANK.mitte.t-com.de><000601c8883b$e3828950$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF64580@S4DE8PSAANK.mitte.t-com.de><000901c88844$f35c1130$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF645A3@S4DE8PSAANK.mitte.t-com.de><000a01c8884d$081c9790$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF64645@S4DE8PSAANK.mitte.t-com.de><1205849919.9521.7.camel@neutrino> <1B6169C658325341A3B8! 066E23919E1CF64B8A@S4 DE8PSAANK.mitte.t-com.de> Date: Wed, 19 Mar 2008 12:37:51 +0100 Message-ID: <002901c889b5$ad4671a0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <1B6169C658325341A3B8066E23919E1CF64B8A@S4DE8PSAANK.mitte.t-com.de> Thread-Index: AciJAvohbA2GphQvQLWjFvOYYSGt+QAo6JrgAAOauuA= X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 19 Mar 2008 12:38:00 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Rudeiger What I am proposing is how to achieve a robust/stable PCN operation = when the PCN domain uses ECMP routing and when a catastrophic event occurs. Best regards, Georgios = > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On = > Behalf Of Geib, Ruediger > Sent: woensdag 19 maart 2008 11:37 > To: steven.blake@ericsson.com > Cc: pcn@ietf.org > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > = > Steven, > = > what Georgios is proposing is to optimise PCN so that it = > works properly if a catastrophic event coincides with a = > misconfigured router. = > = > If this is the main or even an important task of PCN, then I = > waste my time here. > = > The salary I obtain monthly depends on my companies backbone = > network providing good service to customers under regular = > operational conditions (which cover planned outages and = > expectable failures). The telephony or streaming services = > offered to our customers should experience a minimised = > network impact on the Quality of Experience perceived by the = > consumers under regular operational conditions. This includes = > the creation of a "Network Busy Indication", which however is = > a rare event. So my position on what PCN should be optimised = > for is to create this "network busy indication" for regular = > operational conditions, reliably and only if it is required. = > This should be done with the least possible complexity (like = > the least possible flow awareness, the least codepoint = > consumption, simple queuing/policing and measurement = > functions, utmost re-use of allready implemented features). = > = > To clarify what I mean by a rare event: a well engineered = > backbone creating a PCN network busy indication either during = > a main traffic hour or after a re-routing event. During ISDN = > times, engineering resulted in what Americans called 5ESS = > switches, aiming on a network busy indication probability of = > (100 - 99,999%, the 5 nines). We may see that a bit more = > relaxed for IP networks, but I don't think the customers of = > my company should experience the consequences of PCN = > behaviour more often than in (100 - 99,x)%. > = > I don't look at PCN as a replacement of network engineering, = > it is rather an add on to guarantee service quality of = > admitted users by stopping admission of new traffic once = > engineering reaches its limits. Under regular operational conditions. > = > If someone now answers to this mail: uhh, just that - easy! > Then lets move this easy thing to WGLC. Now. I can't see that. > = > If the PCN WG indeed has completely different aims, then I'm = > sorry for bothering you with my mails (but I wonder whether = > I'm the one having gotten things wrong). > = > By the way, I'm happy with the progress visible in the = > questions you / the WG has formulated. That looks like a = > constructive approach. > = > Regards, > = > Rudiger > = > = > = > | -----Original Message----- > | From: Steven Blake [mailto:steven.blake@ericsson.com] > | Sent: Tuesday, March 18, 2008 3:19 PM > | To: Geib, R=FCdiger > | Cc: pcn@ietf.org > | Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > | = > | On Tue, 2008-03-18 at 08:29 +0100, Geib, Ruediger wrote: > | = > | > Hi Georgios, > | > = > | > in the situation you describe, packet losses occur. This > | will result > | > in bad press, as the customers using PCN based services > | were promised > | > another type of service. > | > = > | > In this situation it doesn't matter whether or not ECMP = > is deployed = > | > and it also doesn't matter whether termination is fair or = > not. The = > | > important event is: packet losses occur (in one of your examples = > | > several routers drop packets). The drops are the only > | relevant issue. > | > Whether service resumes after 5 seconds due to extremly well = > | > engineered termination or after 10 seconds after a > | sufficient number > | > of customers hang up is not important. > | > I can't recall having read anytime in the news "Major > | network outage - > | > but termination was fair." I can only recall having seen = > the first = > | > part. > | > = > | > I'm sure you're happy in adapting your example, as you do all the = > | > time. I'm having work to do, but maybe someone else is > | interested in > | > continuing discusion. I think, I've made my point. > | = > | Ruediger, > | = > | If I follow this comment to its logical conclusion, then PCN is = > | superfluous in this network. Is that what you are trying to say? > | = > | = > | Regards, > | = > | =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D > | Steven Blake > | Ericsson/Redback Networks +1 919-472-9913 > | = > | = > _______________________________________________ > 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 From pcn-bounces@ietf.org Wed Mar 19 05:07:03 2008 Return-Path: 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 D300728C47F; Wed, 19 Mar 2008 05:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.693 X-Spam-Level: X-Spam-Status: No, score=-100.693 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 zpOgbhaq7M+p; Wed, 19 Mar 2008 05:07:02 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E14728C450; Wed, 19 Mar 2008 05:07:02 -0700 (PDT) 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 1B2203A6B76 for ; Wed, 19 Mar 2008 05:07:01 -0700 (PDT) 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 hrtQPfFuHbyI for ; Wed, 19 Mar 2008 05:07:00 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 6EF243A690D for ; Wed, 19 Mar 2008 05:06:59 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail21.telekom.de with ESMTP; Wed, 19 Mar 2008 13:04:41 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Mar 2008 13:04:41 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Mar 2008 13:06:05 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CF64C3B@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <002901c889b5$ad4671a0$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciJAvohbA2GphQvQLWjFvOYYSGt+QAo6JrgAAOauuAAAN9DsA== References: <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de><000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF6423C@S4DE8PSAANK.mitte.t-com.de><001301c88816$114dab60$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF644B1@S4DE8PSAANK.mitte.t-com.de><000001c88835$998bcf60$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF6451A@S4DE8PSAANK.mitte.t-com.de><000601c8883b$e3828950$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF64580@S4DE8PSAANK.mitte.t-com.de><000901c88844$f35c1130$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF645A3@S4DE8PSAANK.mitte.t-com.de><000a01c8884d$081c9790$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF64645@S4DE8PSAANK.mitte.t-com.de><1205849919.9521.7.camel@neutrino> <1B6169C658325341A3B8! 066E239 19E1CF64B8A@ S4DE8PSAANK.mitte.t-com.de> <002901c889b5$ad4671a0$810c5982@dynamic.ewi.utwente.nl> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 19 Mar 2008 12:04:41.0017 (UTC) FILETIME=[6963EA90:01C889B9] Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Georgios, with how many operator representatives involved into backbone = traffic engineering including activation of ECMP did you = talk prior to proposing your solution on this mailing list? = Regards, Rudiger | -----Original Message----- | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] = | Sent: Wednesday, March 19, 2008 12:38 PM | To: Geib, R=FCdiger; steven.blake@ericsson.com | Cc: pcn@ietf.org | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | = | Hi Rudeiger | = | What I am proposing is how to achieve a robust/stable PCN = | operation when the PCN domain uses ECMP routing and when a = | catastrophic event occurs. | = | Best regards, | Georgios | = | = | = | = | = | > -----Original Message----- | > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On = | Behalf Of = | > Geib, Ruediger | > Sent: woensdag 19 maart 2008 11:37 | > To: steven.blake@ericsson.com | > Cc: pcn@ietf.org | > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting | > = | > Steven, | > = | > what Georgios is proposing is to optimise PCN so that it works = | > properly if a catastrophic event coincides with a misconfigured = | > router. | > = | > If this is the main or even an important task of PCN, then = | I waste my = | > time here. | > = | > The salary I obtain monthly depends on my companies = | backbone network = | > providing good service to customers under regular operational = | > conditions (which cover planned outages and expectable = | failures). The = | > telephony or streaming services offered to our customers should = | > experience a minimised network impact on the Quality of Experience = | > perceived by the consumers under regular operational = | conditions. This = | > includes the creation of a "Network Busy Indication", which = | however is = | > a rare event. So my position on what PCN should be = | optimised for is to = | > create this "network busy indication" for regular operational = | > conditions, reliably and only if it is required. | > This should be done with the least possible complexity = | (like the least = | > possible flow awareness, the least codepoint consumption, simple = | > queuing/policing and measurement functions, utmost re-use = | of allready = | > implemented features). | > = | > To clarify what I mean by a rare event: a well engineered backbone = | > creating a PCN network busy indication either during a main traffic = | > hour or after a re-routing event. During ISDN times, engineering = | > resulted in what Americans called 5ESS switches, aiming on = | a network = | > busy indication probability of (100 - 99,999%, the 5 nines). We may = | > see that a bit more relaxed for IP networks, but I don't think the = | > customers of my company should experience the consequences of PCN = | > behaviour more often than in (100 - 99,x)%. | > = | > I don't look at PCN as a replacement of network engineering, it is = | > rather an add on to guarantee service quality of admitted users by = | > stopping admission of new traffic once engineering reaches = | its limits. = | > Under regular operational conditions. | > = | > If someone now answers to this mail: uhh, just that - easy! | > Then lets move this easy thing to WGLC. Now. I can't see that. | > = | > If the PCN WG indeed has completely different aims, then = | I'm sorry for = | > bothering you with my mails (but I wonder whether I'm the = | one having = | > gotten things wrong). | > = | > By the way, I'm happy with the progress visible in the = | questions you / = | > the WG has formulated. That looks like a constructive approach. | > = | > Regards, | > = | > Rudiger | > = | > = | > = | > | -----Original Message----- | > | From: Steven Blake [mailto:steven.blake@ericsson.com] | > | Sent: Tuesday, March 18, 2008 3:19 PM | > | To: Geib, R=FCdiger | > | Cc: pcn@ietf.org | > | Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting | > | = | > | On Tue, 2008-03-18 at 08:29 +0100, Geib, Ruediger wrote: | > | = | > | > Hi Georgios, | > | > = | > | > in the situation you describe, packet losses occur. This | > | will result | > | > in bad press, as the customers using PCN based services | > | were promised | > | > another type of service. | > | > = | > | > In this situation it doesn't matter whether or not ECMP | > is deployed | > | > and it also doesn't matter whether termination is fair or | > not. The | > | > important event is: packet losses occur (in one of your = | examples = | > | > several routers drop packets). The drops are the only | > | relevant issue. | > | > Whether service resumes after 5 seconds due to extremly well = | > | > engineered termination or after 10 seconds after a | > | sufficient number | > | > of customers hang up is not important. | > | > I can't recall having read anytime in the news "Major | > | network outage - | > | > but termination was fair." I can only recall having seen | > the first | > | > part. | > | > = | > | > I'm sure you're happy in adapting your example, as you = | do all the = | > | > time. I'm having work to do, but maybe someone else is | > | interested in | > | > continuing discusion. I think, I've made my point. | > | = | > | Ruediger, | > | = | > | If I follow this comment to its logical conclusion, then PCN is = | > | superfluous in this network. Is that what you are trying to say? | > | = | > | = | > | Regards, | > | = | > | =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D | > | Steven Blake | > | Ericsson/Redback Networks +1 919-472-9913 | > | = | > | = | > _______________________________________________ | > 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 From pcn-bounces@ietf.org Wed Mar 19 05:30:59 2008 Return-Path: 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 89A9728C427; Wed, 19 Mar 2008 05:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.659 X-Spam-Level: X-Spam-Status: No, score=-100.659 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 biEKGzrwwMNm; Wed, 19 Mar 2008 05:30:53 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 225D73A6A35; Wed, 19 Mar 2008 05:30:53 -0700 (PDT) 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 958F93A6A35 for ; Wed, 19 Mar 2008 05:30:51 -0700 (PDT) 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 y9LKFdrWo56y for ; Wed, 19 Mar 2008 05:30:50 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 58D8D3A690E for ; Wed, 19 Mar 2008 05:30:50 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Wed, 19 Mar 2008 13:28:31 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Mar 2008 13:28:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Mar 2008 13:29:56 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CF64C6C@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1205860102.9521.27.camel@neutrino> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions: Q1, Q2, and Q3. Thread-Index: AciJGtzew89sUW52QQKTSvD7Op+kbQAnt2OA References: <1205860102.9521.27.camel@neutrino> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 19 Mar 2008 12:28:31.0501 (UTC) FILETIME=[BE0673D0:01C889BC] Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions: Q1, Q2, and Q3. X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Steven, | Q1: As an initial standardization activity, should the PCN wg | produce a standards-track PCN scheme that requires only two | encoding states? | (Note: this question does not presume that the solution is | Single Marking). Yes. | Q2: Presuming consensus in favor of Q1, should the PCN wg | produce one or more experimental-track extensions to the | standards-track PCN scheme that require another encoding | state (for a total of three encoding states)? Yes. Experimental Track seems to me to be most important here. | | Q3: Does the PCN working group have enough information to make a | decision about the way forward for the standards-track PCN scheme? Yes. No further comments on these questions from me. Regards, Rudiger _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 19 05:37:46 2008 Return-Path: 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 84D8528C3A7; Wed, 19 Mar 2008 05:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.309 X-Spam-Level: X-Spam-Status: No, score=-100.309 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 fDAWz4w1B45X; Wed, 19 Mar 2008 05:37:42 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9603F28C0E3; Wed, 19 Mar 2008 05:37:41 -0700 (PDT) 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 BF7CA3A6BD2 for ; Wed, 19 Mar 2008 05:37:40 -0700 (PDT) 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 pyI64qVONXdW for ; Wed, 19 Mar 2008 05:37:39 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 5ED8928C0E3 for ; Wed, 19 Mar 2008 05:37:39 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m2JCZIgB020265; Wed, 19 Mar 2008 13:35:21 +0100 (MET) From: "Georgios Karagiannis" To: "'Geib, Ruediger'" References: <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de><000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF6423C@S4DE8PSAANK.mitte.t-com.de><001301c88816$114dab60$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF644B1@S4DE8PSAANK.mitte.t-com.de><000001c88835$998bcf60$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF6451A@S4DE8PSAANK.mitte.t-com.de><000601c8883b$e3828950$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF64580@S4DE8PSAANK.mitte.t-com.de><000901c88844$f35c1130$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF645A3@S4DE8PSAANK.mitte.t-com.de><000a01c8884d$081c9790$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF64645@S4DE8PSAANK.mitte.t-com.de><1205849919.9521.7.camel@neutrino> <1B6169C658325341A3B8! ! ! 066E23919E1CF64B8 A@S4DE8PSAANK.mitte.t-com.de> <002901c889b5$ad4671a0$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF64C3B@S4DE8PSAANK.mitte.t-com.de> Date: Wed, 19 Mar 2008 13:35:13 +0100 Message-ID: <003501c889bd$b07549c0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <1B6169C658325341A3B8066E23919E1CF64C3B@S4DE8PSAANK.mitte.t-com.de> Thread-Index: AciJAvohbA2GphQvQLWjFvOYYSGt+QAo6JrgAAOauuAAAN9DsAABQa1g X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 19 Mar 2008 13:35:21 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ruediger It is not a new solution! What I describe are problems that are in my opinion occuring when = the PCN domain uses ECMP routing, AND when a catastrophic event occurs AND when marked = packets are preferentially dropped. The only thing that I am trying to say, is PLEASE DO NOT mandate the preferentially = dropping of marked packets, such that we can avoid such difficult and nasty problems. I am not proposing here another solution. Best regards, Georgios = > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] = > Sent: woensdag 19 maart 2008 13:06 > To: karagian@cs.utwente.nl > Cc: pcn@ietf.org > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > = > Hi Georgios, > = > with how many operator representatives involved into backbone = > traffic engineering including activation of ECMP did you talk = > prior to proposing your solution on this mailing list? = > = > Regards, > = > Rudiger > = > = > | -----Original Message----- > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | Sent: Wednesday, March 19, 2008 12:38 PM > | To: Geib, R=FCdiger; steven.blake@ericsson.com > | Cc: pcn@ietf.org > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > | = > | Hi Rudeiger > | = > | What I am proposing is how to achieve a robust/stable PCN operation = > | when the PCN domain uses ECMP routing and when a catastrophic event = > | occurs. > | = > | Best regards, > | Georgios > | = > | = > | = > | = > | = > | > -----Original Message----- > | > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > | Behalf Of > | > Geib, Ruediger > | > Sent: woensdag 19 maart 2008 11:37 > | > To: steven.blake@ericsson.com > | > Cc: pcn@ietf.org > | > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > | > = > | > Steven, > | > = > | > what Georgios is proposing is to optimise PCN so that it works = > | > properly if a catastrophic event coincides with a misconfigured = > | > router. > | > = > | > If this is the main or even an important task of PCN, then > | I waste my > | > time here. > | > = > | > The salary I obtain monthly depends on my companies > | backbone network > | > providing good service to customers under regular operational = > | > conditions (which cover planned outages and expectable > | failures). The > | > telephony or streaming services offered to our customers should = > | > experience a minimised network impact on the Quality of = > Experience = > | > perceived by the consumers under regular operational > | conditions. This > | > includes the creation of a "Network Busy Indication", which > | however is > | > a rare event. So my position on what PCN should be > | optimised for is to > | > create this "network busy indication" for regular operational = > | > conditions, reliably and only if it is required. > | > This should be done with the least possible complexity > | (like the least > | > possible flow awareness, the least codepoint consumption, simple = > | > queuing/policing and measurement functions, utmost re-use > | of allready > | > implemented features). > | > = > | > To clarify what I mean by a rare event: a well engineered = > backbone = > | > creating a PCN network busy indication either during a = > main traffic = > | > hour or after a re-routing event. During ISDN times, engineering = > | > resulted in what Americans called 5ESS switches, aiming on > | a network > | > busy indication probability of (100 - 99,999%, the 5 = > nines). We may = > | > see that a bit more relaxed for IP networks, but I don't = > think the = > | > customers of my company should experience the consequences of PCN = > | > behaviour more often than in (100 - 99,x)%. > | > = > | > I don't look at PCN as a replacement of network = > engineering, it is = > | > rather an add on to guarantee service quality of admitted = > users by = > | > stopping admission of new traffic once engineering reaches > | its limits. = > | > Under regular operational conditions. > | > = > | > If someone now answers to this mail: uhh, just that - easy! > | > Then lets move this easy thing to WGLC. Now. I can't see that. > | > = > | > If the PCN WG indeed has completely different aims, then > | I'm sorry for > | > bothering you with my mails (but I wonder whether I'm the > | one having > | > gotten things wrong). > | > = > | > By the way, I'm happy with the progress visible in the > | questions you / > | > the WG has formulated. That looks like a constructive approach. > | > = > | > Regards, > | > = > | > Rudiger > | > = > | > = > | > = > | > | -----Original Message----- > | > | From: Steven Blake [mailto:steven.blake@ericsson.com] > | > | Sent: Tuesday, March 18, 2008 3:19 PM > | > | To: Geib, R=FCdiger > | > | Cc: pcn@ietf.org > | > | Subject: Re: [PCN] Concensus questions from Thursday's = > PCN meeting > | > | = > | > | On Tue, 2008-03-18 at 08:29 +0100, Geib, Ruediger wrote: > | > | = > | > | > Hi Georgios, > | > | > = > | > | > in the situation you describe, packet losses occur. This > | > | will result > | > | > in bad press, as the customers using PCN based services > | > | were promised > | > | > another type of service. > | > | > = > | > | > In this situation it doesn't matter whether or not ECMP > | > is deployed > | > | > and it also doesn't matter whether termination is fair or > | > not. The > | > | > important event is: packet losses occur (in one of your > | examples > | > | > several routers drop packets). The drops are the only > | > | relevant issue. > | > | > Whether service resumes after 5 seconds due to extremly well = > | > | > engineered termination or after 10 seconds after a > | > | sufficient number > | > | > of customers hang up is not important. > | > | > I can't recall having read anytime in the news "Major > | > | network outage - > | > | > but termination was fair." I can only recall having seen > | > the first > | > | > part. > | > | > = > | > | > I'm sure you're happy in adapting your example, as you > | do all the > | > | > time. I'm having work to do, but maybe someone else is > | > | interested in > | > | > continuing discusion. I think, I've made my point. > | > | = > | > | Ruediger, > | > | = > | > | If I follow this comment to its logical conclusion, then PCN is = > | > | superfluous in this network. Is that what you are = > trying to say? > | > | = > | > | = > | > | Regards, > | > | = > | > | =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D > | > | Steven Blake > | > | Ericsson/Redback Networks +1 919-472-9913 > | > | = > | > | = > | > _______________________________________________ > | > 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 From pcn-bounces@ietf.org Wed Mar 19 06:19:13 2008 Return-Path: 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 A1FC128C3E1; Wed, 19 Mar 2008 06:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.677 X-Spam-Level: X-Spam-Status: No, score=-100.677 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 DMOiom+wkrwU; Wed, 19 Mar 2008 06:19:12 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E80D3A690E; Wed, 19 Mar 2008 06:19:09 -0700 (PDT) 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 7B92028C42D for ; Wed, 19 Mar 2008 06:19:08 -0700 (PDT) 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 ZqKbuYBuzPgS for ; Wed, 19 Mar 2008 06:19:07 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 462933A6EAD for ; Wed, 19 Mar 2008 06:18:43 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail21.telekom.de with ESMTP; Wed, 19 Mar 2008 14:16:24 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Mar 2008 14:16:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Mar 2008 14:17:29 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CF64CCF@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <003501c889bd$b07549c0$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciJAvohbA2GphQvQLWjFvOYYSGt+QAo6JrgAAOauuAAAN9DsAABQa1gAAFkNSA= References: <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de><000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF6423C@S4DE8PSAANK.mitte.t-com.de><001301c88816$114dab60$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF644B1@S4DE8PSAANK.mitte.t-com.de><000001c88835$998bcf60$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF6451A@S4DE8PSAANK.mitte.t-com.de><000601c8883b$e3828950$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF64580@S4DE8PSAANK.mitte.t-com.de><000901c88844$f35c1130$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF645A3@S4DE8PSAANK.mitte.t-com.de><000a01c8884d$081c9790$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF64645@S4DE8PSAANK.mitte.t-com.de><1205849919.9521.7.camel@neutrino> <1B6169C658325341A3B8! ! ! 066 E23919E1CF64 B8A@S4DE8PSAANK.mitte.t-com.de> <002901c889b5$ad4671a0$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF64C3B@S4DE8PSAANK.mitte.t-com.de> <003501c889bd$b07549c0$810c5982@dynamic.ewi.utwente.nl> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 19 Mar 2008 13:16:06.0578 (UTC) FILETIME=[63C8A120:01C889C3] Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Georgios, could you give us an estimate of the propability that this problem = occurs? How often within a year? Regards, Rudiger = | -----Original Message----- | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] = | Sent: Wednesday, March 19, 2008 1:35 PM | To: Geib, R=FCdiger | Cc: pcn@ietf.org | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | = | = | Hi Ruediger | = | It is not a new solution! What I describe are problems that = | are in my opinion occuring when the PCN domain uses ECMP = | routing, AND when a catastrophic event occurs AND when marked = | packets are preferentially dropped. | The only thing that I am trying to say, is PLEASE DO NOT = | mandate the preferentially dropping of marked packets, such = | that we can avoid such difficult and nasty problems. | = | I am not proposing here another solution. | = | = | Best regards, | Georgios = | = | > -----Original Message----- | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > Sent: woensdag 19 maart 2008 13:06 | > To: karagian@cs.utwente.nl | > Cc: pcn@ietf.org | > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | > = | > Hi Georgios, | > = | > with how many operator representatives involved into = | backbone traffic = | > engineering including activation of ECMP did you talk prior to = | > proposing your solution on this mailing list? | > = | > Regards, | > = | > Rudiger | > = | > = | > | -----Original Message----- | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > | Sent: Wednesday, March 19, 2008 12:38 PM | > | To: Geib, R=FCdiger; steven.blake@ericsson.com | > | Cc: pcn@ietf.org | > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | > | = | > | Hi Rudeiger | > | = | > | What I am proposing is how to achieve a robust/stable PCN = | operation = | > | when the PCN domain uses ECMP routing and when a = | catastrophic event = | > | occurs. | > | = | > | Best regards, | > | Georgios | > | = | > | = | > | = | > | = | > | = | > | > -----Original Message----- | > | > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On | > | Behalf Of | > | > Geib, Ruediger | > | > Sent: woensdag 19 maart 2008 11:37 | > | > To: steven.blake@ericsson.com | > | > Cc: pcn@ietf.org | > | > Subject: Re: [PCN] Concensus questions from Thursday's = | PCN meeting | > | > = | > | > Steven, | > | > = | > | > what Georgios is proposing is to optimise PCN so that it works = | > | > properly if a catastrophic event coincides with a misconfigured = | > | > router. | > | > = | > | > If this is the main or even an important task of PCN, then | > | I waste my | > | > time here. | > | > = | > | > The salary I obtain monthly depends on my companies | > | backbone network | > | > providing good service to customers under regular operational = | > | > conditions (which cover planned outages and expectable | > | failures). The | > | > telephony or streaming services offered to our customers should = | > | > experience a minimised network impact on the Quality of | > Experience | > | > perceived by the consumers under regular operational | > | conditions. This | > | > includes the creation of a "Network Busy Indication", which | > | however is | > | > a rare event. So my position on what PCN should be | > | optimised for is to | > | > create this "network busy indication" for regular operational = | > | > conditions, reliably and only if it is required. | > | > This should be done with the least possible complexity | > | (like the least | > | > possible flow awareness, the least codepoint = | consumption, simple = | > | > queuing/policing and measurement functions, utmost re-use | > | of allready | > | > implemented features). | > | > = | > | > To clarify what I mean by a rare event: a well engineered | > backbone | > | > creating a PCN network busy indication either during a | > main traffic | > | > hour or after a re-routing event. During ISDN times, = | engineering = | > | > resulted in what Americans called 5ESS switches, aiming on | > | a network | > | > busy indication probability of (100 - 99,999%, the 5 | > nines). We may | > | > see that a bit more relaxed for IP networks, but I don't | > think the | > | > customers of my company should experience the = | consequences of PCN = | > | > behaviour more often than in (100 - 99,x)%. | > | > = | > | > I don't look at PCN as a replacement of network | > engineering, it is | > | > rather an add on to guarantee service quality of admitted | > users by | > | > stopping admission of new traffic once engineering reaches | > | its limits. = | > | > Under regular operational conditions. | > | > = | > | > If someone now answers to this mail: uhh, just that - easy! | > | > Then lets move this easy thing to WGLC. Now. I can't see that. | > | > = | > | > If the PCN WG indeed has completely different aims, then | > | I'm sorry for | > | > bothering you with my mails (but I wonder whether I'm the | > | one having | > | > gotten things wrong). | > | > = | > | > By the way, I'm happy with the progress visible in the | > | questions you / | > | > the WG has formulated. That looks like a constructive approach. | > | > = | > | > Regards, | > | > = | > | > Rudiger | > | > = | > | > = | > | > = | > | > | -----Original Message----- | > | > | From: Steven Blake [mailto:steven.blake@ericsson.com] | > | > | Sent: Tuesday, March 18, 2008 3:19 PM | > | > | To: Geib, R=FCdiger | > | > | Cc: pcn@ietf.org | > | > | Subject: Re: [PCN] Concensus questions from Thursday's | > PCN meeting | > | > | = | > | > | On Tue, 2008-03-18 at 08:29 +0100, Geib, Ruediger wrote: | > | > | = | > | > | > Hi Georgios, | > | > | > = | > | > | > in the situation you describe, packet losses occur. This | > | > | will result | > | > | > in bad press, as the customers using PCN based services | > | > | were promised | > | > | > another type of service. | > | > | > = | > | > | > In this situation it doesn't matter whether or not ECMP | > | > is deployed | > | > | > and it also doesn't matter whether termination is fair or | > | > not. The | > | > | > important event is: packet losses occur (in one of your | > | examples | > | > | > several routers drop packets). The drops are the only | > | > | relevant issue. | > | > | > Whether service resumes after 5 seconds due to = | extremly well = | > | > | > engineered termination or after 10 seconds after a | > | > | sufficient number | > | > | > of customers hang up is not important. | > | > | > I can't recall having read anytime in the news "Major | > | > | network outage - | > | > | > but termination was fair." I can only recall having seen | > | > the first | > | > | > part. | > | > | > = | > | > | > I'm sure you're happy in adapting your example, as you | > | do all the | > | > | > time. I'm having work to do, but maybe someone else is | > | > | interested in | > | > | > continuing discusion. I think, I've made my point. | > | > | = | > | > | Ruediger, | > | > | = | > | > | If I follow this comment to its logical conclusion, = | then PCN is = | > | > | superfluous in this network. Is that what you are | > trying to say? | > | > | = | > | > | = | > | > | Regards, | > | > | = | > | > | =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D | > | > | Steven Blake | > | > | Ericsson/Redback Networks +1 919-472-9913 | > | > | = | > | > | = | > | > _______________________________________________ | > | > 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 From pcn-bounces@ietf.org Wed Mar 19 06:23:48 2008 Return-Path: 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 CF4803A6B92; Wed, 19 Mar 2008 06:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.321 X-Spam-Level: X-Spam-Status: No, score=-100.321 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 6DOY3ZNwIVXV; Wed, 19 Mar 2008 06:23:44 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6270928C370; Wed, 19 Mar 2008 06:23:44 -0700 (PDT) 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 DC06D3A6877 for ; Wed, 19 Mar 2008 06:23:42 -0700 (PDT) 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 CzY61Xd3EZQU for ; Wed, 19 Mar 2008 06:23:38 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 656633A6817 for ; Wed, 19 Mar 2008 06:23:38 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m2JDLGCE023698; Wed, 19 Mar 2008 14:21:19 +0100 (MET) From: "Georgios Karagiannis" To: "'Geib, Ruediger'" References: <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de><000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF6423C@S4DE8PSAANK.mitte.t-com.de><001301c88816$114dab60$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF644B1@S4DE8PSAANK.mitte.t-com.de><000001c88835$998bcf60$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF6451A@S4DE8PSAANK.mitte.t-com.de><000601c8883b$e3828950$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF64580@S4DE8PSAANK.mitte.t-com.de><000901c88844$f35c1130$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF645A3@S4DE8PSAANK.mitte.t-com.de><000a01c8884d$081c9790$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF64645@S4DE8PSAANK.mitte.t-com.de><1205849919.9521.7.camel@neutrino> <1B6169C658325341A3B8! ! ! ! ! 066E23919E1CF 64B8A@S4DE8PSAANK.mitte.t-com.de> <002901c889b5$ad4671a0$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF64C3B@S4DE8PSAANK.mitte.t-com.de> <003501c889bd$b07549c0$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF64CCF@S4DE8PSAANK.mitte.t-com.de> Date: Wed, 19 Mar 2008 14:21:11 +0100 Message-ID: <003d01c889c4$1c998e80$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <1B6169C658325341A3B8066E23919E1CF64CCF@S4DE8PSAANK.mitte.t-com.de> Thread-Index: AciJAvohbA2GphQvQLWjFvOYYSGt+QAo6JrgAAOauuAAAN9DsAABQa1gAAFkNSAAABz3EA== X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 19 Mar 2008 14:21:20 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ruediger I do not know, but when such an event occurs, what are then the costs involved associated with the financial losses = and customer losses for an operator of a large network with a huge number of subscribers? Best regards, Georgios > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] = > Sent: woensdag 19 maart 2008 14:17 > To: karagian@cs.utwente.nl > Cc: pcn@ietf.org > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > = > Hi Georgios, > = > could you give us an estimate of the propability that this = > problem occurs? How often within a year? > = > Regards, > = > Rudiger > = > = > | -----Original Message----- > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | Sent: Wednesday, March 19, 2008 1:35 PM > | To: Geib, R=FCdiger > | Cc: pcn@ietf.org > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > | = > | = > | Hi Ruediger > | = > | It is not a new solution! What I describe are problems that = > are in my = > | opinion occuring when the PCN domain uses ECMP routing, AND when a = > | catastrophic event occurs AND when marked packets are = > preferentially = > | dropped. > | The only thing that I am trying to say, is PLEASE DO NOT = > mandate the = > | preferentially dropping of marked packets, such that we can avoid = > | such difficult and nasty problems. > | = > | I am not proposing here another solution. > | = > | = > | Best regards, > | Georgios > | = > | > -----Original Message----- > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > | > Sent: woensdag 19 maart 2008 13:06 > | > To: karagian@cs.utwente.nl > | > Cc: pcn@ietf.org > | > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > | > = > | > Hi Georgios, > | > = > | > with how many operator representatives involved into > | backbone traffic > | > engineering including activation of ECMP did you talk prior to = > | > proposing your solution on this mailing list? > | > = > | > Regards, > | > = > | > Rudiger > | > = > | > = > | > | -----Original Message----- > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | > | Sent: Wednesday, March 19, 2008 12:38 PM > | > | To: Geib, R=FCdiger; steven.blake@ericsson.com > | > | Cc: pcn@ietf.org > | > | Subject: RE: [PCN] Concensus questions from Thursday's = > PCN meeting > | > | = > | > | Hi Rudeiger > | > | = > | > | What I am proposing is how to achieve a robust/stable PCN > | operation > | > | when the PCN domain uses ECMP routing and when a > | catastrophic event > | > | occurs. > | > | = > | > | Best regards, > | > | Georgios > | > | = > | > | = > | > | = > | > | = > | > | = > | > | > -----Original Message----- > | > | > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > | > | Behalf Of > | > | > Geib, Ruediger > | > | > Sent: woensdag 19 maart 2008 11:37 > | > | > To: steven.blake@ericsson.com > | > | > Cc: pcn@ietf.org > | > | > Subject: Re: [PCN] Concensus questions from Thursday's > | PCN meeting > | > | > = > | > | > Steven, > | > | > = > | > | > what Georgios is proposing is to optimise PCN so that = > it works = > | > | > properly if a catastrophic event coincides with a = > misconfigured = > | > | > router. > | > | > = > | > | > If this is the main or even an important task of PCN, then > | > | I waste my > | > | > time here. > | > | > = > | > | > The salary I obtain monthly depends on my companies > | > | backbone network > | > | > providing good service to customers under regular operational = > | > | > conditions (which cover planned outages and expectable > | > | failures). The > | > | > telephony or streaming services offered to our = > customers should = > | > | > experience a minimised network impact on the Quality of > | > Experience > | > | > perceived by the consumers under regular operational > | > | conditions. This > | > | > includes the creation of a "Network Busy Indication", which > | > | however is > | > | > a rare event. So my position on what PCN should be > | > | optimised for is to > | > | > create this "network busy indication" for regular operational = > | > | > conditions, reliably and only if it is required. > | > | > This should be done with the least possible complexity > | > | (like the least > | > | > possible flow awareness, the least codepoint > | consumption, simple > | > | > queuing/policing and measurement functions, utmost re-use > | > | of allready > | > | > implemented features). > | > | > = > | > | > To clarify what I mean by a rare event: a well engineered > | > backbone > | > | > creating a PCN network busy indication either during a > | > main traffic > | > | > hour or after a re-routing event. During ISDN times, > | engineering > | > | > resulted in what Americans called 5ESS switches, aiming on > | > | a network > | > | > busy indication probability of (100 - 99,999%, the 5 > | > nines). We may > | > | > see that a bit more relaxed for IP networks, but I don't > | > think the > | > | > customers of my company should experience the > | consequences of PCN > | > | > behaviour more often than in (100 - 99,x)%. > | > | > = > | > | > I don't look at PCN as a replacement of network > | > engineering, it is > | > | > rather an add on to guarantee service quality of admitted > | > users by > | > | > stopping admission of new traffic once engineering reaches > | > | its limits. = > | > | > Under regular operational conditions. > | > | > = > | > | > If someone now answers to this mail: uhh, just that - easy! > | > | > Then lets move this easy thing to WGLC. Now. I can't see that. > | > | > = > | > | > If the PCN WG indeed has completely different aims, then > | > | I'm sorry for > | > | > bothering you with my mails (but I wonder whether I'm the > | > | one having > | > | > gotten things wrong). > | > | > = > | > | > By the way, I'm happy with the progress visible in the > | > | questions you / > | > | > the WG has formulated. That looks like a constructive = > approach. > | > | > = > | > | > Regards, > | > | > = > | > | > Rudiger > | > | > = > | > | > = > | > | > = > | > | > | -----Original Message----- > | > | > | From: Steven Blake [mailto:steven.blake@ericsson.com] > | > | > | Sent: Tuesday, March 18, 2008 3:19 PM > | > | > | To: Geib, R=FCdiger > | > | > | Cc: pcn@ietf.org > | > | > | Subject: Re: [PCN] Concensus questions from Thursday's > | > PCN meeting > | > | > | = > | > | > | On Tue, 2008-03-18 at 08:29 +0100, Geib, Ruediger wrote: > | > | > | = > | > | > | > Hi Georgios, > | > | > | > = > | > | > | > in the situation you describe, packet losses occur. This > | > | > | will result > | > | > | > in bad press, as the customers using PCN based services > | > | > | were promised > | > | > | > another type of service. > | > | > | > = > | > | > | > In this situation it doesn't matter whether or not ECMP > | > | > is deployed > | > | > | > and it also doesn't matter whether termination is fair or > | > | > not. The > | > | > | > important event is: packet losses occur (in one of your > | > | examples > | > | > | > several routers drop packets). The drops are the only > | > | > | relevant issue. > | > | > | > Whether service resumes after 5 seconds due to > | extremly well > | > | > | > engineered termination or after 10 seconds after a > | > | > | sufficient number > | > | > | > of customers hang up is not important. > | > | > | > I can't recall having read anytime in the news "Major > | > | > | network outage - > | > | > | > but termination was fair." I can only recall having seen > | > | > the first > | > | > | > part. > | > | > | > = > | > | > | > I'm sure you're happy in adapting your example, as you > | > | do all the > | > | > | > time. I'm having work to do, but maybe someone else is > | > | > | interested in > | > | > | > continuing discusion. I think, I've made my point. > | > | > | = > | > | > | Ruediger, > | > | > | = > | > | > | If I follow this comment to its logical conclusion, > | then PCN is > | > | > | superfluous in this network. Is that what you are > | > trying to say? > | > | > | = > | > | > | = > | > | > | Regards, > | > | > | = > | > | > | =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D > | > | > | Steven Blake > | > | > | Ericsson/Redback Networks +1 919-472-9913 > | > | > | = > | > | > | = > | > | > _______________________________________________ > | > | > 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 From pcn-bounces@ietf.org Wed Mar 19 06:42:37 2008 Return-Path: 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 E27363A6C83; Wed, 19 Mar 2008 06:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.687 X-Spam-Level: X-Spam-Status: No, score=-100.687 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 NzUd8VXCn9pJ; Wed, 19 Mar 2008 06:42:36 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AE243A6E3D; Wed, 19 Mar 2008 06:42:36 -0700 (PDT) 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 5B6C53A6E3D for ; Wed, 19 Mar 2008 06:42:35 -0700 (PDT) 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 L6mITDV0P0fn for ; Wed, 19 Mar 2008 06:42:34 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 85CEE3A6C83 for ; Wed, 19 Mar 2008 06:42:33 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail21.telekom.de with ESMTP; Wed, 19 Mar 2008 14:40:15 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Mar 2008 14:40:15 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Mar 2008 14:41:38 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CF64CFA@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <003d01c889c4$1c998e80$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciJAvohbA2GphQvQLWjFvOYYSGt+QAo6JrgAAOauuAAAN9DsAABQa1gAAFkNSAAABz3EAAAq7Kw References: <1B6169C658325341A3B8066E23919E1CF641B0@S4DE8PSAANK.mitte.t-com.de><000001c88809$b2e73840$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF6423C@S4DE8PSAANK.mitte.t-com.de><001301c88816$114dab60$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF644B1@S4DE8PSAANK.mitte.t-com.de><000001c88835$998bcf60$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF6451A@S4DE8PSAANK.mitte.t-com.de><000601c8883b$e3828950$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF64580@S4DE8PSAANK.mitte.t-com.de><000901c88844$f35c1130$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF645A3@S4DE8PSAANK.mitte.t-com.de><000a01c8884d$081c9790$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1CF64645@S4DE8PSAANK.mitte.t-com.de><1205849919.9521.7.camel@neutrino> <1B6169C658325341A3B8! ! ! ! ! 066E23919E1 CF64B8A@S4DE8PSAANK.mitte.t-com.de> <002901c889b5$ad4671a0$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF64C3B@S4DE8PSAANK.mitte.t-com.de> <003501c889bd$b07549c0$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1CF64CCF@S4DE8PSAANK.mitte.t-com.de> <003d01c889c4$1c998e80$810c5982@dynamic.ewi.utwente.nl> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 19 Mar 2008 13:40:15.0337 (UTC) FILETIME=[C34FB590:01C889C6] Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Georgios, I assume the costs to marginal as compared to the expenditure = required to avoid these losses. We face tough regulation and = can't stay in business if we engineer networks for resilience = during catastrophic outages. These times are gone. During catastrophic outages, my operational staff will require = good OAM tools to enable return to bearable operation as soon = as possible. To me, OAM is the only section in PCN drafts = I'd like to be addressed to deal with catastrophic outages. Regards Rudiger | -----Original Message----- | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] = | Sent: Wednesday, March 19, 2008 2:21 PM | To: Geib, R=FCdiger | Cc: pcn@ietf.org | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | = | Hi Ruediger | = | I do not know, but when such an event occurs, what are then = | the costs involved associated with the financial losses and = | customer losses for an operator of a large network with a = | huge number of subscribers? | = | Best regards, | Georgios | = | = | = | > -----Original Message----- | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > Sent: woensdag 19 maart 2008 14:17 | > To: karagian@cs.utwente.nl | > Cc: pcn@ietf.org | > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | > = | > Hi Georgios, | > = | > could you give us an estimate of the propability that this problem = | > occurs? How often within a year? | > = | > Regards, | > = | > Rudiger | > = | > = | > | -----Original Message----- | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > | Sent: Wednesday, March 19, 2008 1:35 PM | > | To: Geib, R=FCdiger | > | Cc: pcn@ietf.org | > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting | > | = | > | = | > | Hi Ruediger | > | = | > | It is not a new solution! What I describe are problems that | > are in my | > | opinion occuring when the PCN domain uses ECMP routing, = | AND when a = | > | catastrophic event occurs AND when marked packets are | > preferentially | > | dropped. | > | The only thing that I am trying to say, is PLEASE DO NOT | > mandate the | > | preferentially dropping of marked packets, such that we = | can avoid = | > | such difficult and nasty problems. | > | = | > | I am not proposing here another solution. | > | = | > | = | > | Best regards, | > | Georgios | > | = | > | > -----Original Message----- | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] | > | > Sent: woensdag 19 maart 2008 13:06 | > | > To: karagian@cs.utwente.nl | > | > Cc: pcn@ietf.org | > | > Subject: RE: [PCN] Concensus questions from Thursday's = | PCN meeting | > | > = | > | > Hi Georgios, | > | > = | > | > with how many operator representatives involved into | > | backbone traffic | > | > engineering including activation of ECMP did you talk prior to = | > | > proposing your solution on this mailing list? | > | > = | > | > Regards, | > | > = | > | > Rudiger | > | > = | > | > = | > | > | -----Original Message----- | > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] | > | > | Sent: Wednesday, March 19, 2008 12:38 PM | > | > | To: Geib, R=FCdiger; steven.blake@ericsson.com | > | > | Cc: pcn@ietf.org | > | > | Subject: RE: [PCN] Concensus questions from Thursday's | > PCN meeting | > | > | = | > | > | Hi Rudeiger | > | > | = | > | > | What I am proposing is how to achieve a robust/stable PCN | > | operation | > | > | when the PCN domain uses ECMP routing and when a | > | catastrophic event | > | > | occurs. | > | > | = | > | > | Best regards, | > | > | Georgios | > | > | = | > | > | = | > | > | = | > | > | = | > | > | = | > | > | > -----Original Message----- | > | > | > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On | > | > | Behalf Of | > | > | > Geib, Ruediger | > | > | > Sent: woensdag 19 maart 2008 11:37 | > | > | > To: steven.blake@ericsson.com | > | > | > Cc: pcn@ietf.org | > | > | > Subject: Re: [PCN] Concensus questions from Thursday's | > | PCN meeting | > | > | > = | > | > | > Steven, | > | > | > = | > | > | > what Georgios is proposing is to optimise PCN so that | > it works | > | > | > properly if a catastrophic event coincides with a | > misconfigured | > | > | > router. | > | > | > = | > | > | > If this is the main or even an important task of PCN, then | > | > | I waste my | > | > | > time here. | > | > | > = | > | > | > The salary I obtain monthly depends on my companies | > | > | backbone network | > | > | > providing good service to customers under regular = | operational = | > | > | > conditions (which cover planned outages and expectable | > | > | failures). The | > | > | > telephony or streaming services offered to our | > customers should | > | > | > experience a minimised network impact on the Quality of | > | > Experience | > | > | > perceived by the consumers under regular operational | > | > | conditions. This | > | > | > includes the creation of a "Network Busy Indication", which | > | > | however is | > | > | > a rare event. So my position on what PCN should be | > | > | optimised for is to | > | > | > create this "network busy indication" for regular = | operational = | > | > | > conditions, reliably and only if it is required. | > | > | > This should be done with the least possible complexity | > | > | (like the least | > | > | > possible flow awareness, the least codepoint | > | consumption, simple | > | > | > queuing/policing and measurement functions, utmost re-use | > | > | of allready | > | > | > implemented features). | > | > | > = | > | > | > To clarify what I mean by a rare event: a well engineered | > | > backbone | > | > | > creating a PCN network busy indication either during a | > | > main traffic | > | > | > hour or after a re-routing event. During ISDN times, | > | engineering | > | > | > resulted in what Americans called 5ESS switches, aiming on | > | > | a network | > | > | > busy indication probability of (100 - 99,999%, the 5 | > | > nines). We may | > | > | > see that a bit more relaxed for IP networks, but I don't | > | > think the | > | > | > customers of my company should experience the | > | consequences of PCN | > | > | > behaviour more often than in (100 - 99,x)%. | > | > | > = | > | > | > I don't look at PCN as a replacement of network | > | > engineering, it is | > | > | > rather an add on to guarantee service quality of admitted | > | > users by | > | > | > stopping admission of new traffic once engineering reaches | > | > | its limits. = | > | > | > Under regular operational conditions. | > | > | > = | > | > | > If someone now answers to this mail: uhh, just that - easy! | > | > | > Then lets move this easy thing to WGLC. Now. I = | can't see that. | > | > | > = | > | > | > If the PCN WG indeed has completely different aims, then | > | > | I'm sorry for | > | > | > bothering you with my mails (but I wonder whether I'm the | > | > | one having | > | > | > gotten things wrong). | > | > | > = | > | > | > By the way, I'm happy with the progress visible in the | > | > | questions you / | > | > | > the WG has formulated. That looks like a constructive | > approach. | > | > | > = | > | > | > Regards, | > | > | > = | > | > | > Rudiger | > | > | > = | > | > | > = | > | > | > = | > | > | > | -----Original Message----- | > | > | > | From: Steven Blake [mailto:steven.blake@ericsson.com] | > | > | > | Sent: Tuesday, March 18, 2008 3:19 PM | > | > | > | To: Geib, R=FCdiger | > | > | > | Cc: pcn@ietf.org | > | > | > | Subject: Re: [PCN] Concensus questions from Thursday's | > | > PCN meeting | > | > | > | = | > | > | > | On Tue, 2008-03-18 at 08:29 +0100, Geib, Ruediger wrote: | > | > | > | = | > | > | > | > Hi Georgios, | > | > | > | > = | > | > | > | > in the situation you describe, packet losses occur. This | > | > | > | will result | > | > | > | > in bad press, as the customers using PCN based services | > | > | > | were promised | > | > | > | > another type of service. | > | > | > | > = | > | > | > | > In this situation it doesn't matter whether or not ECMP | > | > | > is deployed | > | > | > | > and it also doesn't matter whether termination = | is fair or | > | > | > not. The | > | > | > | > important event is: packet losses occur (in one of your | > | > | examples | > | > | > | > several routers drop packets). The drops are the only | > | > | > | relevant issue. | > | > | > | > Whether service resumes after 5 seconds due to | > | extremly well | > | > | > | > engineered termination or after 10 seconds after a | > | > | > | sufficient number | > | > | > | > of customers hang up is not important. | > | > | > | > I can't recall having read anytime in the news "Major | > | > | > | network outage - | > | > | > | > but termination was fair." I can only recall having seen | > | > | > the first | > | > | > | > part. | > | > | > | > = | > | > | > | > I'm sure you're happy in adapting your example, as you | > | > | do all the | > | > | > | > time. I'm having work to do, but maybe someone else is | > | > | > | interested in | > | > | > | > continuing discusion. I think, I've made my point. | > | > | > | = | > | > | > | Ruediger, | > | > | > | = | > | > | > | If I follow this comment to its logical conclusion, | > | then PCN is | > | > | > | superfluous in this network. Is that what you are | > | > trying to say? | > | > | > | = | > | > | > | = | > | > | > | Regards, | > | > | > | = | > | > | > | =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D | > | > | > | Steven Blake | > | > | > | Ericsson/Redback Networks +1 919-472-9913 | > | > | > | = | > | > | > | = | > | > | > _______________________________________________ | > | > | > 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 From pcn-bounces@ietf.org Wed Mar 19 07:52:07 2008 Return-Path: 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 9B3EE28C5DE; Wed, 19 Mar 2008 07:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.701 X-Spam-Level: X-Spam-Status: No, score=-100.701 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 Uc27YJqT4YTE; Wed, 19 Mar 2008 07:52:01 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19DA728C60C; Wed, 19 Mar 2008 07:52:01 -0700 (PDT) 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 ED26928C607 for ; Wed, 19 Mar 2008 07:51:58 -0700 (PDT) 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 ORq25J2idUMC for ; Wed, 19 Mar 2008 07:51:57 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 0050B28C5FF for ; Wed, 19 Mar 2008 07:51:56 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Mar 2008 14:49:38 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Mar 2008 14:49:37 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34667@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <1B6169C658325341A3B8066E23919E1CF64CFA@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciJAvohbA2GphQvQLWjFvOYYSGt+QAo6JrgAAOauuAAAN9DsAABQa1gAAFkNSAAABz3EAAAq7KwAAJMKqA= From: To: , X-OriginalArrivalTime: 19 Mar 2008 14:49:38.0638 (UTC) FILETIME=[74D506E0:01C889D0] Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Georgios - it would have been very useful to have raised this last week at IETF. Pro= gress is so much easier face to face. - are you talking about admission or termination? I got confused; your emai= ls didn't seem consistent. - I haven't read all the emails in detail, but I don't understand what are = you saying that's different from http://www.ietf.org/internet-drafts/draft-= charny-pcn-comparison-00.txt ? eg Table 8.1 extract: -------------------------------------------------------------------| |Comparison | SM | 3SM | CL | |criteria | | | | |-------------------------------------------------------------------- |-------------------------------------------------------------------| |ECMP support |no; only | yes | no; but full | |for |partial support| | support with | |Termination |with additional| | additional | | | complexity at | | complexity at | | | the edge + | | the edge + | | | signaling flow| | plus signalling | | | flow IDs from | | flow IDs from | | | egress to | | egress to | | | ingress | | ingress | |-------------------------------------------------------------------| |ECMP support |no w/out probes| no w/out probing | no w/out probing| |for Admission |yes with probes| yes with probing | yes with probing| | |but needs many |(needs one probe, |(needs one probe,| | |probes; use of |can use RSVP as | can use RSVP | | |RSVP as probes |probe) | as probe) | | |not understood | | | |-------------------------------------------------------------------| - you seem to be saying that preferential dropping of excess-rate-marking p= kts in your view can lead to problems - and proposing instead random droppi= ng, but saying this can also lead to the same problem (but maybe not as oft= en). Is that right? best wishes, phil > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Geib, Ruediger > Sent: 19 March 2008 13:42 > To: karagian@cs.utwente.nl > Cc: pcn@ietf.org > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > = > Hi Georgios, > = > I assume the costs to marginal as compared to the expenditure > required to avoid these losses. We face tough regulation and > can't stay in business if we engineer networks for resilience > during catastrophic outages. These times are gone. > = > During catastrophic outages, my operational staff will require > good OAM tools to enable return to bearable operation as soon > as possible. To me, OAM is the only section in PCN drafts > I'd like to be addressed to deal with catastrophic outages. > = > Regards > = > Rudiger > = > | -----Original Message----- > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | Sent: Wednesday, March 19, 2008 2:21 PM > | To: Geib, R=FCdiger > | Cc: pcn@ietf.org > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > | > | Hi Ruediger > | > | I do not know, but when such an event occurs, what are then > | the costs involved associated with the financial losses and > | customer losses for an operator of a large network with a > | huge number of subscribers? > | > | Best regards, > | Georgios > | > | > | > | > -----Original Message----- > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > | > Sent: woensdag 19 maart 2008 14:17 > | > To: karagian@cs.utwente.nl > | > Cc: pcn@ietf.org > | > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > | > > | > Hi Georgios, > | > > | > could you give us an estimate of the propability that this problem > | > occurs? How often within a year? > | > > | > Regards, > | > > | > Rudiger > | > > | > > | > | -----Original Message----- > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | > | Sent: Wednesday, March 19, 2008 1:35 PM > | > | To: Geib, R=FCdiger > | > | Cc: pcn@ietf.org > | > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > | > | > | > | > | > | Hi Ruediger > | > | > | > | It is not a new solution! What I describe are problems that > | > are in my > | > | opinion occuring when the PCN domain uses ECMP routing, > | AND when a > | > | catastrophic event occurs AND when marked packets are > | > preferentially > | > | dropped. > | > | The only thing that I am trying to say, is PLEASE DO NOT > | > mandate the > | > | preferentially dropping of marked packets, such that we > | can avoid > | > | such difficult and nasty problems. > | > | > | > | I am not proposing here another solution. > | > | > | > | > | > | Best regards, > | > | Georgios > | > | > | > | > -----Original Message----- > | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > | > | > Sent: woensdag 19 maart 2008 13:06 > | > | > To: karagian@cs.utwente.nl > | > | > Cc: pcn@ietf.org > | > | > Subject: RE: [PCN] Concensus questions from Thursday's > | PCN meeting > | > | > > | > | > Hi Georgios, > | > | > > | > | > with how many operator representatives involved into > | > | backbone traffic > | > | > engineering including activation of ECMP did you talk prior to > | > | > proposing your solution on this mailing list? > | > | > > | > | > Regards, > | > | > > | > | > Rudiger > | > | > > | > | > > | > | > | -----Original Message----- > | > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > | > | > | Sent: Wednesday, March 19, 2008 12:38 PM > | > | > | To: Geib, R=FCdiger; steven.blake@ericsson.com > | > | > | Cc: pcn@ietf.org > | > | > | Subject: RE: [PCN] Concensus questions from Thursday's > | > PCN meeting > | > | > | > | > | > | Hi Rudeiger > | > | > | > | > | > | What I am proposing is how to achieve a robust/stable PCN > | > | operation > | > | > | when the PCN domain uses ECMP routing and when a > | > | catastrophic event > | > | > | occurs. > | > | > | > | > | > | Best regards, > | > | > | Georgios > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > | > -----Original Message----- > | > | > | > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > | > | > | Behalf Of > | > | > | > Geib, Ruediger > | > | > | > Sent: woensdag 19 maart 2008 11:37 > | > | > | > To: steven.blake@ericsson.com > | > | > | > Cc: pcn@ietf.org > | > | > | > Subject: Re: [PCN] Concensus questions from Thursday's > | > | PCN meeting > | > | > | > > | > | > | > Steven, > | > | > | > > | > | > | > what Georgios is proposing is to optimise PCN so that > | > it works > | > | > | > properly if a catastrophic event coincides with a > | > misconfigured > | > | > | > router. > | > | > | > > | > | > | > If this is the main or even an important task of PCN, then > | > | > | I waste my > | > | > | > time here. > | > | > | > > | > | > | > The salary I obtain monthly depends on my companies > | > | > | backbone network > | > | > | > providing good service to customers under regular > | operational > | > | > | > conditions (which cover planned outages and expectable > | > | > | failures). The > | > | > | > telephony or streaming services offered to our > | > customers should > | > | > | > experience a minimised network impact on the Quality of > | > | > Experience > | > | > | > perceived by the consumers under regular operational > | > | > | conditions. This > | > | > | > includes the creation of a "Network Busy Indication", which > | > | > | however is > | > | > | > a rare event. So my position on what PCN should be > | > | > | optimised for is to > | > | > | > create this "network busy indication" for regular > | operational > | > | > | > conditions, reliably and only if it is required. > | > | > | > This should be done with the least possible complexity > | > | > | (like the least > | > | > | > possible flow awareness, the least codepoint > | > | consumption, simple > | > | > | > queuing/policing and measurement functions, utmost re-use > | > | > | of allready > | > | > | > implemented features). > | > | > | > > | > | > | > To clarify what I mean by a rare event: a well engineered > | > | > backbone > | > | > | > creating a PCN network busy indication either during a > | > | > main traffic > | > | > | > hour or after a re-routing event. During ISDN times, > | > | engineering > | > | > | > resulted in what Americans called 5ESS switches, aiming on > | > | > | a network > | > | > | > busy indication probability of (100 - 99,999%, the 5 > | > | > nines). We may > | > | > | > see that a bit more relaxed for IP networks, but I don't > | > | > think the > | > | > | > customers of my company should experience the > | > | consequences of PCN > | > | > | > behaviour more often than in (100 - 99,x)%. > | > | > | > > | > | > | > I don't look at PCN as a replacement of network > | > | > engineering, it is > | > | > | > rather an add on to guarantee service quality of admitted > | > | > users by > | > | > | > stopping admission of new traffic once engineering reaches > | > | > | its limits. > | > | > | > Under regular operational conditions. > | > | > | > > | > | > | > If someone now answers to this mail: uhh, just that - easy! > | > | > | > Then lets move this easy thing to WGLC. Now. I > | can't see that. > | > | > | > > | > | > | > If the PCN WG indeed has completely different aims, then > | > | > | I'm sorry for > | > | > | > bothering you with my mails (but I wonder whether I'm the > | > | > | one having > | > | > | > gotten things wrong). > | > | > | > > | > | > | > By the way, I'm happy with the progress visible in the > | > | > | questions you / > | > | > | > the WG has formulated. That looks like a constructive > | > approach. > | > | > | > > | > | > | > Regards, > | > | > | > > | > | > | > Rudiger > | > | > | > > | > | > | > > | > | > | > > | > | > | > | -----Original Message----- > | > | > | > | From: Steven Blake [mailto:steven.blake@ericsson.com] > | > | > | > | Sent: Tuesday, March 18, 2008 3:19 PM > | > | > | > | To: Geib, R=FCdiger > | > | > | > | Cc: pcn@ietf.org > | > | > | > | Subject: Re: [PCN] Concensus questions from Thursday's > | > | > PCN meeting > | > | > | > | > | > | > | > | On Tue, 2008-03-18 at 08:29 +0100, Geib, Ruediger wrote: > | > | > | > | > | > | > | > | > Hi Georgios, > | > | > | > | > > | > | > | > | > in the situation you describe, packet losses occur. This > | > | > | > | will result > | > | > | > | > in bad press, as the customers using PCN based services > | > | > | > | were promised > | > | > | > | > another type of service. > | > | > | > | > > | > | > | > | > In this situation it doesn't matter whether or not ECMP > | > | > | > is deployed > | > | > | > | > and it also doesn't matter whether termination > | is fair or > | > | > | > not. The > | > | > | > | > important event is: packet losses occur (in one of your > | > | > | examples > | > | > | > | > several routers drop packets). The drops are the only > | > | > | > | relevant issue. > | > | > | > | > Whether service resumes after 5 seconds due to > | > | extremly well > | > | > | > | > engineered termination or after 10 seconds after a > | > | > | > | sufficient number > | > | > | > | > of customers hang up is not important. > | > | > | > | > I can't recall having read anytime in the news "Major > | > | > | > | network outage - > | > | > | > | > but termination was fair." I can only recall having seen > | > | > | > the first > | > | > | > | > part. > | > | > | > | > > | > | > | > | > I'm sure you're happy in adapting your example, as you > | > | > | do all the > | > | > | > | > time. I'm having work to do, but maybe someone else is > | > | > | > | interested in > | > | > | > | > continuing discusion. I think, I've made my point. > | > | > | > | > | > | > | > | Ruediger, > | > | > | > | > | > | > | > | If I follow this comment to its logical conclusion, > | > | then PCN is > | > | > | > | superfluous in this network. Is that what you are > | > | > trying to say? > | > | > | > | > | > | > | > | > | > | > | > | Regards, > | > | > | > | > | > | > | > | =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D= -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D > | > | > | > | Steven Blake > | > | > | > | Ericsson/Redback Networks +1 919-472-9913 > | > | > | > | > | > | > | > | > | > | > | > _______________________________________________ > | > | > | > 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 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 19 08:06:54 2008 Return-Path: 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 E35FD28C4E2; Wed, 19 Mar 2008 08:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.612 X-Spam-Level: X-Spam-Status: No, score=-99.612 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, MIME_QP_LONG_LINE=1.396, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 wcAK-EAYxfsN; Wed, 19 Mar 2008 08:06:50 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 593C73A6B6A; Wed, 19 Mar 2008 08:06:50 -0700 (PDT) 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 3C18A3A6B6A for ; Wed, 19 Mar 2008 08:06:49 -0700 (PDT) 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 I-6N0rNCwu4i for ; Wed, 19 Mar 2008 08:06:47 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 5C9283A6A2A for ; Wed, 19 Mar 2008 08:06:47 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m2JEuYlF004719; Wed, 19 Mar 2008 15:56:37 +0100 (MET) From: "Georgios Karagiannis" To: , References: <1B6169C658325341A3B8066E23919E1CF64CFA@S4DE8PSAANK.mitte.t-com.de> <75A199C5D243C741BF3D3F1EBCEF9BA503B34667@E03MVZ1-UKDY.domain1.systemhost.net> Date: Wed, 19 Mar 2008 15:56:29 +0100 Message-ID: <004e01c889d1$6d01e4f0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B34667@E03MVZ1-UKDY.domain1.systemhost.net> Thread-Index: AciJAvohbA2GphQvQLWjFvOYYSGt+QAo6JrgAAOauuAAAN9DsAABQa1gAAFkNSAAABz3EAAAq7KwAAJMKqAAAE1g8A== X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 19 Mar 2008 15:56:39 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil Actually the problem is that when ECMP routing is used, then = the stability/robustness during a catastrophic event (thus flow termination) of the PCN domain operation is decreased. Therefore, we should not mandate = to preferentially drop marked packets. Please note that I have identified this problem after the = IETF meeting. Best regards, Georgios = > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] = > Sent: woensdag 19 maart 2008 15:50 > To: Ruediger.Geib@t-systems.com; karagian@cs.utwente.nl > Cc: pcn@ietf.org > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > = > Georgios > = > - it would have been very useful to have raised this last = > week at IETF. Progress is so much easier face to face. > - are you talking about admission or termination? I got = > confused; your emails didn't seem consistent. > - I haven't read all the emails in detail, but I don't = > understand what are you saying that's different from = > http://www.ietf.org/internet-drafts/draft-charny-pcn-compariso n-00.txt ? eg Table 8.1 extract: > = > -------------------------------------------------------------------| > |Comparison | SM | 3SM | = > CL | > |criteria | | | = > | > = > |-------------------------------------------------------------------- > = > |-------------------------------------------------------------------| > |ECMP support |no; only | yes | no; = > but full | > |for |partial support| | = > support with | > |Termination |with additional| | = > additional | > | | complexity at | | = > complexity at | > | | the edge + | | the = > edge + | > | | signaling flow| | plus = > signalling | > | | flow IDs from | | flow = > IDs from | > | | egress to | | egress = > to | > | | ingress | | = > ingress | > = > |-------------------------------------------------------------------| > |ECMP support |no w/out probes| no w/out probing | no = > w/out probing| > |for Admission |yes with probes| yes with probing | yes = > with probing| > | |but needs many |(needs one probe, |(needs = > one probe,| > | |probes; use of |can use RSVP as | can = > use RSVP | > | |RSVP as probes |probe) | as = > probe) | > | |not understood | | = > | > = > |-------------------------------------------------------------------| > = > - you seem to be saying that preferential dropping of = > excess-rate-marking pkts in your view can lead to problems - = > and proposing instead random dropping, but saying this can = > also lead to the same problem (but maybe not as often). Is that right? > = > best wishes, > phil > = > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On = > Behalf Of = > > Geib, Ruediger > > Sent: 19 March 2008 13:42 > > To: karagian@cs.utwente.nl > > Cc: pcn@ietf.org > > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > > = > > Hi Georgios, > > = > > I assume the costs to marginal as compared to the = > expenditure required = > > to avoid these losses. We face tough regulation and can't stay in = > > business if we engineer networks for resilience during catastrophic = > > outages. These times are gone. > > = > > During catastrophic outages, my operational staff will require good = > > OAM tools to enable return to bearable operation as soon as = > possible. = > > To me, OAM is the only section in PCN drafts I'd like to be = > addressed = > > to deal with catastrophic outages. > > = > > Regards > > = > > Rudiger > > = > > | -----Original Message----- > > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > | Sent: Wednesday, March 19, 2008 2:21 PM > > | To: Geib, R=FCdiger > > | Cc: pcn@ietf.org > > | Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > > | > > | Hi Ruediger > > | > > | I do not know, but when such an event occurs, what are then the = > > | costs involved associated with the financial losses and customer = > > | losses for an operator of a large network with a huge number of = > > | subscribers? > > | > > | Best regards, > > | Georgios > > | > > | > > | > > | > -----Original Message----- > > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > > | > Sent: woensdag 19 maart 2008 14:17 > > | > To: karagian@cs.utwente.nl > > | > Cc: pcn@ietf.org > > | > Subject: RE: [PCN] Concensus questions from Thursday's = > PCN meeting > > | > > > | > Hi Georgios, > > | > > > | > could you give us an estimate of the propability that = > this problem = > > | > occurs? How often within a year? > > | > > > | > Regards, > > | > > > | > Rudiger > > | > > > | > > > | > | -----Original Message----- > > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > | > | Sent: Wednesday, March 19, 2008 1:35 PM > > | > | To: Geib, R=FCdiger > > | > | Cc: pcn@ietf.org > > | > | Subject: RE: [PCN] Concensus questions from Thursday's PCN = > > | > | meeting > > | > | > > | > | > > | > | Hi Ruediger > > | > | > > | > | It is not a new solution! What I describe are problems that > > | > are in my > > | > | opinion occuring when the PCN domain uses ECMP routing, > > | AND when a > > | > | catastrophic event occurs AND when marked packets are > > | > preferentially > > | > | dropped. > > | > | The only thing that I am trying to say, is PLEASE DO NOT > > | > mandate the > > | > | preferentially dropping of marked packets, such that we > > | can avoid > > | > | such difficult and nasty problems. > > | > | > > | > | I am not proposing here another solution. > > | > | > > | > | > > | > | Best regards, > > | > | Georgios > > | > | > > | > | > -----Original Message----- > > | > | > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > > | > | > Sent: woensdag 19 maart 2008 13:06 > > | > | > To: karagian@cs.utwente.nl > > | > | > Cc: pcn@ietf.org > > | > | > Subject: RE: [PCN] Concensus questions from Thursday's > > | PCN meeting > > | > | > > > | > | > Hi Georgios, > > | > | > > > | > | > with how many operator representatives involved into > > | > | backbone traffic > > | > | > engineering including activation of ECMP did you = > talk prior to = > > | > | > proposing your solution on this mailing list? > > | > | > > > | > | > Regards, > > | > | > > > | > | > Rudiger > > | > | > > > | > | > > > | > | > | -----Original Message----- > > | > | > | From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > | > | > | Sent: Wednesday, March 19, 2008 12:38 PM > > | > | > | To: Geib, R=FCdiger; steven.blake@ericsson.com > > | > | > | Cc: pcn@ietf.org > > | > | > | Subject: RE: [PCN] Concensus questions from Thursday's > > | > PCN meeting > > | > | > | > > | > | > | Hi Rudeiger > > | > | > | > > | > | > | What I am proposing is how to achieve a robust/stable PCN > > | > | operation > > | > | > | when the PCN domain uses ECMP routing and when a > > | > | catastrophic event > > | > | > | occurs. > > | > | > | > > | > | > | Best regards, > > | > | > | Georgios > > | > | > | > > | > | > | > > | > | > | > > | > | > | > > | > | > | > > | > | > | > -----Original Message----- > > | > | > | > From: pcn-bounces@ietf.org = > [mailto:pcn-bounces@ietf.org] = > > | > | > | > On > > | > | > | Behalf Of > > | > | > | > Geib, Ruediger > > | > | > | > Sent: woensdag 19 maart 2008 11:37 > > | > | > | > To: steven.blake@ericsson.com > > | > | > | > Cc: pcn@ietf.org > > | > | > | > Subject: Re: [PCN] Concensus questions from Thursday's > > | > | PCN meeting > > | > | > | > > > | > | > | > Steven, > > | > | > | > > > | > | > | > what Georgios is proposing is to optimise PCN so that > > | > it works > > | > | > | > properly if a catastrophic event coincides with a > > | > misconfigured > > | > | > | > router. > > | > | > | > > > | > | > | > If this is the main or even an important task = > of PCN, then > > | > | > | I waste my > > | > | > | > time here. > > | > | > | > > > | > | > | > The salary I obtain monthly depends on my companies > > | > | > | backbone network > > | > | > | > providing good service to customers under regular > > | operational > > | > | > | > conditions (which cover planned outages and expectable > > | > | > | failures). The > > | > | > | > telephony or streaming services offered to our > > | > customers should > > | > | > | > experience a minimised network impact on the Quality of > > | > | > Experience > > | > | > | > perceived by the consumers under regular operational > > | > | > | conditions. This > > | > | > | > includes the creation of a "Network Busy Indication", = > > | > | > | > which > > | > | > | however is > > | > | > | > a rare event. So my position on what PCN should be > > | > | > | optimised for is to > > | > | > | > create this "network busy indication" for regular > > | operational > > | > | > | > conditions, reliably and only if it is required. > > | > | > | > This should be done with the least possible complexity > > | > | > | (like the least > > | > | > | > possible flow awareness, the least codepoint > > | > | consumption, simple > > | > | > | > queuing/policing and measurement functions, = > utmost re-use > > | > | > | of allready > > | > | > | > implemented features). > > | > | > | > > > | > | > | > To clarify what I mean by a rare event: a well = > engineered > > | > | > backbone > > | > | > | > creating a PCN network busy indication either during a > > | > | > main traffic > > | > | > | > hour or after a re-routing event. During ISDN times, > > | > | engineering > > | > | > | > resulted in what Americans called 5ESS = > switches, aiming on > > | > | > | a network > > | > | > | > busy indication probability of (100 - 99,999%, the 5 > > | > | > nines). We may > > | > | > | > see that a bit more relaxed for IP networks, but I don't > > | > | > think the > > | > | > | > customers of my company should experience the > > | > | consequences of PCN > > | > | > | > behaviour more often than in (100 - 99,x)%. > > | > | > | > > > | > | > | > I don't look at PCN as a replacement of network > > | > | > engineering, it is > > | > | > | > rather an add on to guarantee service quality = > of admitted > > | > | > users by > > | > | > | > stopping admission of new traffic once = > engineering reaches > > | > | > | its limits. > > | > | > | > Under regular operational conditions. > > | > | > | > > > | > | > | > If someone now answers to this mail: uhh, just = > that - easy! > > | > | > | > Then lets move this easy thing to WGLC. Now. I > > | can't see that. > > | > | > | > > > | > | > | > If the PCN WG indeed has completely different aims, then > > | > | > | I'm sorry for > > | > | > | > bothering you with my mails (but I wonder = > whether I'm the > > | > | > | one having > > | > | > | > gotten things wrong). > > | > | > | > > > | > | > | > By the way, I'm happy with the progress visible in the > > | > | > | questions you / > > | > | > | > the WG has formulated. That looks like a constructive > > | > approach. > > | > | > | > > > | > | > | > Regards, > > | > | > | > > > | > | > | > Rudiger > > | > | > | > > > | > | > | > > > | > | > | > > > | > | > | > | -----Original Message----- > > | > | > | > | From: Steven Blake [mailto:steven.blake@ericsson.com] > > | > | > | > | Sent: Tuesday, March 18, 2008 3:19 PM > > | > | > | > | To: Geib, R=FCdiger > > | > | > | > | Cc: pcn@ietf.org > > | > | > | > | Subject: Re: [PCN] Concensus questions from Thursday's > > | > | > PCN meeting > > | > | > | > | > > | > | > | > | On Tue, 2008-03-18 at 08:29 +0100, Geib, = > Ruediger wrote: > > | > | > | > | > > | > | > | > | > Hi Georgios, > > | > | > | > | > > > | > | > | > | > in the situation you describe, packet losses occur. = > > | > | > | > | > This > > | > | > | > | will result > > | > | > | > | > in bad press, as the customers using PCN based = > > | > | > | > | > services > > | > | > | > | were promised > > | > | > | > | > another type of service. > > | > | > | > | > > > | > | > | > | > In this situation it doesn't matter whether or not = > > | > | > | > | > ECMP > > | > | > | > is deployed > > | > | > | > | > and it also doesn't matter whether termination > > | is fair or > > | > | > | > not. The > > | > | > | > | > important event is: packet losses occur (in one of = > > | > | > | > | > your > > | > | > | examples > > | > | > | > | > several routers drop packets). The drops = > are the only > > | > | > | > | relevant issue. > > | > | > | > | > Whether service resumes after 5 seconds due to > > | > | extremly well > > | > | > | > | > engineered termination or after 10 seconds after a > > | > | > | > | sufficient number > > | > | > | > | > of customers hang up is not important. > > | > | > | > | > I can't recall having read anytime in the = > news "Major > > | > | > | > | network outage - > > | > | > | > | > but termination was fair." I can only recall having = > > | > | > | > | > seen > > | > | > | > the first > > | > | > | > | > part. > > | > | > | > | > > > | > | > | > | > I'm sure you're happy in adapting your = > example, as you > > | > | > | do all the > > | > | > | > | > time. I'm having work to do, but maybe = > someone else is > > | > | > | > | interested in > > | > | > | > | > continuing discusion. I think, I've made my point. > > | > | > | > | > > | > | > | > | Ruediger, > > | > | > | > | > > | > | > | > | If I follow this comment to its logical conclusion, > > | > | then PCN is > > | > | > | > | superfluous in this network. Is that what you are > > | > | > trying to say? > > | > | > | > | > > | > | > | > | > > | > | > | > | Regards, > > | > | > | > | > > | > | > | > | = > =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-= =3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D > > | > | > | > | Steven Blake = > > > | > | > | > | Ericsson/Redback Networks +1 = > 919-472-9913 > > | > | > | > | > > | > | > | > | > > | > | > | > _______________________________________________ > > | > | > | > 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 > = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 19 08:19:31 2008 Return-Path: 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 55ABE28C239; Wed, 19 Mar 2008 08:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.462 X-Spam-Level: X-Spam-Status: No, score=-100.462 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 Y288dOOn0ucN; Wed, 19 Mar 2008 08:19:27 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51FE13A6AF7; Wed, 19 Mar 2008 08:19:27 -0700 (PDT) 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 843ED3A693F for ; Wed, 19 Mar 2008 08:19:26 -0700 (PDT) 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 HALEtTzJY0-I for ; Wed, 19 Mar 2008 08:19:19 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id B41D33A6A7F for ; Wed, 19 Mar 2008 08:19:19 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m2JFGkeS017761; Wed, 19 Mar 2008 10:16:46 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Mar 2008 10:16:46 -0500 Received: from [147.117.169.77] ([147.117.169.77]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Mar 2008 10:16:45 -0500 From: Steven Blake To: Georgios Karagiannis In-Reply-To: <004e01c889d1$6d01e4f0$810c5982@dynamic.ewi.utwente.nl> References: <1B6169C658325341A3B8066E23919E1CF64CFA@S4DE8PSAANK.mitte.t-com.de> <75A199C5D243C741BF3D3F1EBCEF9BA503B34667@E03MVZ1-UKDY.domain1.systemhost.net> <004e01c889d1$6d01e4f0$810c5982@dynamic.ewi.utwente.nl> Organization: Ericsson IP Infrastructure Date: Wed, 19 Mar 2008 11:16:42 -0400 Message-Id: <1205939802.3021.9.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) X-OriginalArrivalTime: 19 Mar 2008 15:16:45.0773 (UTC) FILETIME=[3EAE1FD0:01C889D4] Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Georgios, Let me try to paraphrase the scenario you are describing: - There is an ingress-egress aggregate whose traffic is split across multiple paths via ECMP. - Traffic is admitted along this split path. - One (or more) of the paths fails. - One (or more) of the remaining paths becomes severely congested (for example because there is traffic from other ingress-egress aggregates flowing along that path). - Marked packets are preferentially dropped at the severely congested router(s). As a consequence, not enough marked traffic arrives at the egress router to drive the CLE for the ingress-egress aggregate above the threshold needed to trigger a response (termination, say). Does this description accurately capture your scenario? Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 19 08:27:08 2008 Return-Path: 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 5E7BD3A6F2C; Wed, 19 Mar 2008 08:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.299 X-Spam-Level: X-Spam-Status: No, score=-100.299 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 PQn5pvRK2ovo; Wed, 19 Mar 2008 08:27:04 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 788693A6F0D; Wed, 19 Mar 2008 08:27:04 -0700 (PDT) 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 A6CCB3A6EB3 for ; Wed, 19 Mar 2008 08:27:03 -0700 (PDT) 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 M-rNuLr7bDlA for ; Wed, 19 Mar 2008 08:27:02 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 9E5CC3A6DEA for ; Wed, 19 Mar 2008 08:27:02 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m2JFOfFi006762; Wed, 19 Mar 2008 16:24:44 +0100 (MET) From: "Georgios Karagiannis" To: "'Steven Blake'" References: <1B6169C658325341A3B8066E23919E1CF64CFA@S4DE8PSAANK.mitte.t-com.de> <75A199C5D243C741BF3D3F1EBCEF9BA503B34667@E03MVZ1-UKDY.domain1.systemhost.net> <004e01c889d1$6d01e4f0$810c5982@dynamic.ewi.utwente.nl> <1205939802.3021.9.camel@neutrino> Date: Wed, 19 Mar 2008 16:24:37 +0100 Message-ID: <005501c889d5$5acccdf0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <1205939802.3021.9.camel@neutrino> Thread-Index: AciJ1EhataudZp4yRFCCnG657FSEHQAADmEQ X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 19 Mar 2008 16:24:44 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Steven Please see that I have included some information into the last bullet: - There is an ingress-egress aggregate whose traffic is split across multiple paths via ECMP. - Traffic is admitted along this split path. - One (or more) of the paths fails. - One (or more) of the remaining paths becomes severely congested (for example because there is traffic from other ingress-egress aggregates flowing along that path). - <> Marked packets are preferentially dropped at the severely congested router(s). As a consequence, not enough marked traffic arrives at the egress router to drive the CLE for the ingress-egress aggregate above the threshold needed to trigger a response (termination, say). Best regards, Georgios > -----Original Message----- > From: Steven Blake [mailto:steven.blake@ericsson.com] > Sent: woensdag 19 maart 2008 16:17 > To: Georgios Karagiannis > Cc: pcn@ietf.org > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > > Georgios, > > Let me try to paraphrase the scenario you are describing: > > - There is an ingress-egress aggregate whose traffic is split across > multiple paths via ECMP. > - Traffic is admitted along this split path. > - One (or more) of the paths fails. > - One (or more) of the remaining paths becomes severely congested (for > example because there is traffic from other ingress-egress > aggregates > flowing along that path). > - Marked packets are preferentially dropped at the severely congested > router(s). As a consequence, not enough marked traffic > arrives at the > egress router to drive the CLE for the ingress-egress > aggregate above > the threshold needed to trigger a response (termination, say). > > Does this description accurately capture your scenario? > > > Regards, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven Blake > Ericsson/Redback Networks +1 919-472-9913 > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 19 08:45:16 2008 Return-Path: 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 D04AE28C31E; Wed, 19 Mar 2008 08:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.54 X-Spam-Level: X-Spam-Status: No, score=-100.54 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 gTws45zt+hEh; Wed, 19 Mar 2008 08:45:11 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAADD3A6AF7; Wed, 19 Mar 2008 08:45:11 -0700 (PDT) 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 6451F28C215 for ; Wed, 19 Mar 2008 08:45:10 -0700 (PDT) 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 mgf-ajJflChT for ; Wed, 19 Mar 2008 08:45:08 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id CF1213A67D9 for ; Wed, 19 Mar 2008 08:45:07 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m2JFgcDN028893; Wed, 19 Mar 2008 10:42:38 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Mar 2008 10:42:38 -0500 Received: from [147.117.169.77] ([147.117.169.77]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Mar 2008 10:42:38 -0500 From: Steven Blake To: Georgios Karagiannis In-Reply-To: <005501c889d5$5acccdf0$810c5982@dynamic.ewi.utwente.nl> References: <1B6169C658325341A3B8066E23919E1CF64CFA@S4DE8PSAANK.mitte.t-com.de> <75A199C5D243C741BF3D3F1EBCEF9BA503B34667@E03MVZ1-UKDY.domain1.systemhost.net> <004e01c889d1$6d01e4f0$810c5982@dynamic.ewi.utwente.nl> <1205939802.3021.9.camel@neutrino> <005501c889d5$5acccdf0$810c5982@dynamic.ewi.utwente.nl> Organization: Ericsson IP Infrastructure Date: Wed, 19 Mar 2008 11:42:37 -0400 Message-Id: <1205941357.3021.18.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) X-OriginalArrivalTime: 19 Mar 2008 15:42:38.0435 (UTC) FILETIME=[DC238B30:01C889D7] Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org On Wed, 2008-03-19 at 16:24 +0100, Georgios Karagiannis wrote: > Hi Steven > > Please see that I have included some information into the last bullet: > > - There is an ingress-egress aggregate whose traffic is split across > multiple paths via ECMP. > - Traffic is admitted along this split path. > - One (or more) of the paths fails. > - One (or more) of the remaining paths becomes severely congested (for > example because there is traffic from other ingress-egress > aggregates flowing along that path). > - < belonging to > the same ingress-egress-aggregate that will be unmarked.>> Marked packets > are > preferentially dropped at the severely congested > router(s). As a consequence, not enough marked traffic arrives at the > egress router to drive the CLE for the ingress-egress aggregate above > the threshold needed to trigger a response (termination, say). Ok. To be specific, the egressrouter will see some fraction of packets from the severely congested router(s), some of which will be marked, and will see a larger fraction of un-marked packets from the un-pre-congested routers. So let me now ask you this: given N ECMP paths (after a path failure), with one being severely congested and the rest being un-pre-congested, and given a CLE threshold CLE_thresh at the egress router, can you solve for the minimum PCN_lower_threshold value at the severely congested router, where PCN still works (e.g., CLE crosses the threshold), for the two cases where (1) marked packets are preferentially dropped, and (2) marked packets are dropped with equal probability with un-marked packets? Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 19 08:51:53 2008 Return-Path: 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 0D9D03A6F42; Wed, 19 Mar 2008 08:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.303 X-Spam-Level: X-Spam-Status: No, score=-100.303 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 YvoBV2uLCwDX; Wed, 19 Mar 2008 08:51:52 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2790D3A6F31; Wed, 19 Mar 2008 08:51:49 -0700 (PDT) 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 098323A6F31 for ; Wed, 19 Mar 2008 08:51:48 -0700 (PDT) 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 p-KjfQE6WFLb for ; Wed, 19 Mar 2008 08:51:44 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 3D3DC3A68BB for ; Wed, 19 Mar 2008 08:51:36 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m2JFnEuq008517; Wed, 19 Mar 2008 16:49:17 +0100 (MET) From: "Georgios Karagiannis" To: "'Steven Blake'" References: <1B6169C658325341A3B8066E23919E1CF64CFA@S4DE8PSAANK.mitte.t-com.de> <75A199C5D243C741BF3D3F1EBCEF9BA503B34667@E03MVZ1-UKDY.domain1.systemhost.net> <004e01c889d1$6d01e4f0$810c5982@dynamic.ewi.utwente.nl> <1205939802.3021.9.camel@neutrino> <005501c889d5$5acccdf0$810c5982@dynamic.ewi.utwente.nl> <1205941357.3021.18.camel@neutrino> Date: Wed, 19 Mar 2008 16:49:09 +0100 Message-ID: <005a01c889d8$c86e9250$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <1205941357.3021.18.camel@neutrino> Thread-Index: AciJ1+MI5FcT3On/QSSm/yR8ASiixQAAMd5Q X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 19 Mar 2008 16:49:18 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Steven Okay, I will have to spend some time on this! Best regards, Georgios > -----Original Message----- > From: Steven Blake [mailto:steven.blake@ericsson.com] > Sent: woensdag 19 maart 2008 16:43 > To: Georgios Karagiannis > Cc: pcn@ietf.org > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > > On Wed, 2008-03-19 at 16:24 +0100, Georgios Karagiannis wrote: > > > Hi Steven > > > > Please see that I have included some information into the > last bullet: > > > > - There is an ingress-egress aggregate whose traffic is > split across > > multiple paths via ECMP. > > - Traffic is admitted along this split path. > > - One (or more) of the paths fails. > > - One (or more) of the remaining paths becomes severely > congested (for > > example because there is traffic from other ingress-egress > > aggregates flowing along that path). > > - < forward packets > > belonging to > > the same ingress-egress-aggregate that will be unmarked.>> Marked > > packets are > > preferentially dropped at the severely congested > > router(s). As a consequence, not enough marked traffic arrives at > > the egress router to drive the CLE for the ingress-egress aggregate > > above the threshold needed to trigger a response (termination, say). > > Ok. To be specific, the egressrouter will see some fraction > of packets from the severely congested router(s), some of > which will be marked, and will see a larger fraction of > un-marked packets from the un-pre-congested routers. > > So let me now ask you this: given N ECMP paths (after a path > failure), with one being severely congested and the rest > being un-pre-congested, and given a CLE threshold CLE_thresh > at the egress router, can you solve for the minimum > PCN_lower_threshold value at the severely congested router, > where PCN still works (e.g., CLE crosses the threshold), for > the two cases where (1) marked packets are preferentially > dropped, and (2) marked packets are dropped with equal > probability with un-marked packets? > > > > Regards, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven Blake > Ericsson/Redback Networks +1 919-472-9913 > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 19 09:09:35 2008 Return-Path: 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 9FF773A6B98; Wed, 19 Mar 2008 09:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.701 X-Spam-Level: X-Spam-Status: No, score=-100.701 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 Z3q5FsGiXCBk; Wed, 19 Mar 2008 09:09:30 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4A1128C119; Wed, 19 Mar 2008 09:09:30 -0700 (PDT) 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 4B5EE3A69DA for ; Wed, 19 Mar 2008 09:09:29 -0700 (PDT) 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 ln00gLut89jQ for ; Wed, 19 Mar 2008 09:09:27 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 919E43A6D31 for ; Wed, 19 Mar 2008 09:09:23 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Mar 2008 16:07:06 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Mar 2008 16:07:05 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B3466B@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <005a01c889d8$c86e9250$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciJ1+MI5FcT3On/QSSm/yR8ASiixQAAMd5QAACQVrA= From: To: , X-OriginalArrivalTime: 19 Mar 2008 16:07:06.0115 (UTC) FILETIME=[46F1BD30:01C889DB] Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Georgios, I notice you refer to CLE below. Note that for termination the relevant parameter is the Sustainable rate, that is the rate of unmarked pkts (or, if SM being used, this rate is multiplied by the domain-wide parameter U). phil > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Georgios Karagiannis > Sent: 19 March 2008 15:49 > To: 'Steven Blake' > Cc: pcn@ietf.org > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > > Hi Steven > > Okay, I will have to spend some time on this! > > Best regards, > Georgios > > > > -----Original Message----- > > From: Steven Blake [mailto:steven.blake@ericsson.com] > > Sent: woensdag 19 maart 2008 16:43 > > To: Georgios Karagiannis > > Cc: pcn@ietf.org > > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > > > > On Wed, 2008-03-19 at 16:24 +0100, Georgios Karagiannis wrote: > > > > > Hi Steven > > > > > > Please see that I have included some information into the > > last bullet: > > > > > > - There is an ingress-egress aggregate whose traffic is > > split across > > > multiple paths via ECMP. > > > - Traffic is admitted along this split path. > > > - One (or more) of the paths fails. > > > - One (or more) of the remaining paths becomes severely > > congested (for > > > example because there is traffic from other ingress-egress > > > aggregates flowing along that path). > > > - < > forward packets > > > belonging to > > > the same ingress-egress-aggregate that will be unmarked.>> Marked > > > packets are > > > preferentially dropped at the severely congested > > > router(s). As a consequence, not enough marked traffic arrives at > > > the egress router to drive the CLE for the ingress-egress aggregate > > > above the threshold needed to trigger a response (termination, say). > > > > Ok. To be specific, the egressrouter will see some fraction > > of packets from the severely congested router(s), some of > > which will be marked, and will see a larger fraction of > > un-marked packets from the un-pre-congested routers. > > > > So let me now ask you this: given N ECMP paths (after a path > > failure), with one being severely congested and the rest > > being un-pre-congested, and given a CLE threshold CLE_thresh > > at the egress router, can you solve for the minimum > > PCN_lower_threshold value at the severely congested router, > > where PCN still works (e.g., CLE crosses the threshold), for > > the two cases where (1) marked packets are preferentially > > dropped, and (2) marked packets are dropped with equal > > probability with un-marked packets? > > > > > > > > Regards, > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > Steven Blake > > Ericsson/Redback Networks +1 919-472-9913 > > > > > _______________________________________________ > 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 From pcn-bounces@ietf.org Wed Mar 19 09:12:32 2008 Return-Path: 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 566403A6E83; Wed, 19 Mar 2008 09:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.309 X-Spam-Level: X-Spam-Status: No, score=-100.309 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 IeXF+ZtURzsn; Wed, 19 Mar 2008 09:12:31 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 697933A6BE1; Wed, 19 Mar 2008 09:12:31 -0700 (PDT) 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 E53323A6BE1 for ; Wed, 19 Mar 2008 09:12:30 -0700 (PDT) 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 eM4qjKWT+amr for ; Wed, 19 Mar 2008 09:12:30 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id B76E23A69D1 for ; Wed, 19 Mar 2008 09:12:29 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m2JGA7ku010231; Wed, 19 Mar 2008 17:10:10 +0100 (MET) From: "Georgios Karagiannis" To: , References: <005a01c889d8$c86e9250$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B3466B@E03MVZ1-UKDY.domain1.systemhost.net> Date: Wed, 19 Mar 2008 17:10:02 +0100 Message-ID: <006101c889db$b32d6940$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B3466B@E03MVZ1-UKDY.domain1.systemhost.net> Thread-Index: AciJ1+MI5FcT3On/QSSm/yR8ASiixQAAMd5QAACQVrAAACH5oA== X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 19 Mar 2008 17:10:11 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil But in order to trigger the admission control and flow termination, the situation CLE > 1% has to be first triggered. Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: woensdag 19 maart 2008 17:07 > To: karagian@cs.utwente.nl; steven.blake@ericsson.com > Cc: pcn@ietf.org > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > > Georgios, > > I notice you refer to CLE below. Note that for termination > the relevant parameter is the Sustainable rate, that is the > rate of unmarked pkts (or, if SM being used, this rate is > multiplied by the domain-wide parameter U). > > phil > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of > > Georgios Karagiannis > > Sent: 19 March 2008 15:49 > > To: 'Steven Blake' > > Cc: pcn@ietf.org > > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > > > > Hi Steven > > > > Okay, I will have to spend some time on this! > > > > Best regards, > > Georgios > > > > > > > -----Original Message----- > > > From: Steven Blake [mailto:steven.blake@ericsson.com] > > > Sent: woensdag 19 maart 2008 16:43 > > > To: Georgios Karagiannis > > > Cc: pcn@ietf.org > > > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > > > > > > On Wed, 2008-03-19 at 16:24 +0100, Georgios Karagiannis wrote: > > > > > > > Hi Steven > > > > > > > > Please see that I have included some information into the > > > last bullet: > > > > > > > > - There is an ingress-egress aggregate whose traffic is > > > split across > > > > multiple paths via ECMP. > > > > - Traffic is admitted along this split path. > > > > - One (or more) of the paths fails. > > > > - One (or more) of the remaining paths becomes severely > > > congested (for > > > > example because there is traffic from other ingress-egress > > > > aggregates flowing along that path). > > > > - < > > forward packets > > > > belonging to > > > > the same ingress-egress-aggregate that will be unmarked.>> > Marked > > > > packets are > > > > preferentially dropped at the severely congested > > > > router(s). As a consequence, not enough marked traffic arrives > at > > > > the egress router to drive the CLE for the ingress-egress > aggregate > > > > above the threshold needed to trigger a response (termination, > say). > > > > > > Ok. To be specific, the egressrouter will see some fraction of > > > packets from the severely congested router(s), some of > which will be > > > marked, and will see a larger fraction of un-marked > packets from the > > > un-pre-congested routers. > > > > > > So let me now ask you this: given N ECMP paths (after a path > > > failure), with one being severely congested and the rest being > > > un-pre-congested, and given a CLE threshold CLE_thresh at > the egress > > > router, can you solve for the minimum PCN_lower_threshold > value at > > > the severely congested router, where PCN still works (e.g., CLE > > > crosses the threshold), for the two cases where (1) > marked packets > > > are preferentially dropped, and (2) marked packets are > dropped with > > > equal probability with un-marked packets? > > > > > > > > > > > > Regards, > > > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > Steven Blake > > > Ericsson/Redback Networks +1 919-472-9913 > > > > > > > > > _______________________________________________ > > 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 From pcn-bounces@ietf.org Wed Mar 19 09:18:13 2008 Return-Path: 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 AE9793A6E99; Wed, 19 Mar 2008 09:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.363 X-Spam-Level: X-Spam-Status: No, score=-100.363 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 roGXI2rVnrTU; Wed, 19 Mar 2008 09:18:09 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3D423A6F2B; Wed, 19 Mar 2008 09:18:09 -0700 (PDT) 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 004283A6F16 for ; Wed, 19 Mar 2008 09:18:09 -0700 (PDT) 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 Uy4QhUEWZHKx for ; Wed, 19 Mar 2008 09:18:08 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id A8A833A6D31 for ; Wed, 19 Mar 2008 09:18:07 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Mar 2008 16:15:49 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Mar 2008 16:15:48 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B3466C@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <006101c889db$b32d6940$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciJ1+MI5FcT3On/QSSm/yR8ASiixQAAMd5QAACQVrAAACH5oAAAModg From: To: , X-OriginalArrivalTime: 19 Mar 2008 16:15:49.0986 (UTC) FILETIME=[7F321C20:01C889DC] Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Ok - you'd forgotten to remind us of that! Note that you're making the assumption of SM [for CL (is excess rate marking just for termination) the requirement is to see one mark.] > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: 19 March 2008 16:10 > To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com > Cc: pcn@ietf.org > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > > Hi Phil > > But in order to trigger the admission control and flow termination, > the situation CLE > 1% has to be first triggered. > > Best regards, > Georgios > > > > -----Original Message----- > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > Sent: woensdag 19 maart 2008 17:07 > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com > > Cc: pcn@ietf.org > > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > > > > Georgios, > > > > I notice you refer to CLE below. Note that for termination > > the relevant parameter is the Sustainable rate, that is the > > rate of unmarked pkts (or, if SM being used, this rate is > > multiplied by the domain-wide parameter U). > > > > phil > > > > > -----Original Message----- > > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > > Behalf Of > > > Georgios Karagiannis > > > Sent: 19 March 2008 15:49 > > > To: 'Steven Blake' > > > Cc: pcn@ietf.org > > > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > > > > > > Hi Steven > > > > > > Okay, I will have to spend some time on this! > > > > > > Best regards, > > > Georgios > > > > > > > > > > -----Original Message----- > > > > From: Steven Blake [mailto:steven.blake@ericsson.com] > > > > Sent: woensdag 19 maart 2008 16:43 > > > > To: Georgios Karagiannis > > > > Cc: pcn@ietf.org > > > > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > > > > > > > > On Wed, 2008-03-19 at 16:24 +0100, Georgios Karagiannis wrote: > > > > > > > > > Hi Steven > > > > > > > > > > Please see that I have included some information into the > > > > last bullet: > > > > > > > > > > - There is an ingress-egress aggregate whose traffic is > > > > split across > > > > > multiple paths via ECMP. > > > > > - Traffic is admitted along this split path. > > > > > - One (or more) of the paths fails. > > > > > - One (or more) of the remaining paths becomes severely > > > > congested (for > > > > > example because there is traffic from other ingress-egress > > > > > aggregates flowing along that path). > > > > > - < > > > forward packets > > > > > belonging to > > > > > the same ingress-egress-aggregate that will be unmarked.>> > > Marked > > > > > packets are > > > > > preferentially dropped at the severely congested > > > > > router(s). As a consequence, not enough marked traffic arrives > > at > > > > > the egress router to drive the CLE for the ingress-egress > > aggregate > > > > > above the threshold needed to trigger a response (termination, > > say). > > > > > > > > Ok. To be specific, the egressrouter will see some fraction of > > > > packets from the severely congested router(s), some of > > which will be > > > > marked, and will see a larger fraction of un-marked > > packets from the > > > > un-pre-congested routers. > > > > > > > > So let me now ask you this: given N ECMP paths (after a path > > > > failure), with one being severely congested and the rest being > > > > un-pre-congested, and given a CLE threshold CLE_thresh at > > the egress > > > > router, can you solve for the minimum PCN_lower_threshold > > value at > > > > the severely congested router, where PCN still works (e.g., CLE > > > > crosses the threshold), for the two cases where (1) > > marked packets > > > > are preferentially dropped, and (2) marked packets are > > dropped with > > > > equal probability with un-marked packets? > > > > > > > > > > > > > > > > Regards, > > > > > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > > Steven Blake > > > > Ericsson/Redback Networks +1 919-472-9913 > > > > > > > > > > > > > _______________________________________________ > > > 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 From pcn-bounces@ietf.org Wed Mar 19 09:22:08 2008 Return-Path: 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 3920A28C4BD; Wed, 19 Mar 2008 09:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.418 X-Spam-Level: X-Spam-Status: No, score=-101.418 tagged_above=-999 required=5 tests=[AWL=-1.581, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 GTzoLSe6VLkR; Wed, 19 Mar 2008 09:22:07 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ED353A6EDC; Wed, 19 Mar 2008 09:22:07 -0700 (PDT) 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 EBC1D3A6A96 for ; Wed, 19 Mar 2008 09:22:05 -0700 (PDT) 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 sRdngAVFjQju for ; Wed, 19 Mar 2008 09:22:04 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id E0D6828C330 for ; Wed, 19 Mar 2008 09:22:02 -0700 (PDT) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Mar 2008 16:19:45 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Mar 2008 16:19:46 -0000 Message-ID: In-Reply-To: <006101c889db$b32d6940$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciJ1+MI5FcT3On/QSSm/yR8ASiixQAAMd5QAACQVrAAACH5oAAAN3bw From: To: , , X-OriginalArrivalTime: 19 Mar 2008 16:19:45.0868 (UTC) FILETIME=[0BCAD8C0:01C889DD] Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Georgios, Just trying to get my head round this scenario a bit better. I take it you are envisaging the severely congested path having several points of congestion so that at some routers early on the path packets are being marked and at some point later on the path some packets are then having to be dropped? I have always sort of assumed (quite possibly wrongly) that the point at which routers are so congested they need to be doing preferential drop is significantly above the termination threshold and thus even with the drop there should still be a strong enough termination signal reaching the egress... Toby > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Georgios Karagiannis > Sent: 19 March 2008 16:10 > To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com > Cc: pcn@ietf.org > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > > Hi Phil > > But in order to trigger the admission control and flow termination, > the situation CLE > 1% has to be first triggered. > > Best regards, > Georgios > > > > -----Original Message----- > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > Sent: woensdag 19 maart 2008 17:07 > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com > > Cc: pcn@ietf.org > > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > > > > Georgios, > > > > I notice you refer to CLE below. Note that for termination > > the relevant parameter is the Sustainable rate, that is the > > rate of unmarked pkts (or, if SM being used, this rate is > > multiplied by the domain-wide parameter U). > > > > phil > > > > > -----Original Message----- > > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > > Behalf Of > > > Georgios Karagiannis > > > Sent: 19 March 2008 15:49 > > > To: 'Steven Blake' > > > Cc: pcn@ietf.org > > > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > > > > > > Hi Steven > > > > > > Okay, I will have to spend some time on this! > > > > > > Best regards, > > > Georgios > > > > > > > > > > -----Original Message----- > > > > From: Steven Blake [mailto:steven.blake@ericsson.com] > > > > Sent: woensdag 19 maart 2008 16:43 > > > > To: Georgios Karagiannis > > > > Cc: pcn@ietf.org > > > > Subject: RE: [PCN] Concensus questions from Thursday's > PCN meeting > > > > > > > > On Wed, 2008-03-19 at 16:24 +0100, Georgios Karagiannis wrote: > > > > > > > > > Hi Steven > > > > > > > > > > Please see that I have included some information into the > > > > last bullet: > > > > > > > > > > - There is an ingress-egress aggregate whose traffic is > > > > split across > > > > > multiple paths via ECMP. > > > > > - Traffic is admitted along this split path. > > > > > - One (or more) of the paths fails. > > > > > - One (or more) of the remaining paths becomes severely > > > > congested (for > > > > > example because there is traffic from other ingress-egress > > > > > aggregates flowing along that path). > > > > > - < > > > forward packets > > > > > belonging to > > > > > the same ingress-egress-aggregate that will be unmarked.>> > > Marked > > > > > packets are > > > > > preferentially dropped at the severely congested > > > > > router(s). As a consequence, not enough marked > traffic arrives > > at > > > > > the egress router to drive the CLE for the ingress-egress > > aggregate > > > > > above the threshold needed to trigger a response (termination, > > say). > > > > > > > > Ok. To be specific, the egressrouter will see some > fraction of > > > > packets from the severely congested router(s), some of > > which will be > > > > marked, and will see a larger fraction of un-marked > > packets from the > > > > un-pre-congested routers. > > > > > > > > So let me now ask you this: given N ECMP paths (after a path > > > > failure), with one being severely congested and the rest being > > > > un-pre-congested, and given a CLE threshold CLE_thresh at > > the egress > > > > router, can you solve for the minimum PCN_lower_threshold > > value at > > > > the severely congested router, where PCN still works (e.g., CLE > > > > crosses the threshold), for the two cases where (1) > > marked packets > > > > are preferentially dropped, and (2) marked packets are > > dropped with > > > > equal probability with un-marked packets? > > > > > > > > > > > > > > > > Regards, > > > > > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > > Steven Blake > > > > Ericsson/Redback Networks +1 919-472-9913 > > > > > > > > > > > > > _______________________________________________ > > > 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 > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 19 09:45:18 2008 Return-Path: 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 8A15628C54C; Wed, 19 Mar 2008 09:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.083 X-Spam-Level: X-Spam-Status: No, score=-100.083 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 1q87bF6FKoMG; Wed, 19 Mar 2008 09:45:17 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3D9428C5C3; Wed, 19 Mar 2008 09:45:14 -0700 (PDT) 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 41D0228C4EF for ; Wed, 19 Mar 2008 09:45:13 -0700 (PDT) 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 C-D8K0LMLD6H for ; Wed, 19 Mar 2008 09:45:11 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 93E6628C652 for ; Wed, 19 Mar 2008 09:45:09 -0700 (PDT) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 19 Mar 2008 09:42:52 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m2JGgqqO001693; Wed, 19 Mar 2008 09:42:52 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id m2JGgqLX029059; Wed, 19 Mar 2008 16:42:52 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Mar 2008 12:42:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Mar 2008 12:42:50 -0400 Message-ID: In-Reply-To: <005501c889d5$5acccdf0$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciJ1EhataudZp4yRFCCnG657FSEHQAADmEQAALarNA= From: "Anna Charny (acharny)" To: "Georgios Karagiannis" , "Steven Blake" X-OriginalArrivalTime: 19 Mar 2008 16:42:51.0868 (UTC) FILETIME=[45E9A9C0:01C889E0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3061; t=1205944972; x=1206808972; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20(acharny)=22=20 |Subject:=20RE=3A=20[PCN]=20Concensus=20questions=20from=20 Thursday's=20PCN=20meeting |Sender:=20; bh=MkaMSo+VVcH6Ido+qNVxJIOt/N/HUYY/0BIX9jQFtCo=; b=uD4J8rLLQ1LQcht5WmDHeOXN63bQjPZazGQNJfRFgRnsf9s2aQpJVFH1MA 3APAS2M6a+AWdx1F7fe8W4BPamRelBBTkBKGkaABTzFoUI0ndSSjwEVe8P3I k37o+NjyBkrH/HbSkXeFoBWH4+NSASTtXDKeQQKQAZWhEDl4HXPVE=; Authentication-Results: sj-dkim-1; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Georgios, Please see below: > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Georgios Karagiannis > Sent: Wednesday, March 19, 2008 11:25 AM > To: 'Steven Blake' > Cc: pcn@ietf.org > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > > Hi Steven > > Please see that I have included some information into the last bullet: > > - There is an ingress-egress aggregate whose traffic is split > across multiple paths via ECMP. > - Traffic is admitted along this split path. > - One (or more) of the paths fails. > - One (or more) of the remaining paths becomes severely > congested (for > example because there is traffic from other ingress-egress > aggregates flowing along that path). > - < packets belonging to > the same ingress-egress-aggregate that will be unmarked.>> But these rerouted and previously unmarked packets will be marked on the congested interface, would they not? Anna > Marked packets are > preferentially dropped at the severely congested > router(s). As a consequence, not enough marked traffic > arrives at the egress router to drive the CLE for the > ingress-egress aggregate above the threshold needed to > trigger a response (termination, say). > > > Best regards, > Georgios > > > > > > > -----Original Message----- > > From: Steven Blake [mailto:steven.blake@ericsson.com] > > Sent: woensdag 19 maart 2008 16:17 > > To: Georgios Karagiannis > > Cc: pcn@ietf.org > > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > > > > Georgios, > > > > Let me try to paraphrase the scenario you are describing: > > > > - There is an ingress-egress aggregate whose traffic is split across > > multiple paths via ECMP. > > - Traffic is admitted along this split path. > > - One (or more) of the paths fails. > > - One (or more) of the remaining paths becomes severely > congested (for > > example because there is traffic from other ingress-egress > > aggregates > > flowing along that path). > > - Marked packets are preferentially dropped at the severely > congested > > router(s). As a consequence, not enough marked traffic > arrives at > > the > > egress router to drive the CLE for the ingress-egress aggregate > > above > > the threshold needed to trigger a response (termination, say). > > > > Does this description accurately capture your scenario? > > > > > > Regards, > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > Steven Blake > > Ericsson/Redback Networks +1 919-472-9913 > > > > > _______________________________________________ > 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 From pcn-bounces@ietf.org Wed Mar 19 13:35:54 2008 Return-Path: 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 015B728C615; Wed, 19 Mar 2008 13:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.429 X-Spam-Level: X-Spam-Status: No, score=-100.429 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 fd-dCD8q6jcq; Wed, 19 Mar 2008 13:35:52 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B04228C260; Wed, 19 Mar 2008 13:35:51 -0700 (PDT) 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 1F60528C215 for ; Wed, 19 Mar 2008 13:35:51 -0700 (PDT) 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 RKVpNg8v1eyi for ; Wed, 19 Mar 2008 13:35:49 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1744E28C260 for ; Wed, 19 Mar 2008 13:35:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,526,1199682000"; d="scan'208";a="2313281" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 19 Mar 2008 16:33:24 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m2JKXOLp014553; Wed, 19 Mar 2008 16:33:24 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m2JKXO8o009596; Wed, 19 Mar 2008 20:33:24 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Mar 2008 16:33:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Mar 2008 16:33:22 -0400 Message-ID: In-Reply-To: <006101c889db$b32d6940$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciJ1+MI5FcT3On/QSSm/yR8ASiixQAAMd5QAACQVrAAACH5oAACZnhQ From: "Anna Charny (acharny)" To: "Georgios Karagiannis" , , X-OriginalArrivalTime: 19 Mar 2008 20:33:24.0027 (UTC) FILETIME=[7A85A0B0:01C88A00] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9138; t=1205958804; x=1206822804; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20(acharny)=22=20 |Subject:=20RE=3A=20[PCN]=20Concensus=20questions=20from=20 Thursday's=20PCN=20meeting |Sender:=20 |To:=20=22Georgios=20Karagiannis=22=20,=20,=0A=20=20=20=20=20=20=20=20; bh=wvvXTiFD36QZ4tJ1vnqCqmKuaLHmZ0NKPEsVn5A1GYc=; b=h4+xgP/T2G1ozVyko/4xbSr2z8EE/jBkCkaWfhTpIECRV85PXElcTA1OSu XWdGa4hzuzSMz4d5evay+eYsmbba6PuNC+IroFWclICQww+HBgmOFpiej2ML aXf/id+Ipd; Authentication-Results: rtp-dkim-2; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Georgios, I must confess that I do not really see the examples you are presenting as arguments for having (or for that matter not having) preferential drop that I can understand. While I may certainly be missing the points you are making, I want to point out that quite regardless of all these examples, if all you are trying to achieve is that the standard does not force a particular preferential drop policy, I believe the current proposal already does that, as it has a SHOULD, not a MUST in the preferential drop clause. So perhaps that means that this does not need to be argued so intensely? On the examples themselves, I also reread your recent emails (and assuming I understand correctly which of the multiple examples you actually are referring to in your exchange with Steve and Phil), I realized that the problem you are referring to may have nothing to do with dropping marked or unmarked packets. It has simply to do with a well-recognized problem of dilution of marking signal received by the egress in the case when traffic of a given on any particular ECMP path is drastically smaller than the combined traffic of this IEA on other (uncongested) ECMP paths. Let us consider what seems to be a rather aggressive example. Let us assume that we have a bottleneck link, and - for the moment- assume it is the only bottleneck in the network, so in fact there is no marking occurring anywhere but on this link. Just using this assumption to demonstrate that marking preference is irrelevant for the problem you seem to be referring to. Suppose now you have an IEA on this link and you have other ECMP paths shared by this aggregate. Let us assume that the total amount of traffic of this IEA on the link of interest is K. Suppose now that the total traffic on the IEA aggregate is M*K, and assume that M is large. I doubt it will ever be more than 16 - so let us take 16 for the moment. Assume now that the link in question has a very high overload. I would assume is 5X overload is quite large (Rudiger I am sure will agree :)), so let us just take 5. That means that approximately 80% of traffic of this IEA is dropped at the input, so we end up having only 0.2K actually leaving this link. Now assume that the admission threshold is set to 80% of your link (picking a high value to make things worse). And assume we are running SM - or LC-PCN (or whatever other alg that uses excess marking). Now that means that ~20% of our remaining traffic of the IEA aggregate gets marked. The egress now sees: 0.2*0.2K=0.04K of marked traffic and (M-1)K+0.2*0.8K unmarked traffic. The CLE now is now ~0.04K/15K~0.002. If you need a larger CLE than that, then neither SM, nor, for that matter, LC-PCN, would trigger admission stop on that aggregate (without probing added). As it happens, the CLE setting with which the vast majority of SM simulations were done was actually 0.001 (less than the above) - so in fact for this particular set of the parameters (even though I think quite aggressive) this would not actually cause SM a problem. But obviously if you increase either M to be greater than 16 or the overload on the link to be even greater than 5 times the links capacity, you may indeed get into the situation when the actual amount of marked traffic that gets through to the egress is small compared to the total rate of other uncongested ECMP paths for this aggregate. While I personally believe that the parameters I chose are probably overly conservative and in practice things will look dramatically better - nevertheless in principle this problem does in fact exist in theory. In for sufficiently large overloads and ratio M this problem theoretically exists even for threshold marking - although you would need even more aggressive parameters to see the problem then. The point however is that all of this seems to have little to do with what you prefer to drop. In particular, in the example above there were no packets at all that were marked before the bottleneck. The same example will remain even if in fact some packets were previously marked, and all of them were dropped at the entry to the bottleneck. What matters is what percentage of the traffic gets through the tightest bottleneck and how much of it gets marked at *this* bottleneck. So I just can't get why all of these examples show the point about preferential drop you are trying to make... Anna > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Georgios Karagiannis > Sent: Wednesday, March 19, 2008 12:10 PM > To: philip.eardley@bt.com; steven.blake@ericsson.com > Cc: pcn@ietf.org > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > > Hi Phil > > But in order to trigger the admission control and flow > termination, the situation CLE > 1% has to be first triggered. > > Best regards, > Georgios > > > > -----Original Message----- > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > Sent: woensdag 19 maart 2008 17:07 > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com > > Cc: pcn@ietf.org > > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > > > > Georgios, > > > > I notice you refer to CLE below. Note that for termination the > > relevant parameter is the Sustainable rate, that is the rate of > > unmarked pkts (or, if SM being used, this rate is multiplied by the > > domain-wide parameter U). > > > > phil > > > > > -----Original Message----- > > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > > Behalf Of > > > Georgios Karagiannis > > > Sent: 19 March 2008 15:49 > > > To: 'Steven Blake' > > > Cc: pcn@ietf.org > > > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > > > > > > Hi Steven > > > > > > Okay, I will have to spend some time on this! > > > > > > Best regards, > > > Georgios > > > > > > > > > > -----Original Message----- > > > > From: Steven Blake [mailto:steven.blake@ericsson.com] > > > > Sent: woensdag 19 maart 2008 16:43 > > > > To: Georgios Karagiannis > > > > Cc: pcn@ietf.org > > > > Subject: RE: [PCN] Concensus questions from Thursday's > PCN meeting > > > > > > > > On Wed, 2008-03-19 at 16:24 +0100, Georgios Karagiannis wrote: > > > > > > > > > Hi Steven > > > > > > > > > > Please see that I have included some information into the > > > > last bullet: > > > > > > > > > > - There is an ingress-egress aggregate whose traffic is > > > > split across > > > > > multiple paths via ECMP. > > > > > - Traffic is admitted along this split path. > > > > > - One (or more) of the paths fails. > > > > > - One (or more) of the remaining paths becomes severely > > > > congested (for > > > > > example because there is traffic from other ingress-egress > > > > > aggregates flowing along that path). > > > > > - < > > > forward packets > > > > > belonging to > > > > > the same ingress-egress-aggregate that will be unmarked.>> > > Marked > > > > > packets are > > > > > preferentially dropped at the severely congested > > > > > router(s). As a consequence, not enough marked > traffic arrives > > at > > > > > the egress router to drive the CLE for the ingress-egress > > aggregate > > > > > above the threshold needed to trigger a response (termination, > > say). > > > > > > > > Ok. To be specific, the egressrouter will see some > fraction of > > > > packets from the severely congested router(s), some of > > which will be > > > > marked, and will see a larger fraction of un-marked > > packets from the > > > > un-pre-congested routers. > > > > > > > > So let me now ask you this: given N ECMP paths (after a path > > > > failure), with one being severely congested and the rest being > > > > un-pre-congested, and given a CLE threshold CLE_thresh at > > the egress > > > > router, can you solve for the minimum PCN_lower_threshold > > value at > > > > the severely congested router, where PCN still works (e.g., CLE > > > > crosses the threshold), for the two cases where (1) > > marked packets > > > > are preferentially dropped, and (2) marked packets are > > dropped with > > > > equal probability with un-marked packets? > > > > > > > > > > > > > > > > Regards, > > > > > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > > Steven Blake > > > > Ericsson/Redback Networks +1 919-472-9913 > > > > > > > > > > > > > _______________________________________________ > > > 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 > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 19 23:08:07 2008 Return-Path: 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 DB6CA28C332; Wed, 19 Mar 2008 23:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.693 X-Spam-Level: X-Spam-Status: No, score=-99.693 tagged_above=-999 required=5 tests=[AWL=-1.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_BL_SPAMCOP_NET=1.96, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 e-MfJO1yxToX; Wed, 19 Mar 2008 23:08:07 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0721428C363; Wed, 19 Mar 2008 23:08:07 -0700 (PDT) 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 80CC228C221 for ; Wed, 19 Mar 2008 23:08:06 -0700 (PDT) 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 rhsiVzlnD8nr for ; Wed, 19 Mar 2008 23:08:05 -0700 (PDT) Received: from smtp-6-97.vip.sina.com (smtp.vip.sina.com [202.108.3.172]) by core3.amsl.com (Postfix) with ESMTP id 03C7428C3F4 for ; Wed, 19 Mar 2008 23:08:03 -0700 (PDT) Received: from ibmPC (unknown [211.160.21.17]) by smtp-6-97.vip.sina.com (SINAMAIL) with ESMTP id BBC7D1DD725; Thu, 20 Mar 2008 14:05:42 +0800 (CST) Message-ID: From: "Wei Gengyu" To: "Anna Charny \(acharny\)" , "Georgios Karagiannis" , , References: In-Reply-To: Date: Thu, 20 Mar 2008 14:05:28 +0800 Organization: BUPT MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.5840.16384 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.5840.16384 Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi, all, No matter what you want to express, the explanation of your assumed model is incorrect. Also, see comments inline. Gengyu ----- Original Message ----- From: "Anna Charny (acharny)" To: "Georgios Karagiannis" ; ; Cc: Sent: Thursday, March 20, 2008 4:33 AM Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > Hi Georgios, > > Assume now that the link in question has a very high overload. I would > assume is 5X overload is quite large (Rudiger I am sure will agree :)), > so let us just take 5. That means that approximately 80% of traffic of > this IEA is dropped at the input, so we end up having only 0.2K actually > leaving this link. It is wrong. You can not get 0.2K ACTUALLY! And because of this, the following calculation is inredible. > > Now assume that the admission threshold is set to 80% of your link > (picking a high value to make things worse). And assume we are running > SM - or LC-PCN (or whatever other alg that uses excess marking). Now > that means that ~20% of our remaining traffic of the IEA aggregate gets > marked. The egress now sees: 0.2*0.2K=0.04K of marked traffic and > (M-1)K+0.2*0.8K unmarked traffic. The CLE now is now ~0.04K/15K~0.002. > If you need a larger CLE than that, then neither SM, nor, for that > matter, LC-PCN, would trigger admission stop on that aggregate (without > probing added). > > > Anna > Strongly suggest people refer to textbook about throughput performance of congested node. The throughput of the congested will be different in case the input is 5*X and 16*X. Gengyu _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Mar 20 02:03:10 2008 Return-Path: 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 603D03A6F01; Thu, 20 Mar 2008 02:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.32 X-Spam-Level: X-Spam-Status: No, score=-100.32 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 yUftIEH2pwRW; Thu, 20 Mar 2008 02:03:09 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FEC13A6F25; Thu, 20 Mar 2008 02:03:09 -0700 (PDT) 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 C6F3428C165 for ; Thu, 20 Mar 2008 02:03:06 -0700 (PDT) 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 IIP5kcuYHNV1 for ; Thu, 20 Mar 2008 02:03:02 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 66CA73A6B97 for ; Thu, 20 Mar 2008 02:03:01 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m2K90Bb4011540; Thu, 20 Mar 2008 10:00:17 +0100 (MET) From: "Georgios Karagiannis" To: "'Anna Charny \(acharny\)'" , "'Steven Blake'" References: <005501c889d5$5acccdf0$810c5982@dynamic.ewi.utwente.nl> Date: Thu, 20 Mar 2008 10:00:07 +0100 Message-ID: <000901c88a68$ceb6fdb0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AciJ1EhataudZp4yRFCCnG657FSEHQAADmEQAALarNAAIigacA== X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 20 Mar 2008 10:00:17 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Anna Please see in line! > -----Original Message----- > From: Anna Charny (acharny) [mailto:acharny@cisco.com] > Sent: woensdag 19 maart 2008 17:43 > To: Georgios Karagiannis; Steven Blake > Cc: pcn@ietf.org > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > > Georgios, > > Please see below: > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of > > Georgios Karagiannis > > Sent: Wednesday, March 19, 2008 11:25 AM > > To: 'Steven Blake' > > Cc: pcn@ietf.org > > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > > > > Hi Steven > > > > Please see that I have included some information into the > last bullet: > > > > - There is an ingress-egress aggregate whose traffic is > split across > > multiple paths via ECMP. > > - Traffic is admitted along this split path. > > - One (or more) of the paths fails. > > - One (or more) of the remaining paths becomes severely congested > > (for > > example because there is traffic from other ingress-egress > > aggregates flowing along that path). > > - < forward packets > > belonging to > > the same ingress-egress-aggregate that will be unmarked.>> > > But these rerouted and previously unmarked packets will be > marked on the congested interface, would they not? Georgios: If they are not passing throug the severely congested node, they will not be marked! Best regards, Georgios > > Anna > > > Marked packets are > > preferentially dropped at the severely congested > > router(s). As a consequence, not enough marked traffic arrives at > > the egress router to drive the CLE for the ingress-egress aggregate > > above the threshold needed to trigger a response (termination, say). > > > > > > Best regards, > > Georgios > > > > > > > > > > > > > -----Original Message----- > > > From: Steven Blake [mailto:steven.blake@ericsson.com] > > > Sent: woensdag 19 maart 2008 16:17 > > > To: Georgios Karagiannis > > > Cc: pcn@ietf.org > > > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > > > > > > Georgios, > > > > > > Let me try to paraphrase the scenario you are describing: > > > > > > - There is an ingress-egress aggregate whose traffic is > split across > > > multiple paths via ECMP. > > > - Traffic is admitted along this split path. > > > - One (or more) of the paths fails. > > > - One (or more) of the remaining paths becomes severely > > congested (for > > > example because there is traffic from other ingress-egress > > > aggregates > > > flowing along that path). > > > - Marked packets are preferentially dropped at the severely > > congested > > > router(s). As a consequence, not enough marked traffic > > arrives at > > > the > > > egress router to drive the CLE for the ingress-egress aggregate > > > above > > > the threshold needed to trigger a response (termination, say). > > > > > > Does this description accurately capture your scenario? > > > > > > > > > Regards, > > > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > Steven Blake > > > Ericsson/Redback Networks +1 919-472-9913 > > > > > > > > > _______________________________________________ > > 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 From pcn-bounces@ietf.org Thu Mar 20 02:46:51 2008 Return-Path: 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 28D4028C2B0; Thu, 20 Mar 2008 02:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.023 X-Spam-Level: X-Spam-Status: No, score=-100.023 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_72=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 nUCvM4FmhXVC; Thu, 20 Mar 2008 02:46:50 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E29028C28C; Thu, 20 Mar 2008 02:46:50 -0700 (PDT) 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 7648828C25B for ; Thu, 20 Mar 2008 02:46:49 -0700 (PDT) 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 9yKF57QQywSD for ; Thu, 20 Mar 2008 02:46:46 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 76B5A28C28C for ; Thu, 20 Mar 2008 02:46:46 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m2K9aQxh014048; Thu, 20 Mar 2008 10:36:34 +0100 (MET) From: "Georgios Karagiannis" To: , References: <006101c889db$b32d6940$810c5982@dynamic.ewi.utwente.nl> <75A199C5D243C741BF3D3F1EBCEF9BA503B3466C@E03MVZ1-UKDY.domain1.systemhost.net> Date: Thu, 20 Mar 2008 10:36:21 +0100 Message-ID: <000a01c88a6d$e104b6b0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B3466C@E03MVZ1-UKDY.domain1.systemhost.net> Thread-Index: AciJ1+MI5FcT3On/QSSm/yR8ASiixQAAMd5QAACQVrAAACH5oAAAModgACRdWnA= X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 20 Mar 2008 10:36:34 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil Indeed I am refering to SM! Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: woensdag 19 maart 2008 17:16 > To: karagian@cs.utwente.nl; steven.blake@ericsson.com > Cc: pcn@ietf.org > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > > Ok - you'd forgotten to remind us of that! > Note that you're making the assumption of SM [for CL (is > excess rate marking just for termination) the requirement is > to see one mark.] > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: 19 March 2008 16:10 > > To: Eardley,PL,Philip,CXR9 R; steven.blake@ericsson.com > > Cc: pcn@ietf.org > > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > > > > Hi Phil > > > > But in order to trigger the admission control and flow termination, > > the situation CLE > 1% has to be first triggered. > > > > Best regards, > > Georgios > > > > > > > -----Original Message----- > > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > > Sent: woensdag 19 maart 2008 17:07 > > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com > > > Cc: pcn@ietf.org > > > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > > > > > > Georgios, > > > > > > I notice you refer to CLE below. Note that for termination the > > > relevant parameter is the Sustainable rate, that is the rate of > > > unmarked pkts (or, if SM being used, this rate is > multiplied by the > > > domain-wide parameter U). > > > > > > phil > > > > > > > -----Original Message----- > > > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > > > Behalf Of > > > > Georgios Karagiannis > > > > Sent: 19 March 2008 15:49 > > > > To: 'Steven Blake' > > > > Cc: pcn@ietf.org > > > > Subject: Re: [PCN] Concensus questions from Thursday's > PCN meeting > > > > > > > > Hi Steven > > > > > > > > Okay, I will have to spend some time on this! > > > > > > > > Best regards, > > > > Georgios > > > > > > > > > > > > > -----Original Message----- > > > > > From: Steven Blake [mailto:steven.blake@ericsson.com] > > > > > Sent: woensdag 19 maart 2008 16:43 > > > > > To: Georgios Karagiannis > > > > > Cc: pcn@ietf.org > > > > > Subject: RE: [PCN] Concensus questions from Thursday's PCN > meeting > > > > > > > > > > On Wed, 2008-03-19 at 16:24 +0100, Georgios Karagiannis wrote: > > > > > > > > > > > Hi Steven > > > > > > > > > > > > Please see that I have included some information into the > > > > > last bullet: > > > > > > > > > > > > - There is an ingress-egress aggregate whose traffic is > > > > > split across > > > > > > multiple paths via ECMP. > > > > > > - Traffic is admitted along this split path. > > > > > > - One (or more) of the paths fails. > > > > > > - One (or more) of the remaining paths becomes severely > > > > > congested (for > > > > > > example because there is traffic from other > ingress-egress > > > > > > aggregates flowing along that path). > > > > > > - < > > > > forward packets > > > > > > belonging to > > > > > > the same ingress-egress-aggregate that will be unmarked.>> > > > Marked > > > > > > packets are > > > > > > preferentially dropped at the severely congested > > > > > > router(s). As a consequence, not enough marked traffic > arrives > > > at > > > > > > the egress router to drive the CLE for the ingress-egress > > > aggregate > > > > > > above the threshold needed to trigger a response > (termination, > > > say). > > > > > > > > > > Ok. To be specific, the egressrouter will see some > fraction of > > > > > packets from the severely congested router(s), some of > > > which will be > > > > > marked, and will see a larger fraction of un-marked > > > packets from the > > > > > un-pre-congested routers. > > > > > > > > > > So let me now ask you this: given N ECMP paths (after a path > > > > > failure), with one being severely congested and the > rest being > > > > > un-pre-congested, and given a CLE threshold CLE_thresh at > > > the egress > > > > > router, can you solve for the minimum PCN_lower_threshold > > > value at > > > > > the severely congested router, where PCN still works > (e.g., CLE > > > > > crosses the threshold), for the two cases where (1) > > > marked packets > > > > > are preferentially dropped, and (2) marked packets are > > > dropped with > > > > > equal probability with un-marked packets? > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > > > Steven Blake > > > > > Ericsson/Redback Networks +1 919-472-9913 > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 From pcn-bounces@ietf.org Thu Mar 20 02:47:02 2008 Return-Path: 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 C80AB28C21D; Thu, 20 Mar 2008 02:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.318 X-Spam-Level: X-Spam-Status: No, score=-100.318 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 ootciOb8xCWM; Thu, 20 Mar 2008 02:47:01 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C64A28C292; Thu, 20 Mar 2008 02:47:01 -0700 (PDT) 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 5356928C2C3 for ; Thu, 20 Mar 2008 02:47:00 -0700 (PDT) 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 Kx97xbyD1r5a for ; Thu, 20 Mar 2008 02:46:59 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id D2F1328C296 for ; Thu, 20 Mar 2008 02:46:58 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m2K9gnaL014472; Thu, 20 Mar 2008 10:42:52 +0100 (MET) From: "Georgios Karagiannis" To: "'Anna Charny \(acharny\)'" , , References: <006101c889db$b32d6940$810c5982@dynamic.ewi.utwente.nl> Date: Thu, 20 Mar 2008 10:42:44 +0100 Message-ID: <000b01c88a6e$c2b5f740$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AciJ1+MI5FcT3On/QSSm/yR8ASiixQAAMd5QAACQVrAAACH5oAACZnhQACI28OA= X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 20 Mar 2008 10:42:54 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Anna What I was trying to say is that we should not mandate to preferential drop marked packets, because then the PCN domain operation can become more instable than in the situations that either random dropping of marked and unmmarked packets is used or when unmarked packets are preferentially dropped. I think that the method of dropping should not be mandated. Best regards, Georgios > -----Original Message----- > From: Anna Charny (acharny) [mailto:acharny@cisco.com] > Sent: woensdag 19 maart 2008 21:33 > To: Georgios Karagiannis; philip.eardley@bt.com; > steven.blake@ericsson.com > Cc: pcn@ietf.org > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > > Hi Georgios, > > I must confess that I do not really see the examples you are > presenting as arguments for having (or for that matter not > having) preferential drop that I can understand. While I may > certainly be missing the points you are making, I want to > point out that quite regardless of all these examples, if all > you are trying to achieve is that the standard does not force > a particular preferential drop policy, I believe the current > proposal already does that, as it has a SHOULD, not a MUST in > the preferential drop clause. So perhaps that means that > this does not need to be argued so intensely? > > On the examples themselves, I also reread your recent emails > (and assuming I understand correctly which of the multiple > examples you actually are referring to in your exchange with > Steve and Phil), I realized that the problem you are > referring to may have nothing to do with dropping marked or > unmarked packets. It has simply to do with a well-recognized > problem of dilution of marking signal received by the egress > in the case when traffic of a given on any particular ECMP > path is drastically smaller than the combined traffic of this > IEA on other > (uncongested) ECMP paths. > > Let us consider what seems to be a rather aggressive example. > Let us assume that we have a bottleneck link, and - for the > moment- assume it is the only bottleneck in the network, so > in fact there is no marking occurring anywhere but on this > link. Just using this assumption to demonstrate that marking > preference is irrelevant for the problem you seem to be referring to. > > Suppose now you have an IEA on this link and you have other > ECMP paths shared by this aggregate. Let us assume that the > total amount of traffic of this IEA on the link of interest > is K. Suppose now that the total traffic on the IEA aggregate > is M*K, and assume that M is large. > I doubt it will ever be more than 16 - so let us take 16 for > the moment. > > Assume now that the link in question has a very high > overload. I would assume is 5X overload is quite large > (Rudiger I am sure will agree :)), so let us just take 5. > That means that approximately 80% of traffic of this IEA is > dropped at the input, so we end up having only 0.2K actually > leaving this link. > > Now assume that the admission threshold is set to 80% of your > link (picking a high value to make things worse). And assume > we are running SM - or LC-PCN (or whatever other alg that > uses excess marking). Now that means that ~20% of our > remaining traffic of the IEA aggregate gets marked. The > egress now sees: 0.2*0.2K=0.04K of marked traffic and > (M-1)K+0.2*0.8K unmarked traffic. The CLE now is now > ~0.04K/15K~0.002. > If you need a larger CLE than that, then neither SM, nor, for > that matter, LC-PCN, would trigger admission stop on that > aggregate (without probing added). > > As it happens, the CLE setting with which the vast majority > of SM simulations were done was actually 0.001 (less than the > above) - so in fact for this particular set of the parameters > (even though I think quite aggressive) this would not > actually cause SM a problem. > > But obviously if you increase either M to be greater than 16 > or the overload on the link to be even greater than 5 times > the links capacity, you may indeed get into the situation > when the actual amount of marked traffic that gets through to > the egress is small compared to the total rate of other > uncongested ECMP paths for this aggregate. While I personally > believe that the parameters I chose are probably overly > conservative and in practice things will look dramatically > better - nevertheless in principle this problem does in fact > exist in theory. In for sufficiently large overloads and > ratio M this problem theoretically exists even for threshold > marking - although you would need even more aggressive > parameters to see the problem then. > > The point however is that all of this seems to have little to > do with what you prefer to drop. In particular, in the > example above there were no packets at all that were marked > before the bottleneck. The same example will remain even if > in fact some packets were previously marked, and all of them > were dropped at the entry to the bottleneck. What matters is > what percentage of the traffic gets through the tightest > bottleneck and how much of it gets marked at *this* > bottleneck. So I just can't get why all of these examples > show the point about preferential drop you are trying to make... > > Anna > > > > > > > > > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of > > Georgios Karagiannis > > Sent: Wednesday, March 19, 2008 12:10 PM > > To: philip.eardley@bt.com; steven.blake@ericsson.com > > Cc: pcn@ietf.org > > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > > > > Hi Phil > > > > But in order to trigger the admission control and flow termination, > > the situation CLE > 1% has to be first triggered. > > > > Best regards, > > Georgios > > > > > > > -----Original Message----- > > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > > Sent: woensdag 19 maart 2008 17:07 > > > To: karagian@cs.utwente.nl; steven.blake@ericsson.com > > > Cc: pcn@ietf.org > > > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > > > > > > Georgios, > > > > > > I notice you refer to CLE below. Note that for termination the > > > relevant parameter is the Sustainable rate, that is the rate of > > > unmarked pkts (or, if SM being used, this rate is > multiplied by the > > > domain-wide parameter U). > > > > > > phil > > > > > > > -----Original Message----- > > > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > > > Behalf Of > > > > Georgios Karagiannis > > > > Sent: 19 March 2008 15:49 > > > > To: 'Steven Blake' > > > > Cc: pcn@ietf.org > > > > Subject: Re: [PCN] Concensus questions from Thursday's > PCN meeting > > > > > > > > Hi Steven > > > > > > > > Okay, I will have to spend some time on this! > > > > > > > > Best regards, > > > > Georgios > > > > > > > > > > > > > -----Original Message----- > > > > > From: Steven Blake [mailto:steven.blake@ericsson.com] > > > > > Sent: woensdag 19 maart 2008 16:43 > > > > > To: Georgios Karagiannis > > > > > Cc: pcn@ietf.org > > > > > Subject: RE: [PCN] Concensus questions from Thursday's > > PCN meeting > > > > > > > > > > On Wed, 2008-03-19 at 16:24 +0100, Georgios Karagiannis wrote: > > > > > > > > > > > Hi Steven > > > > > > > > > > > > Please see that I have included some information into the > > > > > last bullet: > > > > > > > > > > > > - There is an ingress-egress aggregate whose traffic is > > > > > split across > > > > > > multiple paths via ECMP. > > > > > > - Traffic is admitted along this split path. > > > > > > - One (or more) of the paths fails. > > > > > > - One (or more) of the remaining paths becomes severely > > > > > congested (for > > > > > > example because there is traffic from other > ingress-egress > > > > > > aggregates flowing along that path). > > > > > > - < > > > > forward packets > > > > > > belonging to > > > > > > the same ingress-egress-aggregate that will be unmarked.>> > > > Marked > > > > > > packets are > > > > > > preferentially dropped at the severely congested > > > > > > router(s). As a consequence, not enough marked > > traffic arrives > > > at > > > > > > the egress router to drive the CLE for the ingress-egress > > > aggregate > > > > > > above the threshold needed to trigger a response > (termination, > > > say). > > > > > > > > > > Ok. To be specific, the egressrouter will see some > > fraction of > > > > > packets from the severely congested router(s), some of > > > which will be > > > > > marked, and will see a larger fraction of un-marked > > > packets from the > > > > > un-pre-congested routers. > > > > > > > > > > So let me now ask you this: given N ECMP paths (after a path > > > > > failure), with one being severely congested and the > rest being > > > > > un-pre-congested, and given a CLE threshold CLE_thresh at > > > the egress > > > > > router, can you solve for the minimum PCN_lower_threshold > > > value at > > > > > the severely congested router, where PCN still works > (e.g., CLE > > > > > crosses the threshold), for the two cases where (1) > > > marked packets > > > > > are preferentially dropped, and (2) marked packets are > > > dropped with > > > > > equal probability with un-marked packets? > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > > > Steven Blake > > > > > Ericsson/Redback Networks +1 919-472-9913 > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Mar 20 04:19:32 2008 Return-Path: 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 A1F0E3A691C; Thu, 20 Mar 2008 04:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.677 X-Spam-Level: X-Spam-Status: No, score=-100.677 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 rE+09Jr-TcRC; Thu, 20 Mar 2008 04:19:31 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6FFB3A69C8; Thu, 20 Mar 2008 04:19:31 -0700 (PDT) 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 1FFEC3A69BB for ; Thu, 20 Mar 2008 04:19:27 -0700 (PDT) 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 IEdv7dpCv-6Y for ; Thu, 20 Mar 2008 04:19:22 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 8B7F928C3A1 for ; Thu, 20 Mar 2008 04:18:59 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail11.telekom.de with ESMTP; Thu, 20 Mar 2008 12:16:41 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Mar 2008 12:16:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 12:18:05 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CFC834B@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciKUHTGZ9BmSgQ0REOEjQjU515mCwAKU3pQ References: From: "Geib, Ruediger" To: , X-OriginalArrivalTime: 20 Mar 2008 11:16:40.0991 (UTC) FILETIME=[DF2C92F0:01C88A7B] Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Gengyu, hi Anna please don't argue over this. It doesn't matter whether it is 80%, 90% or 70% loss. Voice customers will hang up and people watching a video will turn off. This will reduce the catastrophic overload within 10-60 seconds. Standard operation can resume then to the extent possible after a catastrophy. Anna> Assume now that the link in question has a very high overload. I | > would assume is 5X overload is quite large (Rudiger I am sure will | > agree :)), so let us just take 5. That means that approximately 80% | > of traffic of this IEA is dropped at the input, so we end up having | > only 0.2K actually leaving this link. | Genyu| It is wrong. | You can not get 0.2K ACTUALLY! | And because of this, the following calculation is inredible. Anna: yes, "5% congestion" is a reasonable assumption for a link congested under regular network conditions for engineered carrier backbones (i.e. including single outages). Regards, Rudiger _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Mar 20 04:51:44 2008 Return-Path: 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 1DDD93A6C22; Thu, 20 Mar 2008 04:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.594 X-Spam-Level: X-Spam-Status: No, score=-100.594 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 aHKz3SYDDZH9; Thu, 20 Mar 2008 04:51:40 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CA403A6A3B; Thu, 20 Mar 2008 04:51:40 -0700 (PDT) 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 994653A69AC for ; Thu, 20 Mar 2008 04:51:38 -0700 (PDT) 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 l9aF3JiW3gPC for ; Thu, 20 Mar 2008 04:51:33 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id DE1BE28C287 for ; Thu, 20 Mar 2008 04:51:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,530,1199682000"; d="scan'208";a="2379260" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 20 Mar 2008 07:49:15 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m2KBnFeB026589; Thu, 20 Mar 2008 07:49:15 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m2KBnFkI008981; Thu, 20 Mar 2008 11:49:15 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Mar 2008 07:49:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 07:49:14 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciKUHqJbvYsQbslQrm2UL9Qiuh0awALrScA From: "Anna Charny (acharny)" To: "Wei Gengyu" X-OriginalArrivalTime: 20 Mar 2008 11:49:15.0126 (UTC) FILETIME=[6BEDE960:01C88A80] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2952; t=1206013755; x=1206877755; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20(acharny)=22=20 |Subject:=20RE=3A=20[PCN]=20Concensus=20questions=20from=20 Thursday's=20PCN=20meeting |Sender:=20 |To:=20=22Wei=20Gengyu=22=20; bh=Thkpqd/Bwt+YOG8Q7cBswgbfxGM9VZ5H5AJNt2ilwMg=; b=qV4iOsMswqsWeNhXoCAc157JV+Q77Q86SQBfQFTNtTgmb6FWrKU6URjPau EehNTuHGlCuX1+/nmg5tPDUK1D17sCPPDDy7ZUZGgV6xEfrVs0Uqz2KuTbT0 iGhl3w+nD5; Authentication-Results: rtp-dkim-2; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Gengyu, Can you clarify please? If you have 5x congestion overall on a link, (which means you have 5 times more traffic than your link can carry), would you not expect to lose 4/5 of your traffic? You may have misunderstood that in this example the IEA in question itself only has K amount of traffic arriving to this link, not 16K. I am assuming then that approximately 4/5 of k will be lost. This clearly assumes that the loss is proportionally spread among all IEAs, which is indeed not always the case - but seems like a fair approximation for this level of discussion. If I am missing something fundamental, can you explain? Anna > -----Original Message----- > From: Wei Gengyu [mailto:weigengyu@vip.sina.com] > Sent: Thursday, March 20, 2008 2:05 AM > To: Anna Charny (acharny); Georgios Karagiannis; > philip.eardley@bt.com; steven.blake@ericsson.com > Cc: pcn@ietf.org > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > > Hi, all, > > No matter what you want to express, > the explanation of your assumed model is incorrect. > > Also, see comments inline. > > Gengyu > > ----- Original Message ----- > From: "Anna Charny (acharny)" > To: "Georgios Karagiannis" ; > ; > Cc: > Sent: Thursday, March 20, 2008 4:33 AM > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > > > > Hi Georgios, > > > > > Assume now that the link in question has a very high overload. I > > would assume is 5X overload is quite large (Rudiger I am sure will > > agree :)), so let us just take 5. That means that > approximately 80% > > of traffic of this IEA is dropped at the input, so we end up having > > only 0.2K actually leaving this link. > > It is wrong. > You can not get 0.2K ACTUALLY! > And because of this, the following calculation is inredible. > > > > > > Now assume that the admission threshold is set to 80% of your link > > (picking a high value to make things worse). And assume we > are running > > SM - or LC-PCN (or whatever other alg that uses excess > marking). Now > > that means that ~20% of our remaining traffic of the IEA aggregate > > gets marked. The egress now sees: 0.2*0.2K=0.04K of marked traffic > > and (M-1)K+0.2*0.8K unmarked traffic. The CLE now is now > ~0.04K/15K~0.002. > > If you need a larger CLE than that, then neither SM, nor, for that > > matter, LC-PCN, would trigger admission stop on that aggregate > > (without probing added). > > > > > > Anna > > > > Strongly suggest people refer to textbook about throughput > performance of congested node. > The throughput of the congested will be different in case the > input is 5*X and 16*X. > > Gengyu > > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Mar 20 05:50:08 2008 Return-Path: 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 3DE8528C48B; Thu, 20 Mar 2008 05:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.67 X-Spam-Level: X-Spam-Status: No, score=-100.67 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 pHZag8YYRMFG; Thu, 20 Mar 2008 05:50:04 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D52B13A6F02; Thu, 20 Mar 2008 05:49:57 -0700 (PDT) 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 2F7AE3A6F36 for ; Thu, 20 Mar 2008 05:49:57 -0700 (PDT) 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 privzuSybTz1 for ; Thu, 20 Mar 2008 05:49:55 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1B8503A6F40 for ; Thu, 20 Mar 2008 05:48:58 -0700 (PDT) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 20 Mar 2008 05:46:40 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m2KCke1R007738; Thu, 20 Mar 2008 05:46:40 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id m2KCkeb9008133; Thu, 20 Mar 2008 12:46:40 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Mar 2008 08:46:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 08:46:39 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciKhshC8wiB4PMFRoqniGF5muqS/gAAEHYQ From: "Anna Charny (acharny)" To: "Wei Gengyu" X-OriginalArrivalTime: 20 Mar 2008 12:46:40.0259 (UTC) FILETIME=[71637D30:01C88A88] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4330; t=1206017200; x=1206881200; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20(acharny)=22=20 |Subject:=20RE=3A=20[PCN]=20Concensus=20questions=20from=20 Thursday's=20PCN=20meeting |Sender:=20; bh=7waNga/2IgCZAzxaRxwbCgTe6WpD6o2BjoOnNLMSPoQ=; b=EDgRP5uz/kDbNy1r9pAGxu6IpnVbZg3VB2kXkS6mK7DaVEOMzf/mwmEjNe B+WZ6hRlPXSPEg5DVFByezwYYpjpJibjTAnR48qcZPbFj4Dztpm/Qlly7E2f myI989xzJZ; Authentication-Results: sj-dkim-3; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Ah, I see what you mean. At this level of approximation however this does not matter at all - so I just ignored this issue. Just assume that whatever throughput a device can sustain under heavy overload is 100% of your desired capacity. Just how low this throughput might be depends on the queuing architecture of your device and details of traffic arrivals. I indeed ignored all that. Anna > -----Original Message----- > From: Wei Gengyu [mailto:weigengyu@vip.sina.com] > Sent: Thursday, March 20, 2008 8:34 AM > To: Anna Charny (acharny) > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > > Hi, See comments inline. > > ----- Original Message ----- > From: "Anna Charny (acharny)" > To: "Wei Gengyu" > Cc: > Sent: Thursday, March 20, 2008 7:49 PM > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > > > >Hi Gengyu, > > >Can you clarify please? > > >If you have 5x congestion overall on a link, (which means you have 5 > >times more traffic than your link can carry), would you not > expect to > >lose 4/5 of your traffic? > > The amount of traffic lost may be more than 4/5 of your traffic. > The link output may not sustain to be the link capacity, > it may be near to zero. > > >You may have misunderstood that in this example the IEA in question > >itself only has K amount of traffic arriving to this link, > not 16K. I am > >assuming then that approximately 4/5 of k will be lost. This clearly > >assumes that the loss is proportionally spread among all > IEAs, which is > >indeed not always the case - but seems like a fair approximation for > >this level of discussion. > > >If I am missing something fundamental, can you explain? > > >Anna > > > -----Original Message----- > > From: Wei Gengyu [mailto:weigengyu@vip.sina.com] > > Sent: Thursday, March 20, 2008 2:05 AM > > To: Anna Charny (acharny); Georgios Karagiannis; > > philip.eardley@bt.com; steven.blake@ericsson.com > > Cc: pcn@ietf.org > > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > > > > Hi, all, > > > > No matter what you want to express, > > the explanation of your assumed model is incorrect. > > > > Also, see comments inline. > > > > Gengyu > > > > ----- Original Message ----- > > From: "Anna Charny (acharny)" > > To: "Georgios Karagiannis" ; > > ; > > Cc: > > Sent: Thursday, March 20, 2008 4:33 AM > > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > > > > > > > Hi Georgios, > > > > > > > > Assume now that the link in question has a very high > overload. I > > > would assume is 5X overload is quite large (Rudiger I am > sure will > > > agree :)), so let us just take 5. That means that > > approximately 80% > > > of traffic of this IEA is dropped at the input, so we end > up having > > > only 0.2K actually leaving this link. > > > > It is wrong. > > You can not get 0.2K ACTUALLY! > > And because of this, the following calculation is inredible. > > > > > > > > > > Now assume that the admission threshold is set to 80% of > your link > > > (picking a high value to make things worse). And assume we > > are running > > > SM - or LC-PCN (or whatever other alg that uses excess > > marking). Now > > > that means that ~20% of our remaining traffic of the IEA > aggregate > > > gets marked. The egress now sees: 0.2*0.2K=0.04K of > marked traffic > > > and (M-1)K+0.2*0.8K unmarked traffic. The CLE now is now > > ~0.04K/15K~0.002. > > > If you need a larger CLE than that, then neither SM, nor, > for that > > > matter, LC-PCN, would trigger admission stop on that aggregate > > > (without probing added). > > > > > > > > > Anna > > > > > > > Strongly suggest people refer to textbook about throughput > > performance of congested node. > > The throughput of the congested will be different in case the > > input is 5*X and 16*X. > > > > Gengyu > > > > > > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Mar 20 06:14:28 2008 Return-Path: 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 D62A828C55B; Thu, 20 Mar 2008 06:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.62 X-Spam-Level: X-Spam-Status: No, score=-100.62 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 zUCu+0oVq88a; Thu, 20 Mar 2008 06:14:27 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DE2028C3DE; Thu, 20 Mar 2008 06:14:21 -0700 (PDT) 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 C1B363A6872 for ; Thu, 20 Mar 2008 06:14:20 -0700 (PDT) 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 hq275iffEyOf for ; Thu, 20 Mar 2008 06:14:19 -0700 (PDT) Received: from smtp-6-97.vip.sina.com (smtp.vip.sina.com [202.108.3.172]) by core3.amsl.com (Postfix) with ESMTP id 2DEF828C36C for ; Thu, 20 Mar 2008 06:13:23 -0700 (PDT) Received: from ibmPC (unknown [211.160.21.17]) by smtp-6-97.vip.sina.com (SINAMAIL) with ESMTP id 9F9891DDA8D for ; Thu, 20 Mar 2008 21:11:04 +0800 (CST) Message-ID: <4AD9563181174CD69BF477D68DF81072@ibmPC> From: "Wei Gengyu" To: Date: Thu, 20 Mar 2008 21:10:42 +0800 Organization: BUPT MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.5840.16384 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.5840.16384 Subject: [PCN] Fw: Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org ----- Original Message ----- From: "Wei Gengyu" To: "Geib, Ruediger" Sent: Thursday, March 20, 2008 9:08 PM Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > Hi, Rudiger, > > I have to say some your assumption is not correct. > For voice custotmer, which is called the subscriber in telecom industry. > > When the subscriber come across an unsuccessful call-setup process or > break-up, > and he hears the busy tone, he will hangup first. > > But consider what he will do then. > Most of the subscriber will handoff immediatelly and make a new call. > This is the real case. > > When you measure the SS7 link when a sudden event happens, > the the number of call attempt may increase sharply, not decrease. > the number of successful calls decrease if the exchange is highly > congested. > This situation may last more than 60s. > > > What I want to say is the mechanism based on counting the number of > packets should be stable even in statistics. > But the output of count process may not be stable in the case that > Georgios gave. > > regards, > > Gengyu > > ----- Original Message ----- > From: "Geib, Ruediger" > To: ; > Cc: > Sent: Thursday, March 20, 2008 7:18 PM > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > > > Hi Gengyu, hi Anna > > please don't argue over this. It doesn't matter whether it is 80%, 90% > or 70% loss. Voice customers will hang up and people watching a video > will turn off. This will reduce the catastrophic overload within > 10-60 seconds. Standard operation can resume then to the extent > possible after a catastrophy. > > Anna> Assume now that the link in question has a very high overload. I > | > would assume is 5X overload is quite large (Rudiger I am sure will > | > agree :)), so let us just take 5. That means that approximately 80% > | > of traffic of this IEA is dropped at the input, so we end up having > | > only 0.2K actually leaving this link. > | > Genyu| It is wrong. > | You can not get 0.2K ACTUALLY! > | And because of this, the following calculation is inredible. > > Anna: yes, "5% congestion" is a reasonable assumption for a link congested > under regular network conditions for engineered carrier backbones (i.e. > including single outages). > > Regards, > > Rudiger > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Mar 20 06:30:14 2008 Return-Path: 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 AB2B128C31D; Thu, 20 Mar 2008 06:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.742 X-Spam-Level: X-Spam-Status: No, score=-100.742 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 EXTMU0Yw3K6f; Thu, 20 Mar 2008 06:30:13 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C420C28C258; Thu, 20 Mar 2008 06:30:13 -0700 (PDT) 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 23CA53A6A28 for ; Thu, 20 Mar 2008 06:30:12 -0700 (PDT) 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 3V81q0x7oSe3 for ; Thu, 20 Mar 2008 06:30:03 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B4D6E3A6892 for ; Thu, 20 Mar 2008 06:30:03 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,531,1199682000"; d="scan'208";a="2407836" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 20 Mar 2008 09:27:39 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m2KDRdYr001526; Thu, 20 Mar 2008 09:27:39 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2KDRdaI001901; Thu, 20 Mar 2008 13:27:39 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Mar 2008 09:27:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 09:27:38 -0400 Message-ID: In-Reply-To: <1B6169C658325341A3B8066E23919E1CFC834B@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: On pcn and overloads (was: [PCN] Concensus questions from Thursday's PCN meeting) Thread-Index: AciKUHTGZ9BmSgQ0REOEjQjU515mCwAKU3pQAAOsnCA= From: "Anna Charny (acharny)" To: "Geib, Ruediger" X-OriginalArrivalTime: 20 Mar 2008 13:27:39.0545 (UTC) FILETIME=[2B3CC090:01C88A8E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2421; t=1206019659; x=1206883659; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20(acharny)=22=20 |Subject:=20On=20pcn=20and=20overloads=20(was=3A=20[PCN]=20 Concensus=20questions=20from=20Thursday's=20PCN=20meeting) |Sender:=20 |To:=20=22Geib,=20Ruediger=22=20; bh=eShZsV54jF9NBb9yuH2tLp8y78CbkFvFp0m6U7zJsVE=; b=LQZOxxt25LwVxNjQn12xn0CrRcHVZqnjuW2qh6mxUNAA3FhFq7QYkImdtR DgoFKcbJHHPEsavD4zj6t02CB/sCtOVbI5NgFKWUkAG8898T7TTgEmP3ikEI GsZj0bpQ18; Authentication-Results: rtp-dkim-1; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: pcn@ietf.org Subject: [PCN] On pcn and overloads (was: Concensus questions from Thursday's PCN meeting) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ruediger, > > Anna: yes, "5% congestion" is a reasonable assumption for a > link congested under regular network conditions for > engineered carrier backbones (i.e. > including single outages). > > Regards, > > Rudiger > You know, I keep wondering about this statement that you cannot really have larger overloads. We did, a few years ago, a study of bandwidth requirements for MPLS FRR on a relatively large set of actual networks of some of our reputable customers with their expected traffic matrices, as provided by them. We looked specifically at bandwidth requirements for real-time traffic only - so we assumed that we actually just need to protect traffic that is using priority queue. We found that if you just wanted to protect against individual link failures, then capacity requirements were quite reasonable. These capacity requirements were also not too bad if we wanted to protect against individual node failures. However, as soon as it came to SRLGs, the bandwidth requirements necessary to ensure that on any individual SRLG failure real time traffic did not overload any link, we discovered that in a surprisingly large number of (real) networks (of reputable providers) we looked at, the requirement to fully protect real-time traffic against a single SRLG failure could not take more than ~10% of the link bandwidth on some links before failure. And that does seem too low for many networks. Which seems to argue that unless 10% is an acceptable limit for real-time traffic, then in the rare cases on SRLG failures one *could* expect a fair amount of overload even for real-time traffic. And in those cases pcn (and specifically its termination function) could serve as a means to allow graceful flow termination in such cases - as an alternative to build up capacity to deal with rare events. Indeed, to make it useful, this termination should work at a timescale that is smaller than the time when all users on that link hang up. Which is why it seemed that a fast - even if not quite accurate or fair - termination process might be preferable to a slow but more accurate one. So it does appear that there could be useful applications of pcn termination that would have to deal with more than 5% overload of real-time traffic. That is not to say that this is necessarily the case for your network :-). Anna _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Mar 20 07:13:14 2008 Return-Path: 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 E8F2D28C3AB; Thu, 20 Mar 2008 07:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.671 X-Spam-Level: X-Spam-Status: No, score=-100.671 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 GYYcr-4XzdKl; Thu, 20 Mar 2008 07:13:14 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0746028C4D0; Thu, 20 Mar 2008 07:13:14 -0700 (PDT) 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 7183928C31D for ; Thu, 20 Mar 2008 07:13:12 -0700 (PDT) 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 bn-VnHpsYPWI for ; Thu, 20 Mar 2008 07:13:08 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id E69D628C3AB for ; Thu, 20 Mar 2008 07:13:03 -0700 (PDT) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Thu, 20 Mar 2008 15:10:44 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Mar 2008 15:10:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 15:12:08 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1CFC844D@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: On pcn and overloads (was: [PCN] Concensus questions from Thursday's PCN meeting) Thread-Index: AciKUHTGZ9BmSgQ0REOEjQjU515mCwAKU3pQAAOsnCAAApwa4A== References: <1B6169C658325341A3B8066E23919E1CFC834B@S4DE8PSAANK.mitte.t-com.de> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 20 Mar 2008 14:10:43.0973 (UTC) FILETIME=[2FAD2B50:01C88A94] Cc: pcn@ietf.org Subject: Re: [PCN] On pcn and overloads (was: Concensus questions from Thursday's PCN meeting) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Anna, 5-10% overload doesn't look as a catastrophy scenario to me. A 10% = overload following the loss of an SRLG and then meeting ECMP = routing will be evenly distributed on the multiple paths. How much = head ache does this cause, if there the congestion one single link = is no more than 5% (keeping in mind, that the traffic of origins = not impacted by the SRLG loss soon decays)? I still have a hard = time to understand what's 'new' on the problem that's claimed = to be caused by ECMP. I drop out for vacation now, will be back on 31st. Regards, Rudiger | -----Original Message----- | From: Anna Charny (acharny) [mailto:acharny@cisco.com] = | Sent: Thursday, March 20, 2008 2:28 PM | To: Geib, R=FCdiger | Cc: pcn@ietf.org | Subject: On pcn and overloads (was: [PCN] Concensus questions = | from Thursday's PCN meeting) | = | Hi Ruediger, | > = | > Anna: yes, "5% congestion" is a reasonable assumption for a link = | > congested under regular network conditions for engineered carrier = | > backbones (i.e. | > including single outages). | > = | > Regards, | > = | > Rudiger | > = | = | You know, I keep wondering about this statement that you = | cannot really have larger overloads. We did, a few years = | ago, a study of bandwidth requirements for MPLS FRR on a = | relatively large set of actual networks of some of our = | reputable customers with their expected traffic matrices, as = | provided by them. We looked specifically at bandwidth = | requirements for real-time traffic only - so we assumed that = | we actually just need to protect traffic that is using = | priority queue. We found that if you just wanted to protect = | against individual link failures, then capacity requirements = | were quite reasonable. These capacity requirements were also = | not too bad if we wanted to protect against individual node = | failures. However, as soon as it came to SRLGs, the = | bandwidth requirements necessary to ensure that on any = | individual SRLG failure real time traffic did not overload = | any link, we discovered that in a surprisingly large number = | of (real) networks (of reputable providers) we looked at, the = | requirement to fully protect real-time traffic against a = | single SRLG failure could not take more than ~10% of the link = | bandwidth on some links before failure. And that does seem = | too low for many networks. | = | Which seems to argue that unless 10% is an acceptable limit = | for real-time traffic, then in the rare cases on SRLG = | failures one *could* expect a fair amount of overload even = | for real-time traffic. And in those cases pcn (and = | specifically its termination function) could serve as a means = | to allow graceful flow termination in such cases - as an = | alternative to build up capacity to deal with rare events. = | = | Indeed, to make it useful, this termination should work at a = | timescale that is smaller than the time when all users on = | that link hang up. Which is why it seemed that a fast - even = | if not quite accurate or fair - termination process might be = | preferable to a slow but more accurate one. | = | So it does appear that there could be useful applications of = | pcn termination that would have to deal with more than 5% = | overload of real-time traffic. That is not to say that this = | is necessarily the case for your network :-). | = | Anna = | = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Mar 20 07:24:57 2008 Return-Path: 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 8F6CB28C59E; Thu, 20 Mar 2008 07:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.742 X-Spam-Level: X-Spam-Status: No, score=-100.742 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 Cc3UcdjH7-J9; Thu, 20 Mar 2008 07:24:53 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7146928C4CB; Thu, 20 Mar 2008 07:24:53 -0700 (PDT) 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 95A893A6CD0 for ; Thu, 20 Mar 2008 07:24:51 -0700 (PDT) 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 BwsP-N9mqwcL for ; Thu, 20 Mar 2008 07:24:50 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 27DDC28C5B0 for ; Thu, 20 Mar 2008 07:24:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,531,1199682000"; d="scan'208";a="2420643" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 20 Mar 2008 10:22:28 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m2KEMSHi001445; Thu, 20 Mar 2008 10:22:28 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m2KEMSo0006239; Thu, 20 Mar 2008 14:22:28 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Mar 2008 10:22:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 10:22:27 -0400 Message-ID: In-Reply-To: <1B6169C658325341A3B8066E23919E1CFC844D@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: On pcn and overloads (was: [PCN] Concensus questions from Thursday's PCN meeting) Thread-Index: AciKUHTGZ9BmSgQ0REOEjQjU515mCwAKU3pQAAOsnCAAApwa4AAAcvqw From: "Anna Charny (acharny)" To: "Geib, Ruediger" X-OriginalArrivalTime: 20 Mar 2008 14:22:28.0497 (UTC) FILETIME=[D39B0010:01C88A95] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5079; t=1206022948; x=1206886948; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20(acharny)=22=20 |Subject:=20RE=3A=20On=20pcn=20and=20overloads=20(was=3A=20 [PCN]=20Concensus=20questions=20from=20Thursday's=20PCN=20me eting) |Sender:=20 |To:=20=22Geib,=20Ruediger=22=20; bh=hd4ZrpNGFidryYNUjfa5Fdr5KKT/+guFB0qEuHj+91U=; b=LR+r16LxUaJG8S0Uw4KnfsvtF5yLEHJLASZ0sfxeox8gpRm2bm7Uc3alpk SUaq0KhCYH/IM6ckL3yBpWTkuUbWaTaiMi5IrgcgDRncpDMQ0QL7dtBWkemP OhMkVTBl1d; Authentication-Results: rtp-dkim-2; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: pcn@ietf.org Subject: Re: [PCN] On pcn and overloads (was: Concensus questions from Thursday's PCN meeting) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Ruediger, = > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] = > Sent: Thursday, March 20, 2008 10:12 AM > To: Anna Charny (acharny) > Cc: pcn@ietf.org > Subject: RE: On pcn and overloads (was: [PCN] Concensus = > questions from Thursday's PCN meeting) > = > Hi Anna, > = > 5-10% overload doesn't look as a catastrophy scenario to me. = > A 10% overload following the loss of an SRLG and then meeting = > ECMP routing will be evenly distributed on the multiple = > paths. How much head ache does this cause, if there the = > congestion one single link is no more than 5% (keeping in = > mind, that the traffic of origins not impacted by the SRLG = > loss soon decays)? I still have a hard time to understand = > what's 'new' on the problem that's claimed to be caused by ECMP. > = I must confess do not understand what is new in the ECMP issue either. The point of my previous message however, was different and unrelated to EC= MP. If indeed there are networks that can only support 10% of some links f= or real-time traffic - without any overload on SRLG failure - then it means= that if/when that becomes unacceptably low, you have two choices: 1) do NOT fully provision against SRLG failure. E.g. allow, saw 50% of you= r link in question to carry real-time traffic. Then if and when a failure o= ccurs, your real time traffic with overload the link potentially much highe= r than 5-10%. In that case, pcn termination may be useful. 2) Or, you can just upgrade your links so you can carry more real time traf= fic on it AND have 100% bandwidth guarantee on failures. That may be expen= sive - and if it is, than pcn termination might be a reasonable approach, a= nd it might need to deal with higher than 5-10% overloads. That is all I tried to say. Have a good vacation. Anna = > I drop out for vacation now, will be back on 31st. > = > Regards, > = > Rudiger > = > | -----Original Message----- > | From: Anna Charny (acharny) [mailto:acharny@cisco.com] > | Sent: Thursday, March 20, 2008 2:28 PM > | To: Geib, R=FCdiger > | Cc: pcn@ietf.org > | Subject: On pcn and overloads (was: [PCN] Concensus questions from = > | Thursday's PCN meeting) > | = > | Hi Ruediger, > | > = > | > Anna: yes, "5% congestion" is a reasonable assumption for a link = > | > congested under regular network conditions for engineered carrier = > | > backbones (i.e. > | > including single outages). > | > = > | > Regards, > | > = > | > Rudiger > | > = > | = > | You know, I keep wondering about this statement that you = > cannot really = > | have larger overloads. We did, a few years ago, a study of = > bandwidth = > | requirements for MPLS FRR on a relatively large set of = > actual networks = > | of some of our reputable customers with their expected traffic = > | matrices, as provided by them. We looked specifically at bandwidth = > | requirements for real-time traffic only - so we assumed that we = > | actually just need to protect traffic that is using = > priority queue. = > | We found that if you just wanted to protect against individual link = > | failures, then capacity requirements were quite reasonable. These = > | capacity requirements were also not too bad if we wanted to protect = > | against individual node failures. However, as soon as it came to = > | SRLGs, the bandwidth requirements necessary to ensure that on any = > | individual SRLG failure real time traffic did not overload = > any link, = > | we discovered that in a surprisingly large number of (real) = > networks = > | (of reputable providers) we looked at, the requirement to fully = > | protect real-time traffic against a single SRLG failure = > could not take = > | more than ~10% of the link bandwidth on some links before = > failure. And = > | that does seem too low for many networks. > | = > | Which seems to argue that unless 10% is an acceptable limit for = > | real-time traffic, then in the rare cases on SRLG failures = > one *could* = > | expect a fair amount of overload even for real-time traffic. And in = > | those cases pcn (and specifically its termination function) could = > | serve as a means to allow graceful flow termination in such = > cases - as = > | an alternative to build up capacity to deal with rare events. > | = > | Indeed, to make it useful, this termination should work at = > a timescale = > | that is smaller than the time when all users on that link hang up. = > | Which is why it seemed that a fast - even if not quite accurate or = > | fair - termination process might be preferable to a slow but more = > | accurate one. > | = > | So it does appear that there could be useful applications of pcn = > | termination that would have to deal with more than 5% overload of = > | real-time traffic. That is not to say that this is necessarily the = > | case for your network :-). > | = > | Anna > | = > = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Mar 20 08:31:55 2008 Return-Path: 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 70BA228C3E2; Thu, 20 Mar 2008 08:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.707 X-Spam-Level: X-Spam-Status: No, score=-100.707 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 tx7qNzpPA1E6; Thu, 20 Mar 2008 08:31:54 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B0183A6E50; Thu, 20 Mar 2008 08:31:54 -0700 (PDT) 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 881A93A6E42 for ; Thu, 20 Mar 2008 08:31:53 -0700 (PDT) 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 GUiyYP2xAxAX for ; Thu, 20 Mar 2008 08:31:49 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 5FE3C3A6D84 for ; Thu, 20 Mar 2008 08:31:49 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Mar 2008 15:29:26 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 15:29:25 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34683@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <1205860102.9521.27.camel@neutrino> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Consensus questions: Q1, Q2, and Q3. Thread-Index: AciJGtlnZAlG7tPJS7isZ3AoqqEdxgBgnjpA From: To: , X-OriginalArrivalTime: 20 Mar 2008 15:29:26.0943 (UTC) FILETIME=[2EC932F0:01C88A9F] Subject: Re: [PCN] Consensus questions: Q1, Q2, and Q3. X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Steven, yes to all 3. I add some notes to clarify my viewpoint. Q1 - yes, I support a Standards track encoding with two PCN encoding states Q2 - yes, I support an Experimental track encoding that extends the Standards track encoding to give an extra PCN encoding state Q3 - yes, I believe there is enough information now for the PCN WG to make its decisions immediately about the Standards track elements of its Charter, ie the encoding(*) and the PCN-interior-node's marking behaviours. (*) including the Exptal encoding of Q2. The recent discussion on the list has (as far as I can tell) not raised any substantive new issue; it's a re-statement of the ECMP issue, which is known to be an issue. (And incidentally was a known issue for NSIS - which suggests it's a fundamental characteristic of a system with both ECMP and flow admission control. That simply means the user of PCN has to recognise the issue and either be appropriately cautious or use one of the known, but not wholly satisfactory, solutions.) Best wishes and Happy Easter! Phil/ > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Steven Blake > Sent: 18 March 2008 17:08 > To: pcn > Subject: [PCN] Concensus questions: Q1, Q2, and Q3. > > Six consensus questions were taken during the IETF 71 meeting. I would > now like to raise them on the list. I will do this in step-wise > fashion. > > Q1: As an initial standardization activity, should the PCN wg produce a > standards-track PCN scheme that requires only two encoding states? > (Note: this question does not presume that the solution is Single > Marking). > > Q2: Presuming consensus in favor of Q1, should the PCN wg produce one or > more experimental-track extensions to the standards-track PCN scheme > that require another encoding state (for a total of three encoding > states)? > > Q3: Does the PCN working group have enough information to make a > decision about the way forward for the standards-track PCN scheme? > > By my notes, Q1 was accepted in the meeting 8-0, Q2 was accepted 9-0, > and Q3 was accepted 6-1 (but my notes are fuzzy on Q3's result). > > Please send comments to the list during the next few days. > > > Regards, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven Blake > Ericsson/Redback Networks +1 919-472-9913 > > _______________________________________________ > 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 From pcn-bounces@ietf.org Thu Mar 20 08:36:38 2008 Return-Path: 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 1EBCF28C20A; Thu, 20 Mar 2008 08:36:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.573 X-Spam-Level: X-Spam-Status: No, score=-100.573 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 dpcfqjYPF3DQ; Thu, 20 Mar 2008 08:36:34 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2445D28C6D4; Thu, 20 Mar 2008 08:36:19 -0700 (PDT) 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 93A3228C55B for ; Thu, 20 Mar 2008 08:36:17 -0700 (PDT) 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 a1151I48Uodu for ; Thu, 20 Mar 2008 08:36:16 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 48E2D28C6C9 for ; Thu, 20 Mar 2008 08:36:10 -0700 (PDT) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Mar 2008 15:33:52 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 15:33:53 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: On pcn and overloads (was: Concensus questions fromThursday's PCN meeting) Thread-Index: AciKUHTGZ9BmSgQ0REOEjQjU515mCwAKU3pQAAOsnCAAApwa4AAAcvqwAAKf8RA= From: To: , X-OriginalArrivalTime: 20 Mar 2008 15:33:52.0257 (UTC) FILETIME=[CCECE710:01C88A9F] Cc: pcn@ietf.org Subject: Re: [PCN] On pcn and overloads (was: Concensus questions fromThursday's PCN meeting) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org I get the impression that this is all just restating the ECMP problem that = has been known and talked about for ages... It may highlight a particular c= ase where the effects are especially bad but I don't see that it actually i= nvalidates any of the PCN work. Nor do I see that it is an argument for or = against any drop preference strategy (dropping marked, dropping unmarked or= doing neither). What it does highlight however is there is apparently still some uncertaint= y as to what is a realistic deployment scenario for PCN. This is obviously = important and something that people need to make sure they agree on... Toby > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On = > Behalf Of Anna Charny (acharny) > Sent: 20 March 2008 14:22 > To: Geib, Ruediger > Cc: pcn@ietf.org > Subject: Re: [PCN] On pcn and overloads (was: Concensus = > questions fromThursday's PCN meeting) > = > Hi Ruediger, = > = > > -----Original Message----- > > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] = > > Sent: Thursday, March 20, 2008 10:12 AM > > To: Anna Charny (acharny) > > Cc: pcn@ietf.org > > Subject: RE: On pcn and overloads (was: [PCN] Concensus = > > questions from Thursday's PCN meeting) > > = > > Hi Anna, > > = > > 5-10% overload doesn't look as a catastrophy scenario to me. = > > A 10% overload following the loss of an SRLG and then meeting = > > ECMP routing will be evenly distributed on the multiple = > > paths. How much head ache does this cause, if there the = > > congestion one single link is no more than 5% (keeping in = > > mind, that the traffic of origins not impacted by the SRLG = > > loss soon decays)? I still have a hard time to understand = > > what's 'new' on the problem that's claimed to be caused by ECMP. > > = > = > I must confess do not understand what is new in the ECMP issue either. > = > The point of my previous message however, was different and = > unrelated to ECMP. If indeed there are networks that can = > only support 10% of some links for real-time traffic - = > without any overload on SRLG failure - then it means that = > if/when that becomes unacceptably low, you have two choices: > = > 1) do NOT fully provision against SRLG failure. E.g. allow, = > saw 50% of your link in question to carry real-time traffic. = > Then if and when a failure occurs, your real time traffic = > with overload the link potentially much higher than 5-10%. In = > that case, pcn termination may be useful. > = > 2) Or, you can just upgrade your links so you can carry more = > real time traffic on it AND have 100% bandwidth guarantee on = > failures. That may be expensive - and if it is, than pcn = > termination might be a reasonable approach, and it might need = > to deal with higher than 5-10% overloads. > = > That is all I tried to say. Have a good vacation. > Anna = > = > > I drop out for vacation now, will be back on 31st. > > = > > Regards, > > = > > Rudiger > > = > > | -----Original Message----- > > | From: Anna Charny (acharny) [mailto:acharny@cisco.com] > > | Sent: Thursday, March 20, 2008 2:28 PM > > | To: Geib, R=FCdiger > > | Cc: pcn@ietf.org > > | Subject: On pcn and overloads (was: [PCN] Concensus = > questions from = > > | Thursday's PCN meeting) > > | = > > | Hi Ruediger, > > | > = > > | > Anna: yes, "5% congestion" is a reasonable assumption = > for a link = > > | > congested under regular network conditions for = > engineered carrier = > > | > backbones (i.e. > > | > including single outages). > > | > = > > | > Regards, > > | > = > > | > Rudiger > > | > = > > | = > > | You know, I keep wondering about this statement that you = > > cannot really = > > | have larger overloads. We did, a few years ago, a study of = > > bandwidth = > > | requirements for MPLS FRR on a relatively large set of = > > actual networks = > > | of some of our reputable customers with their expected traffic = > > | matrices, as provided by them. We looked specifically at = > bandwidth = > > | requirements for real-time traffic only - so we assumed that we = > > | actually just need to protect traffic that is using = > > priority queue. = > > | We found that if you just wanted to protect against = > individual link = > > | failures, then capacity requirements were quite = > reasonable. These = > > | capacity requirements were also not too bad if we wanted = > to protect = > > | against individual node failures. However, as soon as it came to = > > | SRLGs, the bandwidth requirements necessary to ensure = > that on any = > > | individual SRLG failure real time traffic did not overload = > > any link, = > > | we discovered that in a surprisingly large number of (real) = > > networks = > > | (of reputable providers) we looked at, the requirement to fully = > > | protect real-time traffic against a single SRLG failure = > > could not take = > > | more than ~10% of the link bandwidth on some links before = > > failure. And = > > | that does seem too low for many networks. > > | = > > | Which seems to argue that unless 10% is an acceptable limit for = > > | real-time traffic, then in the rare cases on SRLG failures = > > one *could* = > > | expect a fair amount of overload even for real-time = > traffic. And in = > > | those cases pcn (and specifically its termination function) could = > > | serve as a means to allow graceful flow termination in such = > > cases - as = > > | an alternative to build up capacity to deal with rare events. > > | = > > | Indeed, to make it useful, this termination should work at = > > a timescale = > > | that is smaller than the time when all users on that link = > hang up. = > > | Which is why it seemed that a fast - even if not quite = > accurate or = > > | fair - termination process might be preferable to a slow but more = > > | accurate one. > > | = > > | So it does appear that there could be useful applications of pcn = > > | termination that would have to deal with more than 5% overload of = > > | real-time traffic. That is not to say that this is = > necessarily the = > > | case for your network :-). > > | = > > | Anna > > | = > > = > _______________________________________________ > 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 From pcn-bounces@ietf.org Thu Mar 20 08:40:31 2008 Return-Path: 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 F091F3A6E8E; Thu, 20 Mar 2008 08:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.633 X-Spam-Level: X-Spam-Status: No, score=-100.633 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 sBIZ7rz2Zurn; Thu, 20 Mar 2008 08:40:26 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5BA0328C0F7; Thu, 20 Mar 2008 08:40:26 -0700 (PDT) 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 C72D53A67F2 for ; Thu, 20 Mar 2008 08:40:24 -0700 (PDT) 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 ctyfHyM5wQ55 for ; Thu, 20 Mar 2008 08:40:24 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id AED013A6774 for ; Thu, 20 Mar 2008 08:40:23 -0700 (PDT) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Mar 2008 15:38:05 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 15:38:07 -0000 Message-ID: In-Reply-To: <1205860102.9521.27.camel@neutrino> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions: Q1, Q2, and Q3. Thread-Index: AciJGtmAr1YwA8NSQFu1ROhzaztYcgBhQO+g From: To: , X-OriginalArrivalTime: 20 Mar 2008 15:38:05.0919 (UTC) FILETIME=[641EA6F0:01C88AA0] Subject: Re: [PCN] Concensus questions: Q1, Q2, and Q3. X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Steven, Q1: Yes, I agree that we should initially aim to standardise a scheme that gives two encoding states. Q2: Yes, I agree that we should simultaneously produce one (or more) experimental extensions to provide a third encoding state. Q3: Yes, I think the PCN WG has sufficient information to make a decision on the way forward for a standards track PCN scheme. This should be done in parallel with working on the experimental extensions. Toby > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Steven Blake > Sent: 18 March 2008 17:08 > To: pcn > Subject: [PCN] Concensus questions: Q1, Q2, and Q3. > > Six consensus questions were taken during the IETF 71 > meeting. I would > now like to raise them on the list. I will do this in step-wise > fashion. > > Q1: As an initial standardization activity, should the PCN wg > produce a > standards-track PCN scheme that requires only two encoding states? > (Note: this question does not presume that the solution is Single > Marking). > > Q2: Presuming consensus in favor of Q1, should the PCN wg > produce one or > more experimental-track extensions to the standards-track > PCN scheme > that require another encoding state (for a total of three encoding > states)? > > Q3: Does the PCN working group have enough information to make a > decision about the way forward for the standards-track PCN scheme? > > By my notes, Q1 was accepted in the meeting 8-0, Q2 was accepted 9-0, > and Q3 was accepted 6-1 (but my notes are fuzzy on Q3's result). > > Please send comments to the list during the next few days. > > > Regards, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven Blake > Ericsson/Redback Networks +1 919-472-9913 > > _______________________________________________ > 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 From pcn-bounces@ietf.org Thu Mar 20 09:12:09 2008 Return-Path: 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 E806028C63B; Thu, 20 Mar 2008 09:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.756 X-Spam-Level: X-Spam-Status: No, score=-100.756 tagged_above=-999 required=5 tests=[AWL=-0.319, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 fcYy3XNDTRsZ; Thu, 20 Mar 2008 09:12:04 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAF4528C503; Thu, 20 Mar 2008 09:12:04 -0700 (PDT) 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 3070F28C2A9 for ; Thu, 20 Mar 2008 09:12:03 -0700 (PDT) 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 PyqIFdzuhmuP for ; Thu, 20 Mar 2008 09:12:02 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0ED2A3A6CA9 for ; Thu, 20 Mar 2008 09:12:02 -0700 (PDT) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 20 Mar 2008 09:09:44 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id m2KG9h8C013472; Thu, 20 Mar 2008 09:09:43 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m2KG9f0R007039; Thu, 20 Mar 2008 16:09:43 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Mar 2008 12:09:28 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Mar 2008 12:09:28 -0400 Message-ID: In-Reply-To: <1205860102.9521.27.camel@neutrino> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions: Q1, Q2, and Q3. Thread-Index: AciJGtzmWRfCIPYmRmCMvC/OqOa+xgBibsLA From: "Anna Charny (acharny)" To: "Steven Blake" , "pcn" X-OriginalArrivalTime: 20 Mar 2008 16:09:28.0979 (UTC) FILETIME=[C682CE30:01C88AA4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2074; t=1206029383; x=1206893383; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20(acharny)=22=20 |Subject:=20RE=3A=20[PCN]=20Concensus=20questions=3A=20Q1,= 20Q2,=20and=20Q3. |Sender:=20; bh=ufas2gZpGJbtF39Bc4qQMnk/mz8E4J20k9apwYCUy48=; b=dO/AtMPX0SOY6SqHnipweFVBmQQL3XhOPvUoWfyuDILFHAK83QdK8kQ4Sj 9vJDWjttRqKAazbD0KYPNaL0rMElxTSHjNRW8/ozi8sGzTkKWFv3rtDciq0N wbB/cu6ljt; Authentication-Results: sj-dkim-4; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [PCN] Concensus questions: Q1, Q2, and Q3. X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Steven, Q1: Yes - we should initially aim to standardize a scheme that gives two encoding states. Q2: Yes - we should simultaneously produce one (or more) experimental extensions to provide a third encoding state. Q3: Yes - I believe the PCN WG has sufficient information to make a decision on the way forward for a standards track PCN scheme. Anna > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Steven Blake > Sent: Tuesday, March 18, 2008 1:08 PM > To: pcn > Subject: [PCN] Concensus questions: Q1, Q2, and Q3. > > Six consensus questions were taken during the IETF 71 > meeting. I would now like to raise them on the list. I will > do this in step-wise fashion. > > Q1: As an initial standardization activity, should the PCN wg > produce a > standards-track PCN scheme that requires only two encoding states? > (Note: this question does not presume that the solution is Single > Marking). > > Q2: Presuming consensus in favor of Q1, should the PCN wg > produce one or > more experimental-track extensions to the standards-track > PCN scheme > that require another encoding state (for a total of three encoding > states)? > > Q3: Does the PCN working group have enough information to make a > decision about the way forward for the standards-track PCN scheme? > > By my notes, Q1 was accepted in the meeting 8-0, Q2 was > accepted 9-0, and Q3 was accepted 6-1 (but my notes are fuzzy > on Q3's result). > > Please send comments to the list during the next few days. > > > Regards, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven Blake > Ericsson/Redback Networks +1 919-472-9913 > > _______________________________________________ > 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 From pcn-bounces@ietf.org Thu Mar 20 10:21:32 2008 Return-Path: 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 0CD293A6F27; Thu, 20 Mar 2008 10:21:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.482 X-Spam-Level: X-Spam-Status: No, score=-100.482 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 lgbOdSIXNxF2; Thu, 20 Mar 2008 10:21:31 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B60E3A6E99; Thu, 20 Mar 2008 10:21:31 -0700 (PDT) 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 5A4523A6B01 for ; Thu, 20 Mar 2008 10:21:30 -0700 (PDT) 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 L86yjFKlox0e for ; Thu, 20 Mar 2008 10:21:29 -0700 (PDT) Received: from smtp103.rog.mail.re2.yahoo.com (smtp103.rog.mail.re2.yahoo.com [206.190.36.81]) by core3.amsl.com (Postfix) with SMTP id 6DD513A6E99 for ; Thu, 20 Mar 2008 10:21:29 -0700 (PDT) Received: (qmail 83388 invoked from network); 20 Mar 2008 17:19:11 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=M+b4RVCqjrO0kDSR3tZTugUco3Nx1yN01Soja5iFY58TkXlizxClxpURJmR5beaOsL7n2b4N1dB6UVEGolmwr6h1OLhB95kndpvU8PcknCji3OObfnDnviHU2i6rJ1jOi52799CUmpO0VG18t4l3mruMTRq2smTDrjsCbP5LJ7g= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@rogers.com@72.140.46.24 with plain) by smtp103.rog.mail.re2.yahoo.com with SMTP; 20 Mar 2008 17:19:11 -0000 X-YMail-OSG: xMbduqkVM1kekzP_wRimvTnoBFVymCqFlPxf4R4sxF0zUQxOibHlAZtY5WwNi5Nw9A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <47E29C8F.3070708@rogers.com> Date: Thu, 20 Mar 2008 13:19:11 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: pcn Subject: [PCN] Consensus call on Q1 - Q3 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org I'll join the chorus. YES, YES, and YES. Tom Taylor _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Mar 20 10:52:51 2008 Return-Path: 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 63F6E28C737; Thu, 20 Mar 2008 10:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.325 X-Spam-Level: X-Spam-Status: No, score=-100.325 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 Q5ZLhB2il+YQ; Thu, 20 Mar 2008 10:52:50 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B30628C69B; Thu, 20 Mar 2008 10:52:50 -0700 (PDT) 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 3050328C69B for ; Thu, 20 Mar 2008 10:52:49 -0700 (PDT) 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 CpylRAH6AeQR for ; Thu, 20 Mar 2008 10:52:43 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 5C23C28C6F3 for ; Thu, 20 Mar 2008 10:52:43 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m2KHoIqq024482; Thu, 20 Mar 2008 18:50:23 +0100 (MET) From: "Georgios Karagiannis" To: "'Steven Blake'" References: <1B6169C658325341A3B8066E23919E1CF64CFA@S4DE8PSAANK.mitte.t-com.de> <75A199C5D243C741BF3D3F1EBCEF9BA503B34667@E03MVZ1-UKDY.domain1.systemhost.net> <004e01c889d1$6d01e4f0$810c5982@dynamic.ewi.utwente.nl> <1205939802.3021.9.camel@neutrino> <005501c889d5$5acccdf0$810c5982@dynamic.ewi.utwente.nl> <1205941357.3021.18.camel@neutrino> Date: Thu, 20 Mar 2008 18:50:13 +0100 Message-ID: <000301c88ab2$dddab990$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <1205941357.3021.18.camel@neutrino> Thread-Index: AciJ1+MI5FcT3On/QSSm/yR8ASiixQA2orKg X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 20 Mar 2008 18:50:24 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Steven I have tried to work out this problem! This is what I have found! I assume that N * ECMP paths are carrying packets that are belonging to the same Ingress-egress-aggregate. I assume that one of the paths fails and one of the routers in only one of the other N-1 paths will become congested. Thus after failure, one path failed, one path is congested and N-2 paths are not congested. I assume that Ci is the minimum capacity (per PHB) supported on a path i. The maximum capacity (per PHB) on the congested router is denoted as Ci_cong. In situation (1) when preferential dropping is used then I find the following PCN_lower_threshold(1): N -2 --- PCN_lower_th(1) < Ci_cong*(1- CLE_thres)-CLE_thres * \Ci / --- i=1 The value of PCN_lower_threshold it mainly depends on the value of the total unmarked rate (of the congested and uncongested paths) that is arriving at the egress. The higher this total unmarked rate Value, the smaller PCN_lower_th(1) must be. In the situation (2) when marked and unmarked packets are dropped with equal probability p, then I found the following equation: Note that dropping probability can be defined as: rt - Ci_cong P = ------------ rt Where rt = total rate (per PHB) that is seen by the congested PCN_interior_node, that supports the maximum capacity (per PHB) equal to Ci_cong. Then the PCN_lower_th (2) can be found as: PCN_lower_th(2) < MINIMUM(Ci_cong ; SECOND_PART), where N -2 --- CLE_thres* Ci_cong - CLE_thres \Ci SECOND_PART = rt - ----------------------------- * / ) (1-p) / --- i=1 The value of PCN_lower_threshold in this case, it has to mainly be smaller than the maximum capacity supported by the congested router. This situation can always be supported. Example: Use N = 6, CLE_th = 1%, p = 50%, Suppose that path6 fails and path1 is the one that becomes congested, rt = C1 + C6, because p = 50% it means that C6 = C1; The thresholds on these tw situations can be then calculated as: When router is preferentially dropping marked packets: PCN_lower_threshold (1) < C1*(99%) - 1%* (C2 + C3 + C4 + C5) ----------------------------------------------------- When router is dropping marked and unmarked packets are with equal probability p: PCN_lower_threshold (2) < MINIMUM {C1; SECOND_PART}, where: [(C1 + C6) - 1%C1 - 1%(C2 + C3 + C4 + C5)]} SECOND_PART= ----------------------------------------- 50% PCN_lower_threshold (2) < MINIMUM {C1; SECOND_PART}, where: [(2*C1) - 1%C1 - 1%(C2 + C3 + C4 + C5)]} SECOND_PART = ------------------------------------------ 50% => PCN_lower_threshold (2) < C1 Therefore, the second scheme (2) can be considered more robust and more stable then the first scheme. Best regards, Georgios > -----Original Message----- > From: Steven Blake [mailto:steven.blake@ericsson.com] > Sent: woensdag 19 maart 2008 16:43 > To: Georgios Karagiannis > Cc: pcn@ietf.org > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > > On Wed, 2008-03-19 at 16:24 +0100, Georgios Karagiannis wrote: > > > Hi Steven > > > > Please see that I have included some information into the > last bullet: > > > > - There is an ingress-egress aggregate whose traffic is > split across > > multiple paths via ECMP. > > - Traffic is admitted along this split path. > > - One (or more) of the paths fails. > > - One (or more) of the remaining paths becomes severely > congested (for > > example because there is traffic from other ingress-egress > > aggregates flowing along that path). > > - < forward packets > > belonging to > > the same ingress-egress-aggregate that will be unmarked.>> Marked > > packets are > > preferentially dropped at the severely congested > > router(s). As a consequence, not enough marked traffic arrives at > > the egress router to drive the CLE for the ingress-egress aggregate > > above the threshold needed to trigger a response (termination, say). > > Ok. To be specific, the egressrouter will see some fraction > of packets from the severely congested router(s), some of > which will be marked, and will see a larger fraction of > un-marked packets from the un-pre-congested routers. > > So let me now ask you this: given N ECMP paths (after a path > failure), with one being severely congested and the rest > being un-pre-congested, and given a CLE threshold CLE_thresh > at the egress router, can you solve for the minimum > PCN_lower_threshold value at the severely congested router, > where PCN still works (e.g., CLE crosses the threshold), for > the two cases where (1) marked packets are preferentially > dropped, and (2) marked packets are dropped with equal > probability with un-marked packets? > > > > Regards, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven Blake > Ericsson/Redback Networks +1 919-472-9913 > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Mar 20 11:02:26 2008 Return-Path: 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 9DECC28C701; Thu, 20 Mar 2008 11:02:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.332 X-Spam-Level: X-Spam-Status: No, score=-100.332 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 nFqgq2IrTtRh; Thu, 20 Mar 2008 11:02:25 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 909063A6D3A; Thu, 20 Mar 2008 11:02:25 -0700 (PDT) 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 73C883A6CA3 for ; Thu, 20 Mar 2008 11:02:24 -0700 (PDT) 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 TViRToM4LYn0 for ; Thu, 20 Mar 2008 11:02:20 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id C264828C701 for ; Thu, 20 Mar 2008 11:02:19 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m2KHxvcH025084; Thu, 20 Mar 2008 19:00:00 +0100 (MET) From: "Georgios Karagiannis" To: "'Steven Blake'" References: <1B6169C658325341A3B8066E23919E1CF64CFA@S4DE8PSAANK.mitte.t-com.de> <75A199C5D243C741BF3D3F1EBCEF9BA503B34667@E03MVZ1-UKDY.domain1.systemhost.net> <004e01c889d1$6d01e4f0$810c5982@dynamic.ewi.utwente.nl> <1205939802.3021.9.camel@neutrino> <005501c889d5$5acccdf0$810c5982@dynamic.ewi.utwente.nl> <1205941357.3021.18.camel@neutrino> Date: Thu, 20 Mar 2008 18:59:52 +0100 Message-ID: <000401c88ab4$35903a10$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <1205941357.3021.18.camel@neutrino> Thread-Index: AciJ1+MI5FcT3On/QSSm/yR8ASiixQA2+AJQ X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 20 Mar 2008 19:00:01 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Steven <> The EXAMPLE contained an error>> The below EXAMPLE is okay! I have tried to work out this problem! This is what I have found! I assume that N * ECMP paths are carrying packets that are belonging to the same Ingress-egress-aggregate. I assume that one of the paths fails and one of the routers in only one of the other N-1 paths will become congested. Thus after failure, one path failed, one path is congested and N-2 paths are not congested. I assume that Ci is the minimum capacity (per PHB) supported on a path i. The maximum capacity (per PHB) on the congested router is denoted as Ci_cong. In situation (1) when preferential dropping is used then I find the following PCN_lower_threshold(1): N -2 --- PCN_lower_th(1) < Ci_cong*(1- CLE_thres)-CLE_thres * \Ci / --- i=1 The value of PCN_lower_threshold it mainly depends on the value of the total unmarked rate (of the congested and uncongested paths) that is arriving at the egress. The higher this total unmarked rate Value, the smaller PCN_lower_th(1) must be. In the situation (2) when marked and unmarked packets are dropped with equal probability p, then I found the following equation: Note that dropping probability can be defined as: rt - Ci_cong P = ------------ rt Where rt = total rate (per PHB) that is seen by the congested PCN_interior_node, that supports the maximum capacity (per PHB) equal to Ci_cong. Then the PCN_lower_th (2) can be found as: PCN_lower_th(2) < MINIMUM(Ci_cong ; SECOND_PART), where N -2 --- CLE_thres* Ci_cong - CLE_thres \Ci SECOND_PART = rt - ----------------------------- * / ) (1-p) / --- i=1 The value of PCN_lower_threshold in this case, it has to mainly be smaller than the maximum capacity supported by the congested router. This situation can always be supported. Example: Use N = 6, CLE_th = 1%, p = 50%, Suppose that path6 fails and path1 is the one that becomes congested, rt = C1 + C6, because p = 50% it means that C6 = C1; The thresholds on these tw situations can be then calculated as: When router is preferentially dropping marked packets: PCN_lower_threshold (1) < C1*(99%) - 1%* (C2 + C3 + C4 + C5) ----------------------------------------------------- When router is dropping marked and unmarked packets are with equal probability p: PCN_lower_threshold (2) < MINIMUM {C1; SECOND_PART}, where: [(C1 + C6) - 1%C1 - 1%(C2 + C3 + C4 + C5)]} SECOND_PART= ---------------------------- 50% PCN_lower_threshold (2) < MINIMUM {C1; SECOND_PART}, where: [(2*C1) - 1%C1 - 1%(C2 + C3 + C4 + C5)]} SECOND_PART = -------------------------------- 50% => PCN_lower_threshold (2) < C1 Therefore, the second scheme (2) can be considered more robust and more stable then the first scheme. Best regards, Georgios > -----Original Message----- > From: Steven Blake [mailto:steven.blake@ericsson.com] > Sent: woensdag 19 maart 2008 16:43 > To: Georgios Karagiannis > Cc: pcn@ietf.org > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > > On Wed, 2008-03-19 at 16:24 +0100, Georgios Karagiannis wrote: > > > Hi Steven > > > > Please see that I have included some information into the > last bullet: > > > > - There is an ingress-egress aggregate whose traffic is > split across > > multiple paths via ECMP. > > - Traffic is admitted along this split path. > > - One (or more) of the paths fails. > > - One (or more) of the remaining paths becomes severely > congested (for > > example because there is traffic from other ingress-egress > > aggregates flowing along that path). > > - < forward packets > > belonging to > > the same ingress-egress-aggregate that will be unmarked.>> Marked > > packets are > > preferentially dropped at the severely congested > > router(s). As a consequence, not enough marked traffic arrives at > > the egress router to drive the CLE for the ingress-egress aggregate > > above the threshold needed to trigger a response (termination, say). > > Ok. To be specific, the egressrouter will see some fraction > of packets from the severely congested router(s), some of > which will be marked, and will see a larger fraction of > un-marked packets from the un-pre-congested routers. > > So let me now ask you this: given N ECMP paths (after a path > failure), with one being severely congested and the rest > being un-pre-congested, and given a CLE threshold CLE_thresh > at the egress router, can you solve for the minimum > PCN_lower_threshold value at the severely congested router, > where PCN still works (e.g., CLE crosses the threshold), for > the two cases where (1) marked packets are preferentially > dropped, and (2) marked packets are dropped with equal > probability with un-marked packets? > > > > Regards, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven Blake > Ericsson/Redback Networks +1 919-472-9913 > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Mar 20 17:45:33 2008 Return-Path: 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 2A1E628C703; Thu, 20 Mar 2008 17:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.35 X-Spam-Level: X-Spam-Status: No, score=-100.35 tagged_above=-999 required=5 tests=[AWL=-0.513, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 myCkAUIVW0wF; Thu, 20 Mar 2008 17:45:32 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C5EB28C2DF; Thu, 20 Mar 2008 17:45:31 -0700 (PDT) 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 0F1E53A6905 for ; Thu, 20 Mar 2008 17:45:29 -0700 (PDT) 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 f5cBtEz-XcU1 for ; Thu, 20 Mar 2008 17:45:11 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id D79183A685F for ; Thu, 20 Mar 2008 17:45:10 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Mar 2008 00:42:50 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Mar 2008 00:42:49 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1206060168933; Fri, 21 Mar 2008 00:42:48 +0000 Received: from mut.jungle.bt.co.uk ([10.73.176.21]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m2L0gFfW020114; Fri, 21 Mar 2008 00:42:46 GMT Message-Id: <200803210042.m2L0gFfW020114@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 21 Mar 2008 00:40:02 +0000 To: Michael Menth From: Bob Briscoe Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 21 Mar 2008 00:42:49.0613 (UTC) FILETIME=[7D1E93D0:01C88AEC] Cc: PCN IETF list Subject: [PCN] Core Marked Flow Termination anti-cheating? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Michael, In your presentation on marked flow termination, you mentioned a couple of times that the core-based approach prevents cheating. Can you elaborate? - I don't see how. Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Mar 20 17:45:35 2008 Return-Path: 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 17CA53A686D; Thu, 20 Mar 2008 17:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.277 X-Spam-Level: X-Spam-Status: No, score=-100.277 tagged_above=-999 required=5 tests=[AWL=-0.440, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_42=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 JPhn0AkOjxXW; Thu, 20 Mar 2008 17:45:31 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF8C93A685F; Thu, 20 Mar 2008 17:45:30 -0700 (PDT) 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 02C393A67A2 for ; Thu, 20 Mar 2008 17:45:29 -0700 (PDT) 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 skiEsFq4nwT9 for ; Thu, 20 Mar 2008 17:45:08 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id DB13D3A6905 for ; Thu, 20 Mar 2008 17:45:07 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Mar 2008 00:42:47 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Mar 2008 00:42:47 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1206060166792; Fri, 21 Mar 2008 00:42:46 +0000 Received: from mut.jungle.bt.co.uk ([10.73.176.21]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m2L0gFfV020114; Fri, 21 Mar 2008 00:42:41 GMT Message-Id: <200803210042.m2L0gFfV020114@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 21 Mar 2008 00:38:30 +0000 To: "BLAKE, Steven" From: Bob Briscoe Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 21 Mar 2008 00:42:47.0050 (UTC) FILETIME=[7B977EA0:01C88AEC] Cc: PCN IETF list Subject: [PCN] Draft Notes of IETF71 PCN w-g meeting PtII, Thu 13 Mar 08 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Steven, & PCN list, Please check whether this represents a true reflection of your experience of the meeting... Thanks to Kwok Ho Chan for his notes to help me compile these. I hope these notes help remote folks like Kwok who clearly had trouble following what was going on, what with last minute slide changes, and loss of audio, etc. Bob ============================================================================ Congestion and Pre-Congestion Notification WG (pcn) Pt II IETF71 Meeting Minutes (Draft) THURSDAY, March 13, 2008 0900-1130 Morning Session I Salon I Marriot Downtown, Philadelphia Meeting materials: Audio archive: ==================================== CHAIRs: Scott Bradner (not present) Steven Blake o Administrivia chairs 5 min - Blue sheets - Scribe - Shuffled agenda relative to that uploaded Initials: [SB]: Steven Blake (when not acting as chair) [BB]: Bob Briscoe [ACh]: Anna Charny [PE]: Phil Eardley [LE]: Lars Eggert [RJ]: Raj Jain [GK]: Georgios Karagiannis [MM]: Michael Menth [TM]: Toby Moncaster Abbreviations used throughout (not incl those coined by individual presenters): AC: Admission control FT: Flow termination CLE: Congestion level estimate ERM: Excess rate marking ThM: Threshold marking AfM: Affected marking NM: PCN-capable but not marked IEA: Ingress-egress aggregate CL: Controlled load (refers to expired draft-briscoe-tsvwg-cl-architecture-04.txt and draft-briscoe-tsvwg-cl-phb-03.txt) SM: Single marking (draft-charny-pcn-single-marking-03) LC-PCN: Load controlled PCN (draft-westberg-pcn-load-control-03) 3SM: 3-state marking (draft-babiarz-pcn-3sm-01) ECMP: Equal cost multi-path PDP: Policy Decision Point o Performance of admission control methods Michael Menth 20 min draft-menth-pcn-performance-02 ==================================== Slides at Acknowledged Frank Lehrieder Presentation summary: Performance evaluation of:- Congestion level estimate-based AC (CLEBAC) = block if fraction marked/all exceeds a threshold - Observation-based AC (OBBAC) = one marked packet switches IEA to block state, switch back to admit if no marked packets for a timeout Simulation set-up - Single bottleneck link with n (~100) independent sources - Different size IEAs over this link (n or 10) Metric used: fraction of time (flow blocking prob) when false AC decisions: - False positive = admit when shouldn't - False negative = block when shouldn't Q. Anna Charny: Does 10 flows mean 10 in aggregate, or are there also only 10 on the link? A. No, 10 in aggregate but 10% over-capacity means 110 flows on the bottleneck link. Not saying SM (or ERM) is bad, just that it doesn't work well with small IEAs. It's not a property of the link aggregation. It's a property of the ingress-egress aggregation. This is just a property that we would have to live with. Results false false parameter Summary negt'vs post'vs sensitivity __________________________________________ CLEBAC ThM few few little OBAC ThM many few little CLEBAC ERM few many little OBAC ERM few many significant With ERM, blocking ratio is still low with 10% more flows than intended, but with OBAC you can configure the detection algo to have a fairly high blocking ratio at 10% overload by requiring a long time without any marked packets in block state before returning to admit state. This says OBAC can give better AC in the cases we have investigated. Probably haven't done as many simulations as Anna, but there are cases where OBAC gives better results, essentially in small aggregates. [ACh]: In SM presentation we'll try to quantify the excess capacity you need to avoid false positives. Will give quite precise numbers. But results broadly in agreement with more extensive simulations we did. Summary With ThM everything's fine. With ERM many false positives if IEA small (10-30 flows) Questions usefulness of AC based on ERM, but on other side can say it is useful but just need to know its limitations. OBAC also not good in that case, but have seen it can be better than CLEBAC. No figures available on the speed of admission control, but OBAC designed to react faster, which is important when we have a flash crowd, but with CLE-based, we have to wait until the end of a measurement period. Questions? [ACh]: Rather than saying ER marking is useless for small IEAs, a more accurate statement: If you used ER marking you would have to account for the relatively larger error that results which would translate into the appropriate capacity guidance. Certainly better than saying it doesn't work, but it is certainly more inaccurate with small aggregates than we would like to see. [MM]: [Essentially agreeing] Don't say it doesn't work. We need to know: Do we have small IEAs? etc We need to know whether we have difficulties, and if so how do we deal with them. o Edge-assisted marked flow termination (EMFT) Michael Menth 30 min draft-menth-pcn-emft-00 ==================================== Slides at: Summary of presentation: Marked flow termination (MFT): terminates some flows that are marked. Better for ECMP because only flows marked are terminated. Problem: too aggressive if terminate every flow with a marked packet. Solutions: Marking frequency reduction: - Core-assisted MFT (CMFT - same as 3SM): Modify excess rate marking to proprotionately mark - Edge-assisted MFT (EMFT): Edges only terminate some flows that receive marked packets EMFT, two options: - Flow-based EMFT: Per flow credit counter initialised randomly; each marked byte reduces counter, when .le.0, terminate flow - Aggregate-based EMFT: Per IEA credit counter initialised randomly; each marked packet reduces counter, when .le.0, terminate a flow picked from IEA; increase credit counter proportionately to rate of terminated flow [BB]: Credit counter should be decremented by no. of marked bytes, not packets, to be fair to small-packet flows. [MM]: Y [slide says bytes, incorrectly said packets] Expt set-up: single bottleneck, termination rate at 100 flows. 100% overload. 200ms termination delay. No packet loss is a recognised limitation. [GK]: Suppose there is severe congestion somewhere, traffic going through the congestion point will get rerouted to another route, then at least one point in the new path will get congested and packets get dropped. At that point the terminate marked packets will never get to the edge. Then this will not work. If have severe disaster, traffic going through the congestion point will get rerouted to another route, then at least one point in the new path will get congested and packets get dropped. If packets that would have been marked are dropped preferentially, may not get enough marked packets to trigger termination. May not get /any/ packets through for some flows. If this problem is not solved then we fail on getting a sufficient solution for flow termination. [MM]: Will get enough, but yes, it will slow down termination. We solve this problem by ensuring the termination threshold is not too close to the link rate. [GK]: Repeated point about possibly not getting /any/ marked packets in some flows with sever congestion of >100%. [MM]: Not true, as long as termination threshold below link rate, then flows get termination marks. [GK]: /Some/ flows. [Chair]: Pls continue presenting (? inaudible?) Flow termination delay is feedback time of system. The time between termination being triggered and no more packets from that flow arriving at the egress. Parameter we have to take into account: set to 200ms and did sensitivity studies. Knob to control termination speed: Termination aggressiveness, alpha. Controls marking frequency reduction. Same alpha for core or edge solutions. Can control tradeoff betw speed of termination and over-termination. If too high, over-terminates. If too low, termination too slow but doesn't over-terminate. All the approaches have similar mean termination curves with time, but the differences can be seen by plotting the 5th and 95th percentiles. Then flow-based EMFT has wider variance. Termination process still inreasonable, controllable, bounds. For larger (double) overload, still get fast termination in one more cycle, because of exponential nature of termination curve. Packet loss not simulated would reduce termination speed (shortcoming of simulations). Differences between variants. For all, flow termination delay affects termination speed. But not fairness - ie if long & short flow termination delay mixed in same network, they have the same flow termination probability. Comparison: * CMFT: - Termination - No termination priorities - allows anti-cheating for e2e PCN (no details - not in charter) * EMFT - termination precedence possible - flow & aggregate both suitable, but richer policies with aggregates - per flow suitable for e2e (not chartered), per aggregate suitable for PCN domain Summary: Have added analysis of edge-based marking frequency reduction to previous work in 3SM on core-based marking frequency reduction. Marked-flow termination exactly same whether marking freq reduction at edge or core - same knob in both cases. Mechanism self-corrects so invariant to many system parameters (see papers for which parameters are important and have an impact). Severe overload and packet loss missing in this study, but important and needs quantifying. [BB]: Important decision for group: Do we put marking freq reduction on core routers or at the edge. Did this study show there was any statistical difference? [MM]: Managed to design system so termination behaviour is exactly the same. Pointed out differences: Core-based allows for anti-cheating control at the borders. However, edge better control on termination process because - termination behaviour independent of different packet frequencies (packet sizes) so we get better fairness - can apply policy control to flow termination. [GK/MM]: Repeated exchange above about packet losses. [GK]: Only 20% of the 110% over link usage, resulting in 10% of the re-routed flows will reach the termination decision point. Hence the termination decision operation will be very slow. [GK]: Could be a lot slower [MM]: May be 2 s instead of 100ms [GK]: 1 min [MM]: no (chuckling) o LC-PCN Georgios Karagiannis 20 min draft-westberg-pcn-load-control-03 ==================================== Slides: Acknowledged Lars Westberg, Anurag Bhargava, Attila Bader. Load Controlled LC-PCN Presentation summary: LC-PCN provides solutions to the 3 main issues: * AC - Data marking - Probing (solves ECMP during AC) - Combination of both * Flow termination - Base mode - optimization mode * ECMP solutions - AC - using probing - FT - using affected Marking ECMP problem outlined (see slide) ECMP AC solution: - if interior node congested, then all probe packets must be marked - problem: with ER marking not all packets marked - solution: use router alert option so interior nodes know it's a probe packet and mark it always if rate is above admission threshold Raj Jain [RJ], Washington Uni: If probes special they could be small so many more could be handled than data packets. They need not have single bit, but could contain fields to carry more information from the congested nodes. [GK]: next slide explains this. Lars Eggert [LE]: Brought up on list: Because ECMP not standardised, don't know whether router alert will make probe could go through slow path and not see ECMP - we don't know. Might take a different path. Could work but we don't know that. [GK]: That's True Phil Eardley [PE]: Two points on one slide. Other point is correct (all probes must be marked). But an operator might just implement Ac and not FT and hence may not choose SM as the algo for 2 codepoint solution. May possibly do something else for Flow Termination. [LE]: In that case, should use the SHOULD and not MUST words. [GK (realising answer to Raj's question is not on next slide, but continued)]: Probes must have same flow ID as user packets so they will be treated same as user packets. [LE]: But you don't know that (repeating point above) so can't depend on this behaviour. [GK]: This could be different for RFC3175 where e2e RSVP path is used with a different protocol ID and aggregation level 0. I'm not sure how it works but it might be that the RSVP path is not taken out of the fast path. [LE]: Problem: no standard that says router alert packets must take same path as normal packets. [SB]: Isn't it a problem is RSVP PATH messages (and the reserve state they pin in the other direction) aren't on the same path as the data flow? [BB]: I thought, if PCN being used, RSVP turned off on interior nodes, so RSVP would just be treated as data [GK]: True [BB]: (but may have different addresses) [ACh]: At least two reasons that might make this not work: i) Router alert as we've heard. ii) If probes have different protocol ID, ECMP will likely treat them different to data [KG]: Might work if RSVP run on top of UDP, otherwise a problem. ECMP & flow termination ----------------------- Aim: Only flows passing thru congested nodes marked for termination When PCN interior node in flow termination state, all packets not marked for termination are marked as AfM. Need extra encoding state with ECMP: AfM Egress can only select flows marked for termination or AfM Parameters globally equal across PCN domain U,N .ge. 1 (see draft) N is proportionality between measured and marked excess rate. N can be used to solve the previously mentioned problem (loss of marked packets), when node congested, can mark all the rate that is congested, even the rate that will be dropped. When ECMP isn't supported only uses one encoding state. But for optimisation accuracy, some things have to be changed. Eg. marked excess rate = measured excess rate / N. Measured before dropping, marked after dropping. And PCN mark-encoded packets should not be preferentially dropped. [ACh]: LC-PCN identical to SM, but with one big, important exception. SM looks at unmarked packet at edge, LC looks at marked packets, so dropping preference for marked packets has to be reversed. [GK]: Yup Flow termination - Basic mode as described - Optimization mode: uses sliding window to allow for delays between measurements on egress & ingress nodes, Optimization mode on interior nodes (see slides or draft for state diagram & state change events, & algos) [BB]: Are you saying this would need to be standardised, or that this is something people can choose to do? [GK]: That the algorithm works and accuracy can be improved. Detection of AC identical to SM draft AC with probing at egress based deterministically on marking of probes (to solve ECMP) Flow termination identical to SM Egress node state diag & state change events (see slide) Ingress nodes easy (obvious) Probes can be user or signalling. Repeated other previous facts about probes. Summary LC-PCN at ingress: - Different to SM LC-PCN at interior: - Admission control with data marking: - Same as SM draft, but to increase accuracy small modifications needed - Admission control with probing (additional option to solve ECMP) - Flow termination: - Base mode, same as features used in admission control with data marking - Optimization mode (optional feature that is required in order toincrease accuracy of algorithm) - ECMP solution (additional and optional feature that requires a flow termination state and additional encoding state) LC-PCN at Egress: - Admission control with data marking: identical to SM - Admission control with probing (additional option used to solve ECMP problem) - Flow termination: - Detection feature: identical to SM - Selection of the flows to be terminated: different than SM - Feedback to ingress: different than SM - ECMP solution (additional and optional feature) Why is this presentation done here? Insight into solutions provided by LC-PCN Show how close LC-PCN is to SM o Discuss encoding options Moncaster 40 min (Carried forward from Tuesday session) ==================================== Slides not yet available on the meeting materials site, but the attachment to Toby's posting to the PCN list should be useful: (Windows users will have to force a .bin file to be read by their Acrobat Reader) Intent: Wrap up encoding discussion from previous mtg (bumped from Tuesday's agenda) trying to reach consensus on encoding questions. Need to have been following list - moving rapidly this week. Two basic options: 2-state solution for single marking Proposal: standardise 2-state solution and simultaneously produce experimental extension scheme providing for a 3-state solution. If expt successful and lots of operators require it, then we'll come back with the aim of standardising a 3-state solution. Constraints - need to minimise no's of standards space DSCPs - avoid interactions with tunnels - comply with relevant RFCs Probably got agreement from Fred Baker that it would be appropriate for PCN to use the VOICE-ADMIT DSCP he has in tsvwg last call (draft-ietf-tsvwg-admitted-dscp-03) - may or may not be standardised (with that name). New scheme on list from Toby & Bob Briscoe - v young * Basic scheme using one DSCP (Fred's VOICE-ADMIT) - Not-ECT = Not-PCN, ie treat as for Fred's draft, and not a candidate for PCN-marking - ECT = PCN-capable but Not Marked (NM) - CE = PCN-capable and Excess-rate marked (ERM) * Extended scheme to allow experiments with 3 marking states and e2e ECN - Any packet with VOICE-ADMIT DSCP would mean the same as the basic scheme, except: o ECT = PCN-capable but NM and originally ECT before entering this PCN domain - Another DSCP (initially from the LU/EXP range) would be give 3 extra states o Not-ECT = PCN-capable but NM and originally Not-ECT before entering this PCN domain o ECT = PCN-capable but NM and originally CE before entering the PCN domain o CE = PCN-capable and Threshold marked Possible state transitions are given in the slide Two possible consensus questions Q. Can you live with only standardising a 2 codepoint solution? [BB]: I assume you mean initially standardising, not for ever? Q. Can you live with only initially standardising a 2 encoding state solution? [Chair]: encoding states not codepoints Q. Can you live with only initially standardising a 2 encoding state solution? [LE?]: (inaudible) [Chair]: As an initial standardisation effort for PCN, will people be not violently unhappy if we only pursue to standardising a solution that uses 2 encoding state solution [Chair]: Show of hands [Chair]: 8 for - 0 against - rough consensus Q. Do you agree that we should simulataneously aim to produce a 3 encoding state solution as an experimental extension [GK]: I don't understand what exactly the experimental extension includes? [LE]: Motivation: Feedback from some operators says minimising DSCPs is a must. But some of the schemes have a creative interpretation of what a codepoint means. Some do hop-by-hop marking, which some people say is outside what Diffserv would allow you to do, while others say that's not the case. but it appears better to consume fewer codepoints. There is also this range, not only experimental but local use (EXP/LU) that are defined by the Diffserv RFC. So the proposal is that if a standards track codepoint is used to provide a minimum set of PCN functionality, especially if we use the codepoint being defined in tsvwg, which you've called VOICE-ADMIT but the title is actually Capacity Admitted traffic. So the experiment will be to see if operators would rather make the tradeoff of consuming an extra codepoint to get an accurate solution, or whether they be willing to have a less accurate solution so they could use the codepoint for something else. Later on, if we've gotten some deployment experience, if many operators have shown they want the more accurate PCN scheme, we've then got stronger argument to take to the wider community to get an extra codepoint for PCN. [GK]: OK [GK]: Another question that would arise: where detection and handling functionalities could be located (ingress or egress) [TM]: That is irrelevant to this question (interrupted)... [Chair]: Not trying to rule out any particular edge arrangement, not deciding which of the 3-state schemes we might use [GK]: Do you agree that another question would be should we have two 3-state solutions? [Chair]: True [GK]: A third question could be whether we optimise ingress-based functions and another question could be whether we optimise egress-based functions [PE]: Clarifying question: Do you mean you want a question on whether we have 2 experimental DSCPs? [GK]: That's not how I understand it [Chair]: I'm trying to avoid the ambiguous term codepoint and use only encoding states Q2: Do we agree that we should do some work to produce at least one experimental extension that will use at least three encoding states? [Chair]: Show of hands (some confusion broke out) [Chair]: Before we call it again, any questions on that question [BB]: To clarify what Lars said, rather than getting another DSCP, we might instead have enough weight to go to the Security area and get the ECN tunnelling behaviour fixed to give us more encoding states in the ECN field. [Chair]: Let's just stick with encoding states and leave the details out. Q. Do we agree as a w-g, that we should do work on experimental extensions that would utilise at least 3 encoding states? [Chair]: Show of hands [Chair]: 9 for - 0 against [SB]: Think phrased it vaguely enough to not preclude what you, Georgios, are suggesting. Are you happy with that? [GK]: (interrupted...) [LE]: Let me summarise consensus in a different way to see if you still agree with it: [Chair]: OK [LE]: As I understand it, the consensus is there will be a stds track RFC with an encoding state that PCN compliant implementations MUST use. There'll be a 2nd document that is likely going to be an experimental document (sorry, one or more experimental documents but at least one), that uses another encoding state that is optional to implement. That means that if an operator decides to deploy the experiment, they need to purchase equipment that implements that extension. [PE]: You've only talked about encoding states, not the marking behaviours they imply. I agree when you're just talking about encoding states, but if you also link that into saying something about marking behaviours, then I'm not sure I would agree. [Chair]: Anna's next presentation will talk about an emerging consensus amopngst propoers on core marking behaviours, so can we defer that discussion until after her presentation? [LE]: OK [Chair]: Anyone object to Lars's restatement of the consensus? (no-one) o PCN Comparison draft-charny-pcn-comparison-00 Anna Charny 20 min ==================================== Slides: Presentation summary: Comparison draft - slides not really going to describe that - describe emerging consensus. Work not just of comparison draft authors but most of proposal authors Comparison draft created for last IETF. Functional comparison. Simulations comparing proposals. Included pseudo-code monstrosity encompassing all core marking proposals (CL, SM & 3SM). Some now obsolete. Developments since: MM's edge-based marked flow termination LC-PCN clarification and evolution - essentially we have another proposal - also described. Given the drastic reduction in encoding states due to tunnelling, I will try to reflect emerging consensus. Try to describe what will be lost with only SM. Will not compare proposals, which is what the comparison draft is supposed to be about. See inidividual drafts and the comparison draft itself. If we assume we have only 2 encoding states, we have 3 options: only admission, only termination or both. If we allow option of both, then whatever proposal is put forward for standard marking, we must support SM. Not strictly correct, because LC-PCN also only uses 2 states but the point is SM is the core of both proposals. So, given it looks like we will go forward with more sophisticated proposals as an experimental track, as a result, any proposal to go forward must support SM. We must describe the boundary behaviours for whatever solution comes up, but, although we'll try not to constrain anything too much, whatever we describe must not break SM, unless or until other better schemes can be offered. However, we want to try to keep door open as possible, given constraints to other proposals If we only have 2 encoding states, what is lost if we have AC only, or termination only? Obviously the other. Also need to add configuration about which one you are using. Need to support SM as the core. Not clear to me that anything else is lost if we did just termination or just admission. [PE]: In your phrase "If we want both", does 'we' mean an operator, it doesn't mean the w-g? [ACh]: Whatever the w-g does, it needs to know which of the two options to go. [LE]: Also, if we do only either one, losing some ability to control each function: e.g might get into termination state more often if don't do admission [ACh]: Right. Implicit assumption that there is enough interest in having both AC & FT. If that's not the case, a lot of the things I'm going to say will become irrelevant. Assuming SM must be supported, must have ER metering & marking [GK]: I'd like to allow optimisation just presented [ACh]: Slides assume not, but will talk about that later Other things core node should do - if arriving packet already excess-rate marked, then don't meter - any arriving packets already excess-rate marked should be preferentially dropped if drop required - if metered packet is dropped, don't excess rate meter it Other things that must be defined - egress to ingress (& possibly PDP) messages contain: - CLE - sustainable rate - (optional) rate to terminate - (optional) ingress sending rate - Boundary node behaviours to be specified - implicit assumption SM will be the initial behaviour, but more may be defined What has been lost? - Req of pref dropping excess-marked packet is problematic for 3SM, EMFT & PC-PCN - Limits possibility of defining simpler edge behaviours. - And very suboptimal for LC-PCN - This proposal limits possibilities of optimisations at core nodes, effectively ignoring all of those in LC-PCN. That needs to be discussed whether this is alright. Reasons: - Requires core complexity - Insufficient simulation evidence of benefit of these core optimisations [GK]: Would like option of including that later [ACh]: Stds track marking behaviour can't have a SHOULD, must have a MUST. So need evidence that optimisation necessary [GK]: Evidence is there in papers [ACh]: Evidence you're referring to is for a diff algo [GK]: But similar, the way it terminates flows is exactly the same [ACh]: Need stronger evidence for a MUST, not a SHOULD [GK]: Well I do not agree with that (shrug) Other sacrifice is performance: - small no. of flows per IEA - not an infrequent case at all - some perf degradation for multiple bottlenecks on path - see following presentation - No ECMP solution (needs a further encoding state), so only way to deal with ECMP is probing. But we don't know how to do probing well. SM suboptimal for support of probing because it needs more probes than other methods - For termination, SM doesn't have enough hooks to stop some flows on path being terminated that are above their admission but below termination theshold - doesn't allow simpler edge implementations possibly afforded by 3SM & EMFT solutions [LE]: Clarification question: Which of these limitations cannot be addressed by some amount of over-provisioning? [ACh]: None cannot be addressed by some amount of over-provisioning, will be addressed in SM presentation [MM]: Probing to find edge nodes - hard to do admission control without it - cannot be solved [ACh]: Are you saying probing is needed for address discovery? [MM]: N [Ach]: OK [MM]: Other methods are required [ACh]: Probing never been assumed to be that method [GK]: egress behaviour not good for LC-PCN - extensibility is important, eg end-edge or centralised scenarios [ACh]: Two things that prevent PC-PCN solution: i) absence of core optimisation. Dropping of SM not good for LC-PCN [GK]: Also not good for SM [AC]: What? [GK]: Repeated point about dropped packets from previous presentations [ACh]: No. See email I sent this morning - two examples you gave are not correct for SM Chair: Take that offline Chair: You're going to say what you don't get with SM, so we won't have consensus calls until after that [BB]: To answer Lars's question: - ECMP problems of SM wouldn't be solved by overprovisioning - We don't have a way to go to multiple non-trusting domains with SM, which wouldn't be solved by overprovisioning either Previous slide said core must do ER marking. Where does that leave ThM marking? Core MUST do threshold marking if want to expt with 3 states or if we want to allow just admission - the 2 state solution no longer allows doing just AC with ThM. So this proposal eliminates that option. [PE]: Uncomfortable about operator not being able to do AC with PCN and termination with something else. And to be able to do that with just the 2 encoding states. [ACh]: If wanted to do only AC, would either have to i) say MUST do both marking behaviours, or allow a SHOULD, which we've previously said was not OK for LC_PCN or iii) we can say EITHER/OR at which point we have an interoperability (?) problem. So we have to decide. [LE]: We can't have a SHOULD. Need to have 2 MUSTS, otherwise equipment can't interoperate in one domain. While if you have equipment that implements the two MUSTS you can configure it to do either one. [GK]: Repeated 2 things Anna stated this proposal ignores. [ACh]: Agreed. These this proposal ignores these two things so there would obviously need to be consensus to do that. [GK]: If these two are ignored, then an egress-based solution will not be possible. [ACh]: Correct. It will require another standard to do that. it will not be possible if we go with any of the three proposals we just discussed, whether we do a MUST to both ThM & ERM then (interrupted...) [GK]: Yes, but 3SM and flow marked solution do not work [ACh]: That was in the previous slide (interrupted...) [GK]: Does this mean the egress-based solutions are excluded from now? [ACh]: No what it means (interrupted...) [??]: No, that's what it means [ACh]: So, what it means (interrupted...) [GK]: It indirectly means egress-based solutions are excluded [ACh]: No. [GK]: Why not? [ACh]: What it means is any egress-based solution that would work with egress-based termination would work [GK]: But doesn't work well. [ACh]: I think we're in agreement, that some of the schemes that do egress-rate termination do not work well. So in order to reach consensus we need to make some sacrifices (interrupted...) [GK]: Yes, but in order to do sacrifices (interrupted...) [ACh]: I'm trying to simply say what the sacrifices are (interrupted...) [GK]: Yes, but in order to do sacrifices we have to have the right information, and if we don't have the right information we should get it. If we take a wrong decision now then we'll have to change a lot of things later. [ACh]: You're point is taken, there are some solutions that are precluded by this proposal. [Chair]: OK [ACh]: What do we need to do? - Which 2 state solution to pursue (3 options)? - Agree on specific encoding - not the point of this presentation - Once agree, need to write draft - Need to specify the signalling requirements for whatever we agree on - Write boundary behaviour o Single Marking Anna Charny 20 min draft-charny-pcn-single-marking-03 draft-zhang-pcn-performance-evaluation-02 ==================================== Slides: Acknowledged Joy Zhang Presentation summary: Single marking poor compared to CL for small aggregates, wrt admission but particularly termination. Also somewhat worse than CL terminating in the presence of overload at multiple bottlenecks in series. Single marking generally comparable with CL for large IEAs Of course, can never check every case no matter how many simulations, but some comfort in that these simulations were run to find how bad SM was relative to CL, not how good it is. * AC: SM has significant AC error only when IEA v low < 10 flow/IEA due to synch effects with CBR. Effect disappears with enough randomization of CBR [BB]: When BT put a typical distribution of sizes of aggregates for their UK core network on the list, a very large proportion of aggregates were small, because, with 100 edge nodes, there are 10,000 possible aggregates and the distribution is long tailed with most aggregates empty. Is it any different to the 'low' figure you have mentioned here, where your 'low' means <10 flow/IEA. [ACh]: Answer not from simulations, but from intuition gained from simulations. If all of these little aggregates take a relatively small proportion of your bottleneck link, that actually will not be a big deal. However, if these small aggregates take a large proportion of the aggregate link, then this problem well become (significant). But I don't know which of the cases will be more reasonable. [BB]: So what if IEA was 2, which it was in a many, many cases? [ACh]: The rightmost side of the plot is where there are as many flows as aggregates, so that's the case you're concerned about. [BB]: Where the black (CBR) plot goes off the (over-admission) scale? [ACh]: Y. * FT: Again, over-termination with SM, again, due to uneven marking across flows which is noticeable when there are few flows per IEA. Degree of IE aggregation SM needs for < 10% over-termination is ~50 to ~150 Flow/IE, whereas CL is generally always within 10% for any size IEA. Emphasise that these are truly the worst of the simulations we could find. Can fix by smoothing FT signal, but trades off reaction time. Simulation did not assume smoothing. * Multi-bottlenecks in series problem: - FT: Charts represent average of many thousands of simulations. CL stays within 10% (and most below 4% error), while SM has a good proportion still in the 10-20% error range. - AC: SM & CL fairly equivalent in this respect. Fairness slightly worse with SM, but not at all significant. Summary: SM comparable to CL for aggregates of sufficient no. of flows, sufficient meaning: - ~10 or more flows wrt AC - 10-100 flows wrt FT. - At low ingress-egress aggregation, Single-Marking is less accurate (over-admission & over-termination) - In the presence of multiple bottleneck, Single-Markingtermination performs worse than CL-PHB [GK]: Before freezing the behaviour of the core node I'd like to have the possibility to prove the the LC-PCN mechanism works. [ACh]: So what are you asking? To delay the decision? The only decision is what exactly the core node function includes. [GK]: The decision is single marking, that is already taken. [ACh]: That's a decision for the chairs. [GK]: If the LC-PCN optimisation is included, the SM functionality will not be affected by it. [Chair]: I'm in process of formulating a question for the w-g. Something I omitted to say earlier. There may be IPR on some of the proposals before this w-g, and I encourage you to go look at the IETF IPR pages and review those IPR disclosures. Is this a satisfactory statement for the ADs? [LE]: Y [BB]: Coming back on what Georgios said, the longer there's delay less chance of implementers still being around. The whole thing requires doing in a finite amount of time otherwise it will never happen. We're already 6 months late, so we need to be aware that if we delay it may never happen. [GK]: The delay will only be 2 months. And the delay will not be a delay, because we already have made the decision to use single marking. The only decision is if the MUST should be a SHOULD or not. I'm not asking for another option. If I can prove the LC-PCN mechanism works then the egress-based functionality could work, then we can set the SHOULD to a MUST. Then if it doesn't let it stay as SHOULD. [ACh]: This proposal has been made in view of the fact that there seems ot be no more time doing the research in this group. We need to look at the existing proposal today to have a chance of anything happening. The reason this proposal came about was so that something was available now. [PE]: My view would be that we go forward, then in 2 months time if you bring evidence that yor idea brings us loads, 2 months is not going to be too late to say we gain all this by doing your proposal. But I think we've got ample evidence now to know what direction we should take now. The problem of waiting 2 months is that we will still be arguing at that point whether we have enough evidence on your proposal to make a decision. [GK]: I think I've been misunderstood. We have made certain decisions (interrupted...) [ACh]: We haven't made any decisions (interrupted...) [Chair]: Reiterate that we've only made 2 decisions on encoding state aspects so far [LE]: We haven't reached consensus on router behaviour, how exactly it marks packets which is still open, which is what we're discussing that now. [GK]: We have the single marking behaviour [PE]: We haven't had a consensus call on the single marking behaviour [GK]: Yes, I know. But this has not to do with gain, it has to do with extensibility. [ACh]: I would propose to delay the discussion until there is evidence, and when there is evidence we can revisit the decisions. Today there is no evidence and we are running out of time. [GK]: In the formulation of the question can we have this opening? Chair: Does w-g feel they have enough info to come to some conclusion about a way forward here at this time? [Chair]: Show of hands [Chair]: 6 for - 1 against [Chair]: Proposal by Anna for a 2 encoding state solution that we could move to standardise thats based on a type of excess-rate marking [ACh]: To be clear, the proposal is that the core does excess rate marking (interrupted...) [Chair]: In a particular way... [ACh]: No, just using a standard token bucket, but with the specific additions of how already marked packets are handled [Chair]: Right [PE]: Pls clarify exactly what the question. [Chair]: There is a proposal on the table for excess rate marking which has specifics about how previoiusly marked packets and dropped packets are handled. And the question is, who in the w-g believes that is a reasonable path to move forward on, so that we can empower a design team to go write that up in the direction of becoming a w-g doc for a standardised solution? ... I probably should re-phrase that a little bit [PE]: I'm very comfortable with having that in std as a MUST. My question will be then whether there will be an opportunity for anything else to be in the std as a MUST, ie threshold marking. Or whether, in that question you're saying that would be in an experimental RFC or if that is also in the stds RFC, and then you have this configuration thing. [LE]: Let me try to rephrase the options. Earlier we had a call on whether we have a two state standards option with a three state experimental extension. Now we're talking about how these bits get set. - One algorithm option: Single MUST algo to do excess rate marking and that is the only thing that a router needs to implement to be a PCN-compatible router. - Other algorithm option: Add another MUST that say eg. you can configure router to set those same bits Keeping in mind that having a long shopping list of options on marking schemes in a router defeats the purpose of standardising PCN, because it allows the space to fragment and everyone gets their own scheme again, which is something we wanted to avoid. - One scheme we thrashed out this morning was that the router MUST implement ThM as well as ERM, and it can be configured for AC without FT, so for a deployment scenario you use the ThM to set the two encoding states rather than the ERM. That's one option. That seems relatively simple, but it's already twice as complex as having one mandatory to implement scheme. [ACh]: That would mean that each router that claims compatibility with PCN and is used in the single marking case is actually required to implement something else - just to clarify? [LE]: Would need to implement two marking algorithms. Yes. That would be one proposal. Rationale: All expt schemes need ThM of some type, so could have 2 MUSTs. However that's up for discussion. [ACh]: The drawback would be that fewer vendors would be interested in implementing that. [LE]: Sure. It's a tradeoff [GK]: Could the optional points related to egress-based termination also be included in an extension draft? [LE]: Personal (hat off) interpretation. When we chartered PCN, there were multiple solutions that all required different marking schemes. Not good, as a vendor it required you to implement multiple things. 4 schemes instead of one. Or 5 or 6. For interior we wanted one solution that allowed multiple ingress-egress behaviours. With informational documents that might discuss how you implement different ingress-egress schemes using the one interior behaviour. If we talk about many interior schemes, especially many schemes with interior complexity, we would be in effect standardising multiple solutions here. That I would personally like to avoid because then, why do we have the w-g? There would be no need to standardise anything if you have could have had all the options long before with proprietary solutions. [ACh]: Propose a sequence of questions to get us out of this. What if we ask whether: There is consensus that this kind of marking is required for PCN first. Then we can ask whether, at a later point, if there is evidence that hte additional enhancements that Georgios is proposing are beneficial then we'll revisit that. Third question: Must we also require implementation of threshold marking initially. [LE]: THe beginning questions are good. I'd like to caution that the motivation for allowing multiple schemes must be more than that you don't want to see your baby die. [GK]: But it's about where the flow termination is actually handled [ACh]: But we're not discussing that. [GK]: No, but it's related to what Lars just said. [ACh]: This has nothing to do with the core behaviour. [GK]: The difference is not about performance, because I think the SM performance (interrupted...) [LE]: If performance is not the reason, why does it matter where functionality sits? [GK]: It has to do with deployment scenarios - if we want to deploy FT at the egress, because there are some scenarios e.g. centralised node that is using using the information from only one point. And the other scenario where you have end-edge, if we close it now then if we recharter there will be no chance to work on these things. [ACh]: Georgios, there is no evidence today for what you're saying right now. If this evidence comes up, can we revisit then? if you want the centralised node case, that still doesn't matter if you make the decision at the ingress. I don't know about the end-edge case because we haven't discussed that. This might come up in the future. [GK]: That's why it's called extensibility, no? [LE?]: You (Anna) were going to ask a question. [ACh]: So I'm going to ask a question. Does the w-g agree that the core behaviour described today which is essentially token-bucket-based excess rate marking with additional handling of excess-rate marked packets is a MUST for the PCN core node behaviour? [PE]: That depends whether by saying that, that's it. [ACh]: other question that could be asked first: Does the w-g believe that the equipment must be forced to implement two types of markings today? [MM]: I think it is a must for preferential treatment and single marking to work properly. Iit would be a good to have an option, not to require, preferential marking for experimental development. [ACh]: If a SHOULD were allowed in the standard, I would be happy to have a SHOULD for this preferential treatment, but I don't know whether we're allowed to put a SHOULD in. [LE]: I would really like the option space to be very, very small here, because we can't have 20 different marking schemes. [ACh]: Actually the SHOULD in this case (interrupted...) [LE]: Actually you're second question is imprecise, because two doesn't say what the other one is. [ACh]: Threshold marking, as defined by Phil in his presentation yesterday, which means roughly virtual-queue based marking. [LE]: Q1 Do people agree whether ERM is a MUST [ACh]: And the 2nd question is whether ThM is also a MUST. But Phil wants the 2nd question asked first. [PE]: I don't mind as long as (interrupted...) [BB]: I want to put my dilemma to the w-g, because I don't how to answer these questions because neither give what I'm looking for but I can't think of another way of doing it. The problem is all these schemes eventually will need two sorts of marking, given the evidence shows SM has problems, but I'd like there to be two MUSTs. But I don't want that to mean an implementer has to say, I can't sell a machine that does PCN now because it won't comply with the standard, because I can only do SM now with my current hardware. [ACh]: So the tradeoff again is if we ask both now, we have immediate capability to do experimentation with any PCN implentation, but it then requires every router to implement this functionality, even though the use of this extra marking is experimental. [BB]: It doesn't require every router to do it. It requires every router to do it to be PCN-compatible. [ACh]: Right, right, right. Every router that is required to do anything for PCN would be required to do something that is experimental and not standard. To me that's a bit of a problem. I would prefer that all the MUSTs for the experimental scheme would go into the experimental standard. [BB]: But then you've got configuration complexity later. [ACh]: Right, right, right. [LE]: When we say MUST, we mean must implement to be be minimally PCN-compliant. [ACh]: Yes, that's the proposal. [GK]: I didn't see the third question. [Chair]: I'll let you ask the question [Chair]: Questions will be about Excess rate, then the 2 MUSTs, then Georgios's question. [ACh]: Does the w-g agree that a PCN-compatible node must implement excess-rate marking with additional handling of previoiusly marked packets as described in this presentation? [Chair]: Show of hands 8 for - 0 against [ACh]: Does the w-g think that a minimal PCN-compatibility statement will say you must also implement threshold marking? [Chair]: Show of hands 6 for - 1 against [GK]: Actually it's the first question but having some time to bring some evidence to show whether LC-PCN is able to perform well in an egress-based scenario. [Chair]: I don't understand - would that preclude doing ERM in the core? [GK]: I'm not sure if the question included the exact description of how it was done here in the slides. [Chair]: Of how excess rate marking is performed? [GK]: How the token bucket is implemented [LE]: (to GK) assuming you get time, what is the question you will ask then? (Audio recording terminated) [GK]: Is it reasonable to include the additional optimisations of excess-rate marking in the standard? [BB]: Will it interwork with the details we have just agreed to? [GK]: Not sure. [LE?]: If evidence is produced before IETF-72 that there is an improved way, would w-g entertain replacing our standards work on the algo? [Chair]: Show of hands 2 for - 0 against o A Simple Analytical Model for Pre-Congestion Notification Raj Jain 20 min ==================================== Slides: Acknowledged Jin Jiang Summary of presentation: Simulation set-up using single bottleneck. See slides for further details. Flow acceptance probability still significant when 10% over theshold If Admission & termination thresholds close enough, termination probability 5% when admission probability is also 5%: leads to thrashing. Propose thrashing index based on max product of probabiltity of admission and of simultaneous termination. [BB]: indices are oft-quoted, so need to get them right. Shouldn't it be area, not just height of the product of probabilities curve? [RJ]: Could have another index Using x% termination threshold (over admission threshold), makes significant difference to thrashing index Log curve of thrashing index shows highly significant drop in thrashing as thresholds moved apart (see slides). If flows are on more often, then have to set termination threshold higher (see slide) For larger capacity links, termination threshold can be set closer Summary 1. A closed form expression for flow rejection probability and flow termination probability for single marker case 2. The model explains the thrashing behaviour when the system reaches rejection /termination threshold region 3. Thrashing Index = Max{P(Acceptance)xP(Termination)} 4. The termination threshold should be set 10-15% above rejection theshold to avoid thrashing 5. The difference can be less if the number of flows is larger (large capacity links) or if the flow on probability is smaller (inactive flows). [BB]: Suggested 6th summary point: criterion for judging Th marking algos, how tightly they approach a step to reduce thrashing index. W-g meeting closed (20-odd mins late) Scribe: Bob Briscoe 20 Mar 2008 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Mar 20 17:51:36 2008 Return-Path: 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 8A0C93A685F; Thu, 20 Mar 2008 17:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.228 X-Spam-Level: X-Spam-Status: No, score=-100.228 tagged_above=-999 required=5 tests=[AWL=-0.391, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 XFu+7fV8bwnM; Thu, 20 Mar 2008 17:51:35 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2B133A69D9; Thu, 20 Mar 2008 17:51:35 -0700 (PDT) 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 547693A69D9 for ; Thu, 20 Mar 2008 17:51:34 -0700 (PDT) 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 eqBNwUqC0RSH for ; Thu, 20 Mar 2008 17:51:33 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 4188D3A685F for ; Thu, 20 Mar 2008 17:51:33 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id E8F3A19B150; Fri, 21 Mar 2008 01:49:14 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id DD0CB19B14E; Fri, 21 Mar 2008 01:49:14 +0100 (CET) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id B19F619B14D; Fri, 21 Mar 2008 01:49:13 +0100 (CET) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m2L0nDV08171; Fri, 21 Mar 2008 01:49:13 +0100 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 40D18C88E2; Fri, 21 Mar 2008 01:49:13 +0100 (CET) Message-ID: <47E305D4.1010108@informatik.uni-wuerzburg.de> Date: Fri, 21 Mar 2008 01:48:20 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Bob Briscoe References: <200803210042.m2L0gFfW020114@bagheera.jungle.bt.co.uk> In-Reply-To: <200803210042.m2L0gFfW020114@bagheera.jungle.bt.co.uk> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: PCN IETF list Subject: Re: [PCN] Core Marked Flow Termination anti-cheating? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Bob, when I am talking about anti-cheating, I am talking about an end-to-end PCN architecture. with CMFT, every flow with at least one marked packet must be terminated. The egress nodes see these packets and know which flows must stop. This can be enforced at the ingress by setting up appropriate policers. With EMFT this is not possible as not any marked packet requires its flow to stop. Regards Michael Bob Briscoe wrote: > Michael, > > In your presentation on marked flow termination, you mentioned a > couple of times that the core-based approach prevents cheating. Can > you elaborate? - I don't see how. > > > Bob > > > > ____________________________________________________________________________ > > Bob Briscoe, Networks Research Centre, BT > Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 -- 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 From pcn-bounces@ietf.org Tue Mar 25 03:00:57 2008 Return-Path: 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 8E56C3A6EA1; Tue, 25 Mar 2008 03:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.189 X-Spam-Level: X-Spam-Status: No, score=-100.189 tagged_above=-999 required=5 tests=[AWL=-0.352, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 nTRWAFJ0Tm8O; Tue, 25 Mar 2008 03:00:54 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 787CA3A6E74; Tue, 25 Mar 2008 03:00:54 -0700 (PDT) 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 C9CC028C3AF for ; Tue, 25 Mar 2008 03:00:51 -0700 (PDT) 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 EzPsf12I-Lxg for ; Tue, 25 Mar 2008 03:00:41 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 387DC28C3BF for ; Tue, 25 Mar 2008 03:00:09 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Mar 2008 09:57:49 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Mar 2008 09:57:47 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1206439068437; Tue, 25 Mar 2008 09:57:48 +0000 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m2P9vTKY031544; Tue, 25 Mar 2008 09:57:45 GMT Message-Id: <200803250957.m2P9vTKY031544@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 25 Mar 2008 09:57:38 +0000 To: menth@informatik.uni-wuerzburg.de From: Bob Briscoe In-Reply-To: <47E305D4.1010108@informatik.uni-wuerzburg.de> References: <200803210042.m2L0gFfW020114@bagheera.jungle.bt.co.uk> <47E305D4.1010108@informatik.uni-wuerzburg.de> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 25 Mar 2008 09:57:47.0418 (UTC) FILETIME=[ADCF67A0:01C88E5E] Cc: PCN IETF list Subject: Re: [PCN] Core Marked Flow Termination anti-cheating? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Michael, OK - understood This assumes: i) there is some edge-edge signalling even in the e2e case, between the egress that detects marked packets and the ingress that polices flows. ii) in a multi-domain scenario that an ingress network will act against it's own interests by blocking its own customers' sessions even if the congestion is in some other network downstream, nearer to the receiver. [Apologies to the list: both these cases are currently off-charter, but this seems a valid consideration for later.] Bob At 00:48 21/03/2008, Michael Menth wrote: >Hi Bob, > >when I am talking about anti-cheating, I am talking about an >end-to-end PCN architecture. with CMFT, every flow with at least one >marked packet must be terminated. The egress nodes see these packets >and know which flows must stop. This can be enforced at the ingress >by setting up appropriate policers. With EMFT this is not possible >as not any marked packet requires its flow to stop. > >Regards > > Michael > >Bob Briscoe wrote: >>Michael, >> >>In your presentation on marked flow termination, you mentioned a >>couple of times that the core-based approach prevents cheating. Can >>you elaborate? - I don't see how. >> >> >>Bob >> >> >> >>____________________________________________________________________________ >>Bob Briscoe, Networks Research Centre, BT Research >>B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 > >-- >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 ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 25 03:14:15 2008 Return-Path: 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 A542928C367; Tue, 25 Mar 2008 03:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.158 X-Spam-Level: X-Spam-Status: No, score=-100.158 tagged_above=-999 required=5 tests=[AWL=-0.321, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 7aUBW4aMED-c; Tue, 25 Mar 2008 03:14:11 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5A273A6B22; Tue, 25 Mar 2008 03:14:11 -0700 (PDT) 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 EBCAD3A6BE4 for ; Tue, 25 Mar 2008 03:14:10 -0700 (PDT) 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 0fnRnJ00NzGo for ; Tue, 25 Mar 2008 03:13:59 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 4FE0B3A69E8 for ; Tue, 25 Mar 2008 03:13:59 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Mar 2008 10:11:39 +0000 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Mar 2008 10:11:38 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1206439899801; Tue, 25 Mar 2008 10:11:39 +0000 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m2PABOHC032676; Tue, 25 Mar 2008 10:11:35 GMT Message-Id: <200803251011.m2PABOHC032676@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 25 Mar 2008 10:11:34 +0000 To: "BLAKE, Steven" From: Bob Briscoe Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 25 Mar 2008 10:11:38.0517 (UTC) FILETIME=[9D2F0C50:01C88E60] Cc: PCN IETF list Subject: [PCN] Fwd: Draft Notes of IETF71 PCN w-g meeting PtII, Thu 13 Mar 08 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Folks, Update to draft minutes below: Extract from old draft minutes: +++++++++++++++++++++++++++++++ >o Discuss encoding options Moncaster 40 min > (Carried forward from Tuesday session) >==================================== > >Slides not yet available on the meeting materials site, but the >attachment to Toby's posting to the PCN list should be useful: > >(Windows users will have to force a .bin file to be read by their >Acrobat Reader) Replace with: +++++++++++++ o Discuss encoding options Moncaster 40 min (Carried forward from Tuesday session) ==================================== Slides: ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 25 05:50:18 2008 Return-Path: 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 13BD63A6EDF; Tue, 25 Mar 2008 05:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.479 X-Spam-Level: X-Spam-Status: No, score=-100.479 tagged_above=-999 required=5 tests=[AWL=-0.642, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 QZAme2QLPCtz; Tue, 25 Mar 2008 05:50:17 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF77A3A6B5D; Tue, 25 Mar 2008 05:49:46 -0700 (PDT) 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 1758B3A6D16 for ; Tue, 25 Mar 2008 05:49:45 -0700 (PDT) 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 D1LBVGe4LBnf for ; Tue, 25 Mar 2008 05:49:41 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C42283A6AA6 for ; Tue, 25 Mar 2008 05:49:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.25,552,1199682000"; d="scan'208";a="2991259" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 25 Mar 2008 08:47:21 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m2PClLaZ027452; Tue, 25 Mar 2008 08:47:21 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id m2PClLUU007267; Tue, 25 Mar 2008 12:47:21 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Mar 2008 08:47:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Mar 2008 08:47:19 -0400 Message-ID: In-Reply-To: <200803250957.m2P9vTKY031544@bagheera.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Core Marked Flow Termination anti-cheating? Thread-Index: AciOXtZh2Miff4eKRByJxRu/5eBQmgAFwShQ From: "Anna Charny (acharny)" To: "Bob Briscoe" , X-OriginalArrivalTime: 25 Mar 2008 12:47:20.0987 (UTC) FILETIME=[5DBAD6B0:01C88E76] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3188; t=1206449241; x=1207313241; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20(acharny)=22=20 |Subject:=20RE=3A=20[PCN]=20Core=20Marked=20Flow=20Terminat ion=20anti-cheating? |Sender:=20 |To:=20=22Bob=20Briscoe=22=20,=0A =20=20=20=20=20=20=20=20; bh=g5NnwLFJNGG9o/HOryyThHFfz8Wmul9I+2RVkwxo7is=; b=WkhrL9Zem2n+fUqDAoZa87TTW+X5+q+2ylqCliln3QeoHXfXYD/Hk9ZDG/ bb2YuB5038hf20TqpynujzvxhXt9i9Johnm/7A8ZL/Wf0tgUsWYgC2hSKWMV tWX23+XLVZ; Authentication-Results: rtp-dkim-1; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: PCN IETF list Subject: Re: [PCN] Core Marked Flow Termination anti-cheating? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Michael, Bob, Wouldn't the same argument hold for CL-style termination if you say that the ingress, after choosing the flows to terminate, can police these flows? (Sorry if I am missing the crux of the argument). Anna > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Bob Briscoe > Sent: Tuesday, March 25, 2008 5:58 AM > To: menth@informatik.uni-wuerzburg.de > Cc: PCN IETF list > Subject: Re: [PCN] Core Marked Flow Termination anti-cheating? > > Michael, > > OK - understood > > This assumes: > i) there is some edge-edge signalling even in the e2e case, > between the egress that detects marked packets and the > ingress that polices flows. > ii) in a multi-domain scenario that an ingress network will > act against it's own interests by blocking its own customers' > sessions even if the congestion is in some other network > downstream, nearer to the receiver. > > [Apologies to the list: both these cases are currently > off-charter, but this seems a valid consideration for later.] > > > Bob > > At 00:48 21/03/2008, Michael Menth wrote: > >Hi Bob, > > > >when I am talking about anti-cheating, I am talking about an > >end-to-end PCN architecture. with CMFT, every flow with at least one > >marked packet must be terminated. The egress nodes see these packets > >and know which flows must stop. This can be enforced at the ingress > >by setting up appropriate policers. With EMFT this is not possible > >as not any marked packet requires its flow to stop. > > > >Regards > > > > Michael > > > >Bob Briscoe wrote: > >>Michael, > >> > >>In your presentation on marked flow termination, you mentioned a > >>couple of times that the core-based approach prevents cheating. Can > >>you elaborate? - I don't see how. > >> > >> > >>Bob > >> > >> > >> > >>____________________________________________________________ > ________________ > >>Bob Briscoe, Networks Research > Centre, BT Research > >>B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. > +44 1473 645196 > > > >-- > >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 > > ______________________________________________________________ > ______________ > Notice: This contribution is the personal view of the author and does > not necessarily reflect the technical nor commercial > direction of BT plc. > ______________________________________________________________ > ______________ > Bob Briscoe, Networks Research > Centre, BT Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. > +44 1473 645196 > > > _______________________________________________ > 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 From pcn-bounces@ietf.org Tue Mar 25 07:26:57 2008 Return-Path: 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 7F51528C1F6; Tue, 25 Mar 2008 07:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.29 X-Spam-Level: X-Spam-Status: No, score=-100.29 tagged_above=-999 required=5 tests=[AWL=-0.453, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 H41ePdEpUHMf; Tue, 25 Mar 2008 07:26:56 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B7B33A6971; Tue, 25 Mar 2008 07:26:56 -0700 (PDT) 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 53FF33A6971 for ; Tue, 25 Mar 2008 07:26:56 -0700 (PDT) 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 rJh-N9Z1+fKl for ; Tue, 25 Mar 2008 07:26:55 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 08F683A67D6 for ; Tue, 25 Mar 2008 07:26:54 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 62CADA19C1; Tue, 25 Mar 2008 15:24:32 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 57832A19C0; Tue, 25 Mar 2008 15:24:32 +0100 (CET) Received: from [85.176.238.56] (e176238056.adsl.alicedsl.de [85.176.238.56]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id DED5C19A395; Tue, 25 Mar 2008 15:24:30 +0100 (CET) Message-ID: <47E90AEB.60908@informatik.uni-wuerzburg.de> Date: Tue, 25 Mar 2008 15:23:39 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Bob Briscoe References: <200803210042.m2L0gFfW020114@bagheera.jungle.bt.co.uk> <47E305D4.1010108@informatik.uni-wuerzburg.de> <200803250957.m2P9vTKY031544@bagheera.jungle.bt.co.uk> In-Reply-To: <200803250957.m2P9vTKY031544@bagheera.jungle.bt.co.uk> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: PCN IETF list Subject: Re: [PCN] Core Marked Flow Termination anti-cheating? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Bob, Bob Briscoe wrote: > Michael, > > OK - understood > > This assumes: > i) there is some edge-edge signalling even in the e2e case, between > the egress that detects marked packets and the ingress that polices > flows. Yes. End-to-end PCN is only attractive if it can rely on the marking of edge-to-edge PCN domains that already exist, otherwise the deployment of end-to-end PCN is not realistic at all. I assume that edge-to-edge PCN domains have some edge-to-edge signaling to terminate flows. > ii) in a multi-domain scenario that an ingress network will act > against it's own interests by blocking its own customers' sessions > even if the congestion is in some other network downstream, nearer to > the receiver. Yes, that's true. Regards, Michael > > [Apologies to the list: both these cases are currently off-charter, > but this seems a valid consideration for later.] > > > Bob > > At 00:48 21/03/2008, Michael Menth wrote: >> Hi Bob, >> >> when I am talking about anti-cheating, I am talking about an >> end-to-end PCN architecture. with CMFT, every flow with at least one >> marked packet must be terminated. The egress nodes see these packets >> and know which flows must stop. This can be enforced at the ingress >> by setting up appropriate policers. With EMFT this is not possible as >> not any marked packet requires its flow to stop. >> >> Regards >> >> Michael >> >> Bob Briscoe wrote: >>> Michael, >>> >>> In your presentation on marked flow termination, you mentioned a >>> couple of times that the core-based approach prevents cheating. Can >>> you elaborate? - I don't see how. >>> >>> >>> Bob >>> >>> >>> >>> ____________________________________________________________________________ >>> >>> Bob Briscoe, Networks Research Centre, BT >>> Research >>> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 >>> 1473 645196 >> >> -- >> 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 > > ____________________________________________________________________________ > > Notice: This contribution is the personal view of the author and does > not necessarily reflect the technical nor commercial direction of BT plc. > ____________________________________________________________________________ > > Bob Briscoe, Networks Research Centre, BT > Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 -- 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 From pcn-bounces@ietf.org Tue Mar 25 07:34:14 2008 Return-Path: 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 8C42028C3A5; Tue, 25 Mar 2008 07:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.064 X-Spam-Level: X-Spam-Status: No, score=-100.064 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 gicRzgwMjc46; Tue, 25 Mar 2008 07:34:13 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 843CF3A6EF1; Tue, 25 Mar 2008 07:34:13 -0700 (PDT) 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 8263828C173 for ; Tue, 25 Mar 2008 07:34:11 -0700 (PDT) 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 eD7yCZs+0KEz for ; Tue, 25 Mar 2008 07:34:07 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id C98B728C145 for ; Tue, 25 Mar 2008 07:34:06 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 7264619B4E0; Tue, 25 Mar 2008 15:31:47 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 6611119B4DC; Tue, 25 Mar 2008 15:31:47 +0100 (CET) Received: from [85.176.238.56] (e176238056.adsl.alicedsl.de [85.176.238.56]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id C32D919AFD4; Tue, 25 Mar 2008 15:31:44 +0100 (CET) Message-ID: <47E90C9D.4000907@informatik.uni-wuerzburg.de> Date: Tue, 25 Mar 2008 15:30:53 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: "Anna Charny (acharny)" References: In-Reply-To: X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: PCN IETF list Subject: Re: [PCN] Core Marked Flow Termination anti-cheating? X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Anna, Anna Charny (acharny) wrote: > Hi Michael, Bob, > > Wouldn't the same argument hold for CL-style termination if you say that > the ingress, after choosing the flows to terminate, can police these > flows? (Sorry if I am missing the crux of the argument). > Yes, the ingress could police a flow. The problem is: how does a single PCN domain realize that an end-to-end PCN flow should terminate? With core-assisted marked flow termination, every flow with at least one marked packet must be terminated and this is easy to recognize by a PCN domain's egress node. Regards, Michael > Anna > >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On >> Behalf Of Bob Briscoe >> Sent: Tuesday, March 25, 2008 5:58 AM >> To: menth@informatik.uni-wuerzburg.de >> Cc: PCN IETF list >> Subject: Re: [PCN] Core Marked Flow Termination anti-cheating? >> >> Michael, >> >> OK - understood >> >> This assumes: >> i) there is some edge-edge signalling even in the e2e case, >> between the egress that detects marked packets and the >> ingress that polices flows. >> ii) in a multi-domain scenario that an ingress network will >> act against it's own interests by blocking its own customers' >> sessions even if the congestion is in some other network >> downstream, nearer to the receiver. >> >> [Apologies to the list: both these cases are currently >> off-charter, but this seems a valid consideration for later.] >> >> >> Bob >> >> At 00:48 21/03/2008, Michael Menth wrote: >> >>> Hi Bob, >>> >>> when I am talking about anti-cheating, I am talking about an >>> end-to-end PCN architecture. with CMFT, every flow with at least one >>> marked packet must be terminated. The egress nodes see these packets >>> and know which flows must stop. This can be enforced at the ingress >>> by setting up appropriate policers. With EMFT this is not possible >>> as not any marked packet requires its flow to stop. >>> >>> Regards >>> >>> Michael >>> >>> Bob Briscoe wrote: >>> >>>> Michael, >>>> >>>> In your presentation on marked flow termination, you mentioned a >>>> couple of times that the core-based approach prevents cheating. Can >>>> you elaborate? - I don't see how. >>>> >>>> >>>> Bob >>>> >>>> >>>> >>>> ____________________________________________________________ >>>> >> ________________ >> >>>> Bob Briscoe, Networks Research >>>> >> Centre, BT Research >> >>>> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. >>>> >> +44 1473 645196 >> >>> -- >>> 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 >>> >> ______________________________________________________________ >> ______________ >> Notice: This contribution is the personal view of the author and does >> not necessarily reflect the technical nor commercial >> direction of BT plc. >> ______________________________________________________________ >> ______________ >> Bob Briscoe, Networks Research >> Centre, BT Research >> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. >> +44 1473 645196 >> >> >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn >> >> -- 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 From pcn-bounces@ietf.org Tue Mar 25 08:10:22 2008 Return-Path: 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 F2B523A6EF1; Tue, 25 Mar 2008 08:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.685 X-Spam-Level: X-Spam-Status: No, score=-100.685 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 wWCHJSqu3m1X; Tue, 25 Mar 2008 08:10:20 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DA433A6967; Tue, 25 Mar 2008 08:09:54 -0700 (PDT) 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 D38103A6967 for ; Tue, 25 Mar 2008 08:09:52 -0700 (PDT) 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 9ecuRAtpN65U for ; Tue, 25 Mar 2008 08:09:47 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 9056E3A67D4 for ; Tue, 25 Mar 2008 08:09:46 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Mar 2008 15:07:25 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 25 Mar 2008 15:07:24 -0000 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B34695@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <000401c88ab4$35903a10$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Georgios's example Thread-Index: AciJ1+MI5FcT3On/QSSm/yR8ASiixQA2+AJQAPSQl7A= From: To: , X-OriginalArrivalTime: 25 Mar 2008 15:07:25.0993 (UTC) FILETIME=[EF80F990:01C88E89] Cc: pcn@ietf.org Subject: [PCN] Georgios's example X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Georgios, (1) again, I need to remind myself of the context: this is termination control, assuming Single Marking is being used (2) the term PCN_lower_threshold(1) is unexplained (3) the term CLE_thres is unexplained. (4) Since this is just the first equation of many, at this point I give up trying to follow your email (5) I actually don't want you to tell me what the two terms above mean. At this stage I don't care. (6) Instead, I want to understand what the point you're making is and whether it has any importance. (7) My impression is that Anna managed to explain what the general point was that you'd been attempting to make in her email http://www.ietf.org/mail-archive/web/pcn/current/msg01350.html (8) Anna in the same email also heroically added some estimated size of parameters, showing that in practice this won't ever be a real problem. (9) I believe you haven't answered this email of Anna's, so I assume you agree with it - and your email below agrees with it whilst trying to add some equations to further support it. (10) it would be good if you could confirm you do agree with anna's email. (11) if you basically agree with anna, but think the issue is more significant in scale (anna's parameters need to be changed), please present reasonable arguments for a different set of parameters. (12) if you actually mean a different problem from the one explained by anna in msg1350, then you need to explain it in clear, short English (maths such as below is just a hindrance) (13) I believe this whole discussion is already covered by the architecture draft (which says, paraphrasing a lot, ECMP is nasty). However I can add some more detail (whilst remembering that, as the architecture draft says in S6'Design goals and challenges', "NOTE: Potential solutions are out of scope for this document." Best wishes phil -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Georgios Karagiannis > Sent: 20 March 2008 18:00 > To: 'Steven Blake' > Cc: pcn@ietf.org > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > > Hi Steven > > < solution!>> > The EXAMPLE contained an error>> > The below EXAMPLE is okay! > > > I have tried to work out this problem! > > This is what I have found! > I assume that N * ECMP paths are carrying packets that are belonging to > the > same Ingress-egress-aggregate. > I assume that one of the paths fails and one of the routers in only one of > the other N-1 paths will become congested. > Thus after failure, one path failed, one path is congested and N-2 paths > are > not congested. > > I assume that Ci is the minimum capacity (per PHB) supported on a path i. > The maximum capacity (per PHB) on the congested router is denoted as > Ci_cong. > > In situation (1) when preferential dropping is used then I find the > following PCN_lower_threshold(1): > > > N -2 > --- > PCN_lower_th(1) < Ci_cong*(1- CLE_thres)-CLE_thres * \Ci > / > --- > i=1 > > The value of PCN_lower_threshold it mainly depends on the value of the > total > unmarked rate (of the > congested and uncongested paths) that is arriving at the egress. The > higher > this total unmarked rate > Value, the smaller PCN_lower_th(1) must be. > > > In the situation (2) when marked and unmarked packets are dropped with > equal > probability p, > then I found the following equation: > Note that dropping probability can be defined as: > > > rt - Ci_cong > P = ------------ > rt > > Where rt = total rate (per PHB) that is seen by the congested > PCN_interior_node, > that supports the maximum capacity (per PHB) equal to Ci_cong. Then the > PCN_lower_th (2) can be found as: > > PCN_lower_th(2) < MINIMUM(Ci_cong ; SECOND_PART), where > > N -2 > --- > CLE_thres* Ci_cong - CLE_thres \Ci > SECOND_PART = rt - ----------------------------- * / ) > (1-p) / > --- > i=1 > > > The value of PCN_lower_threshold in this case, it has to mainly be smaller > than the maximum capacity supported by the congested router. This > situation > can > always be supported. > > Example: > > Use N = 6, CLE_th = 1%, p = 50%, > Suppose that path6 fails and path1 is the one that becomes congested, > rt = C1 + C6, because p = 50% it means that C6 = C1; > The thresholds on these tw situations can be then calculated as: > > When router is preferentially dropping marked packets: > > PCN_lower_threshold (1) < C1*(99%) - 1%* (C2 + C3 + C4 + C5) > > > > > ----------------------------------------------------- > > When router is dropping marked and unmarked packets are > with equal probability p: > > > PCN_lower_threshold (2) < MINIMUM {C1; SECOND_PART}, where: > > [(C1 + C6) - 1%C1 - 1%(C2 + C3 + C4 + C5)]} > SECOND_PART= ---------------------------- > 50% > > PCN_lower_threshold (2) < MINIMUM {C1; SECOND_PART}, where: > > [(2*C1) - 1%C1 - 1%(C2 + C3 + C4 + C5)]} > SECOND_PART = -------------------------------- > 50% > > => PCN_lower_threshold (2) < C1 > > > Therefore, the second scheme (2) can be considered more robust and more > stable then the first scheme. > > Best regards, > Georgios > > > -----Original Message----- > > From: Steven Blake [mailto:steven.blake@ericsson.com] > > Sent: woensdag 19 maart 2008 16:43 > > To: Georgios Karagiannis > > Cc: pcn@ietf.org > > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > > > > On Wed, 2008-03-19 at 16:24 +0100, Georgios Karagiannis wrote: > > > > > Hi Steven > > > > > > Please see that I have included some information into the > > last bullet: > > > > > > - There is an ingress-egress aggregate whose traffic is > > split across > > > multiple paths via ECMP. > > > - Traffic is admitted along this split path. > > > - One (or more) of the paths fails. > > > - One (or more) of the remaining paths becomes severely > > congested (for > > > example because there is traffic from other ingress-egress > > > aggregates flowing along that path). > > > - < > forward packets > > > belonging to > > > the same ingress-egress-aggregate that will be unmarked.>> Marked > > > packets are > > > preferentially dropped at the severely congested > > > router(s). As a consequence, not enough marked traffic arrives at > > > the egress router to drive the CLE for the ingress-egress aggregate > > > above the threshold needed to trigger a response (termination, say). > > > > Ok. To be specific, the egressrouter will see some fraction > > of packets from the severely congested router(s), some of > > which will be marked, and will see a larger fraction of > > un-marked packets from the un-pre-congested routers. > > > > So let me now ask you this: given N ECMP paths (after a path > > failure), with one being severely congested and the rest > > being un-pre-congested, and given a CLE threshold CLE_thresh > > at the egress router, can you solve for the minimum > > PCN_lower_threshold value at the severely congested router, > > where PCN still works (e.g., CLE crosses the threshold), for > > the two cases where (1) marked packets are preferentially > > dropped, and (2) marked packets are dropped with equal > > probability with un-marked packets? > > > > > > > > Regards, > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > Steven Blake > > Ericsson/Redback Networks +1 919-472-9913 > > > > > _______________________________________________ > 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 From pcn-bounces@ietf.org Tue Mar 25 08:16:18 2008 Return-Path: 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 6AC3D28C363; Tue, 25 Mar 2008 08:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.605 X-Spam-Level: X-Spam-Status: No, score=-100.605 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 n2ZczblgC+Ew; Tue, 25 Mar 2008 08:16:15 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 630ED3A6CA0; Tue, 25 Mar 2008 08:16:15 -0700 (PDT) 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 789C53A6CA0 for ; Tue, 25 Mar 2008 08:16:13 -0700 (PDT) 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 lewctnqgQji0 for ; Tue, 25 Mar 2008 08:16:11 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 944973A69D6 for ; Tue, 25 Mar 2008 08:15:50 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m2PFDVYI020827 for ; Tue, 25 Mar 2008 10:13:31 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Mar 2008 10:13:30 -0500 Received: from [147.117.169.77] ([147.117.169.77]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Mar 2008 10:13:30 -0500 From: Steven Blake To: pcn In-Reply-To: <1205860102.9521.27.camel@neutrino> References: <1205860102.9521.27.camel@neutrino> Organization: Ericsson IP Infrastructure Date: Tue, 25 Mar 2008 11:13:26 -0400 Message-Id: <1206458006.3065.18.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) X-OriginalArrivalTime: 25 Mar 2008 15:13:30.0790 (UTC) FILETIME=[C8F09460:01C88E8A] Subject: Re: [PCN] Concensus questions: Q1, Q2, and Q3. X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org On Tue, 2008-03-18 at 13:08 -0400, Steven Blake wrote: > Six consensus questions were taken during the IETF 71 meeting. I would > now like to raise them on the list. I will do this in step-wise > fashion. > > Q1: As an initial standardization activity, should the PCN wg produce a > standards-track PCN scheme that requires only two encoding states? > (Note: this question does not presume that the solution is Single > Marking). > > Q2: Presuming consensus in favor of Q1, should the PCN wg produce one or > more experimental-track extensions to the standards-track PCN scheme > that require another encoding state (for a total of three encoding > states)? > > Q3: Does the PCN working group have enough information to make a > decision about the way forward for the standards-track PCN scheme? > > By my notes, Q1 was accepted in the meeting 8-0, Q2 was accepted 9-0, > and Q3 was accepted 6-1 (but my notes are fuzzy on Q3's result). > > Please send comments to the list during the next few days. We've heard from a few. Does anyone else have comments? Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Mar 25 08:22:30 2008 Return-Path: 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 4F0D628C4EC; Tue, 25 Mar 2008 08:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.633 X-Spam-Level: X-Spam-Status: No, score=-100.633 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 Sr2K+TcNf5pi; Tue, 25 Mar 2008 08:22:25 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D9BF3A6967; Tue, 25 Mar 2008 08:22:25 -0700 (PDT) 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 9FBB73A6865 for ; Tue, 25 Mar 2008 08:22:23 -0700 (PDT) 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 spVKnKq-Xn8t for ; Tue, 25 Mar 2008 08:22:18 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 3020028C25A for ; Tue, 25 Mar 2008 08:22:18 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m2PFJjVO024870; Tue, 25 Mar 2008 10:19:45 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Mar 2008 10:19:45 -0500 Received: from [147.117.169.77] ([147.117.169.77]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Mar 2008 10:19:45 -0500 From: Steven Blake To: Georgios Karagiannis In-Reply-To: <000401c88ab4$35903a10$810c5982@dynamic.ewi.utwente.nl> References: <1B6169C658325341A3B8066E23919E1CF64CFA@S4DE8PSAANK.mitte.t-com.de> <75A199C5D243C741BF3D3F1EBCEF9BA503B34667@E03MVZ1-UKDY.domain1.systemhost.net> <004e01c889d1$6d01e4f0$810c5982@dynamic.ewi.utwente.nl> <1205939802.3021.9.camel@neutrino> <005501c889d5$5acccdf0$810c5982@dynamic.ewi.utwente.nl> <1205941357.3021.18.camel@neutrino> <000401c88ab4$35903a10$810c5982@dynamic.ewi.utwente.nl> Organization: Ericsson IP Infrastructure Date: Tue, 25 Mar 2008 11:19:44 -0400 Message-Id: <1206458384.3065.24.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) X-OriginalArrivalTime: 25 Mar 2008 15:19:45.0272 (UTC) FILETIME=[A825FF80:01C88E8B] Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org On Thu, 2008-03-20 at 18:59 +0100, Georgios Karagiannis wrote: [snip] > When router is preferentially dropping marked packets: > > PCN_lower_threshold (1) < C1*(99%) - 1%* (C2 + C3 + C4 + C5) > > > > > ----------------------------------------------------- > > When router is dropping marked and unmarked packets are > with equal probability p: > > > PCN_lower_threshold (2) < MINIMUM {C1; SECOND_PART}, where: > > [(C1 + C6) - 1%C1 - 1%(C2 + C3 + C4 + C5)]} > SECOND_PART= ---------------------------- > 50% > > PCN_lower_threshold (2) < MINIMUM {C1; SECOND_PART}, where: > > [(2*C1) - 1%C1 - 1%(C2 + C3 + C4 + C5)]} > SECOND_PART = -------------------------------- > 50% > > => PCN_lower_threshold (2) < C1 > > > Therefore, the second scheme (2) can be considered more robust and more > stable then the first scheme. Georgios, If I assume that C1 = C2 = C3 = C4 = C5, then PCN_lower_threshold(1) < (0.99 * C1) - (0.01 * 4 * C1) = 0.95 * C1 whereas PCN_lower_threshold(2) < C1 I think you will agree that this is not a significant difference. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 26 02:02:51 2008 Return-Path: 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 850E428C534; Wed, 26 Mar 2008 02:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.336 X-Spam-Level: X-Spam-Status: No, score=-100.336 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 N99LeUNAX5Qz; Wed, 26 Mar 2008 02:02:50 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 288A228C4D5; Wed, 26 Mar 2008 02:02:50 -0700 (PDT) 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 39A133A6A3E for ; Wed, 26 Mar 2008 02:02:49 -0700 (PDT) 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 BqkEMiwE92z6 for ; Wed, 26 Mar 2008 02:02:48 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id B638928C314 for ; Wed, 26 Mar 2008 02:02:47 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m2Q8xw6V000456; Wed, 26 Mar 2008 10:00:11 +0100 (MET) From: "Georgios Karagiannis" To: "'Steven Blake'" References: <1B6169C658325341A3B8066E23919E1CF64CFA@S4DE8PSAANK.mitte.t-com.de> <75A199C5D243C741BF3D3F1EBCEF9BA503B34667@E03MVZ1-UKDY.domain1.systemhost.net> <004e01c889d1$6d01e4f0$810c5982@dynamic.ewi.utwente.nl> <1205939802.3021.9.camel@neutrino> <005501c889d5$5acccdf0$810c5982@dynamic.ewi.utwente.nl> <1205941357.3021.18.camel@neutrino> <000401c88ab4$35903a10$810c5982@dynamic.ewi.utwente.nl> <1206458384.3065.24.camel@neutrino> Date: Wed, 26 Mar 2008 09:59:56 +0100 Message-ID: <000301c88f1f$ccd972a0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciOi6+88muXDLeyQZKGAtZGHauhdgAk0AIg In-Reply-To: <1206458384.3065.24.camel@neutrino> X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 26 Mar 2008 10:00:12 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Steven Please see in line! > -----Original Message----- > From: Steven Blake [mailto:steven.blake@ericsson.com] > Sent: dinsdag 25 maart 2008 16:20 > To: Georgios Karagiannis > Cc: pcn@ietf.org > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > > On Thu, 2008-03-20 at 18:59 +0100, Georgios Karagiannis wrote: > > [snip] > > > When router is preferentially dropping marked packets: > > > > PCN_lower_threshold (1) < C1*(99%) - 1%* (C2 + C3 + C4 + C5) > > > > > > > > > > ----------------------------------------------------- > > > > When router is dropping marked and unmarked packets are with equal > > probability p: > > > > > > PCN_lower_threshold (2) < MINIMUM {C1; SECOND_PART}, where: > > > > [(C1 + C6) - 1%C1 - 1%(C2 + C3 + C4 + C5)]} > > SECOND_PART= ---------------------------- > > 50% > > > > PCN_lower_threshold (2) < MINIMUM {C1; SECOND_PART}, where: > > > > [(2*C1) - 1%C1 - 1%(C2 + C3 + C4 + C5)]} > > SECOND_PART = -------------------------------- > > 50% > > > > => PCN_lower_threshold (2) < C1 > > > > > > Therefore, the second scheme (2) can be considered more robust and > > more stable then the first scheme. > > Georgios, > > If I assume that C1 = C2 = C3 = C4 = C5, then > > PCN_lower_threshold(1) < (0.99 * C1) - (0.01 * 4 * C1) = 0.95 * C1 > > whereas > > PCN_lower_threshold(2) < C1 > > I think you will agree that this is not a significant difference. Georgios: For this example, yes, but note that not all links in the PCN domain will support equal bandwidth! Consider that the following situation occurs: C2=C3=C4=C5= 10*C1 Thenn (1) will be: PCN_lower_threshold(1) < (0.99 * C1) - (0.01 * 4 * 10 *C1) PCN_lower_thhershold (1) < C1 (0.99 - 0.4) PCN_lower_thhershold (1) < C1 * 0.54 Whereas: PCN_lower_threshold (2) < C1 Best regards, Georgios > > > Regards, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven Blake > Ericsson/Redback Networks +1 919-472-9913 > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Mar 26 02:26:32 2008 Return-Path: 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 2DDE728C55D; Wed, 26 Mar 2008 02:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.343 X-Spam-Level: X-Spam-Status: No, score=-100.343 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 5bv+hPboHMeN; Wed, 26 Mar 2008 02:26:28 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49CE528C54B; Wed, 26 Mar 2008 02:26:28 -0700 (PDT) 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 15C0828C425 for ; Wed, 26 Mar 2008 02:26:27 -0700 (PDT) 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 RFqgn8cFkVam for ; Wed, 26 Mar 2008 02:26:26 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id ECF2B28C534 for ; Wed, 26 Mar 2008 02:26:25 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m2Q9O2VH002512; Wed, 26 Mar 2008 10:24:05 +0100 (MET) From: "Georgios Karagiannis" To: "'Steven Blake'" , "'pcn'" References: <1205860102.9521.27.camel@neutrino> <1206458006.3065.18.camel@neutrino> Date: Wed, 26 Mar 2008 10:23:57 +0100 Message-ID: <001c01c88f23$21160e20$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciOiu1sRWQ9aTAJS3ixG1rZi5feWAAlg9kw In-Reply-To: <1206458006.3065.18.camel@neutrino> X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 26 Mar 2008 10:24:05 +0100 (MET) Subject: Re: [PCN] Concensus questions: Q1, Q2, and Q3. X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Steven Regarding Question Q1, I think that, from my point of view, it is Yes! Before answering questions Q2 and Q3, I would like that some questions/comments should be clarified. Question Q2: I consider that an experimental-track extension for another PCN scheme that uses only two encoding states should also be allowed. Is this option also included in the question. Question Q3: According to the current version of the PCN architecture, The PCN scheme should also be able to support the admission control and flow termination detection and handling (selection of the flows to be terminated) at the egress. SM and CL-PHB cannot support the handling (selection of the flows to be terminated) at the egress. This means that such a PCN scheme should also be allowed, i.e., as an experimental-track extension. Furthermore, according to the previous discussions on the PCN mailing list, I think that care should be taken on the way of how preferential dropping is used wthin the PCN domain. In other words, preferetial dropping of marked packet should not be mandated. Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Steven Blake > Sent: dinsdag 25 maart 2008 16:13 > To: pcn > Subject: Re: [PCN] Concensus questions: Q1, Q2, and Q3. > > On Tue, 2008-03-18 at 13:08 -0400, Steven Blake wrote: > > > Six consensus questions were taken during the IETF 71 meeting. I > > would now like to raise them on the list. I will do this > in step-wise > > fashion. > > > > Q1: As an initial standardization activity, should the PCN > wg produce a > > standards-track PCN scheme that requires only two > encoding states? > > (Note: this question does not presume that the solution > is Single > > Marking). > > > > Q2: Presuming consensus in favor of Q1, should the PCN wg > produce one or > > more experimental-track extensions to the > standards-track PCN scheme > > that require another encoding state (for a total of > three encoding > > states)? > > > > Q3: Does the PCN working group have enough information to make a > > decision about the way forward for the standards-track > PCN scheme? > > > > By my notes, Q1 was accepted in the meeting 8-0, Q2 was > accepted 9-0, > > and Q3 was accepted 6-1 (but my notes are fuzzy on Q3's result). > > > > Please send comments to the list during the next few days. > > We've heard from a few. Does anyone else have comments? > > > Regards, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven Blake > Ericsson/Redback Networks +1 919-472-9913 > > _______________________________________________ > 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 From pcn-bounces@ietf.org Wed Mar 26 02:52:21 2008 Return-Path: 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 A363928C3CE; Wed, 26 Mar 2008 02:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.346 X-Spam-Level: X-Spam-Status: No, score=-100.346 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 7Wxd5hEoVTs6; Wed, 26 Mar 2008 02:52:20 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD0863A6DF7; Wed, 26 Mar 2008 02:52:20 -0700 (PDT) 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 4338C28C4FE for ; Wed, 26 Mar 2008 02:52:20 -0700 (PDT) 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 AqqpV+iX5yix for ; Wed, 26 Mar 2008 02:52:14 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 536A73A69BA for ; Wed, 26 Mar 2008 02:52:14 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m2Q9ngnF005404; Wed, 26 Mar 2008 10:49:47 +0100 (MET) From: "Georgios Karagiannis" To: "'Steven Blake'" References: <1B6169C658325341A3B8066E23919E1CF64CFA@S4DE8PSAANK.mitte.t-com.de><75A199C5D243C741BF3D3F1EBCEF9BA503B34667@E03MVZ1-UKDY.domain1.systemhost.net><004e01c889d1$6d01e4f0$810c5982@dynamic.ewi.utwente.nl><1205939802.3021.9.camel@neutrino><005501c889d5$5acccdf0$810c5982@dynamic.ewi.utwente.nl><1205941357.3021.18.camel@neutrino><000401c88ab4$35903a10$810c5982@dynamic.ewi.utwente.nl><1206458384.3065.24.camel@neutrino> <000301c88f1f$ccd972a0$810c5982@dynamic.ewi.utwente.nl> Date: Wed, 26 Mar 2008 10:49:37 +0100 Message-ID: <002401c88f26$b86b0610$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciOi6+88muXDLeyQZKGAtZGHauhdgAk0AIgAAHbrOA= In-Reply-To: <000301c88f1f$ccd972a0$810c5982@dynamic.ewi.utwente.nl> X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 26 Mar 2008 10:49:49 +0100 (MET) Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Steven The comments that I have sent in the previous email cannot be clearly seen. Please see again in line: > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Georgios Karagiannis > Sent: woensdag 26 maart 2008 10:00 > To: 'Steven Blake' > Cc: pcn@ietf.org > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > > Hi Steven > > Please see in line! > > > > -----Original Message----- > > From: Steven Blake [mailto:steven.blake@ericsson.com] > > Sent: dinsdag 25 maart 2008 16:20 > > To: Georgios Karagiannis > > Cc: pcn@ietf.org > > Subject: RE: [PCN] Concensus questions from Thursday's PCN meeting > > > > On Thu, 2008-03-20 at 18:59 +0100, Georgios Karagiannis wrote: > > > > [snip] > > > > > When router is preferentially dropping marked packets: > > > > > > PCN_lower_threshold (1) < C1*(99%) - 1%* (C2 + C3 + C4 + C5) > > > > > > > > > > > > > > > ----------------------------------------------------- > > > > > > When router is dropping marked and unmarked packets are > with equal > > > probability p: > > > > > > > > > PCN_lower_threshold (2) < MINIMUM {C1; SECOND_PART}, where: > > > > > > [(C1 + C6) - 1%C1 - 1%(C2 + C3 + C4 + C5)]} > > > SECOND_PART= ---------------------------- > > > 50% > > > > > > PCN_lower_threshold (2) < MINIMUM {C1; SECOND_PART}, where: > > > > > > [(2*C1) - 1%C1 - 1%(C2 + C3 + C4 + C5)]} > > > SECOND_PART = -------------------------------- > > > 50% > > > > > > => PCN_lower_threshold (2) < C1 > > > > > > > > > Therefore, the second scheme (2) can be considered more > robust and > > > more stable then the first scheme. > > > > Georgios, > > > > If I assume that C1 = C2 = C3 = C4 = C5, then > > > > PCN_lower_threshold(1) < (0.99 * C1) - (0.01 * 4 * C1) = 0.95 * C1 > > > > whereas > > > > PCN_lower_threshold(2) < C1 > > > > I think you will agree that this is not a significant difference. > Georgios: For this example, yes, but note that not all links in the PCN domain will support equal bandwidth! Consider that the following situation occurs: C2=C3=C4=C5= 10*C1 Thenn (1) will be: PCN_lower_threshold(1) < (0.99 * C1) - (0.01 * 4 * 10 *C1) PCN_lower_thhershold (1) < C1 (0.99 - 0.4) PCN_lower_thhershold (1) < C1 * 0.59 Whereas: PCN_lower_threshold (2) < C1 Best regards, Georgios > > > > > > > > > > > Regards, > > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > Steven Blake > > Ericsson/Redback Networks +1 919-472-9913 > > > > > _______________________________________________ > 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 From pcn-bounces@ietf.org Wed Mar 26 09:01:24 2008 Return-Path: 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 CAEE528C607; Wed, 26 Mar 2008 09:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.683 X-Spam-Level: X-Spam-Status: No, score=-100.683 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 qufb53ujk+uw; Wed, 26 Mar 2008 09:01:23 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5D9B28C4D9; Wed, 26 Mar 2008 09:01:23 -0700 (PDT) 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 DF03D28C135 for ; Wed, 26 Mar 2008 09:01:22 -0700 (PDT) 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 eZcy36Bw+Lj5 for ; Wed, 26 Mar 2008 09:01:17 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id D2A0028C62D for ; Wed, 26 Mar 2008 09:01:12 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id m2QFwP7h007635; Wed, 26 Mar 2008 10:58:25 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Mar 2008 10:58:24 -0500 Received: from [147.117.169.77] ([147.117.169.77]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Mar 2008 10:58:24 -0500 From: Steven Blake To: Georgios Karagiannis In-Reply-To: <001c01c88f23$21160e20$810c5982@dynamic.ewi.utwente.nl> References: <1205860102.9521.27.camel@neutrino> <1206458006.3065.18.camel@neutrino> <001c01c88f23$21160e20$810c5982@dynamic.ewi.utwente.nl> Organization: Ericsson IP Infrastructure Date: Wed, 26 Mar 2008 11:58:24 -0400 Message-Id: <1206547104.3049.7.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) X-OriginalArrivalTime: 26 Mar 2008 15:58:24.0162 (UTC) FILETIME=[38BA4820:01C88F5A] Cc: 'pcn' Subject: Re: [PCN] Concensus questions: Q1, Q2, and Q3. X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org On Wed, 2008-03-26 at 10:23 +0100, Georgios Karagiannis wrote: > Hi Steven > > Regarding Question Q1, I think that, from my point of view, it is Yes! > > > Before answering questions Q2 and Q3, I would like that > some questions/comments should be clarified. > > Question Q2: > I consider that an experimental-track extension for another > PCN scheme that uses only two encoding states should also be allowed. > Is this option also included in the question. My intent with the question is that any experimental-track proposals would be extensions of the standards-track scheme. I believe that is the sense that others understood as well. > Question Q3: > According to the current version of the PCN architecture, > The PCN scheme should also be able to support the admission control and flow > termination > detection and handling (selection of the flows to be terminated) at the > egress. > SM and CL-PHB cannot support the handling (selection of the flows to be > terminated) > at the egress. This means that such a PCN scheme should also be allowed, > i.e., as > an experimental-track extension. I don't understand why neither SM or CL-PHB can support egress-based flow termination, *assuming that the egress node has flow state* (which is presumed if we are not tunneling). > Furthermore, according to the previous discussions on the PCN mailing list, > I think that care should be taken on the way of how preferential dropping is > used > wthin the PCN domain. In other words, preferetial dropping of marked packet > should not be mandated. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Mar 28 03:24:04 2008 Return-Path: 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 DECC23A6AD3; Fri, 28 Mar 2008 03:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.845 X-Spam-Level: X-Spam-Status: No, score=-97.845 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 FwVbnrcSR0SO; Fri, 28 Mar 2008 03:24:03 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA2253A682C; Fri, 28 Mar 2008 03:24:03 -0700 (PDT) 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 32CFA3A682C for ; Fri, 28 Mar 2008 03:24:03 -0700 (PDT) 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 JyiYbfew3qff for ; Fri, 28 Mar 2008 03:24:02 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 0E7DB3A6800 for ; Fri, 28 Mar 2008 03:24:01 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id m2SANgMV007377; Fri, 28 Mar 2008 11:23:59 +0100 (MET) From: "Georgios Karagiannis" To: "'Steven Blake'" References: <1205860102.9521.27.camel@neutrino> <1206458006.3065.18.camel@neutrino> <001c01c88f23$21160e20$810c5982@dynamic.ewi.utwente.nl> <1206547104.3049.7.camel@neutrino> Date: Fri, 28 Mar 2008 11:23:37 +0100 Message-ID: <000001c890bd$d4b353c0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1206547104.3049.7.camel@neutrino> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AciPWknqaaCrWcczTm2zm7G9zCQo7gBYqX4g X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Fri, 28 Mar 2008 11:24:00 +0100 (MET) Cc: 'pcn' Subject: Re: [PCN] Concensus questions: Q1, Q2, and Q3. X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Steven Please see in line! > -----Original Message----- > From: Steven Blake [mailto:steven.blake@ericsson.com] > Sent: woensdag 26 maart 2008 16:58 > To: Georgios Karagiannis > Cc: 'pcn' > Subject: RE: [PCN] Concensus questions: Q1, Q2, and Q3. > > On Wed, 2008-03-26 at 10:23 +0100, Georgios Karagiannis wrote: > > > Hi Steven > > > > Regarding Question Q1, I think that, from my point of view, > it is Yes! > > > > > > Before answering questions Q2 and Q3, I would like that some > > questions/comments should be clarified. > > > > Question Q2: > > I consider that an experimental-track extension for another > PCN scheme > > that uses only two encoding states should also be allowed. > > Is this option also included in the question. > > My intent with the question is that any experimental-track > proposals would be extensions of the standards-track scheme. > I believe that is the sense that others understood as well. Georgios: Okay, if n experimental-track extension for another PCN scheme that uses only two encoding states should also be allowed, then my answer to question Q2 is YES. > > > Question Q3: > > According to the current version of the PCN architecture, The PCN > > scheme should also be able to support the admission control > and flow > > termination detection and handling (selection of the flows to be > > terminated) at the egress. > > SM and CL-PHB cannot support the handling (selection of the > flows to > > be > > terminated) > > at the egress. This means that such a PCN scheme should also be > > allowed, i.e., as an experimental-track extension. > > I don't understand why neither SM or CL-PHB can support > egress-based flow termination, *assuming that the egress node > has flow state* (which is presumed if we are not tunneling). Georgios: The main problem with these schemes is that they are measuring the actual value of the throughput and not the actual value of the excess rate. Note that the actual value of the excess rate is needed in order to know how many flows should be selected for termination. SM and CL-PHB are able to calculate this actual excess rate only at the ingress. The egress sends the value of the measured throughput. Then the ingress measures the incoming load and substracts the measured throughput in order to calculate the actual Excess rate. In this way, the ingress can calculate and select flows to be terminated in order to solve the severe congestion. A scheme like LC-PCN is measuring the actual excess rate directly at the egress. In this way, the egress can calculate and select flows to be terminated in order to solve the severe congestion. Best regards, Georgios > > > Furthermore, according to the previous discussions on the > PCN mailing > > list, I think that care should be taken on the way of how > preferential > > dropping is used wthin the PCN domain. In other words, preferetial > > dropping of marked packet should not be mandated. > > > > Regards, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven Blake > Ericsson/Redback Networks +1 919-472-9913 > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sat Mar 29 15:01:33 2008 Return-Path: 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 4652E3A6E9E; Sat, 29 Mar 2008 15:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.951 X-Spam-Level: X-Spam-Status: No, score=-100.951 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 rqJypfuRgnA0; Sat, 29 Mar 2008 15:01:32 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4299C3A695E; Sat, 29 Mar 2008 15:01:32 -0700 (PDT) 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 D15823A6880 for ; Sat, 29 Mar 2008 15:01:27 -0700 (PDT) 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 LLPExkz17BGZ for ; Sat, 29 Mar 2008 15:01:27 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id D25D928C0FC for ; Sat, 29 Mar 2008 15:00:57 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m2TM0Kl24663; Sat, 29 Mar 2008 22:00:20 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 29 Mar 2008 18:00:50 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB6465153C509B@zcarhxm1.corp.nortel.com> In-Reply-To: <1205860102.9521.27.camel@neutrino> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions: Q1, Q2, and Q3. Thread-Index: AciJGt5dLi64fJH1Tgyz+bgn5rIHzAImLj/Q References: <1205860102.9521.27.camel@neutrino> From: "Jozef Babiarz" To: "Steven Blake" , "pcn" Subject: Re: [PCN] Concensus questions: Q1, Q2, and Q3. X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org My answers: Yes to Q1, Q2 and Q3. On Q1, I'm assuming that the next question that needs to be asked is what will PCN wg standards using only two codepoints? a) Method for admission control? b) Method for flow termination? c) Method that attempts to do both admission control and flow termination using only two codepoints? As has been pointed out on the list there are performance and deployment constrictions with c approach. On Q2, I believe the other encoding should be optional versus experimental, but can live if the wg prefers experimental. Further, I believe that PCN wg needs to standardize a method for admission control that can be deployed and will work well in most networks. Flow termination should be optional as it may not be needed in many network and operators may choose other ways to solve single link failures or even multiple link/node failures versus using flow termination. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Steven Blake Sent: March 18, 2008 1:08 PM To: pcn Subject: [PCN] Concensus questions: Q1, Q2, and Q3. Six consensus questions were taken during the IETF 71 meeting. I would now like to raise them on the list. I will do this in step-wise fashion. Q1: As an initial standardization activity, should the PCN wg produce a standards-track PCN scheme that requires only two encoding states? (Note: this question does not presume that the solution is Single Marking). Q2: Presuming consensus in favor of Q1, should the PCN wg produce one or more experimental-track extensions to the standards-track PCN scheme that require another encoding state (for a total of three encoding states)? Q3: Does the PCN working group have enough information to make a decision about the way forward for the standards-track PCN scheme? By my notes, Q1 was accepted in the meeting 8-0, Q2 was accepted 9-0, and Q3 was accepted 6-1 (but my notes are fuzzy on Q3's result). Please send comments to the list during the next few days. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ 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 From pcn-bounces@ietf.org Sat Mar 29 16:15:52 2008 Return-Path: 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 3830C3A6D3D; Sat, 29 Mar 2008 16:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.207 X-Spam-Level: X-Spam-Status: No, score=-101.207 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 Grl7YRJiuFKu; Sat, 29 Mar 2008 16:15:51 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 548C53A6A8E; Sat, 29 Mar 2008 16:15:51 -0700 (PDT) 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 5C62B3A6921 for ; Sat, 29 Mar 2008 16:15:49 -0700 (PDT) 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 c3NoFS1-nZQk for ; Sat, 29 Mar 2008 16:15:48 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 9842E3A6965 for ; Sat, 29 Mar 2008 16:15:42 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id m2TNFbd06990; Sat, 29 Mar 2008 23:15:38 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 29 Mar 2008 19:15:19 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB6465153C50A6@zcarhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Possible clever encoding for PCN Thread-Index: AciElmZkIrMBDw6WSZSJ5bmxbCMnQANV3k6w References: From: "Jozef Babiarz" To: , Subject: Re: [PCN] Possible clever encoding for PCN X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Toby, Bob, I like your approach and would like to suggest a minor modification. EF-admit is used for admission control with the ECN bits being used in the following way: ECN = 00 Not-PCN-capable meaning that admission control is done some other way. ECN = 10 or 01 (ECT) means that PCN based admission control will be done on these packets. ECN = 11 (CE) means that admission control traffic (PCN and non-PCN) is above the configured admission threshold and no additional flows should be admitted. Note: If PCN wg decides to use the EF-admit codepoint it needs consider traffic that is admission control via other means passing through the network. Networks that wish to support flow termination they use a DSCP to signal that state to indicate that some flows need to be terminated. This approach reduces the risk if there are ECMP implementations which may cause mis-ordering of packets of flows that may be terminated. Should mis-ordering occur it will be very infrequent event. Should also point out to the PCN wg that 3sm approach for flow termination marking in seniors where changing DSCP for flow termination cause route change will only mis-order one packet of a flow that is to be terminated. Packets of flows that that are not going to be terminated will not be mis-ordered. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of toby.moncaster@bt.com Sent: March 12, 2008 7:11 PM To: pcn@ietf.org Subject: [PCN] Possible clever encoding for PCN Hi All, Bob and I just spent a fun 30 minutes trying to work out how to carry end-to-end ECN across PCN whilst still retaining all the PCN codepoints we need. We think we have succeeded... The attached 2 slides try to set this encoding out as clearly as possible. Note the new terminology being used! Also note that this is making the assumption that we will be re-using Fred Baker's DSCP and hence need to identify PCN traffic from not PCN traffic. Toby ____________________________________________________________________ Toby Moncaster, Networks Research Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 (in case anyone is wondering at the title it stands for: you can please everyone all the time...) _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sun Mar 30 12:10:36 2008 Return-Path: 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 5F19B3A695F; Sun, 30 Mar 2008 12:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.72 X-Spam-Level: X-Spam-Status: No, score=-99.72 tagged_above=-999 required=5 tests=[AWL=-1.585, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, MIME_HTML_MOSTLY=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] 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 EOYZ+LuCbSq2; Sun, 30 Mar 2008 12:10:30 -0700 (PDT) Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 699883A6857; Sun, 30 Mar 2008 12:10:21 -0700 (PDT) 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 043523A6822 for ; Sun, 30 Mar 2008 12:10:20 -0700 (PDT) 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 ifRwBAjkbSVd for ; Sun, 30 Mar 2008 12:10:13 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 8D4573A6907 for ; Sun, 30 Mar 2008 12:10:12 -0700 (PDT) Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id m2UJ9Ya26101 for ; Sun, 30 Mar 2008 19:09:35 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 30 Mar 2008 15:10:05 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB6465153C513F@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Single DSCP for Admission and Flow Termination Marking Thread-Index: AciSmam/Ae1M4lI9Ra60kF9c/KnbMQ== From: "Jozef Babiarz" To: Subject: [PCN] Single DSCP for Admission and Flow Termination Marking X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0711107313==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0711107313== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C89299.AB336AF2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C89299.AB336AF2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was thinking about the encoding and tunneling problem for PCN and I think there may be a method by which a single DSCP and the ECN field can be used to signal both admission control and flow termination using ECN bits. Would like others to think about this and point out any issues that I may have missed. The proposed approach can use the EF-admit DSCP for PCN. My assumptions: The EF-admit DSCP is used for end-to-end admission control as proposed by Fred Baker and the PCN wg also reuses this DSCP for PCN based admission control and flow termination function for edge-to-edge. Should note that I believe this can also be used for end-to-end PCN based admission and termination but this is currently out of scope so I will not discuss. Proposed encoding: A packet that is market with EF-admit DSCP means that it is admission control with that ECN bits be used in the following way: ECN =3D 00, means that packet is not-PCN-capable and that admission control is done some other way. Interior nodes remark ECN =3D "01" packets to "11" if traffic rate is above PCN-lower-rate. Interior nodes remark ECN =3D "10" packets to "11" if traffic rate is above PCN-upper-rate.=20 How it works: For PCN based admission control this approach requires that "probe" packet be sent at flow setup to determine if a new flow can be admitted. Example of a probe packet is a RSVP Path message sent from ingress-edge-node to egress-edge-node. The RSVP Path packet is market with EF-admit DSCP and has its ECN bits set to "01". Interior nodes meter EF-admit packets against the PCN-lower-rate and the result of the meter is passed to the marker where the marker remarks "01" packet to "11" if PCN-lower-rate was exceeded. The metering and marking behavior is the so called "threshold marking" as defined in CL or 3sm drafts for admission control. For PCN based flow termination, once a flow is admitted, ingress-edge-node marks admitted PCN traffic with ECN bits to "10". Interior nodes meter EF-admit packets against PCN-upper-rate and the results of the meter is passed to the marker where the maker remarks "10" packets to "11" based on "excess-rate marking" with or without marking frequency reduction.=20 The egress-edge-node knows if the "11" market packet is a probe or it belongs to an admitted flow therefore it can interpret what the marking means.=20 This sounds simple, so what have I missed?=20 This approach works with tunneling, as ECN CE state is copied from outer to inner IP header on de-encapsulation. I believe that this marking also satisfies guidelines in RFC4774. Are there any conditions where this marking approach will not work? One final note: If PCN wg decides to reuse the EF-admit DSCP for PCN than we need to ask Fred Baker to add a statement in to his draft that the ECN bits in the IP header are used for other function and that RFC3168 does not apply to EF-admit DSCP as per guidance in RFC4774. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 ------_=_NextPart_001_01C89299.AB336AF2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Single DSCP for Admission and Flow Termination Marking

I was thinking about the encoding and tunneling = problem for PCN and I think there may be a method by which a single DSCP = and the ECN field can be used to signal both admission control and flow = termination using ECN bits. Would like others to think about this and = point out any issues that I may have missed.

The proposed approach can use the EF-admit DSCP for = PCN.

My = assumptions:

The = EF-admit DSCP is used for end-to-end admission control as proposed by = Fred Baker and the PCN wg also reuses this DSCP for PCN based admission = control and flow termination function for edge-to-edge. Should note that = I believe this can also be used for end-to-end PCN based admission and = termination but this is currently out of scope so I will not = discuss.

Proposed encoding:

A packet that is market with = EF-admit DSCP means that it is admission control with that ECN bits be = used in the following way:

ECN =3D = 00, means that packet is not-PCN-capable and that admission control is = done some other way.

Interior nodes remark ECN = =3D “01” packets to “11” if traffic rate is above = PCN-lower-rate.

Interior nodes remark ECN =3D “10” packets to = “11” if traffic rate is above PCN-upper-rate. =

How it = works:

For PCN = based admission control this approach requires that “probe” = packet be sent at flow setup to determine if a new flow can be admitted. = Example of a probe packet is a RSVP Path message sent from ingress-edge-node to = egress-edge-node. The RSVP Path packet is market with EF-admit DSCP and = has its ECN bits set to “01”. Interior nodes meter EF-admit packets against the = PCN-lower-rate and the result of the meter is passed to the marker where = the marker remarks “01” packet to “11” if PCN-lower-rate was exceeded. The metering and marking behavior is the so = called = “threshold marking” as defined in CL or 3sm = drafts for admission control.

For PCN based flow termination, = once a flow is admitted, ingress-edge-node marks admitted PCN = traffic = with ECN bits to “10”. Interior nodes meter EF-admit packets against PCN-upper-rate and the results of the meter is passed to the = marker where the maker = remarks = “10” packets to “11” based = on “excess-rate marking” with or without marking = frequency reduction.

The egress-edge-node knows if the “11” market = packet is a probe or it belongs to an admitted flow therefore it can interpret what the marking = means.

This sounds simple, so what have I = missed? =

This = approach = works with tunneling, = as ECN CE state is copied from outer to inner IP header on de-encapsulation.

I = believe = that this marking also satisfies guidelines in = RFC4774.

Are there any conditions where = this marking approach will not work?

One final note:

If PCN wg decides to reuse the EF-admit DSCP for = PCN than we need to ask Fred Baker to add a statement in to his draft = that = the ECN bits in the IP header are used for other function and = that RFC3168 does not apply to EF-admit DSCP as per guidance in = RFC4774.

Regards, Joe

email:babiarz@nortel.com

Telephone:613-763-6098

------_=_NextPart_001_01C89299.AB336AF2-- --===============0711107313== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0711107313==-- From pcn-bounces@ietf.org Mon Mar 31 08:42:07 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02C8028C1A8; Mon, 31 Mar 2008 08:42:07 -0700 (PDT) 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 D1F7C28C156 for ; Mon, 31 Mar 2008 08:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.527 X-Spam-Level: X-Spam-Status: No, score=-0.527 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_40=-0.185] 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 lrxIIzNEdFTr for ; Mon, 31 Mar 2008 08:42:05 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id 1F1AF3A6B62 for ; Mon, 31 Mar 2008 08:42:05 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 19929833DF6; Mon, 31 Mar 2008 11:42:43 -0400 (EDT) To: pcn@ietf.org Message-Id: <20080331154243.19929833DF6@newdev.eecs.harvard.edu> Date: Mon, 31 Mar 2008 11:42:43 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: [PCN] minutes for the Phili mtg X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org I uploaded the draft minutes for the PCN sessions in Phili to the preceedings web site - please review & send me any changes http://www.ietf.org/proceedings/08mar/minutes/pcn.txt thanks to Dave McDysan, Kwok-Ho Chan and Bob Briscoe for their note taking Scott _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 31 10:07:14 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D13BD3A6CDB; Mon, 31 Mar 2008 10:07:14 -0700 (PDT) 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 CE8803A6D08 for ; Mon, 31 Mar 2008 10:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ojMT6Otol9+Z for ; Mon, 31 Mar 2008 10:07:12 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id 205623A6CD5 for ; Mon, 31 Mar 2008 10:07:12 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m2VH79KA021383 for ; Mon, 31 Mar 2008 12:07:10 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Mar 2008 12:07:09 -0500 Received: from [147.117.169.77] ([147.117.169.77]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Mar 2008 12:07:09 -0500 From: Steven Blake To: pcn In-Reply-To: <1205860102.9521.27.camel@neutrino> References: <1205860102.9521.27.camel@neutrino> Organization: Ericsson IP Infrastructure Date: Mon, 31 Mar 2008 13:07:09 -0400 Message-Id: <1206983229.3561.4.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) X-OriginalArrivalTime: 31 Mar 2008 17:07:09.0398 (UTC) FILETIME=[A7A01760:01C89351] Subject: Re: [PCN] Concensus questions: Q1, Q2, and Q3. X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org On Tue, 2008-03-18 at 13:08 -0400, Steven Blake wrote: > Six consensus questions were taken during the IETF 71 meeting. I would > now like to raise them on the list. I will do this in step-wise > fashion. > > Q1: As an initial standardization activity, should the PCN wg produce a > standards-track PCN scheme that requires only two encoding states? > (Note: this question does not presume that the solution is Single > Marking). > > Q2: Presuming consensus in favor of Q1, should the PCN wg produce one or > more experimental-track extensions to the standards-track PCN scheme > that require another encoding state (for a total of three encoding > states)? > > Q3: Does the PCN working group have enough information to make a > decision about the way forward for the standards-track PCN scheme? > > By my notes, Q1 was accepted in the meeting 8-0, Q2 was accepted 9-0, > and Q3 was accepted 6-1 (but my notes are fuzzy on Q3's result). > > Please send comments to the list during the next few days. By my reading of the (limited) feedback, we have very firm consensus on Q1 and Q2, and rough consensus on Q3. I will send a follow-up email on the remaining questions in a moment. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 31 10:16:04 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0E3628C27C; Mon, 31 Mar 2008 10:16:04 -0700 (PDT) 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 6CFFD28C2DD for ; Mon, 31 Mar 2008 10:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 8xDfKopK4BYB for ; Mon, 31 Mar 2008 10:15:58 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by core3.amsl.com (Postfix) with ESMTP id BCAD13A6CB4 for ; Mon, 31 Mar 2008 10:15:51 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d11so831288and.122 for ; Mon, 31 Mar 2008 10:15:49 -0700 (PDT) Received: by 10.100.127.15 with SMTP id z15mr16532135anc.61.1206983749260; Mon, 31 Mar 2008 10:15:49 -0700 (PDT) Received: from ?10.71.0.135? ( [216.133.218.2]) by mx.google.com with ESMTPS id c27sm7729429ana.27.2008.03.31.10.15.47 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 31 Mar 2008 10:15:48 -0700 (PDT) Message-Id: From: Lars Eggert To: ext Jozef Babiarz In-Reply-To: <9671A92C3C8B5744BC97F855F7CB6465153C513F@zcarhxm1.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v919.2) Date: Mon, 31 Mar 2008 10:15:46 -0700 References: <9671A92C3C8B5744BC97F855F7CB6465153C513F@zcarhxm1.corp.nortel.com> X-Mailer: Apple Mail (2.919.2) Cc: pcn@ietf.org Subject: Re: [PCN] Single DSCP for Admission and Flow Termination Marking X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0830346751==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org --===============0830346751== Content-Type: multipart/signed; boundary=Apple-Mail-6-1043279797; micalg=sha1; protocol="application/pkcs7-signature" --Apple-Mail-6-1043279797 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi, Joe, On 2008-3-30, at 12:10, ext Jozef Babiarz wrote: > For PCN based admission control this approach requires that "probe" > packet be sent at flow setup to determine if a new flow can be > admitted. one quick comment: do I understand this correctly that this encoding would require probing, i.e., make it a mandatory part of the architecture? Lars --Apple-Mail-6-1043279797 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIC/TCCAvkw ggJioAMCAQICEFcKn6uMJyFYm3ow9AwDVo0wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA3MTEyMDA4NTMyMloXDTA4MTExOTA4NTMy MlowXDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVnZ2Vy dDEkMCIGCSqGSIb3DQEJARYVbGFycy5lZ2dlcnRAbm9raWEuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAxx0rd8E8VV2l2Y/zV2buSRcCWScJwDJc8moZY88N1Hla1CMhh83tIPQN pukkPE6GMIJjferzgTV8extFAd6jrk96U6HJLXF/xzxKX/U3ksT/rwyLCO8l9T8OwNtmjWjMwn0Y 1f4V5JnXLyZDz97BaN2rnJjccSIYuDJLXPzaTE3kxYe7j35iIgyaqhLYs3dERHOOJpiuWhHOj45C m/4hCWiSEtwabUtufw232z2r4tExOXuxH8OJtbbJxmf/tb+/m5pNRQbKl1KWbFlLqeojqgrG56jx uxNDfMaTNHfygPea8LGjzrE0Ck3lqUYXD2/dk45Y8lJAAhFQ3erCwMw1XwIDAQABozIwMDAgBgNV HREEGTAXgRVsYXJzLmVnZ2VydEBub2tpYS5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUF AAOBgQBGcuNVdbuBMUyXaAiENyTmsKPOwd/PJOI540ONxvVyGtycdaMMlUL+tz/Qcznv/hnqN7u2 NqrvBYn+afSlZKQHgbSjFT4b8hD3rWnU6/EeS+HX8k5ogJqyy4et/TomMp4gIxC/jjhFw3XWhKpm 4Wr51tzDI3lUs2PlVNLFSiBhNzGCAxAwggMMAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBG cmVlbWFpbCBJc3N1aW5nIENBAhBXCp+rjCchWJt6MPQMA1aNMAkGBSsOAwIaBQCgggFvMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA4MDMzMTE3MTU0NlowIwYJKoZI hvcNAQkEMRYEFLjtbBDln8GHIXjZD3k05aHAkdzTMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQVwqfq4wnIVibejD0DANWjTCBhwYL KoZIhvcNAQkQAgsxeKB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGlu ZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBD QQIQVwqfq4wnIVibejD0DANWjTANBgkqhkiG9w0BAQEFAASCAQA1yKz0/1lyBRifX1DNaRR2TpS2 kySV1/IukjoZYe8Id58deD81JhKDPYgdZoS1gV+D19J98+q0jvT1zHkxQUXPAZWrcIjkspuxPVXk TaoIEgNqjtUgiQjgjdyyNQZeUs1L2v+9Bl89Izo7vIcEuNu94DzE5PDCnzpzlYPqGSRhLy9ft8Gz KhlATS1ZM2UzMiVVHCdgm3KLLZ/brKvX5gZDcRSwd5d6+znTKAOLd/vwDA17QU5QGk8bskJ78HFr ZXGzBHafAl3KyRXjV7BuFJRR2w0Ogk0xyX3yXB8d9yOoHV1Tpzu7rU0wXDglPwNcHkU1Uin/e97S eGJ2cTvDnoxWAAAAAAAA --Apple-Mail-6-1043279797-- --===============0830346751== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn --===============0830346751==-- From pcn-bounces@ietf.org Mon Mar 31 10:18:22 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0DE73A6DD6; Mon, 31 Mar 2008 10:18:22 -0700 (PDT) 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 B4B0028C27C for ; Mon, 31 Mar 2008 10:18:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 MaAfzU+aU9nf for ; Mon, 31 Mar 2008 10:18:20 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id A67BB3A6862 for ; Mon, 31 Mar 2008 10:18:18 -0700 (PDT) Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id m2VHIGPr028860 for ; Mon, 31 Mar 2008 12:18:16 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Mar 2008 12:18:16 -0500 Received: from [147.117.169.77] ([147.117.169.77]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 31 Mar 2008 12:18:16 -0500 From: Steven Blake To: pcn Organization: Ericsson IP Infrastructure Date: Mon, 31 Mar 2008 13:18:15 -0400 Message-Id: <1206983895.3561.12.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8) X-OriginalArrivalTime: 31 Mar 2008 17:18:16.0276 (UTC) FILETIME=[351D9940:01C89353] Subject: [PCN] Consensus questions: Q4, Q5, and Q6 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Here are the remaining three questions that were taken during the IETF 71 meeting: Q4: Should the standards-track PCN scheme require (as a MUST implement feature) that interior PCN routers support Excess-Rate marking, according to the particular method of handling already marked packets and drops described in Anna Charny's presentation? http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf Q5: Should the standards-track PCN scheme require (as a MUST implement feature) that interior PCN routers support Threshold marking (in addition to Excess-Rate marking), according to the particular method described in Philip Eardley's presentation on Tuesday? http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf Q6: If presented with sufficient evidence in a timely fashion, would the PCN wg entertain the option of modifying the interior router Excess-Rate marking behavior for the standards-track PCN scheme (as described in question 4)? According to the draft meeting minutes, Q4 was accepted 8-0 (my notes have it as 6-0), Q5 was accepted 6-1, and Q6 was accepted 2-0. Please send comments to the list during the next few days. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Mar 31 15:42:00 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AD3C3A6CCE; Mon, 31 Mar 2008 15:42:00 -0700 (PDT) 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 D88043A6C27 for ; Mon, 31 Mar 2008 15:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.051 X-Spam-Level: X-Spam-Status: No, score=0.051 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_TOOL=2.3] 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 H-+b70hrKw3j for ; Mon, 31 Mar 2008 15:41:57 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id C7AD228C301 for ; Mon, 31 Mar 2008 15:41:48 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 3FEF9A27AE; Tue, 1 Apr 2008 00:41:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 3247BA2799; Tue, 1 Apr 2008 00:41:46 +0200 (CEST) Received: from [213.23.32.86] (213-23-32-86.accor-hotels.arcor-ip.net [213.23.32.86]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id E44A5A276B; Tue, 1 Apr 2008 00:41:44 +0200 (CEST) Message-ID: <47F16879.3000007@informatik.uni-wuerzburg.de> Date: Tue, 01 Apr 2008 00:40:57 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Jozef Babiarz References: <9671A92C3C8B5744BC97F855F7CB6465153C513F@zcarhxm1.corp.nortel.com> In-Reply-To: <9671A92C3C8B5744BC97F855F7CB6465153C513F@zcarhxm1.corp.nortel.com> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Single DSCP for Admission and Flow Termination Marking X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Joe, if I understand correctly, your idea is the following: Apply marking based on admissible rate (AR) only to probe packets (01) = and possibly switch to 11 in case of AR-pre-congestion Apply marking based on supportable rate (SR) only to data packets (10) = and possibly switch to 11 in case of SR-pre-congestion Probe and data packets can be differentiated (somehow) by the egress = node, therefore, the egress knows whether 11 means AM or TM. Lars pointed out that this approach implicitly assumes that AR-marking = is applied only to probe packets and I share his view. Per-flow probing = is one option for this architecture, which could be implicitly done with = RSVP-PATH messages or explicite probes. Another option are regular probe = messages per IEA to keep its admission/block state up to date. This = should not be a problem when regular transmission of CLE values from = egress to the ingress nodes is also considered feasible (cf. CL, SM). = It's basically a ping every e.g. 100ms between communicating = ingress-egress node pairs. What we lose: picky-backing pre-congestion notification concerning = admissible rates onto data packets What we gain: possibility of using more accurate admission control based = on threshold marking (applicable to smaller IEAs) combined with flow = termination, ability to cope with ECMP (assumption: per-flow probing), = and independence of admissible and supportable rates (SR=3Du*AR not = needed) per link (simpler/more flexible configuration of PCN rate = thresholds) while using only a single DSCP. Regards, Michael Jozef Babiarz wrote: > > I was thinking about the encoding and tunneling problem for PCN and I = > think there may be a method by which a single DSCP and the ECN field = > can be used to signal both admission control and flow termination = > using ECN bits. Would like others to think about this and point out = > any issues that I may have missed. > > The proposed approach can use the EF-admit DSCP for PCN. > > My assumptions: > > The EF-admit DSCP is used for end-to-end admission control as proposed = > by Fred Baker and the PCN wg also reuses this DSCP for PCN based = > admission control and flow termination function for edge-to-edge. = > Should note that I believe this can also be used for end-to-end PCN = > based admission and termination but this is currently out of scope so = > I will not discuss. > > Proposed encoding: > > A packet that is market with EF-admit DSCP means that it is admission = > control with that ECN bits be used in the following way: > > ECN =3D 00, means that packet is not-PCN-capable and that admission = > control is done some other way. > > Interior nodes remark ECN =3D =9301=94 packets to =9311=94 if traffic rat= e is = > above PCN-lower-rate. > > Interior nodes remark ECN =3D =9310=94 packets to =9311=94 if traffic rat= e is = > above PCN-upper-rate. > > How it works: > > For PCN based admission control this approach requires that =93probe=94 = > packet be sent at flow setup to determine if a new flow can be = > admitted. Example of a probe packet is a RSVP Path message sent from = > ingress-edge-node to egress-edge-node. The RSVP Path packet is market = > with EF-admit DSCP and has its ECN bits set to =9301=94. Interior nodes = > meter EF-admit packets against the PCN-lower-rate and the result of = > the meter is passed to the marker where the marker remarks =9301=94 packe= t = > to =9311=94 if PCN-lower-rate was exceeded. The metering and marking = > behavior is the so called =93threshold marking=94 as defined in CL or 3sm = > drafts for admission control. > > For PCN based flow termination, once a flow is admitted, = > ingress-edge-node marks admitted PCN traffic with ECN bits to =9310=94. = > Interior nodes meter EF-admit packets against PCN-upper-rate and the = > results of the meter is passed to the marker where the maker remarks = > =9310=94 packets to =9311=94 based on =93excess-rate marking=94 with or w= ithout = > marking frequency reduction. > > The egress-edge-node knows if the =9311=94 market packet is a probe or it = > belongs to an admitted flow therefore it can interpret what the = > marking means. > > This sounds simple, so what have I missed? > > This approach works with tunneling, as ECN CE state is copied from = > outer to inner IP header on de-encapsulation. > > I believe that this marking also satisfies guidelines in RFC4774. > > Are there any conditions where this marking approach will not work? > > One final note: > > If PCN wg decides to reuse the EF-admit DSCP for PCN than we need to = > ask Fred Baker to add a statement in to his draft that the ECN bits in = > the IP header are used for other function and that RFC3168 does not = > apply to EF-admit DSCP as per guidance in RFC4774. > > ///Regards, Joe/ > > email:babiarz@nortel.com > > Telephone:613-763-6098 > > ------------------------------------------------------------------------ > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > = -- = 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 From pcn-bounces@ietf.org Mon Mar 31 15:43:19 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 395A128C2E7; Mon, 31 Mar 2008 15:43:19 -0700 (PDT) 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 219ED28C24E for ; Mon, 31 Mar 2008 15:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 VxMXAsDp6Dqq for ; Mon, 31 Mar 2008 15:43:17 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 6C3263A6D1C for ; Mon, 31 Mar 2008 15:43:13 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id ED4D0A2799; Tue, 1 Apr 2008 00:43:11 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id DFCF5A276B; Tue, 1 Apr 2008 00:43:11 +0200 (CEST) Received: from [213.23.32.86] (213-23-32-86.accor-hotels.arcor-ip.net [213.23.32.86]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id A616D19B06A; Tue, 1 Apr 2008 00:43:10 +0200 (CEST) Message-ID: <47F168CF.9000002@informatik.uni-wuerzburg.de> Date: Tue, 01 Apr 2008 00:42:23 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Steven Blake References: <1205506476.2992.34.camel@neutrino> In-Reply-To: <1205506476.2992.34.camel@neutrino> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi, sorry for being late ... Steven Blake wrote: > Greetings. > > There were six concensus questions called during yesterday's PCN > meeting. Before we call the questions on the list, I want to paraphrase > them and make sure that everyone agrees that this captures the sense of > the discussion. > > > Q1: As an initial standardization activity, should the PCN wg produce a > standards-track PCN scheme that requires only two encoding states? > (Note: this question does not presume that the solution is Single > Marking). > Yes, it seems necessary due to missing approved alternatives. However, I find the new encoding proposal in http://www.ietf.org/mail-archive/web/pcn/current/msg01386.html quite appealing as it achieves both admission control and flow termination with a single DSCP. I think it is worthwhile to be discussed as an alternative for an encoding scheme requiring a single DSCP which seems to be our major constraint. > Q2: Should the PCN wg produce an experimental-track extension to the > standards-track PCN scheme that requires another encoding state (for > a total of three encoding states)? > Yes, it seems to allow for significantly improved PCN performance. > Q3: Does the working group have enough information to make a decision > about the way forward for the standards-track PCN scheme? > Yes - after http://www.ietf.org/mail-archive/web/pcn/current/msg01386.html only partly. It seems to be consensus that * AC based on excess rate marking with regard to the admissible rate cannot reliably deal with small ingress-egress aggregates in the order of 10 flows * We will have many small ingress-egress aggregates in the future that are even smaller http://www.ietf.org/mail-archive/web/pcn/current/msg00831.html * FT based on excess rate marking with regard to the admissible rate does not reliably work with ECMP - FT cannot always detect when strong pre-congestion occurs (u*admissible rate due to signal dilution) - FT cannot tear down only the right flows such that the termination process requires several termination steps - This issue is a matter of traffic distribution under failure conditions and cannot be solved by overprovisioning unless making the need for FT obsolete. * ECMP is a reality in many of today's networks to achieve fast reroute for ingress-egress pairs that have multiple paths. However, I feel that there is not yet a clear idea what the standards track PCN with two codepoints is used for: * admission control (AC) and flow termination (FT) based on excess marking with regard to an admissible rate * only admission control with threshold marking with regard to an admissible rate The new encoding proposal in http://www.ietf.org/mail-archive/web/pcn/current/msg01386.html seems to allow both AC based on threshold marking and FT based on excess marking at the expense of requiring probe packets to support admission decisions. > Q4: Should the standards-track PCN scheme require (as a MUST implement > feature) that interior PCN routers support Excess-Rate marking, > according to the particular method of handling already marked > packets and drops described in Anna Charny's presentation? > http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf > Yes. But it ALSO requires the option for preferential dropping of marked packets and an option for random drops with equal importance. As long as the edge behavior is not clear yet, no decision about preferential dropping can be made. Furthermore, packet size independent marking (PSIM) as described in http://tools.ietf.org/wg/pcn/draft-menth-pcn-emft-00.txt is useful to implement because the fairness of any flow termination scheme making use of marked packets to indicate flows to be terminated profits from this feature. Evidence for that is documented in http://www.ietf.org/internet-drafts/draft-menth-pcn-performance-02.txt or http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08-PCN-MFT.pdf This also applies to potential improvements of SM. > Q5: Should the standards-track PCN scheme require (as a MUST implement > feature) that interior PCN routers support Threshold marking (in > addition to Excess-Rate marking), according to the particular method > described in Philip Eardley's presentation on Tuesday? > http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf > Yes. > Q6: If presented with sufficient evidence in a timely fashion, would > the PCN wg entertain the option of modifying the interior router > Excess-Rate marking behavior for the standards-track PCN scheme (as > described in question 4)? > Yes. Regards, Michael > > Please send comments to the list. > > > Regards, > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Steven Blake > Ericsson/Redback Networks +1 919-472-9913 > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > -- 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 From pcn-bounces@ietf.org Mon Mar 31 16:04:03 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E4063A6C07; Mon, 31 Mar 2008 16:04:03 -0700 (PDT) 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 275CF3A6C11 for ; Mon, 31 Mar 2008 16:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.674 X-Spam-Level: X-Spam-Status: No, score=-1.674 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 zkWDaz6rupuD for ; Mon, 31 Mar 2008 16:04:00 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id CAC9D3A6BB9 for ; Mon, 31 Mar 2008 16:03:59 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id D3B69A27C5; Tue, 1 Apr 2008 01:03:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id C791EA27C1; Tue, 1 Apr 2008 01:03:57 +0200 (CEST) Received: from [213.23.32.86] (213-23-32-86.accor-hotels.arcor-ip.net [213.23.32.86]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 88A59A2548; Tue, 1 Apr 2008 01:03:56 +0200 (CEST) Message-ID: <47F16DAD.9060307@informatik.uni-wuerzburg.de> Date: Tue, 01 Apr 2008 01:03:09 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Steven Blake References: <1205506476.2992.34.camel@neutrino> <47F168CF.9000002@informatik.uni-wuerzburg.de> In-Reply-To: <47F168CF.9000002@informatik.uni-wuerzburg.de> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org I mean http://www.ietf.org/mail-archive/web/pcn/current/msg01387.html instead of http://www.ietf.org/mail-archive/web/pcn/current/msg01386.html See inline! Michael Menth wrote: > Hi, > > sorry for being late ... > > Steven Blake wrote: > >> Greetings. >> >> There were six concensus questions called during yesterday's PCN >> meeting. Before we call the questions on the list, I want to paraphrase >> them and make sure that everyone agrees that this captures the sense of >> the discussion. >> >> >> Q1: As an initial standardization activity, should the PCN wg produce a >> standards-track PCN scheme that requires only two encoding states? >> (Note: this question does not presume that the solution is Single >> Marking). >> >> > > Yes, it seems necessary due to missing approved alternatives. However, I > find the new encoding proposal in > http://www.ietf.org/mail-archive/web/pcn/current/msg01386.html > I mean http://www.ietf.org/mail-archive/web/pcn/current/msg01387.html > quite appealing as it achieves both admission control and flow > termination with a single DSCP. I think it is worthwhile to be discussed > as an alternative for an encoding scheme requiring a single DSCP which > seems to be our major constraint. > > >> Q2: Should the PCN wg produce an experimental-track extension to the >> standards-track PCN scheme that requires another encoding state (for >> a total of three encoding states)? >> >> > > Yes, it seems to allow for significantly improved PCN performance. > > >> Q3: Does the working group have enough information to make a decision >> about the way forward for the standards-track PCN scheme? >> >> > > Yes - after > http://www.ietf.org/mail-archive/web/pcn/current/msg01386.html I mean http://www.ietf.org/mail-archive/web/pcn/current/msg01387.html > only partly. > > It seems to be consensus that > * AC based on excess rate marking with regard to the admissible rate > cannot reliably deal with small ingress-egress aggregates in the order > of 10 flows > * We will have many small ingress-egress aggregates in the future that > are even smaller > http://www.ietf.org/mail-archive/web/pcn/current/msg00831.html > * FT based on excess rate marking with regard to the admissible rate > does not reliably work with ECMP > - FT cannot always detect when strong pre-congestion occurs > (u*admissible rate due to signal dilution) > - FT cannot tear down only the right flows such that the termination > process requires several termination steps > - This issue is a matter of traffic distribution under failure > conditions and cannot be solved by overprovisioning unless making the > need for FT obsolete. > * ECMP is a reality in many of today's networks to achieve fast reroute > for ingress-egress pairs that have multiple paths. > > However, I feel that there is not yet a clear idea what the standards > track PCN with two codepoints is used for: > * admission control (AC) and flow termination (FT) based on excess > marking with regard to an admissible rate > * only admission control with threshold marking with regard to an > admissible rate > > The new encoding proposal in > http://www.ietf.org/mail-archive/web/pcn/current/msg01386.html > seems to allow both AC based on threshold marking and FT based on excess > marking at the expense of requiring probe packets to support admission > decisions. > > >> Q4: Should the standards-track PCN scheme require (as a MUST implement >> feature) that interior PCN routers support Excess-Rate marking, >> according to the particular method of handling already marked >> packets and drops described in Anna Charny's presentation? >> http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf >> >> > > Yes. But it ALSO requires the option for preferential dropping of marked > packets and an option for random drops with equal importance. As long as > the edge behavior is not clear yet, no decision about preferential > dropping can be made. Furthermore, packet size independent marking > (PSIM) as described in > http://tools.ietf.org/wg/pcn/draft-menth-pcn-emft-00.txt > is useful to implement because the fairness of any flow termination > scheme making use of marked packets to indicate flows to be terminated > profits from this feature. Evidence for that is documented in > http://www.ietf.org/internet-drafts/draft-menth-pcn-performance-02.txt > or > http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08-PCN-MFT.pdf > > This also applies to potential improvements of SM. > > >> Q5: Should the standards-track PCN scheme require (as a MUST implement >> feature) that interior PCN routers support Threshold marking (in >> addition to Excess-Rate marking), according to the particular method >> described in Philip Eardley's presentation on Tuesday? >> http://www3.ietf.org/proceedings/08mar/slides/pcn-4.pdf >> >> > Yes. > > >> Q6: If presented with sufficient evidence in a timely fashion, would >> the PCN wg entertain the option of modifying the interior router >> Excess-Rate marking behavior for the standards-track PCN scheme (as >> described in question 4)? >> >> > Yes. > > Regards, > > Michael > > >> Please send comments to the list. >> >> >> Regards, >> >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> Steven Blake >> Ericsson/Redback Networks +1 919-472-9913 >> >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn >> >> > > -- 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 From pcn-bounces@ietf.org Mon Mar 31 16:33:12 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1818B3A6C50; Mon, 31 Mar 2008 16:33:12 -0700 (PDT) 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 1AEF43A68B0 for ; Mon, 31 Mar 2008 16:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.635 X-Spam-Level: X-Spam-Status: No, score=-3.635 tagged_above=-999 required=5 tests=[AWL=2.964, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ojBVRiRxGRcs for ; Mon, 31 Mar 2008 16:33:10 -0700 (PDT) Received: from zcars04f.nortel.com (zcars04f.nortel.com [47.129.242.57]) by core3.amsl.com (Postfix) with ESMTP id 183633A6A35 for ; Mon, 31 Mar 2008 16:33:09 -0700 (PDT) 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 m2VNX4n04711; Mon, 31 Mar 2008 23:33:05 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 31 Mar 2008 19:33:02 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646515433C88@zcarhxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Single DSCP for Admission and Flow Termination Marking Thread-Index: AciTUt7wA0kP6RfDSpqtd1jBbl7rqwAL8stQ References: <9671A92C3C8B5744BC97F855F7CB6465153C513F@zcarhxm1.corp.nortel.com> From: "Jozef Babiarz" To: "Lars Eggert" Cc: pcn@ietf.org Subject: Re: [PCN] Single DSCP for Admission and Flow Termination Marking X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This encoding requires for the ingress and egress-edge-nodes to be able to differentiate which packet that is "11" marking represents pre-congestion marking for admission control and which represent for flow termination. So for example if the ingress-edge-node sends RSVP-PATH message the egress-edge-node would know that this packet is a probe and "11" marking means that traffic level along the path is above the PCN-low-rate, therefore would send response to ingress not to admit the new flow. So yes this encoding approach would require some form of probing or exchange of information between ingress and egress nodes before a new flow is admitted. Without "probing" the ingress-edge-node nodes does not know what path or egress-edge-node the new flow once admitted will be routed. Does probing need to be mandatory? I believe that it should be highly recommended as it addresses citrine problems in PCN architecture. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: Lars Eggert [mailto:lars.eggert@googlemail.com] On Behalf Of Lars Eggert Sent: March 31, 2008 1:16 PM To: Babiarz, Jozef (CAR:0S03) Cc: pcn@ietf.org Subject: Re: [PCN] Single DSCP for Admission and Flow Termination Marking Hi, Joe, On 2008-3-30, at 12:10, ext Jozef Babiarz wrote: > For PCN based admission control this approach requires that "probe" > packet be sent at flow setup to determine if a new flow can be > admitted. one quick comment: do I understand this correctly that this encoding would require probing, i.e., make it a mandatory part of the architecture? Lars _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Apr 1 03:03:00 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F6EF28C492; Tue, 1 Apr 2008 03:03:00 -0700 (PDT) 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 7DB4228C42F for ; Tue, 1 Apr 2008 03:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 2dgopddBQRaz for ; Tue, 1 Apr 2008 03:02:53 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id AC73928C490 for ; Tue, 1 Apr 2008 03:02:49 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.64]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 11:02:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 11:02:22 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B346C2@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <47F168CF.9000002@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciTgh7t/lUl8ZA8Tr6A4px098XvBwAXI4PQ From: To: , X-OriginalArrivalTime: 01 Apr 2008 10:02:46.0712 (UTC) FILETIME=[89184B80:01C893DF] Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org > > Q4: Should the standards-track PCN scheme require (as a MUST implement > > feature) that interior PCN routers support Excess-Rate marking, > > according to the particular method of handling already marked > > packets and drops described in Anna Charny's presentation? > > http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf > > > > Yes. But it ALSO requires the option for preferential dropping of marked > packets and an option for random drops with equal importance. I believe we need to decide. A standard for marking behaviour with 3 options about dropping is not acceptable. As long as > the edge behavior is not clear yet, no decision about preferential > dropping can be made. Furthermore, packet size independent marking > (PSIM) as described in > http://tools.ietf.org/wg/pcn/draft-menth-pcn-emft-00.txt > is useful to implement suggestion in Philadelphia is that this is a SHOULD (for excess rate marking). because the fairness of any flow termination > scheme making use of marked packets to indicate flows to be terminated > profits from this feature. Evidence for that is documented in > http://www.ietf.org/internet-drafts/draft-menth-pcn-performance-02.txt > or > http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08 - > PCN-MFT.pdf > > This also applies to potential improvements of SM. > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Apr 1 08:45:23 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EB6E3A6EBA; Tue, 1 Apr 2008 08:45:23 -0700 (PDT) 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 63C183A6EB7 for ; Tue, 1 Apr 2008 08:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] 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 M+1fI-vufuu1 for ; Tue, 1 Apr 2008 08:45:15 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id A91763A68BC for ; Tue, 1 Apr 2008 08:44:55 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 00B7719A465; Tue, 1 Apr 2008 17:44:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id E918E19A440; Tue, 1 Apr 2008 17:44:52 +0200 (CEST) Received: from [10.0.0.49] (nx15.hrz.uni-dortmund.de [129.217.143.249]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 303F0A1C40; Tue, 1 Apr 2008 17:44:50 +0200 (CEST) Message-ID: <47F25844.9010007@informatik.uni-wuerzburg.de> Date: Tue, 01 Apr 2008 17:44:04 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: philip.eardley@bt.com References: <75A199C5D243C741BF3D3F1EBCEF9BA503B346C2@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <75A199C5D243C741BF3D3F1EBCEF9BA503B346C2@E03MVZ1-UKDY.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, philip.eardley@bt.com wrote: >>> Q4: Should the standards-track PCN scheme require (as a MUST >>> > implement > >>> feature) that interior PCN routers support Excess-Rate marking, >>> according to the particular method of handling already marked >>> packets and drops described in Anna Charny's presentation? >>> http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf >>> >>> >> Yes. But it ALSO requires the option for preferential dropping of >> > marked > >> packets and an option for random drops with equal importance. >> > > I believe we need to decide. A standard for marking behaviour with 3 > options about dropping is not acceptable. > I want to point out that preferential dropping of marked packets makes indirect measured rate termination work well while direct measured rate termination does not work any more with packet loss as it would require preferential dropping of unmarked packets. Thus, not supporting preferential dropping of unmarked packets as another option already rules out possible edge behaviors. Therefore, this decision about preferential dropping is already a decision about possible edge behaviors. Regards, Michael > As long as > >> the edge behavior is not clear yet, no decision about preferential >> dropping can be made. Furthermore, packet size independent marking >> (PSIM) as described in >> http://tools.ietf.org/wg/pcn/draft-menth-pcn-emft-00.txt >> is useful to implement >> > > suggestion in Philadelphia is that this is a SHOULD (for excess rate > marking). > > because the fairness of any flow termination > >> scheme making use of marked packets to indicate flows to be terminated >> profits from this feature. Evidence for that is documented in >> http://www.ietf.org/internet-drafts/draft-menth-pcn-performance-02.txt >> or >> >> > http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08 > - > >> PCN-MFT.pdf >> >> This also applies to potential improvements of SM. >> >> -- 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 From pcn-bounces@ietf.org Tue Apr 1 08:55:30 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8043828C457; Tue, 1 Apr 2008 08:55:30 -0700 (PDT) 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 3C30028C3A1 for ; Tue, 1 Apr 2008 08:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-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 DMNh7rL3j-rP for ; Tue, 1 Apr 2008 08:55:28 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id C8C2428C4D0 for ; Tue, 1 Apr 2008 08:55:13 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.64]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 1 Apr 2008 16:55:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Apr 2008 16:55:09 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA503B346CA@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: <47F25844.9010007@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Concensus questions from Thursday's PCN meeting Thread-Index: AciUD1a6OAeiGXLgQV2kJUcLWSoHBAAAPgbw From: To: X-OriginalArrivalTime: 01 Apr 2008 15:55:11.0006 (UTC) FILETIME=[C41383E0:01C89410] Cc: pcn@ietf.org Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org "does not work" is over-stating it, I think Michael. But yes, which edge behaviour is most naturally supported (or which ones are slightly less well supported) does depend on the dropping behaviour (which we said would be a SHOULD) phil > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: 01 April 2008 16:44 > To: Eardley,PL,Philip,CXR9 R > Cc: steven.blake@ericsson.com; pcn@ietf.org > Subject: Re: [PCN] Concensus questions from Thursday's PCN meeting > > Hi Phil, > > philip.eardley@bt.com wrote: > >>> Q4: Should the standards-track PCN scheme require (as a MUST > >>> > > implement > > > >>> feature) that interior PCN routers support Excess-Rate marking, > >>> according to the particular method of handling already marked > >>> packets and drops described in Anna Charny's presentation? > >>> http://www3.ietf.org/proceedings/08mar/slides/pcn-6.pdf > >>> > >>> > >> Yes. But it ALSO requires the option for preferential dropping of > >> > > marked > > > >> packets and an option for random drops with equal importance. > >> > > > > I believe we need to decide. A standard for marking behaviour with 3 > > options about dropping is not acceptable. > > > > I want to point out that preferential dropping of marked packets makes > indirect measured rate termination work well while direct measured rate > termination does not work any more with packet loss as it would require > preferential dropping of unmarked packets. Thus, not supporting > preferential dropping of unmarked packets as another option already > rules out possible edge behaviors. Therefore, this decision about > preferential dropping is already a decision about possible edge behaviors. > > Regards, > > Michael > > > As long as > > > >> the edge behavior is not clear yet, no decision about preferential > >> dropping can be made. Furthermore, packet size independent marking > >> (PSIM) as described in > >> http://tools.ietf.org/wg/pcn/draft-menth-pcn-emft-00.txt > >> is useful to implement > >> > > > > suggestion in Philadelphia is that this is a SHOULD (for excess rate > > marking). > > > > because the fairness of any flow termination > > > >> scheme making use of marked packets to indicate flows to be terminated > >> profits from this feature. Evidence for that is documented in > >> http://www.ietf.org/internet-drafts/draft-menth-pcn-performance-02.txt > >> or > >> > >> > > http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08 > > - > > > >> PCN-MFT.pdf > >> > >> This also applies to potential improvements of SM. > >> > >> > > -- > 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