From pcn-bounces@ietf.org Fri Aug 1 02:08:24 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E462F3A6AFD; Fri, 1 Aug 2008 02:08: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 D8AA13A6AFD for ; Fri, 1 Aug 2008 02:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 mkQMkSkDSJls for ; Fri, 1 Aug 2008 02:08:23 -0700 (PDT) Received: from smtp129.rog.mail.re2.yahoo.com (smtp129.rog.mail.re2.yahoo.com [206.190.53.34]) by core3.amsl.com (Postfix) with SMTP id DBE913A6AF6 for ; Fri, 1 Aug 2008 02:08:22 -0700 (PDT) Received: (qmail 13464 invoked from network); 1 Aug 2008 09:08:09 -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:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=lP31xF51m0DfoCHpbJ1Q3F6DPicW2qh0ycRLREN8vZqGRURSilyWYraW6BN13va97bpnmeGFu+VEjjM58S0Wo3mHXaxZZYXny9FZjBsxxd2mob22WXxDE1q72YPIM7M/vQlz4ztflNVdds2UupZZ66SachItt5hOW9FHIpQTJVM= ; Received: from unknown (HELO ?130.129.18.207?) (tom.taylor@rogers.com@130.129.18.207 with plain) by smtp129.rog.mail.re2.yahoo.com with SMTP; 1 Aug 2008 09:08:09 -0000 X-YMail-OSG: AW9X0bsVM1npuTe.rxixXQWcJJQe593Zb8l3DHSjvK6y0wejsCQ_idPAuJdLogT_Kw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4892D277.7000906@rogers.com> Date: Fri, 01 Aug 2008 10:08:07 +0100 From: Tom Taylor User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: slblake@petri-meat.com References: <9860859c24d436354089fc9bbe795921@petri-meat.com> In-Reply-To: <9860859c24d436354089fc9bbe795921@petri-meat.com> Cc: pcn@ietf.org Subject: Re: [PCN] Moving draft-eardley-pcn-marking-behavior-01 to WG draft 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Agreed. slblake@petri-meat.com wrote: > There was strong consensus in the meeting today to move (the next revision > of) draft-eardley-pcn-marking-behavior-01 to a WG draft. This email is to > confirm the decision on the list. Please send comments within the next > week. > > > Regards, > > // Steve > > _______________________________________________ > 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 Aug 1 02:08:42 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10AB23A6B2A; Fri, 1 Aug 2008 02:08: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 068CD3A6AFD for ; Fri, 1 Aug 2008 02:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 IikhR1e2zJUe for ; Fri, 1 Aug 2008 02:08:40 -0700 (PDT) Received: from smtp101.rog.mail.re2.yahoo.com (smtp101.rog.mail.re2.yahoo.com [206.190.36.79]) by core3.amsl.com (Postfix) with SMTP id 0D9223A6AF6 for ; Fri, 1 Aug 2008 02:08:39 -0700 (PDT) Received: (qmail 60097 invoked from network); 1 Aug 2008 09:08:23 -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:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=xDZbhpcEq33zg2OobfHw2EjmxZwo1PRnFSOcm1rMGNG1vsBVR3d9tUPDdXFpI09gCphOpplUFjrvNjP8RzI4HtvzFLz/CA3op3pfTPzaXzVynZFBsU1bmmeTdcdsKUkKJBTkr02mt7HwaOP4AICR1JUT5+d530AIWlRs0sk9aMc= ; Received: from unknown (HELO ?130.129.18.207?) (tom.taylor@rogers.com@130.129.18.207 with plain) by smtp101.rog.mail.re2.yahoo.com with SMTP; 1 Aug 2008 09:08:22 -0000 X-YMail-OSG: UkiL42cVM1nFMK5p7Rx.E8qXm_9SpuhYwZuwcGRLSMq_GjN5N7qic0QGxXALO6wzqw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4892D284.2080402@rogers.com> Date: Fri, 01 Aug 2008 10:08:20 +0100 From: Tom Taylor User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: slblake@petri-meat.com References: <0bc6597b39c96b8acffed272ee7975fc@petri-meat.com> In-Reply-To: <0bc6597b39c96b8acffed272ee7975fc@petri-meat.com> Cc: pcn@ietf.org Subject: Re: [PCN] Moving draft-moncaster-pcn-baseline-encoding-02 to WG draft 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Agreed. slblake@petri-meat.com wrote: > There was strong consensus in the meeting today to move (the next revision > of) draft-moncaster-pcn-baseline-encoding-02 to a WG draft. This email is > to confirm that decision on the list. Please send comments to the list > within the next week. > > > Regards, > > // Steve > > _______________________________________________ > 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 Aug 1 04:06:19 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0442D3A6B33; Fri, 1 Aug 2008 04:06: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 B6AF43A6B32 for ; Fri, 1 Aug 2008 04:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=-0.210, 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 D2HKXp7TE7Jy for ; Fri, 1 Aug 2008 04:06:16 -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 AA9863A67F3 for ; Fri, 1 Aug 2008 04:06:16 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 1E362198DDF; Fri, 1 Aug 2008 12:48:39 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 0F636198DD2; Fri, 1 Aug 2008 12:48:39 +0200 (CEST) Received: from [132.187.12.123] (win3123.informatik.uni-wuerzburg.de [132.187.12.123]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id E5F08A06BA; Fri, 1 Aug 2008 12:48:38 +0200 (CEST) Message-ID: <4892E9B9.2070701@informatik.uni-wuerzburg.de> Date: Fri, 01 Aug 2008 12:47:21 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: slblake@petri-meat.com References: <9860859c24d436354089fc9bbe795921@petri-meat.com> In-Reply-To: <9860859c24d436354089fc9bbe795921@petri-meat.com> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Moving draft-eardley-pcn-marking-behavior-01 to WG draft 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org agree slblake@petri-meat.com wrote: > There was strong consensus in the meeting today to move (the next revision > of) draft-eardley-pcn-marking-behavior-01 to a WG draft. This email is to > confirm the decision on the list. Please send comments within the next > week. > > > Regards, > > // Steve > > _______________________________________________ > 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 Aug 1 04:15:32 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 472953A697F; Fri, 1 Aug 2008 04:15: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 DE4803A6904 for ; Fri, 1 Aug 2008 04:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=-0.191, 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 4mm2F12sZOfe for ; Fri, 1 Aug 2008 04:15: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 1577C3A67B3 for ; Fri, 1 Aug 2008 04:15:30 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 8B8BBA06C1; Fri, 1 Aug 2008 12:48:46 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 7EC4AA06BA; Fri, 1 Aug 2008 12:48:46 +0200 (CEST) Received: from [132.187.12.123] (win3123.informatik.uni-wuerzburg.de [132.187.12.123]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 62140198DD2; Fri, 1 Aug 2008 12:48:46 +0200 (CEST) Message-ID: <4892E9C0.3030606@informatik.uni-wuerzburg.de> Date: Fri, 01 Aug 2008 12:47:28 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: slblake@petri-meat.com References: <0bc6597b39c96b8acffed272ee7975fc@petri-meat.com> In-Reply-To: <0bc6597b39c96b8acffed272ee7975fc@petri-meat.com> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Moving draft-moncaster-pcn-baseline-encoding-02 to WG draft 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org agree slblake@petri-meat.com wrote: > There was strong consensus in the meeting today to move (the next revision > of) draft-moncaster-pcn-baseline-encoding-02 to a WG draft. This email is > to confirm that decision on the list. Please send comments to the list > within the next week. > > > Regards, > > // Steve > > _______________________________________________ > 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 Aug 4 06:10:55 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82A463A68D4; Mon, 4 Aug 2008 06:10: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 34B0F3A6849 for ; Mon, 4 Aug 2008 06:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 6zg97Bhf1MNw for ; Mon, 4 Aug 2008 06:10:53 -0700 (PDT) Received: from zrtps0kn.nortel.com (zrtps0kn.nortel.com [47.140.192.55]) by core3.amsl.com (Postfix) with ESMTP id 24BCE3A68D4 for ; Mon, 4 Aug 2008 06:10:53 -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 m74DBG727283; Mon, 4 Aug 2008 13:11:16 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 4 Aug 2008 09:11:16 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB6465173E5F70@zcarhxm1.corp.nortel.com> In-Reply-To: <9860859c24d436354089fc9bbe795921@petri-meat.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Moving draft-eardley-pcn-marking-behavior-01 to WG draft Thread-Index: AcjzXF2e17h+LyKAQuWJDS9SNFnoVgCT8CWQ References: <9860859c24d436354089fc9bbe795921@petri-meat.com> From: "Jozef Babiarz" To: , Subject: Re: [PCN] Moving draft-eardley-pcn-marking-behavior-01 to WG draft 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 support this draft coming WG draft. 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 slblake@petri-meat.com Sent: July 31, 2008 6:25 PM To: pcn@ietf.org Subject: [PCN] Moving draft-eardley-pcn-marking-behavior-01 to WG draft There was strong consensus in the meeting today to move (the next revision of) draft-eardley-pcn-marking-behavior-01 to a WG draft. This email is to confirm the decision on the list. Please send comments within the next week. Regards, // Steve _______________________________________________ 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 Aug 4 17:23:26 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 563B23A690F; Mon, 4 Aug 2008 17:23: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 BB1303A690F for ; Mon, 4 Aug 2008 17:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1CWOcHHYdpR for ; Mon, 4 Aug 2008 17:23:24 -0700 (PDT) Received: from sg.ntt-at.co.jp (roma.ntt-at.co.jp [202.253.160.19]) by core3.amsl.com (Postfix) with SMTP id B0B243A68B6 for ; Mon, 4 Aug 2008 17:23:23 -0700 (PDT) Received: (qmail 72374 invoked by alias); 5 Aug 2008 00:23:52 -0000 Received: from suez.bb.ntt-at.co.jp (192.168.2.9) by subgate.bb.ntt-at.co.jp with SMTP; 5 Aug 2008 00:23:52 -0000 Received: from pacific.bb.ntt-at.co.jp (suez [127.0.0.1]) by suez.bb.ntt-at.co.jp (8.12.10/8.12.10) with ESMTP id m750NpYl024220; Tue, 5 Aug 2008 09:23:51 +0900 Received: from mercury.tec.ntt-at.co.jp (mercury.tec.ntt-at.co.jp [192.168.22.39]) by pacific.bb.ntt-at.co.jp (8.13.1/cf/pacific) with ESMTP id m750No7m074247; Tue, 5 Aug 2008 09:23:51 +0900 (JST) (envelope-from oratai.phanachet@ntt-at.co.jp) Received: from sawasdee.ntt-at.co.jp (ip21-073.tec.ntt-at.co.jp [192.168.21.73]) by mercury.tec.ntt-at.co.jp (Postfix) with ESMTP id 4127653F61; Tue, 5 Aug 2008 09:23:50 +0900 (JST) Message-Id: <6.2.3.4.2.20080805091706.03e66e10@mail.tec.ntt-at.co.jp> X-Mailer: QUALCOMM Windows Eudora Version 6.2J rev4.2 Date: Tue, 05 Aug 2008 09:23:42 +0900 To: slblake@petri-meat.com From: Oratai Phanachet In-Reply-To: References: Mime-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] Moving draft-eardley-pcn-marking-behavior-01 to WG draft 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org I support. >Subject: [PCN] Moving draft-eardley-pcn-marking-behavior-01 to WG draft > >There was strong consensus in the meeting today to move (the next >revision >of) draft-eardley-pcn-marking-behavior-01 to a WG draft. This email is >to >confirm the decision on the list. Please send comments within the next >week. > > >Regards, > >// Steve > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn > ------------------------------------------- Oratai PHANACHET NTT Advanced Technology Corporation Network Technology Center Email: oratai.phanachet@ntt-at.co.jp ------------------------------------------- _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Aug 5 01:21:37 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 363503A6B9E; Tue, 5 Aug 2008 01:21: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 5E6003A6B91 for ; Tue, 5 Aug 2008 01:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 3Z0g-qhLZYbT for ; Tue, 5 Aug 2008 01:21:35 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 3E6C628C137 for ; Tue, 5 Aug 2008 01:21: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; Tue, 5 Aug 2008 10:22:02 +0200 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, 5 Aug 2008 10:22:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Aug 2008 10:22:01 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C019537AC@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <9860859c24d436354089fc9bbe795921@petri-meat.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Moving draft-eardley-pcn-marking-behavior-01 to WG draft thread-index: AcjzXGjyYxgZKVM0Qcirt2HxP48EVQDd88Qw References: <9860859c24d436354089fc9bbe795921@petri-meat.com> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 05 Aug 2008 08:22:02.0539 (UTC) FILETIME=[56892FB0:01C8F6D4] Cc: pcn@ietf.org Subject: Re: [PCN] Moving draft-eardley-pcn-marking-behavior-01 to WG draft 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 support moving this draft to WG status Regards, Ruediger -----Urspr=FCngliche Nachricht----- Von: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] Im Auftrag von slbl= ake@petri-meat.com Gesendet: Freitag, 1. August 2008 00:25 An: pcn@ietf.org Betreff: [PCN] Moving draft-eardley-pcn-marking-behavior-01 to WG draft There was strong consensus in the meeting today to move (the next revision of) draft-eardley-pcn-marking-behavior-01 to a WG draft. This email is to confirm the decision on the list. Please send comments within the next week. Regards, // Steve _______________________________________________ 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 Aug 5 01:22:13 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64ADC28C19B; Tue, 5 Aug 2008 01:22: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 BC0F328C137 for ; Tue, 5 Aug 2008 01:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 Z+p-TOQgPIGf for ; Tue, 5 Aug 2008 01:22:11 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id A02DB3A6B91 for ; Tue, 5 Aug 2008 01:22:10 -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, 5 Aug 2008 10:22:39 +0200 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, 5 Aug 2008 10:22:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 5 Aug 2008 10:22:37 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C019537AE@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <0bc6597b39c96b8acffed272ee7975fc@petri-meat.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Moving draft-moncaster-pcn-baseline-encoding-02 to WG draft thread-index: AcjzXW9P2wZeLB7xTIKKZX1YiHPEDwDduz7A References: <0bc6597b39c96b8acffed272ee7975fc@petri-meat.com> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 05 Aug 2008 08:22:38.0692 (UTC) FILETIME=[6C15B240:01C8F6D4] Cc: pcn@ietf.org Subject: Re: [PCN] Moving draft-moncaster-pcn-baseline-encoding-02 to WG draft 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 support moving this draft to WG status Regards, Ruediger = -----Urspr=FCngliche Nachricht----- Von: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] Im Auftrag von slbl= ake@petri-meat.com Gesendet: Freitag, 1. August 2008 00:33 An: pcn@ietf.org Betreff: [PCN] Moving draft-moncaster-pcn-baseline-encoding-02 to WG draft There was strong consensus in the meeting today to move (the next revision of) draft-moncaster-pcn-baseline-encoding-02 to a WG draft. This email is to confirm that decision on the list. Please send comments to the list within the next week. Regards, // Steve _______________________________________________ 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 Aug 5 05:38:37 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ACA428C2AC; Tue, 5 Aug 2008 05:38: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 DCA3F28C2AC for ; Tue, 5 Aug 2008 05:38:35 -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 oydVsDcMJfzW for ; Tue, 5 Aug 2008 05:38:35 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 013C928C2A8 for ; Tue, 5 Aug 2008 05:38:34 -0700 (PDT) Received: from cpe-071-077-051-078.nc.res.rr.com ([71.77.51.78]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1KQLob-00074m-G3 for pcn@ietf.org; Tue, 05 Aug 2008 08:39:01 -0400 From: Steven Blake To: pcn Content-Type: multipart/mixed; boundary="=-2riVlrrWQaw+1kcBwGqn" Date: Tue, 05 Aug 2008 08:39:02 -0400 Message-Id: <1217939942.10059.6.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Subject: [PCN] [Fwd: Please ask your WG...] 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 --=-2riVlrrWQaw+1kcBwGqn Content-Type: text/plain Content-Transfer-Encoding: 7bit Please see the attachment. I volunteered and served on the NomCom last year. It was a lot of work, but I came out of it with a much better understanding of how the IETF operates and of the challenges faced by the IETF/IAB leadership. Regards, // Steve --=-2riVlrrWQaw+1kcBwGqn Content-Disposition: inline Content-Description: Forwarded message - Please ask your WG... Content-Type: message/rfc822 Return-path: Envelope-to: slblake@petri-meat.com Delivery-date: Mon, 04 Aug 2008 12:07:51 -0400 Received: from mail.ietf.org ([64.170.98.32]) by elom.tchmachines.com with esmtp (Exim 4.69) (envelope-from ) id 1KQ2b9-0003kY-Ac for slblake@petri-meat.com; Mon, 04 Aug 2008 12:07:51 -0400 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B2D63A686D; Mon, 4 Aug 2008 09:02:39 -0700 (PDT) X-Original-To: wgchairs@ietf.org Delivered-To: wgchairs@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id AA9033A68BA; Sun, 3 Aug 2008 07:43:22 -0700 (PDT) From: NomCom Chair To: Working Group Chairs Subject: Please ask your WG... Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20080803144322.AA9033A68BA@core3.amsl.com> Date: Sun, 3 Aug 2008 07:43:22 -0700 (PDT) X-Mailman-Approved-At: Mon, 04 Aug 2008 09:02:36 -0700 X-BeenThere: wgchairs@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Working Group Chairs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: wgchairs-bounces@ietf.org Errors-To: wgchairs-bounces@ietf.org Content-Transfer-Encoding: 7bit To volunteer for the nomcom. The nomcom process is (in my opinion) better served by a large pool of volunteers drawn from a wide spectrum of IETF attendees. As such, please ask on your individual mailing lists for folks to volunteer. Obviously, the exact method for doing so is up to you. The most recent call for volunteers can be reference here: https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1617 Whether you copy that message, or reference is probably up to you and the habits of your working group mailing list. If you want to reference or copy the status message I sent out, that can be found at: https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1618 Thank you, Joel M. Halpern Nomcom Chair jmh@joelahlpern.com nomcom-chair@ietf.org --=-2riVlrrWQaw+1kcBwGqn 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 --=-2riVlrrWQaw+1kcBwGqn-- From pcn-bounces@ietf.org Tue Aug 5 05:40:02 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFA3028C2A5; Tue, 5 Aug 2008 05:40: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 8211828C251 for ; Tue, 5 Aug 2008 05:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.849 X-Spam-Level: X-Spam-Status: No, score=-0.849 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, J_CHICKENPOX_16=0.6, J_CHICKENPOX_22=0.6, 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 fkMZOP8pABWM for ; Tue, 5 Aug 2008 05:39:58 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id E5B1028C25C for ; Tue, 5 Aug 2008 05:39:39 -0700 (PDT) Received: from cpe-071-077-051-078.nc.res.rr.com ([71.77.51.78]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1KQLpe-00079r-1m for pcn@ietf.org; Tue, 05 Aug 2008 08:40:06 -0400 From: Steven Blake To: pcn Content-Type: multipart/mixed; boundary="=-5TkbUAot5kXbqDRhcxq9" Date: Tue, 05 Aug 2008 08:40:02 -0400 Message-Id: <1217940002.10059.8.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Subject: [PCN] **DRAFT** PCN IETF72 Meeting Minutes 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 --=-5TkbUAot5kXbqDRhcxq9 Content-Type: text/plain Content-Transfer-Encoding: 7bit Please review the attached draft meeting minutes from Dublin and send comments/corrections to the list within the next week. Thanks to Peter McCann and Tom Taylor for taking such detailed minutes! Regards, // Steve --=-5TkbUAot5kXbqDRhcxq9 Content-Disposition: attachment; filename=pcn-ietf72-minutes.txt.draft Content-Type: text/plain; name=pcn-ietf72-minutes.txt.draft; charset=UTF-8 Content-Transfer-Encoding: 7bit Congestion and Pre-Congestion Notification WG (pcn) IETF72 **DRAFT** Meeting Minutes CHAIRs: Scott Bradner Steven Blake Notetakers: Peter McCann Tom Taylor THURSDAY, July 31, 2008 0900-1130 Morning Session I Rathcoole =========================== ------------------------------------------------------------------------------ o Administrivia chairs 10 min - Blue sheets - Scribe - Agenda bash - Milestones status Slides: http://www3.ietf.org/proceedings/08jul/slides/pcn-0.pdf Chairs reviewed agenda -- no comment Chairs reviewed milestones -- PCN WG is behind schedule on our milestones Chairs reviewed consensus calls since IETF 71 (Philadelphia) meeting. There were six questions asked: 1. Should WG produce standards-track scheme with only 2 encoding states? YES 2. Should the WG produce experimental-track schemes that might require another encoding state YES 3. Does the wg have enough info to move forward YES 4. Should routers support the excess-rate marking scheme described by Anna Charny? YES 5. Should routers support the threshhold marking scheme described in the Eardley draft? YES 6. Should the wg consider modifying the interior router excess-rate marking scheme? No consensus. No one made an argument for extending that behavior. Chairs asked question 6 again. There was no support for revisiting this issue. ------------------------------------------------------------------------------ o Discuss ITU-T liaison statement chairs 15 min PCN working group received a liaison statement ITU-T that we need to respond to by 2008-09-01. ITU-T LIaison on Q.PCNApp URL: https://datatracker.ietf.org/liaison/461/ Tom Taylor presented summary slides of the liaison statement. These slides are not a part of the official liaison statement from ITU-T, and are only provided for informative purposes by Tom, who is a participant in the associated ITU-T study group. Slides: http://www3.ietf.org/proceedings/08jul/slides/pcn-8.pdf The chairs asked for comments from the room. Bob Briscoe: haven't read it, what are we asked to comment about? Steve Blake: comment on any aspect Scott Bradner: document included in Liaison statement, see if it jives In some places, they say wait for PCN. If they are off on a tangent we need to say so. Chairs ask to start a discussion on the mailing list within the next two weeks, so that the working group can formulate a response. ------------------------------------------------------------------------------ o draft-ietf-pcn-architecture-04 Eardley 25 min Philip Eardley presented slides on the PCN architecture draft. Slides: http://www3.ietf.org/proceedings/08jul/slides/pcn-7.pdf No technical open issues Plan: do a revision ASAP, once the submission tool reopens to clear up a few nits and clarifications that people have raised. Within next couple of weeks. Proposal is that it is ready for WGLC. Changes: Reflect consensus decisions made at Philadelphia or on the mailing list shortly after. Put text re: baseline encoding and experimental extensions Introduction improved Section about backwards compatibility: ECN requirements, doesn't have default ECN behavior (RFC4774) So, Steve, is it ready for last call? Lars Eggert: change, text on probing got moved to appendix. This is one of my all-time favorites. Appendix B on probing. Should it be listed in Appendix A? right now it lists issues for/against. Let's say probing might be something we would do in the future. We don't have a work item to ever do probing right now. Scott Bradner: add text that it might be a future work item. Marcus : optional future TBD of the architecture Jozef Babiarz: can probing be a method for on-path signaling; need to clarify what we mean by probing. Steve Blake: wg has already decided that we are not going to work on probing. Anna Charny: if we are to vote for going to WGLC, is it not better to wait for encoding/marking discussion today? Or do you think no changes will happen? Steve Blake: we will not make decision today, if draft is almost ready (there will be revisions within the next few weeks). Lars Eggert: maybe question should be "assuming no drastic changes..." Steven: Assuming no drastic changes, how many people agree this draft is almost ready for WGLC? 8-9 hands almost ready, 0 against. Chairs strongly encourage Phil to get revision out ASAP. ------------------------------------------------------------------------------ o draft-eardley-pcn-marking-behavior-01 Eardley 25 min Philip Eardley presented slides on the marking behavior draft. Slides: http://www3.ietf.org/proceedings/08jul/slides/pcn-7.pdf Summary: request that we make this a WG doc rather than individual Steven Blake: How many have read this draft? (lots). Would like to hold off on question until other proposals Jozef Babiarz: this is the only one on marking, others are encoding, we could vote on this now. Ruediger Geib: 2 marking behaviors, excess & threshhold. It does not tell you codepoints, it just describes 2 behaviors. It is ready. Steve Blake: Ok, finish summary, then ask question. Philip Eardley: Basics of doc are clear. Changes from 00 to 01: reflect encoding is going to have a baseline + experimental codepoints. Some changes to traffic conditioning, not very good yet Changes TBD: 1. Traffic conditioning - simplify 2. Purely about PHB, right now it has stuff about edge behavior. Traffic conditioning on interior nodes: simplify section: say things about PCN traffic & non-PCN traffic Per-hop policing (metering/dropping) is not needed. Drop packets if queue overflows, flow termination mechanism to reduce the traffic on PCN interior node. Non-PCN traffic: shares same capacity, might be high priority or same Diffserv priority, might be admission controlled in a non-PCN fashion, might not be admission controlled. "Goal of PCN is to keep PCN traffic within some bandwidth on the link. If you are mixing other traffic, you need to control it somehow outside the scope of PCN" Appendix discusses 2 cases PCN & non-PCN share queue: MUST police non-PCN PCN & non-PCN separate queues: run a scheduler If anyone has any more comments, make them now or on the list? No comments... PHB: Focus on PCN interior nodes PHB. Take out all stuff that's about the whole domain behavior. Goes into a new document that would cover things like traffic conditioning for a whole PCN domain. Marking bahavior MUSTs? Threshhold-marking, excess-traffic marking, have you got 2 or 3 encodings? Should they both be MUSTs to do? silly Should they be MUSTS to implement? Yes, migration easier Should they be a conditional MUST? implementation easier Steve Blake: speaking as chair, interpretation of consensus for MUST implement, means router vendor is compelled to provide both but operator need not turn both on Philip Eardley: so number 2? Steve, group: yes. Jozef Babiarz: why should IETF mandate something that customer does not want? Scott Bradner: IETF has a long history of making mandatory to implement where a fallback for interoperability is required. Want to avoid not having a common mechanism Bob Briscoe: stuck my hand up last time for must implement both. It has been explained that there are situations where you're never going to want both (ex/ enterprise deployments). Rather than conditional MUST, maybe say "if you never want to do it"? Ruediger Geib: IETF avoids situation where ask for PCN RFP: both vendors say they support it, but on closer inspection Lars Eggert: if we want to go with one mandatory, have a hard time choosing Jozef Babiarz: can we split document? Lars Eggert: then we would be doing several documents not just one Jozef Babiarz: Diffserv PHB is an example where we have multiple independent documents Lars Eggert: not codepoints, router behavior. Instantiate different flavors of PCN; if you have to buy new equipment that would be bad for PCN in the marketplace Scott Bradner: one question: how expensive is it to put in both? Jozef Babiarz: not that expensive, requires token bucket Scott Bradner: arguing over a few gates on an ASIC Bob Briscoe: compromise where we say both must be implemented but not both at the same time Anna Charny: only reason where you might want to change consensus is if people thought mandating both would delay deployment. If there is one that is easy, other is not so easy, there might be a tradeoff there. Steve Blake: if we want to revisit this, let's do it on the list. My interpretation of the consensus was that both mandatory. You can't force a vendor to implement one or both of these functions, simply a question of being honest about RFC compliance Scott Bradner: would delay PCN adoption, would delay it if you couldn't predict that one PCN product would interwork with another. Bob Briscoe: configure either one turned on, must support both, maybe that's ok but don't see a need to revisit that. Consensus call: ready for WG document? 12-15 yes, 0 no. Scott Bradner: next time you submit, submit it as a WG document. ------------------------------------------------------------------------------ o draft-moncaster-pcn-baseline-encoding-02 Moncaster 10 min Toby Moncaster presented slides on a proposed PCN baseline encoding. Slides: http://www3.ietf.org/proceedings/08jul/slides/pcn-1.pdf Based on consensus call that there should be one standard baseline to allow 2 encoding states. Sufficient functionality to make PCN work, allow experiments, minimize use of DSCPs, work within tunneling constraints, allow e2e ECN if possible (would be nice) Current proposal: A DSCP 1: re-use voice admit codepoint, if ready in time ECN codepoints: 00: not PCN 10: not marked 01: not marked 11: marked Marking state: defined within each domain by the operator No distinguish between threshold and excess Intended change for 03: Wasteful to use both codepoints 01 and 10 Change 01 to be Experimental/Local Use Marked state still interpreted locally, ECN still needs to be tunneled Next steps: Revised by end of august. Would like this to become a WG draft. Steve Blake: a couple more drafts on encoding. We can ask, but let's make it non-binding until we hear other proposals. Let's hold off on asking. In conclusion, this baseline draft allows all the proposals, if any experiment proved successful, would just need to update (not replace) this draft. ------------------------------------------------------------------------------ o draft-moncaster-pcn-3-state-encoding-00 Moncaster 10 min Toby Moncaster presented slides on a proposed 3 state encoding. Slides: http://www3.ietf.org/proceedings/08jul/slides/pcn-2.pdf Basically what was presented at last meeting in Philly Requirements: 3 PCN states Provide support for CL-style admission and termination Minimise use of standards-track DSCPs Optional extension to allow e2e ECN support (must reveal PCN markings as ECN markings to the endpoint, assume that endpoint will do something sensible like reducing vocoder rate). Bob Briscoe: ECN/PCN only one mark will be revealed Toby Moncaster: right, that mark may have been generated by PCN or ECN router Basic proposal 2 DSCPs; DSCP1: likely voice-admit Used effectively same as baseline, now making mark 11 as excess marking Other DSCP2: use 11 for threshold marking Which way around should they be? ECN should be tunneled Extended Proposal Use un-used codepoints to tunnel existing ECN marks through region Use 10 01 on DSCP1 as not marked, use 10 ECT(0) and 01 ECT(1) on DSCP2 Then both ECN and PCN marks revealed to the endpoint. Negotiate that is outside scope of this document. Next Steps Produce as experimental extension Fairly minor modifications to current draft ECN part will be optional Work needed on signalling to negotiate ECN Delay pushing forward until Baseline encoding gets through WGLC Lars Egger: clarification of what would be delayed. Toby Moncaster: 3 state encoding scheme ------------------------------------------------------------------------------ o Multiple PCN Experiments (no draft) Moncaster 10 min Slides: http://www3.ietf.org/proceedings/08jul/slides/pcn-3.pdf Why is baseline so good? Can support a huge number of ways to modify PCN, packet-specific dual-marking 3 state encoding 3 state encoding with ECN Tunnel-less CL: if an ISP knows for certain there are no tunnels inside PCN domain, or if equipment has been done ala Bob's way, then you can use the extra codepoints to use for markings LC-PCN Proposal: show all schemes on one slide Basic message: all 5 options preserve semantics of baseline Lars Eggert: are all other ones aiming for experimental? Toby Moncaster: No, just mentioning that baseline doesn't preclude Lars Eggert: documents that describe everything below the first line, none of them claim to go to PS? Toby Moncaster: Right. Steve Blake: standards track with 2 encoding states, experimental with 3. Toby Moncaster(?): Michael Menth has been pushing that PSDM be the base, but that would go against consensus Steve Blake: baseline 11 codepoint indicates packet is marked, doesn't specify excess vs. threshold marked. That's implied by domain operator. Toby Moncaster: Is now a good time to ask for baseline to become WG document? Steve Blake: let's listen to Jozef, then call question. ------------------------------------------------------------------------------ o draft-menth-pcn-psdm-encoding-00.txt Babiarz 10 min Jozef Babiarz presented slides on PCN Encoding for Packet-Specific Dual Marking (PDSM) Slides: http://www3.ietf.org/proceedings/08jul/slides/pcn-4.pdf Comparison between this and baseline Similarity: Voice-admit DSCP for PCN traffic One DSCP Use ECN for diff PCN and non-PCN PCN encoding Difference 2 Motivation Lot of scenarios in enterprise, number of aggregates not as high as in carrier backbones, threshold marking has better performance. Want mechanism where we can do admission control, on-path signaling. In 3 SM drafts e.g. RSVP. Provide background on what is meant by probing. Also scenarios where flow termination may be needed. Idea Use exhaustive marking in the network. All PCN traffic metered by threshold marking and excess rate marking Probe packets are subject to exhaustive marking only PCN data packets are subject to excess marking only ECN bits tell routers which packets need to be marked and how ECN bits re-marked from 01 or 10 to 11 PCN Codepoints: redefinition of ECN field 00: not-PCN voice admit traffic not subject to PCN control 10: not excess-marked 10: not exhaustive-marked 11: marked Applicability Supports AC, FT, AC&FT (SM), Probe-based Limitations & Options End-to-end ECN needs to be tunneled Does not support CL style AC & FT when both are used Migrate from single marking to both CL-style AC & FT with a second DSCP Steve Blake: Toby's description of PSDM is not correct? Jozef Babiarz: no, evolution using 2 DSCP encoding is different from what was described in 3 state encoding Tom Taylor: with 2 DSCPs, no more information than with 1 DSCP Could run both schemes in same network Tom Taylor divide data packets into 2 treatments. Steve Blake: How decide which set of traffic should be threshold marked, certain aggregates at ingress (e.g., voice) should be marked somehow, other flows (e.g. video) would be marked the other way. Toby Moncaster: simple evolution is not in draft as present. Not convinced allows CL type behavior. Pre-empted that certain packets can only be threshold marked or excess rate marked. CL requires that you be able to over-write one as another. Then you might end up with 3-state marking. Jozef Babiarz: need to write it up in detail Toby Moncaster: then you don't need extra signaling, DSCP does that for you Bob Briscoe: Of all schemes that Toby put up, could we have some procedural rule that experiments need to describe how to do incremental deployment before can be adopted as WG item. Steve Blake: good idea. mic(?): make baseline compliant, switch DSCP Jozef Babiarz: can do that, this is just another way of migrating. Requires only one DSCP (possibly Voice-Admit) Extension of "baseline encoding" Support two concurrent marking schemes Can we adopt as WG item for experimental encoding? Steve Balke: have 2 questions to ask, that will be one. Q1: Lars, Jozef: e2e ECN should be supported, correct? Nothing in that draft that precludes use of ECN by that behavior aggregate. Lars Eggert: believe you're correct Steve Blake: tunnel scheme for passing ECN marks is to use local-use DSCP, voice-admit at ingress with congestion experienced marked, flip the DSCP carried across network, flip it back on egress. Completely possible to handle ECN with local DSCP? Enough local use codepoints to map them one-to-one? Bob Briscoe: world according to Fred Baker & TSV Area, within access may be many DSCPs, different queues & PHBs. In core they all go together, on egress they all go apart again. If you tried to use diff codepoints would need to preserve this would require too many. Jozef Babiarz: changing codepoints on boundaries, need to change them back on egress. Most vendors/equip providers don't want to do that because it places requirements on vendors Scott Bradner: note that there is no e2e guarantee on DSCP Steve Blake: if we want to re-use voice admit for PCN, or use local use DSCP is kind of arbitrary. Jozef Babiarz: ask TSVWG to specify that voice-admit DSCP does not have default ECN semantics Lars Eggert: don't think it's possible. Can't special-case. Dave Larson working on EF Admit -- ECN desirable Jozef Babiarz: in RFC 3774, that's one method suggested. Codepoint that does not have default ECN semantics applied to it. We can redefine it for PCN. Bob Briscoe: could define diff marking behavior for diff PHB, that's different from saying that there's no behavior Jozef Babiarz: codepoint 00, drop the packet Bob Briscoe: is that better? Jozef Babiarz: implementer, ECN treatment is per 3168. Now PCN comes along and says "now do this". Conflict 2 behaviors apply to one codepoint. Bob Briscoe: for all routers already out there, they can be configured to drop or ?. Default for ECN, RED & Marking, we can configure it to drop but maybe we want to mark rather than drop. mic2(?): useful for emergency, national security deployments ------------------------------------------------------------------------------ o draft-menth-pcn-e2e-encoding-00.txt Babiarz 10 min Jozef Babiarz presented slides on End-to-End Extension for PCN Encoding Slides: http://www3.ietf.org/proceedings/08jul/slides/pcn-5.pdf Not part of current charter. Issue: WG define DSCP that can be used for PCN, inside domain or e2e Bob Briscoe: baseline doesn't propose ECN for voice-admit DSCP. It proposes a DSCP of which voice-admit can be one. Motivation for e2e PCN QoS needed e2e, maybe network edge to network edge Need to look at how can do PCN in multiple domains as well as in the future. ECN semantics (RFC 3168) do NOT apply to voice-admit DSCP RFC 4774 defines approach for alternate ECN semantics Request Voice-admit be one of these codepoints Ruediger Geib: what about relying on endpoints to set DSCPs? Jozef Babiarz: In a public network correct, but there are a lot of enterprise networks with devices generally trusted EFadmit draft defines a DSCP value, also describes a PHB and traffic conditioning behaviors. If PCN were to ask for DSCP we would have to do the same. Bob Briscoe: nearly a null PHB. Per-domain behavior. When same PHB being used with a third PHB that is not admission controlled Jozef Babiarz: codepoint has also e2e admission control, EF PHB Bob Briscoe: PCN/ECN marking behavior: PHB is scheduling behavior, then marking behavior is something else. "Marking part" of PHB? We can define that. Steve Blake: do we know which PHB to use for EFadmit? Bob Briscoe: architecture says EF PHB Steve Blake: that is default but not the only one. Q: Should the WG ask for a DSCP to be assigned for PCN? Voice-admit is being defined in another document. Jozef Babiarz: if we want to use voice-admit, we need to speak up now. Otherwise, we will need another DSCP. Lars Eggert: if you want to use voice-admit would be good to have presentation to double-check with TSVWG to make sure our use is ok. Reason for re-use is to reduce DSCP consumption. Encoding schemes attempt to minimize DSCP use. Philip Eardley: Jozef Babiarz: inside a domain, we should have DSCP where RFC 3168 does not apply. Will make interop easier and simpler. Jozef Babiarz: voice-admit ECN semantics 3168, why can't we use EF? Because ECN semantics is per RFC 3168. If we don't we should be able to use any DSCP codepoint, but we can't. Need a different semantics for DSCP Ruediger Geib: use or not to use voice-admit DSCP. Doc stating that should describe from that decision how to treat non-PCN traffic. Measurement based admission control - if use of voice admit would require me to use any other scheme for admission control I'm not interested. Bob Briscoe: couldn't support "at a later time". Jozef Babiarz: suggesting is that we don't stop or delay other draft. In IANA considerations, make statements that 3168 does not apply to this DSCP. In future, another document will define PHB Bob Briscoe: objecting to. Hold packet with TTL of 4 years. Scott Bradner: might get re-transmission Bob Briscoe: have to say drop or 3168 (only PHBs we should have). Can make that choice now. Can't specify another marking behavior because must work for legacy routers. Jozef Babiarz: we are asking for new routers Bob Briscoe: there are routers with EF support, we should not ask for anything new. Lars Eggert: PCN WG can't stick something in the IANA considerations of tsvwg. Very close to being published, almost IESG approved. It is pretty late, need to be quick. Fred Baker will kill you. Doc has been around a long time. Light at the end of the tunnel is near. Jozef Babiarz: we're not all in agreement that we need ECN semantics. Steve Blake: e2e PCN is out of scope Do we need one DSCP codepoint for PCN mechanisms within a diffserv domain? Should it be voice-admit DSCP? Then would need to get it amended post- publication. Can write a 2nd RFC which says to use semantics for this DSCP Bob Briscoe: I thought that's what the marking draft says. Steve Blake: if WG agrees that we need one DSCP codepoint, if we want to use voice admit, write a new document. Bob Briscoe: don't want to agree to one standard codepoint. Steve Blake: Does PCN need only one behavior aggregate in a network? How many people think we could live with one behavior aggregate that gets PCN treatment in a diffserve domain? More than one? Not unanimous, seems like a weak consensus for one. Bob Briscoe: Do we need a diffserv tutorial. Q. Does PCN need more than one queue? One person responds with yes. Lars Eggert: who understands problem we are facing here? Philip Eardley: but do we have the same understanding? Lars Eggert: diffserv tutorial might not be a bad idea. Can make an informed decision. Seems pretty central to what PCN is doing. Small number of people signaling they understand Anna Charny: one aggregate, one queue: different DSCPs can use the same queue. Does it mean that different DSCPs exhibit one behavior? Jozef Babiarz: when you aggregate multiple DSCPs to one queue they get the same PHB. Steve Blake: Behavior aggregate is 1-1 with DSCP values. Different traffic conditioning behaviors but a single scheduling behavior. Bob Briscoe: different e2e behavior, but same in one domain Ruediger Geib: AF 3 codepoints but one scheduling behavior. If you treat it differently in different domains you break that. David Greyson: voice is one application of voice-admit: 2 queues or 2 policers in a single priority queue. Also describes real-time video, would be in more than one queue. Also admission controlled. Can do this for more than one queue. Right direction to apply... asking for another codepoint, now really serious. Have worked with Fred to get it right. PCN on more than one PHB, scheduling Bob Briscoe: Video and audio may have different queues in the access, idea is to put them in same queue in the core. Steve Blake: if we want a standardized DSCP do we want more than one? If only one, would force traffic into one queue. We will craft some questions and test consensus on the list. ------------------------------------------------------------------------------ o Experiment with baseline encoding supporting admission Geib 5 min control and termination (no draft) Ruediger Geib presented slides on an alternative baseline encoding Slides: http://www3.ietf.org/proceedings/08jul/slides/pcn-9.pdf Could use baseline encoding, just 2 states, apply marking behavior to indicate two different states of PCN-threshold rate, all traffic marked. PCN-Excess rate, continue to mark most of the traffic, let pass excess traffic un-marked. Allos you to have traffic admission controlled marked, then apply PSDM mechanism of mark Pro/con Benefits: admission control with PSDM, does not require any measurements Termination of admitted PCN traffic based on measured PCN excess rates in egress nodes. Don't need any feedback. Just need one codepoint. Makes MPLS friendly. Drawbacks: Admission control doesn't work properly when above the excess Egress node measure a traffic pattern similar to PCN excess once traffic crosses the PCN thresh rate for short periods only Behavior in the presence of multiple pre-congested PCN nodes is less optimal Anna Charny: when you do submit the draft, explain why it doesn't work. Ruediger Geib: set up an experiment. Steve Blake: 2 questions:/ Q1: How many people think we should adopt draft-eardley-pcn-marking-behavior-01 as WG document? 12 yes, 0 no. Q2: How many people think we should adopt draft-menth-pcn-psdm-encoding-00 as a WG document intended for experimental track? 4 yes, 0 no. Not consensus. We will confirm it on the list. Philip Eardly: baseline make a bit more progress before having one or more of the experimental drafts made WG documents. Bob Briscoe: is there any harm in making things WG docs that don't eventually become RFCS? Scott Bradner: as long as it's in charter. If it's not in charter or not making a contribution then it shouldn't be. Bob Briscoe: encoding extension that Toby describes could be a WG document. Jozef Babiarz: is the consensus that we wait, before introducing alternate or experimental encodings? Steve Blake: Should experimental-track drafts become WG documents? 6 yes, 2 suggest waiting until the standards track documents progress ------------------------------------------------------------------------------ o draft-briscoe-tsvwg-ecn-tunnel-01 Briscoe 10 min Bob Briscoe presented slides on Layered Encapsulation of Congestion Notification Slides: http://www3.ietf.org/proceedings/08jul/slides/pcn-6.pdf Should be a WG item in the TSVWG, trying to get support. original authors of 3168 support this, there was support about a year ago but was asked to wait until PCN got a bit further. Background on problems we are having with encoding/tunneling. Update to RFC3168: Proposed change: remove one type of behavior that is unneceessary Limited functionality vs. Full Functionality NG IPSec, RFC 4301: Just copy inner header to outer header Copy creates covert channel, but security area doesn't care. This draft removes full functionality column from table. Excess rate markings won't work well with multiple bottlenecks. Over-terminate flows. Steve Blake: on egress of tunnel, behavior is? In an appendix: relationship between ECN and in-band admission control, tunneling For the egress, behavior doesn't change much, just a clarification on one invalid transition. Can't use some bits in outer header for PCN, they will be thrown away. Jozef Babiarz: switching ECT(1) & ECT(0) will it break e2e nonce? Bob Briscoe: no, it is currently broken and this fixes it. Draft says make everything like IPsec, changing the behavior of an IPSec node. IPSec currently does it the other way around. Jozef Babiarz: IPsec doesn't flip the ECT bits, how does that break the nonce? Bob Briscoe: doesn't break e2e nonce, means that a router in the tunnel removes a congestion-experienced that another router put on, can't detech routers that have removed congestion-experiences, which is one of the problems Lars Eggert: update RFC 4301? Only way to affect IPsec is to update 4301. Bob Briscoe: at the moment the draft doesn't update 4301, this is just in an appendix, just a discussion not normative or anything like that. What do you think my chances are to allow this update? Lars Eggert: chance of asking is pretty high. ------------------------------------------------------------------------------ o draft-westberg-pcn-load-control-04.txt Mekkes 15 min Hein Mekkes presented slides on Load Control PCN Slides: http://www3.ietf.org/proceedings/08jul/slides/pcn-10.pdf Main updates from previous draft -03: Supports both trunk and hose model Sliding window is moved to the egress When PCN_Affected_Marking is used, then flow termination is triggered at the egress Calculation of configured termination rate has changed Used to decide how much bandwidth has to be terminated. If PCN_Marked rate * N > link bandwith, ctre = (U-1)*total_load If PCN_Marked_rate Description of flow termination experiments included. Admission control experiments not performed since functionality is identical to Single Marking admission control functionality. Trunk (IE-aggregate) and HOST-model used In draft no results shown, but they are shown in this presentation Experiments: simulation. 2 different topologies. One with a single bottleneck, other with 5 bottlenecks (parking lot topology) Intended to do CBR and VBR, but unable to do VBR experiments Metrics: Over-termination Reaction time Duration of time that a bottleneck node remains in flow termination state Simulation parameters Description of experiments Topologies, number of flows, Over-termination percentages SingleMarking LCPCN-trunk LCPCN-host Handling times vs #ingresses Graph Experiment 2 parking lot topology Over-termination percentages Philip Eardley: previous slide, is there a significant difference between these? What's the range over which they covered? How big is a single point? What is confidence interval? Hein Mekkes: only one point. Reaction time is about 200 ms for each congested link. Conclusions and next steps Leave open the option to use random dropping of marked and unmarked packets in interior nodes Leave open the option to use PCN_Affected_Marking encoding since it can solve the ECMP problem and provide an efficient solution for the HOSE model. Leave open the option using the constant N such that the marked excess rate can represent also high levels of measured excess rate Philip Eardley: 1st and 3rd contradict consensus in Philadelphia Hein Mekkes: didn't know that, wasn't there. Philip Eardley: marking draft presented says excess traffic meter function SHOULD preferential dropping of packets which are excess traffic marked. Random dropping contradicts that should statement. On the effective marking: covered by experimental encoding as presented by Toby Third one contradicts consensus we reached in Philadelphia. Steve Blake: any support for revisiting the question? No support given Steve Blake: We will stick with previous consensus. Meeting adjourned. --=-5TkbUAot5kXbqDRhcxq9 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 --=-5TkbUAot5kXbqDRhcxq9-- From pcn-bounces@ietf.org Tue Aug 5 18:51:51 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB06728C0F3; Tue, 5 Aug 2008 18:51: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 9E58828C0ED for ; Tue, 5 Aug 2008 18:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.09 X-Spam-Level: X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHandQlrjfen for ; Tue, 5 Aug 2008 18:51:50 -0700 (PDT) Received: from sg.ntt-at.co.jp (roma.ntt-at.co.jp [202.253.160.19]) by core3.amsl.com (Postfix) with SMTP id A7D3D28C0E9 for ; Tue, 5 Aug 2008 18:51:49 -0700 (PDT) Received: (qmail 12544 invoked by alias); 6 Aug 2008 01:52:21 -0000 Received: from suez.bb.ntt-at.co.jp (192.168.2.9) by subgate.bb.ntt-at.co.jp with SMTP; 6 Aug 2008 01:52:21 -0000 Received: from pacific.bb.ntt-at.co.jp (suez [127.0.0.1]) by suez.bb.ntt-at.co.jp (8.12.10/8.12.10) with ESMTP id m761qJYl019870; Wed, 6 Aug 2008 10:52:20 +0900 Received: from mercury.tec.ntt-at.co.jp (mercury.tec.ntt-at.co.jp [192.168.22.39]) by pacific.bb.ntt-at.co.jp (8.13.1/cf/pacific) with ESMTP id m761qJPZ025441; Wed, 6 Aug 2008 10:52:19 +0900 (JST) (envelope-from oratai.phanachet@ntt-at.co.jp) Received: from sawasdee.ntt-at.co.jp (ip21-073.tec.ntt-at.co.jp [192.168.21.73]) by mercury.tec.ntt-at.co.jp (Postfix) with ESMTP id B3F3B53F61; Wed, 6 Aug 2008 10:52:19 +0900 (JST) Message-Id: <6.2.3.4.2.20080806104921.02e8a220@mail.tec.ntt-at.co.jp> X-Mailer: QUALCOMM Windows Eudora Version 6.2J rev4.2 Date: Wed, 06 Aug 2008 10:52:13 +0900 To: slblake@petri-meat.com From: Oratai Phanachet In-Reply-To: References: Mime-Version: 1.0 Cc: pcn@ietf.org Subject: Re: [PCN] Moving draft-moncaster-pcn-baseline-encoding-02 to WG draft 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org I support to move this draft to WG draft. Regards, Oratai Phanachet >Date: Thu, 31 Jul 2008 18:33:03 -0400 >From: >Subject: [PCN] Moving draft-moncaster-pcn-baseline-encoding-02 to WG > draft >To: pcn@ietf.org >Message-ID: <0bc6597b39c96b8acffed272ee7975fc@petri-meat.com> >Content-Type: text/plain; charset="UTF-8" > >There was strong consensus in the meeting today to move (the next revision >of) draft-moncaster-pcn-baseline-encoding-02 to a WG draft. This email is >to confirm that decision on the list. Please send comments to the list >within the next week. > > >Regards, > >// Steve > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Aug 6 07:44:43 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8668E3A6AE8; Wed, 6 Aug 2008 07:44:43 -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 309AB3A6AE8 for ; Wed, 6 Aug 2008 07:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.096 X-Spam-Level: X-Spam-Status: No, score=0.096 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_46=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 086aQbGeRfsa for ; Wed, 6 Aug 2008 07:44:42 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 2506B3A6A8D for ; Wed, 6 Aug 2008 07:44:41 -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 m76Ej7W8029771; Wed, 6 Aug 2008 16:45:07 +0200 (MEST) Received: from 87.202.170.248 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Wed, 06 Aug 2008 14:45:06 +0000 To: slblake@petri-meat.com, pcn@ietf.org Date: Wed, 06 Aug 2008 14:45:06 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: 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, 06 Aug 2008 16:45:10 +0200 (MEST) Cc: Lars.Westberg@ericsson.com, Attila.Bader@ericsson.com Subject: [PCN] regarding lc-pcn features and 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 Dear all Hein Mekkes presented the results of a number of experiments associated with the performance of the LC-PCN trunk and HOSE models. From the conclusions of these experiments it could be derived that the LC-PCN algorithm operates well. According to the consensus that was obtained after the IETF 71 and since evidence was provided regarding the LC-PCN performance we would very much appreciate if the following will be considered by the PCN working group: * preferential dropping of marked packets should be an option. Also other types of preferentila dropping of packets should be allowed. Such as random dropping and/or preferential dropping of unmarked packets. * support the option that marked excess rate represents high levels of excess rate. This can be implemented by marking every N-th packet (or bute)instad of marking each packet (or byte). N is a constant that is equal or higher than 1. * support option to allow the use of PCN-Affected-Marking encoding and the related PCN-Affecte-Marking functionalities in order to support the ECMP routing issue and the HOSE model. Best regards, Georgios _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Aug 6 08:49:48 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 753753A6818; Wed, 6 Aug 2008 08:49: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 D41D53A68BF for ; Wed, 6 Aug 2008 08:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.366 X-Spam-Level: X-Spam-Status: No, score=-3.366 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, J_CHICKENPOX_46=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 aZOt9xVH1RLQ for ; Wed, 6 Aug 2008 08:49:46 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id CEE293A63CB for ; Wed, 6 Aug 2008 08:49:35 -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, 6 Aug 2008 16:50:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 6 Aug 2008 16:50:07 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC0329F8FC@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] regarding lc-pcn features and consensus Thread-Index: Acj30xA3vhH+zhrERBS741ha0TCfJgABTgdg From: To: , , X-OriginalArrivalTime: 06 Aug 2008 15:50:06.0672 (UTC) FILETIME=[19241500:01C8F7DC] Cc: Lars.Westberg@ericsson.com, Attila.Bader@ericsson.com Subject: Re: [PCN] regarding lc-pcn features and 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 Georgios, I think you are over-stating the conclusions of your experiments. They seemed to be work in progress; for example, no confidence intervals were associated with the results (since each point represented one run only) and no experiments to explain/analyse the differences with the simulations results that others have done (Joy/Anna, Joe etc). There didn't seem to be results specifically about preferential dropping, marked flow reduction or affected marking. Hence the conclusion was that there wasn't evidence to change the previous consensus ie: - excess-traffic-marked PCN-packets SHOULD be preferentially dropped. rfc2119: SHOULD means "that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." - marking every Nth pkt is not supported. The equivalent functionality can be achieved by appropriate edge behaviour, as in the EMFT draft ie terminating marked flows with some random probability - there's consensus on the baseline encoding draft. Experimental extension encoding draft(s) are TBD. So Affected marking is not precluded, and also edge behaviour involving it is possible. Best wishes Phil/ { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { Georgios Karagiannis { Sent: 06 August 2008 15:45 { To: slblake@petri-meat.com; pcn@ietf.org { Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { Subject: [PCN] regarding lc-pcn features and consensus { { Dear all { { Hein Mekkes presented the results of a number of experiments associated { with the performance of the LC-PCN trunk and HOSE models. From the { conclusions of these experiments it could be derived that the LC-PCN { algorithm operates well. According to the consensus that was obtained { after the IETF 71 and since evidence was provided regarding the LC-PCN { performance we would very much appreciate if the following will be { considered by the PCN working group: { { * preferential dropping of marked packets should be an option. Also other { types of preferentila dropping of packets should be allowed. Such as { random dropping and/or preferential dropping of unmarked packets. { { * support the option that marked excess rate represents high levels of { excess rate. This can be implemented by marking every N-th packet (or { bute)instad of marking each packet (or byte). N is a constant that is { equal or higher than 1. { { * support option to allow the use of PCN-Affected-Marking encoding and { the related PCN-Affecte-Marking functionalities in order to support the { ECMP routing issue and the HOSE model. { { 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 Thu Aug 7 00:43:11 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5C0D3A6A31; Thu, 7 Aug 2008 00:43: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 6122D3A6A31 for ; Thu, 7 Aug 2008 00:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.013 X-Spam-Level: X-Spam-Status: No, score=-3.013 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, 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 6t59i0mub1xz for ; Thu, 7 Aug 2008 00:43:09 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id D900C3A6A14 for ; Thu, 7 Aug 2008 00:43:08 -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); Thu, 7 Aug 2008 08:43:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Aug 2008 08:43:43 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC0329F903@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <200807171813.m6HIDEbf009545@bagheera.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Natural decision point? draft-ietf-pcn-architecture-04 Thread-Index: AcjoOM9kkg/H5u9ATqWAd9s/DZFakwQJ5+Bw From: To: X-OriginalArrivalTime: 07 Aug 2008 07:43:43.0209 (UTC) FILETIME=[50DAC590:01C8F861] Cc: pcn@ietf.org Subject: Re: [PCN] Natural decision point? draft-ietf-pcn-architecture-04 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 You've more or less convinced me. Basically I propose in S7.4 to replace: o The decision is made at the PCN-egress-node and the decision (admit or block) is signalled to the PCN-ingress-node. This seems most natural. By o The decision is made at the PCN-egress-node and the decision (admit or block) is signalled to the PCN-ingress-node. o The decision is recommended by the PCN-egress-node (admit or block) but the decision is definitively made by the PCN-ingress-node. The rationale is that the PCN-egress-node naturally has the necessary information about PCN-marking in the ingress-egress-aggregate, but the PCN-ingress-node is the policy enforcement point which polices incoming traffic to ensure it's part of an admitted PCN-flow. { -----Original Message----- { From: Briscoe,RJ,Bob,XVR9 BRISCORJ R { Sent: 17 July 2008 19:13 { To: Eardley,PL,Philip,CXR9 R { Cc: PCN IETF list { Subject: RE: Natural decision point? draft-ietf-pcn-architecture-04 { { Phil, { { [I've cc'd PCN again in case the list server or BT's mail relay catch { up some time.] { { The issue is this: { - if the ingress can override the decision of the egress, it's best { to accept that the ingress is actually making the decision. The { ingress will have to tell the egress what it has decided (to tear { down path state and receiver state etc). { { So, we should be wary of any implication that the egress is making { the decision, otherwise a signalling design that says the egress { signals its decision to the ingress will look valid. When in fact a { second pass is needed. { { This is an unavoidable consequence of spreading the admission control { decision over a distributed system (PCN domain) rather than keeping { it hop-by-hop like Intserv. The MBAC phase involves packets crossing { the domain, then feedback coming back (in parallel to the signalling { which continues to the destination and comes back). Then, when the { e2e signalling returns to the PEP (ingress) if it has decided to { block, its decision has to be signalled upstream and downstream to { tear down the reservation. { { There are many variants, with different optimistic/pessimistic { models, but this is the basic one (IMHO). { { { Bob { { At 14:10 17/07/2008, philip.eardley@bt.com wrote: { >Bob { > { >[only replying to you, as only got your msg directly, not sure if you { >intended to only send to me, if pcn ML server is slow, or spam filter is { >blocking again] { > { >The text in architecture doc: { >Egress tells ingress the "admit /block" decision. { >Ingress goes with this decision. { >This is what the architecture doc currently says is 'most natural' (nb { >it doesn't say this is the only option!) { > { >Another option: { >Egress tells ingress the CLE. { >Ingress makes the decision. Now the ingress can decide what the { >CLE-threshold is (threshold for admit /block decision). Speculatively { >this might have an advantage where you want to prioritise the admission { >of various classes of users differently. (NB not talking about emergency { >etc calls, which will be admitted differently anyway.) I suspect in { >practive this is pretty marginal. { > { >Your scenario: { >Multi-domain. Ingress will get charged for traffic it admits (by { >downstream networks) so wants control over decision. This is still { >possible in either of the cases above - in either, the msg from the { >egress is treated as advice, eg even if the egress says "admit" the { >ingress might choose to block the new call. { > { >So would your issue be solved if I leave the current text & add some { >text to the effect that the ingress is the PEP so has ultimate control? { >And in the Appendix on possible future work, mention the multi-domain as { >a scenario where the ingress might want to over-ride what the egress { >suggests. { > { >Thanks { >Phil. { > { >Thanks for the spots of errors in text. S4 should have 'egress' { > { > { >{ -----Original Message----- { >{ From: Briscoe,RJ,Bob,XVR9 BRISCORJ R { >{ Sent: 17 July 2008 12:54 { >{ To: Eardley,PL,Philip,CXR9 R { >{ Subject: Natural decision point? draft-ietf-pcn-architecture-04 { >{ { >{ Phil, { >{ { >{ Apologies for re-opening this issue (it was previously discussed in { >{ Mar '08 under the thread subject "Re: [PCN] { >draft-ietf-pcn-architecture- { >{ 03" { >{ { >{ Firstly, There seems to be a contradiction between different parts of { >{ the text (quoted at the end). { >{ { >{ But my main point concerns what 'natural' means in this context. So { >{ far the discussion has focussed on efficiency (where information { >{ gathers naturally?, which node has to be informed anyway?, etc). { >{ { >{ However, "Keeping interconnect strongly in mind" [PCN charter], we { >{ should try to design protocols allowing for nodes doing what's in { >{ their operator's interests rather than what protocol messages from { >{ other operators ask them to do. { >{ { >{ Seen this way, 'natural' means 'the node that has ultimate control { >{ anyway, whatever it is asked to do'. I.e. the ingress, which is the { >{ only node that can be a policy enforcement point (PEP) [RFC2753]. { >{ { >{ I think we should point out that the ingress will be the PEP if PCN { >{ becomes multi-domain later. Otherwise, if today's single-operator { >{ designs give the egress the final decision, the operator might have { >{ to change its design when it becomes multi-domain. { >{ { >{ { >{ >4. Deployment scenarios { >{ >{...} { >{ > For admission control, the most natural place is the PCN-ingress- { >{ node. { >{ { >{ >7.4. Other admission control functions { >{ >{...} { >{ > o The decision is made at the PCN-egress-node and the decision { >{ > (admit or block) is signalled to the PCN-ingress-node. This { >seems { >{ > most natural. { >{ { >{ { >{ { >{ Bob { >{ { >{ { >{ { >{ { >_______________________________________________________________________ _ { >__ { >{ __ { >{ 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 Thu Aug 7 01:05:35 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E411E3A6A20; Thu, 7 Aug 2008 01:05: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 468E43A6A20 for ; Thu, 7 Aug 2008 01:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.537 X-Spam-Level: X-Spam-Status: No, score=-3.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 GtCQ4FjbqFC6 for ; Thu, 7 Aug 2008 01:05:34 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id A1ABA3A6A04 for ; Thu, 7 Aug 2008 01:05:33 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 09:06:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Aug 2008 09:06:06 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC0329F904@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC0329F8AD@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] New version of draft-ietf-pcn-architecture-04.txt Thread-Index: Acjl/W4FEg8NLW6wSQCob5XajFsCSgATjrFgAACiYFAEhPy2MA== From: To: X-OriginalArrivalTime: 07 Aug 2008 08:06:06.0313 (UTC) FILETIME=[71682D90:01C8F864] Subject: Re: [PCN] New version of draft-ietf-pcn-architecture-04.txt 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 Currently updating architecture with various nits. Minor changes to reflect that - baseline encoding is consensus, WG doc, stds track - also the idea of Exptal encoding extensions which may use a 2nd dscp (but not any particular ones agreed) - the corrections to Traffic conditioning agreed to the marking behaviour also means some minor changes to bits of architecture i-d. The most significant is to add a bullet to S6.5 PCN-traffic - at least I think we agreed this, please shout if we didn't: o It is not advised to have non PCN-traffic that shares the same capacity (on a link) as PCN-traffic, since it makes the PCN mechanisms less accurate and so reduces PCN's ability to protect the QoS of admitted PCN-flows. If there is such traffic, there needs to be a mechanism to limit it. - Probing now in Appendix A, and deleted the 'third viewpoint' (admission control based on the marking of a single packet like an RSVP PATH msg. This isn't really probing, and in any case is already mentioned in S6.1. - minor changes to S9 Operations and management - mainly to reflect that consensus on marking behaviour has simplified things so eg there are fewer parameters to configure. Best wishes phil { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { philip.eardley@bt.com { Sent: 15 July 2008 10:02 { To: pcn@ietf.org { Subject: Re: [PCN] New version of draft-ietf-pcn-architecture-04.txt { { I spotted a couple of small corrections needed: { { In S6.2, Flow termination { Exactly how the flow termination decision is made will be defined { separately in informational documents. At a high level several { approaches are proposed: { ... { o Another approach monitors PCN-packets and terminates any PCN-flow { with an excess-traffic-marked packet. Compared with the { approaches above, PCN-marking needs to be done at a reduced rate { (every "s" bytes of excess traffic) otherwise far too much traffic { would be terminated. { { This bullet needs to be changed, as it's inconsistent with the consensus { decisions about marking algorithm. The equivalent approach can be { achieved by randomly selecting some fraction of the marked packets for { termination (as in http://tools.ietf.org/id/draft-menth-pcn-emft-00.txt) { { In S2 Terminology { The last sentence of both PCN-threshold-rate & PCN-excess-rate { definitions needs to be deleted (they don't apply in the single marking { case). { { In addition I think it would be helpful to add a couple of pics to { illustrate what PCN-threshold-rate & PCN-excess-rate mean in terms of { when admission and termination are done. Similar to Fig 1 in { http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08 { -PCN-Comparison.pdf - one for the case with 3 encoding states, and one { for single marking. { { phil { { { -----Original Message----- { { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { { philip.eardley@bt.com { { Sent: 15 July 2008 08:31 { { To: pcn@ietf.org { { Subject: [PCN] New version of draft-ietf-pcn-architecture-04.txt { { { { I updated the Architecture draft. { { { { There are no major changes, but several more minor ones. These mostly { { reflect the consensus call about PCN-marking (as reflected in { { [I-D.eardley-pcn-marking-behaviour]), and the current decisions about { { encoding (as reflected in [I-D.moncaster-pcn-baseline-encoding] and { { [I-D.moncaster-pcn-3-state-encoding]). I also did some slight { { re-structuring and editing to try and improve the clarity, especially { of { { the introductory material and the High level architecture (where I { also { { added a sub-section on backwards compatibility with respect to { { [RFC4774]). I also took account of all the comments received on the { -03 { { version (thanks for them) { { { { Comments welcome! - thanks, { { phil { { { { { -----Original Message----- { { { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf { Of { { { Internet-Drafts@ietf.org { { { Sent: 14 July 2008 23:00 { { { To: i-d-announce@ietf.org { { { Cc: pcn@ietf.org { { { Subject: [PCN] I-D Action:draft-ietf-pcn-architecture-04.txt { { { { { { A New Internet-Draft is available from the on-line Internet-Drafts { { { directories. { { { This draft is a work item of the Congestion and Pre-Congestion { { { Notification Working Group of the IETF. { { { { { { { { { Title : Pre-Congestion Notification Architecture { { { Author(s) : P. Eardley { { { Filename : draft-ietf-pcn-architecture-04.txt { { { Pages : 52 { { { Date : 2008-07-14 { { { { { { The purpose of this document is to describe a general architecture { { { for flow admission and termination based on pre-congestion { { { information in order to protect the quality of service of { established { { { inelastic flows within a single DiffServ domain.Status { { { { { { A URL for this Internet-Draft is: { { { { http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-04.txt { { { { { { Internet-Drafts are also available by anonymous FTP at: { { { ftp://ftp.ietf.org/internet-drafts/ { { { { { { Below is the data which will enable a MIME compliant mail reader { { { implementation to automatically retrieve the ASCII version of the { { { Internet-Draft. { { _______________________________________________ { { 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 Aug 7 01:39:44 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAF1D3A6A04; Thu, 7 Aug 2008 01:39: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 CB34B3A6A04 for ; Thu, 7 Aug 2008 01:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=-0.175, 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 aWfnSrZ999LM for ; Thu, 7 Aug 2008 01:39:42 -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 325913A68DD for ; Thu, 7 Aug 2008 01:39:41 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 39585198E69; Thu, 7 Aug 2008 10:40:15 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 2CFAC198E68; Thu, 7 Aug 2008 10:40:15 +0200 (CEST) Received: from [132.187.12.123] (win3123.informatik.uni-wuerzburg.de [132.187.12.123]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 078B4198E56; Thu, 7 Aug 2008 10:40:15 +0200 (CEST) Message-ID: <489AB49A.5090309@informatik.uni-wuerzburg.de> Date: Thu, 07 Aug 2008 10:38:50 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: philip.eardley@bt.com References: <4A916DBC72536E419A0BD955EDECEDEC0329F904@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC0329F904@E03MVB1-UKBR.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] New version of draft-ietf-pcn-architecture-04.txt 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil, philip.eardley@bt.com wrote: > Currently updating architecture with various nits. > > Minor changes to reflect that > - baseline encoding is consensus, WG doc, stds track - also the idea of > Exptal encoding extensions which may use a 2nd dscp (but not any > particular ones agreed) > I'd appreciate if PSDM is mentioned as a clever extension of baseline encoding to accommodate two marking schemes by a single DSCP. I think this is equally important as extensions by additional DSCPs. > - the corrections to Traffic conditioning agreed to the marking > behaviour also means some minor changes to bits of architecture i-d. The > most significant is to add a bullet to S6.5 PCN-traffic - at least I > think we agreed this, please shout if we didn't: > o It is not advised to have non PCN-traffic that shares the same > capacity (on a link) as PCN-traffic, since it makes the PCN mechanisms > less accurate and so reduces PCN's ability to protect the QoS of > admitted PCN-flows. If there is such traffic, there needs to be a > mechanism to limit it. > > - Probing now in Appendix A, and deleted the 'third viewpoint' > (admission control based on the marking of a single packet like an RSVP > PATH msg. This isn't really probing, and in any case is already > mentioned in S6.1. > It is probing, but without extra traffic. Therefore, wherever this method is described in the document, it should be called a clever probing method. The appendix on probing should have a reference to S6.1 where this clever kind of probing is described. I recommend to introduce the terms admissible and supportable rate. They are needed to say what the "excess-rate-threshold" should be set to in case of single marking or CL. They are also useful to qualify the type of pre-congestion and overload independently of the PCN implementation. In one of your last emails you stated that the meaning of the "excess-rate-threshold" depends on SM or CL and the phrase "It's roughly that rate down to which flow termination should, if necessary, terminate already admitted flows." should be deleted from its definition. http://www.ietf.org/mail-archive/web/pcn/current/msg01594.html http://www.ietf.org/mail-archive/web/pcn/current/msg01595.html Regards, Michael > - minor changes to S9 Operations and management - mainly to reflect that > consensus on marking behaviour has simplified things so eg there are > fewer parameters to configure. > > Best wishes > phil > > { -----Original Message----- > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > { philip.eardley@bt.com > { Sent: 15 July 2008 10:02 > { To: pcn@ietf.org > { Subject: Re: [PCN] New version of draft-ietf-pcn-architecture-04.txt > { > { I spotted a couple of small corrections needed: > { > { In S6.2, Flow termination > { Exactly how the flow termination decision is made will be defined > { separately in informational documents. At a high level several > { approaches are proposed: > { ... > { o Another approach monitors PCN-packets and terminates any > PCN-flow > { with an excess-traffic-marked packet. Compared with the > { approaches above, PCN-marking needs to be done at a reduced rate > { (every "s" bytes of excess traffic) otherwise far too much > traffic > { would be terminated. > { > { This bullet needs to be changed, as it's inconsistent with the > consensus > { decisions about marking algorithm. The equivalent approach can be > { achieved by randomly selecting some fraction of the marked packets for > { termination (as in > http://tools.ietf.org/id/draft-menth-pcn-emft-00.txt) > { > { In S2 Terminology > { The last sentence of both PCN-threshold-rate & PCN-excess-rate > { definitions needs to be deleted (they don't apply in the single > marking > { case). > { > { In addition I think it would be helpful to add a couple of pics to > { illustrate what PCN-threshold-rate & PCN-excess-rate mean in terms of > { when admission and termination are done. Similar to Fig 1 in > { > http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08 > { -PCN-Comparison.pdf - one for the case with 3 encoding states, and one > { for single marking. > { > { phil > { > { { -----Original Message----- > { { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf > Of > { { philip.eardley@bt.com > { { Sent: 15 July 2008 08:31 > { { To: pcn@ietf.org > { { Subject: [PCN] New version of draft-ietf-pcn-architecture-04.txt > { { > { { I updated the Architecture draft. > { { > { { There are no major changes, but several more minor ones. These > mostly > { { reflect the consensus call about PCN-marking (as reflected in > { { [I-D.eardley-pcn-marking-behaviour]), and the current decisions > about > { { encoding (as reflected in [I-D.moncaster-pcn-baseline-encoding] and > { { [I-D.moncaster-pcn-3-state-encoding]). I also did some slight > { { re-structuring and editing to try and improve the clarity, > especially > { of > { { the introductory material and the High level architecture (where I > { also > { { added a sub-section on backwards compatibility with respect to > { { [RFC4774]). I also took account of all the comments received on the > { -03 > { { version (thanks for them) > { { > { { Comments welcome! - thanks, > { { phil > { { > { { { -----Original Message----- > { { { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf > { Of > { { { Internet-Drafts@ietf.org > { { { Sent: 14 July 2008 23:00 > { { { To: i-d-announce@ietf.org > { { { Cc: pcn@ietf.org > { { { Subject: [PCN] I-D Action:draft-ietf-pcn-architecture-04.txt > { { { > { { { A New Internet-Draft is available from the on-line Internet-Drafts > { { { directories. > { { { This draft is a work item of the Congestion and Pre-Congestion > { { { Notification Working Group of the IETF. > { { { > { { { > { { { Title : Pre-Congestion Notification Architecture > { { { Author(s) : P. Eardley > { { { Filename : draft-ietf-pcn-architecture-04.txt > { { { Pages : 52 > { { { Date : 2008-07-14 > { { { > { { { The purpose of this document is to describe a general architecture > { { { for flow admission and termination based on pre-congestion > { { { information in order to protect the quality of service of > { established > { { { inelastic flows within a single DiffServ domain.Status > { { { > { { { A URL for this Internet-Draft is: > { { { > { http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-04.txt > { { { > { { { Internet-Drafts are also available by anonymous FTP at: > { { { ftp://ftp.ietf.org/internet-drafts/ > { { { > { { { Below is the data which will enable a MIME compliant mail reader > { { { implementation to automatically retrieve the ASCII version of the > { { { Internet-Draft. > { { _______________________________________________ > { { 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 Thu Aug 7 01:59:49 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 861C83A6B10; Thu, 7 Aug 2008 01:59: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 932A83A6A08 for ; Thu, 7 Aug 2008 01:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 BOqxUpPjmRm5 for ; Thu, 7 Aug 2008 01:59:47 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 2AB253A6AC9 for ; Thu, 7 Aug 2008 01:59:47 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail21.telekom.de with ESMTP; Thu, 7 Aug 2008 11:00:06 +0200 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, 7 Aug 2008 11:00:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Aug 2008 11:00:05 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C019B6582@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <489AB49A.5090309@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] New version of draft-ietf-pcn-architecture-04.txt thread-index: Acj4aTyYtfpEDkPbTYGL8nW+5jmmXwAAIrXQ References: <4A916DBC72536E419A0BD955EDECEDEC0329F904@E03MVB1-UKBR.domain1.systemhost.net> <489AB49A.5090309@informatik.uni-wuerzburg.de> From: "Geib, Ruediger" To: , X-OriginalArrivalTime: 07 Aug 2008 09:00:06.0447 (UTC) FILETIME=[FCAD63F0:01C8F86B] Cc: pcn@ietf.org Subject: Re: [PCN] New version of draft-ietf-pcn-architecture-04.txt 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, hi Michael, [deleted text I don't comment] > - Probing now in Appendix A, and deleted the 'third viewpoint' > (admission control based on the marking of a single packet like an RSVP > PATH msg. This isn't really probing, and in any case is already > mentioned in S6.1. > [Michael] It is probing, but without extra traffic. Therefore, wherever this method is described in the document, it should be called a clever probing method. The appendix on probing should have a reference to S6.1 where this clever kind of probing is described. [Ruediger] A RSVP Path message and similar NSIS messages are transport service signaling messages. We piggyback a clever probing mechanism on them, but they remain signaling messages. These messages MUST be sent by a service requesting entity, whether PCN is active within a domain or not and I don't think that changing the ECN codings of these messages changes their purpose significantly enough to justify a change in terminology. The point I want to make is, that these messages are or may be present, whether the PCN WG decides to apply probing or not. My interpretation of "probing" is that special measurement traffic is created for the single and only purpose of probing. This definition isn't met by RSVP and NSIS signaling messages. So they shouldn't be called probes. Of course the architecture should mention that a clever probing mechanism could be piggybacked on path coupled signaling messages. Regards, Ruediger _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Aug 7 02:20:03 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BAD13A696A; Thu, 7 Aug 2008 02:20: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 9E5AE3A68AF for ; Thu, 7 Aug 2008 02:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.243 X-Spam-Level: X-Spam-Status: No, score=-3.243 tagged_above=-999 required=5 tests=[AWL=-0.244, 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 kULsGFSartKS for ; Thu, 7 Aug 2008 02:20:00 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 7CFF33A680E for ; Thu, 7 Aug 2008 02:20:00 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 7 Aug 2008 10:20:33 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 7 Aug 2008 10:20:21 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC0329F907@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <489AB49A.5090309@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] New version of draft-ietf-pcn-architecture-04.txt Thread-Index: Acj4aTu1xVz1gUuOQuuAK+Rzm4PQSQABXfiQ From: To: X-OriginalArrivalTime: 07 Aug 2008 09:20:33.0753 (UTC) FILETIME=[D8356C90:01C8F86E] Cc: pcn@ietf.org Subject: Re: [PCN] New version of draft-ietf-pcn-architecture-04.txt 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: 07 August 2008 09:39 { To: Eardley,PL,Philip,CXR9 R { Cc: pcn@ietf.org { Subject: Re: [PCN] New version of draft-ietf-pcn-architecture-04.txt { { Hi Phil, { { philip.eardley@bt.com wrote: { > Currently updating architecture with various nits. { > { > Minor changes to reflect that { > - baseline encoding is consensus, WG doc, stds track - also the idea of { > Exptal encoding extensions which may use a 2nd dscp (but not any { > particular ones agreed) { > { I'd appreciate if PSDM is mentioned as a clever extension of baseline { encoding to accommodate two marking schemes by a single DSCP. I think { this is equally important as extensions by additional DSCPs. { I'll mention it somewhere Thanks phil _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Aug 7 02:24:04 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C5723A6A08; Thu, 7 Aug 2008 02:24: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 308BC3A6A08 for ; Thu, 7 Aug 2008 02:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=-0.162, 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 vsHEfZBT1alv for ; Thu, 7 Aug 2008 02:24:03 -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 D5A6B3A696A for ; Thu, 7 Aug 2008 02:24:02 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 0DF30A06C6; Thu, 7 Aug 2008 11:24:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 0258CA06BD; Thu, 7 Aug 2008 11:24:38 +0200 (CEST) Received: from [132.187.12.123] (win3123.informatik.uni-wuerzburg.de [132.187.12.123]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id DC0A1198E4B; Thu, 7 Aug 2008 11:24:37 +0200 (CEST) Message-ID: <489ABF01.3070307@informatik.uni-wuerzburg.de> Date: Thu, 07 Aug 2008 11:23:13 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: "Geib, Ruediger" References: <4A916DBC72536E419A0BD955EDECEDEC0329F904@E03MVB1-UKBR.domain1.systemhost.net> <489AB49A.5090309@informatik.uni-wuerzburg.de> <1B6169C658325341A3B8066E23919E1C019B6582@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1B6169C658325341A3B8066E23919E1C019B6582@S4DE8PSAANK.mitte.t-com.de> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] New version of draft-ietf-pcn-architecture-04.txt 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-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi R=FCdiger, hi Phil, Geib, Ruediger wrote: > Hi Phil, hi Michael, = > > [deleted text I don't comment] > = >> - Probing now in Appendix A, and deleted the 'third viewpoint' >> (admission control based on the marking of a single packet like an RSVP >> PATH msg. This isn't really probing, and in any case is already >> mentioned in S6.1. >> >> = > > [Michael] = > It is probing, but without extra traffic. Therefore, wherever this = > method is described in the document, it should be called a clever = > probing method. The appendix on probing should have a reference to S6.1 = > where this clever kind of probing is described. > > [Ruediger] > A RSVP Path message and similar NSIS messages are transport service = > signaling messages. We piggyback a clever probing mechanism on them, but = > they remain signaling messages. These messages MUST be sent by a = > service requesting entity, whether PCN is active within a domain or = > not and I don't think that changing the ECN codings of these messages = > changes their purpose significantly enough to justify a change in = > terminology. > > The point I want to make is, that these messages are or may be present, = > whether the PCN WG decides to apply probing or not. My interpretation of = > "probing" is that special measurement traffic is created for = > the single and only purpose of probing. This definition isn't met by = > RSVP and NSIS signaling messages. So they shouldn't be called probes. > = Given your definition of probing I agree with you. But I don't agree = with you on your definition of probing. My definition of probing is: Admission control based on the marking feedback from packets that are = associated with the requesting flow and were recently sent on the same = path. Generation of extra traffic is not necessary when other traffic = can be used for that purpose. This definition covers all facets of probing mechanisms discussed so far = and is sharp enough to distinguish probing from other feedback = mechanisms based on ingress-egress-aggregates. It does not lead to the = observed clashes when talking about various probe mechanisms. When = signaling traffic is reused for probing, the signaling packets on which = the AC decision is based become also probe packets, but they primarily = remain signaling packets of course. It might be useful to add this definition of probing to the terminology = section. Regards, Michael > Of course the architecture should mention that a clever probing mechanism = > could be piggybacked on path coupled signaling messages. > > Regards, > > Ruediger > = -- = 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 Aug 7 08:30:02 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B7F63A6C10; Thu, 7 Aug 2008 08:30:02 -0700 (PDT) X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 35D0D3A699D; Thu, 7 Aug 2008 08:30:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080807153001.35D0D3A699D@core3.amsl.com> Date: Thu, 7 Aug 2008 08:30:01 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-architecture-05.txt 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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF. Title : Pre-Congestion Notification Architecture Author(s) : P. Eardley Filename : draft-ietf-pcn-architecture-05.txt Pages : 54 Date : 2008-08-07 The purpose of this document is to describe a general architecture for flow admission and termination based on pre-congestion information in order to protect the quality of service of established inelastic flows within a single DiffServ domain.Status A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcn-architecture-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-08-07082525.I-D@ietf.org> --NextPart 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-- From pcn-bounces@ietf.org Fri Aug 8 01:32:29 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B8B33A6CAA; Fri, 8 Aug 2008 01:32: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 A22093A6CB2 for ; Fri, 8 Aug 2008 01:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_57=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 wH2Ww1y2pzd5 for ; Fri, 8 Aug 2008 01:32:19 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id D10A03A6CAA for ; Fri, 8 Aug 2008 01:32:18 -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, 8 Aug 2008 09:32:18 +0100 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, 8 Aug 2008 09:32:16 +0100 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 1218184336820; Fri, 8 Aug 2008 09:32:16 +0100 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 m788WDYJ022438; Fri, 8 Aug 2008 09:32:13 +0100 Message-Id: <200808080832.m788WDYJ022438@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 08 Aug 2008 09:32:18 +0100 To: From: Bob Briscoe In-Reply-To: <9860859c24d436354089fc9bbe795921@petri-meat.com> References: <9860859c24d436354089fc9bbe795921@petri-meat.com> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 08 Aug 2008 08:32:16.0223 (UTC) FILETIME=[438F2EF0:01C8F931] Cc: pcn@ietf.org Subject: Re: [PCN] Moving draft-eardley-pcn-marking-behavior-01 to WG draft 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Steve, I support this as WG item Bob At 23:25 31/07/2008, slblake@petri-meat.com wrote: >There was strong consensus in the meeting today to move (the next revision >of) draft-eardley-pcn-marking-behavior-01 to a WG draft. This email is to >confirm the decision on the list. Please send comments within the next >week. > > >Regards, > >// Steve > >_______________________________________________ >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 Fri Aug 8 05:00:42 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 758F93A6889; Fri, 8 Aug 2008 05:00: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 91CCB3A6889 for ; Fri, 8 Aug 2008 05:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.601 X-Spam-Level: X-Spam-Status: No, score=-6.601 tagged_above=-999 required=5 tests=[AWL=-0.002, 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 2SdoJZ3YHpvX for ; Fri, 8 Aug 2008 05:00:40 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 8BC133A67EC for ; Fri, 8 Aug 2008 05:00:40 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m78C0XuS008369; Fri, 8 Aug 2008 15:00:36 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 15:00:22 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 15:00:15 +0300 Received: from net-68.nrpn.net ([10.241.184.208]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 8 Aug 2008 15:00:15 +0300 Message-Id: <3181210E-3E0E-4F3D-9024-827872258578@nokia.com> From: Lars Eggert To: "ext philip.eardley@bt.com" In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC032A07DF@E03MVB1-UKBR.domain1.systemhost.net> Mime-Version: 1.0 (Apple Message framework v926) Date: Fri, 8 Aug 2008 15:00:10 +0300 References: <4A916DBC72536E419A0BD955EDECEDEC032A07DF@E03MVB1-UKBR.domain1.systemhost.net> X-Mailer: Apple Mail (2.926) X-OriginalArrivalTime: 08 Aug 2008 12:00:15.0601 (UTC) FILETIME=[51D92610:01C8F94E] X-Nokia-AV: Clean Cc: pcn@ietf.org Subject: Re: [PCN] Open issue with PCN marking behaviour draft 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org On 2008-7-30, at 17:17, ext philip.eardley@bt.com wrote: > What the WG probably meant was: both the threshold-meter and excess- > rate-meter MUST be *implemented*. However, if in a particular > scenario only the results of one meter are used to make pkt marking > decisions, then the other meter doesn't have to be *running*. That's what's typically meant by "MUST implement" (implement != use). Lars _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Aug 8 17:03:47 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 336F93A6CA1; Fri, 8 Aug 2008 17:03: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 2206C3A6C00 for ; Fri, 8 Aug 2008 17:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[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 w6N-merL0qR1 for ; Fri, 8 Aug 2008 17:03:45 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 769C33A6924 for ; Fri, 8 Aug 2008 17:03:45 -0700 (PDT) Received: from cpe-071-077-051-078.nc.res.rr.com ([71.77.51.78]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1KRbvn-0006gr-Ri for pcn@ietf.org; Fri, 08 Aug 2008 20:03:39 -0400 From: Steven Blake To: pcn Date: Fri, 08 Aug 2008 20:03:40 -0400 Message-Id: <1218240220.16668.6.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Subject: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 message starts a 2+-week PCN working group last call for advancing Title : Pre-Congestion Notification Architecture Author(s) : P. Eardley Filename : draft-ietf-pcn-architecture-05.txt Pages : 54 Date : 2008-08-07 as an Informational RFC. Substantive comments and statements of support for this draft should be sent to the pcn mailing list. Editorial suggestions can be sent directly to the document editor. The last call will end on Wednesday August 27. // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Aug 11 04:57:55 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 147B63A6B73; Mon, 11 Aug 2008 04: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 04C0D3A68BF for ; Mon, 11 Aug 2008 04:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_SE=0.35, 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 1C2KpwOYypAf for ; Mon, 11 Aug 2008 04:57:53 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 0DCFB3A6822 for ; Mon, 11 Aug 2008 04:57:52 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 9B04F20623 for ; Mon, 11 Aug 2008 13:57:12 +0200 (CEST) X-AuditID: c1b4fb3c-aa8c7bb0000015b5-d5-48a02918465f Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 831792004F for ; Mon, 11 Aug 2008 13:57:12 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Aug 2008 13:57:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 11 Aug 2008 13:57:10 +0200 Message-ID: <026F8EEDAD2C4342A993203088C1FC0508064250@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: draft-ietf-pcn-architecture-05 thread-index: Acj7qWKk3skkZFbxQgaXUA0/9E+x9Q== From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 11 Aug 2008 11:57:12.0127 (UTC) FILETIME=[63BA7CF0:01C8FBA9] X-Brightmail-Tracker: AAAAAA== Subject: Re: [PCN] draft-ietf-pcn-architecture-05 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 I have read through the document and I find the draft quite comprehensible = even for a person that is relatively close to laymans level and I believe t= hat many of the concepts that I did not understand how they should work a f= ew months ago has been clarified, atleast on a higher level. Some comments/nits. Secion 6. High-level functional architecture "The objective is to standardise PCN- marking behaviour, but potentially produce more than one (informational) RFC describing how PCN-boundary-nodes react to PCN- marks." Find the sentence a bit odd, should it be something like "but may potential= ly produce" ? Section 6.6. Backwards compatibility My impression is that the 2nd last paragraph (to block ECN-capable traffic)= is mostly applicable to pcn base line encoding. With the use of tunneling = or a future pcn encoding (e.g 3-state) this requirement is more relaxed. Am= I right. If this is the case I would suggest that the text makes this more= clear. Section 7.2. PCN-ingress-node functions Second bullet ends with "If PCN", text missing ? Section 8. Design goals and challenges "Flash crowds and Speed of Reaction". Even though it is currently maybe out= side the WG charter, e2e ECN is one way to limit the potential harm caused = by flash crowds, this mechanism and how it is supposed to interact with PCN= needs more study though. Regards Ingemar ******************************************* = Ingemar Johansson = Senior Research Engineer, IETF "nethead" = EAB/TVP - Multimedia Technologies = Ericsson Research Ericsson AB = Box 920 S-971 28 Lule=E5, Sweden = Tel: +46 (0)8 4043042 = ECN: 850-43042 = ECC: 850-43074 = Mobile: +46 (0)730 783289 = ******************************************* = _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Aug 12 02:55:05 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFC783A69AD; Tue, 12 Aug 2008 02:55: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 5A24C3A69BD for ; Tue, 12 Aug 2008 02:55:05 -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 nEfWJBFtRpOc for ; Tue, 12 Aug 2008 02:55:04 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 422793A6968 for ; Tue, 12 Aug 2008 02:55:04 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Aug 2008 10:54:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 12 Aug 2008 10:54:41 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC0329F91B@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <026F8EEDAD2C4342A993203088C1FC0508064250@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] draft-ietf-pcn-architecture-05 Thread-Index: Acj7qWKk3skkZFbxQgaXUA0/9E+x9QAtlzOA From: To: , X-OriginalArrivalTime: 12 Aug 2008 09:54:42.0266 (UTC) FILETIME=[714873A0:01C8FC61] Subject: Re: [PCN] draft-ietf-pcn-architecture-05 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 Thanks for the support, and the comments In-line phil { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { Ingemar Johansson S { Sent: 11 August 2008 12:57 { To: pcn@ietf.org { Subject: Re: [PCN] draft-ietf-pcn-architecture-05 { = { Hi { = { I have read through the document and I find the draft quite comprehensible { even for a person that is relatively close to laymans level and I believe { that many of the concepts that I did not understand how they should work a { few months ago has been clarified, atleast on a higher level. { = { Some comments/nits. { = { Secion 6. High-level functional architecture { "The objective is to standardise PCN- { marking behaviour, but potentially produce more than one { (informational) RFC describing how PCN-boundary-nodes react to PCN- { marks." { Find the sentence a bit odd, should it be something like "but may { potentially produce" ? will re-phrase { = { Section 6.6. Backwards compatibility { My impression is that the 2nd last paragraph (to block ECN-capable { traffic) is mostly applicable to pcn base line encoding. With the use of { tunneling or a future pcn encoding (e.g 3-state) this requirement is more { relaxed. Am I right. If this is the case I would suggest that the text { makes this more clear. Yes you're right, the 2nd last para is about pcn baseline encoding. And yes= , extended encoding might do something different. Will try to clarify. = { = { Section 7.2. PCN-ingress-node functions { Second bullet ends with "If PCN", text missing ? "If PCN" should be deleted. = { = { Section 8. Design goals and challenges { "Flash crowds and Speed of Reaction". Even though it is currently maybe { outside the WG charter, e2e ECN is one way to limit the potential harm { caused by flash crowds, this mechanism and how it is supposed to interact { with PCN needs more study though. Possibly, I'm not sure. Anyway, in this section I tried to avoid talking ab= out solutions at all, only problems. (there's a note to say this at the sta= rt of the long list of bullets of potential issues.) This was partly for re= asons of space, and partly because I thought it would be inappropriate to s= ay "here are 4 potential solutions to the problem, but we're not going to s= ay anything (or anything definitive) about which one to choose". Anyway, at the moment I won't change any text here (please follow-up if you= want). { = { = { Regards { Ingemar { = { ******************************************* { Ingemar Johansson { Senior Research Engineer, IETF "nethead" { EAB/TVP - Multimedia Technologies { Ericsson Research Ericsson AB { Box 920 S-971 28 Lule=E5, Sweden { Tel: +46 (0)8 4043042 { ECN: 850-43042 { ECC: 850-43074 { Mobile: +46 (0)730 783289 { ******************************************* { _______________________________________________ { 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 Aug 14 03:33:28 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F29773A6886; Thu, 14 Aug 2008 03: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 753A13A6886 for ; Thu, 14 Aug 2008 03:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.11 X-Spam-Level: *** X-Spam-Status: No, score=3.11 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRmhYtf2tLNk for ; Thu, 14 Aug 2008 03:33:26 -0700 (PDT) Received: from sg.ntt-at.co.jp (roma.ntt-at.co.jp [202.253.160.19]) by core3.amsl.com (Postfix) with SMTP id 5B2943A682F for ; Thu, 14 Aug 2008 03:33:26 -0700 (PDT) Received: (qmail 77711 invoked by alias); 14 Aug 2008 10:32:54 -0000 Received: from suez.bb.ntt-at.co.jp (192.168.2.9) by subgate.bb.ntt-at.co.jp with SMTP; 14 Aug 2008 10:32:54 -0000 Received: from pacific.bb.ntt-at.co.jp (suez [127.0.0.1]) by suez.bb.ntt-at.co.jp (8.12.10/8.12.10) with ESMTP id m7EAWrYl002163 for ; Thu, 14 Aug 2008 19:32:53 +0900 Received: from mercury.tec.ntt-at.co.jp (mercury.tec.ntt-at.co.jp [192.168.22.39]) by pacific.bb.ntt-at.co.jp (8.13.1/cf/pacific) with ESMTP id m7EAWqcA007230 for ; Thu, 14 Aug 2008 19:32:53 +0900 (JST) (envelope-from daisuke.satoh@ntt-at.co.jp) Received: from [192.168.21.66] (ip21-066.tec.ntt-at.co.jp [192.168.21.66]) by mercury.tec.ntt-at.co.jp (Postfix) with ESMTP id AA3CC53F61; Thu, 14 Aug 2008 19:32:52 +0900 (JST) Date: Thu, 14 Aug 2008 19:32:34 +0900 From: =?ISO-2022-JP?B?GyRCOjRGIyEhQmdKZRsoQg==?= To: pcn@ietf.org Message-Id: <20080814191815.EA4A.26AD349@ntt-at.co.jp> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.46 [ja] Subject: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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, I have been interested in PCN WG and I have joined PCN WG since IETF69(Chicago). I have reviewed the architecture draft and have a comment on Sec 6.3. The third option (both admission control and flow termination) almost describes the single marking algorithm itself. This description seems to exclude a future new algorithm and to limit a solution. In my opinion, a new algorithm should not be excluded. Actually, a new algorithm idea was presented in Dublin by Roudiger Geib. I propose that the third option is modified as follows, o both admission cotrol and flow termination: Either excess-traffic-marking algorithm or threshold-marking algorithm writes PCN-marks. As an example of excess-traffic-marking case (Figure 2), [I-D. charney-pcn-single-marking] describes how both admission control and flow termination can be triggered and also gives some of the pros and cons of this approarch. The main downside is that admission control is less accurate. Best regards, Daisuke SATOH > Date: Fri, 08 Aug 2008 20:03:40 -0400 > From: Steven Blake > Subject: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt > To: pcn > Message-ID: <1218240220.16668.6.camel@tachyon> > Content-Type: text/plain > > This message starts a 2+-week PCN working group last call for advancing > > Title : Pre-Congestion Notification Architecture > Author(s) : P. Eardley > Filename : draft-ietf-pcn-architecture-05.txt > Pages : 54 > Date : 2008-08-07 > > as an Informational RFC. Substantive comments and statements of support > for this draft should be sent to the pcn mailing list. Editorial > suggestions can be sent directly to the document editor. > The last call will end on Wednesday August 27. > > // Steve > > > > ------------------------------ > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > > > End of PCN Digest, Vol 25, Issue 6 > ********************************** _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Aug 14 05:27:24 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 851353A6AD0; Thu, 14 Aug 2008 05:27: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 7557C3A6AD0 for ; Thu, 14 Aug 2008 05:27:23 -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 mItGwK2jIKHL for ; Thu, 14 Aug 2008 05:27:22 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 5AB3F3A695A for ; Thu, 14 Aug 2008 05:27:22 -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); Thu, 14 Aug 2008 13:24:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 14 Aug 2008 13:24:56 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC0329F939@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <20080814191815.EA4A.26AD349@ntt-at.co.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt Thread-Index: Acj9+xWwGZhnQ0AHQZayiHbV+Re5tQADRzNg From: To: , X-OriginalArrivalTime: 14 Aug 2008 12:24:55.0789 (UTC) FILETIME=[C29669D0:01C8FE08] Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 Thanks Daisuke. Your point seems reasonable to me. Just from a text point of view, I think it would be easier to keep the existing bullet as is (since it describes a well-understood scheme), and add a new bullet that says they're might be something else (currently unknown scheme) to achieve adm ctrl & flow termin with a single marking algo Best wishes, phil { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { daisuke.satoh@ntt-at.co.jp { Sent: 14 August 2008 11:33 { To: pcn@ietf.org { Subject: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt { { Hi all, { { { I have been interested in PCN WG and I have joined PCN WG since { IETF69(Chicago). { { I have reviewed the architecture draft and have a comment on Sec 6.3. { The third option (both admission control and flow termination) almost { describes the single marking algorithm itself. This description seems to { exclude a future new algorithm and to limit a solution. In my opinion, a { new algorithm should not be excluded. Actually, a new algorithm idea was { presented in Dublin by Roudiger Geib. { { { { I propose that the third option is modified as follows, { o both admission cotrol and flow termination: Either excess-traffic- { marking { algorithm or threshold-marking algorithm writes PCN-marks. As an example { of excess-traffic-marking case (Figure 2), [I-D. { charney-pcn-single-marking] describes how both admission control and { flow termination can be triggered and also gives some of the pros and { cons of this approarch. The main downside is that admission control is { less accurate. { { { { { Best regards, { Daisuke SATOH { { { { { { > Date: Fri, 08 Aug 2008 20:03:40 -0400 { > From: Steven Blake { > Subject: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt { > To: pcn { > Message-ID: <1218240220.16668.6.camel@tachyon> { > Content-Type: text/plain { > { > This message starts a 2+-week PCN working group last call for advancing { > { > Title : Pre-Congestion Notification Architecture { > Author(s) : P. Eardley { > Filename : draft-ietf-pcn-architecture-05.txt { > Pages : 54 { > Date : 2008-08-07 { > { > as an Informational RFC. Substantive comments and statements of support { > for this draft should be sent to the pcn mailing list. Editorial { > suggestions can be sent directly to the document editor. { > The last call will end on Wednesday August 27. { > { > // Steve { > { > { > { > ------------------------------ { > { > _______________________________________________ { > PCN mailing list { > PCN@ietf.org { > https://www.ietf.org/mailman/listinfo/pcn { > { > { > End of PCN Digest, Vol 25, Issue 6 { > ********************************** { { _______________________________________________ { 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 Aug 18 07:36:20 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE50A3A6CFA; Mon, 18 Aug 2008 07:36: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 8AE7C3A6CFA for ; Mon, 18 Aug 2008 07:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.296 X-Spam-Level: *** X-Spam-Status: No, score=3.296 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_46=0.6, J_CHICKENPOX_47=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82IZVZ-tb2Gi for ; Mon, 18 Aug 2008 07:36:18 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 531B43A6CE6 for ; Mon, 18 Aug 2008 07:36:17 -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 m7IEaIeb003561; Mon, 18 Aug 2008 16:36:22 +0200 (MEST) From: "Georgios Karagiannis" To: , , References: <4A916DBC72536E419A0BD955EDECEDEC0329F8FC@E03MVB1-UKBR.domain1.systemhost.net> Date: Mon, 18 Aug 2008 16:36:12 +0200 Message-ID: <000301c9013f$c6f8eea0$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: <4A916DBC72536E419A0BD955EDECEDEC0329F8FC@E03MVB1-UKBR.domain1.systemhost.net> Thread-Index: Acj30xA3vhH+zhrERBS741ha0TCfJgABTgdgAljd/RA= 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, 18 Aug 2008 16:36:23 +0200 (MEST) Cc: Lars.Westberg@ericsson.com, Attila.Bader@ericsson.com Subject: Re: [PCN] regarding lc-pcn features and 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 Hallo Phil I agree that confidence intervals are not shown. However, the LC-PCN results are shown in a similar way as the SM results presented in the SM draft. Please note that the shown results for LC-PCN for trunk and HOSE models are not worse than the SM results. >From what you mentioned I can conclude that: > - excess-traffic-marked PCN-packets SHOULD be preferentially dropped. Thus random preferential dropping and preferential dropping of unmarked traffic in not precluded. > - there's consensus on the baseline encoding draft. > Experimental extension encoding draft(s) are TBD. So Affected > marking is not precluded, and also edge behaviour involving > it is possible. Thus the use of Affected Marking and the use of other types of edge behaviour encoding is not precluded. > - marking every Nth pkt is not supported. Thus you mean that the option of marking every Nth pkt is precluded. Without this option the LC-PCN algorithm will become very slow in situations of high overloads that are above the capacity of a link. Therefore, we would very much appreciate if an experimental extesion of this feature will be allowed to support the option that marked excess rate represents high levels of { excess rate). This can be implemented by marking every N-th packet (or { byte)instead of marking each packet (or byte). N is a constant that is { equal or higher than 1. Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: woensdag 6 augustus 2008 17:50 > To: karagian@cs.utwente.nl; slblake@petri-meat.com; pcn@ietf.org > Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com > Subject: RE: [PCN] regarding lc-pcn features and consensus > > Georgios, > > I think you are over-stating the conclusions of your > experiments. They seemed to be work in progress; for example, > no confidence intervals were associated with the results > (since each point represented one run only) and no > experiments to explain/analyse the differences with the > simulations results that others have done (Joy/Anna, Joe > etc). There didn't seem to be results specifically about > preferential dropping, marked flow reduction or affected marking. > > Hence the conclusion was that there wasn't evidence to change > the previous consensus ie: > > - excess-traffic-marked PCN-packets SHOULD be preferentially dropped. > rfc2119: SHOULD means "that there may exist valid reasons in > particular circumstances to ignore a particular item, but the > full implications must be understood and carefully weighed > before choosing a different course." > - marking every Nth pkt is not supported. The equivalent > functionality can be achieved by appropriate edge behaviour, > as in the EMFT draft ie terminating marked flows with some > random probability > - there's consensus on the baseline encoding draft. > Experimental extension encoding draft(s) are TBD. So Affected > marking is not precluded, and also edge behaviour involving > it is possible. > > Best wishes > Phil/ > > { -----Original Message----- > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of { Georgios Karagiannis { Sent: 06 August 2008 15:45 > { To: slblake@petri-meat.com; pcn@ietf.org { Cc: > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > Subject: [PCN] regarding lc-pcn features and consensus { { > Dear all { { Hein Mekkes presented the results of a number of > experiments associated { with the performance of the LC-PCN > trunk and HOSE models. From the { conclusions of these > experiments it could be derived that the LC-PCN { algorithm > operates well. According to the consensus that was obtained { > after the IETF 71 and since evidence was provided regarding > the LC-PCN { performance we would very much appreciate if the > following will be { considered by the PCN working group: > { > { * preferential dropping of marked packets should be an > option. Also other { types of preferentila dropping of > packets should be allowed. Such as { random dropping and/or > preferential dropping of unmarked packets. > { > { * support the option that marked excess rate represents > high levels of { excess rate. This can be implemented by > marking every N-th packet (or { bute)instad of marking each > packet (or byte). N is a constant that is { equal or higher than 1. > { > { * support option to allow the use of PCN-Affected-Marking > encoding and { the related PCN-Affecte-Marking > functionalities in order to support the { ECMP routing issue > and the HOSE model. > { > { 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 Aug 18 08:04:53 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6AC33A6D0C; Mon, 18 Aug 2008 08:04: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 CC4883A6D0C for ; Mon, 18 Aug 2008 08:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AWL=-1.507, BAYES_40=-0.185, J_CHICKENPOX_47=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 APqLZELtfeto for ; Mon, 18 Aug 2008 08:04:50 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id E1AFE3A69DF for ; Mon, 18 Aug 2008 08:04:49 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Aug 2008 16:04:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Aug 2008 16:04:13 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC0329F951@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <000301c9013f$c6f8eea0$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] regarding lc-pcn features and consensus Thread-Index: Acj30xA3vhH+zhrERBS741ha0TCfJgABTgdgAljd/RAAAbLnQA== From: To: , , X-OriginalArrivalTime: 18 Aug 2008 15:04:14.0851 (UTC) FILETIME=[ADE28530:01C90143] Cc: Lars.Westberg@ericsson.com, Attila.Bader@ericsson.com Subject: Re: [PCN] regarding lc-pcn features and 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 { > - marking every Nth pkt is not supported. { Thus you mean that the option of marking every Nth pkt is precluded. { Without this option the LC-PCN algorithm will become very slow { in situations of high overloads that are above the capacity of a link. { { Therefore, we would very much appreciate if an experimental extesion of { this { feature will be allowed { to support the option that marked excess rate represents { high levels of { excess rate). This can be implemented by marking every { N-th packet (or { byte)instead { of marking each packet (or byte). N is a constant that is { equal or { higher { than 1. Georgios We had quite some discussion between a couple of IETFs several months ago, which led to the draft http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt This came out of the desire to achieve marked flow termination. The original suggestion was to do this by marking every Nth pkt. However, it was realised that this could be achieved by marking every pkt, but then altering the edge behaviour (every time it sees a pkt, it terminates that flow with a probability of 1/N). This was shown by simulation (see i-d) and analysis (see email I sent to list) to achieve exactly the same behaviour. Hence marking every Nth pkt was shown to be an unnecessary complication - it's clearly a good thing to eliminate (all other things being equal) since it adds complexity to the marking algorithm and is another parameter to configure. I believe this gives you the system behaviour you want. Best wishes phil _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Aug 18 08:25:03 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA523A6A61; Mon, 18 Aug 2008 08:25: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 CFEEB3A68E8 for ; Mon, 18 Aug 2008 08:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 El28JA0jH3KU for ; Mon, 18 Aug 2008 08:25:02 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id DA84A3A6A71 for ; Mon, 18 Aug 2008 08:25:01 -0700 (PDT) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.64]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Aug 2008 16:25:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 18 Aug 2008 16:25:06 +0100 Message-ID: In-Reply-To: <1217940002.10059.8.camel@tachyon> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] **DRAFT** PCN IETF72 Meeting Minutes Thread-Index: Acj2+HbEllLqwB07SxWSs/qRK57sEQKTeSDQ From: To: , X-OriginalArrivalTime: 18 Aug 2008 15:25:06.0713 (UTC) FILETIME=[980D8090:01C90146] Subject: Re: [PCN] **DRAFT** PCN IETF72 Meeting Minutes 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 Sorry for delay in responding (been on vacation and training). I may be being blind but I can't find any mention in the minutes of the consensus question on adopting my baseline encoding draft as WG item (which was definitely asked and has already been posted to the general list). Toby > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Steven Blake > Sent: 05 August 2008 13:40 > To: pcn > Subject: [PCN] **DRAFT** PCN IETF72 Meeting Minutes > > Please review the attached draft meeting minutes from Dublin and send > comments/corrections to the list within the next week. > > Thanks to Peter McCann and Tom Taylor for taking such > detailed minutes! > > > Regards, > > // Steve > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Aug 18 11:40:20 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B17C93A6D73; Mon, 18 Aug 2008 11:40: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 EB5573A6D7A for ; Mon, 18 Aug 2008 11:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrY5uhyB2vAw for ; Mon, 18 Aug 2008 11:40:18 -0700 (PDT) Received: from smtp127.rog.mail.re2.yahoo.com (smtp127.rog.mail.re2.yahoo.com [206.190.53.32]) by core3.amsl.com (Postfix) with SMTP id EF8973A6D73 for ; Mon, 18 Aug 2008 11:40:17 -0700 (PDT) Received: (qmail 6474 invoked from network); 18 Aug 2008 18:40:24 -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:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ycRrphbvg9H9fXqcerqN6URhTCvUFgbDumStkfjCUXgI2Y5KF8DsZjzd7VBbqKuMHc50cQVBf0Eg0idYIby1cVFhsbNMkC5KTN1pBw6USY4VTdEJqVinbPnY7WQGBeiY9BBpJ1FLLIY1a+Z7qCInTxmUdB42V5TuI12yh+uNTQA= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@rogers.com@72.140.46.24 with plain) by smtp127.rog.mail.re2.yahoo.com with SMTP; 18 Aug 2008 18:40:24 -0000 X-YMail-OSG: V0eGBBUVM1m1aw2rCSXZYMN00Q81EHl11T0_ZEA9mdX.6n93ZVHJaRKALchVFwFDMg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48A9C219.7080501@rogers.com> Date: Mon, 18 Aug 2008 14:40:25 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: toby.moncaster@bt.com References: In-Reply-To: Cc: pcn@ietf.org Subject: Re: [PCN] **DRAFT** PCN IETF72 Meeting Minutes 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Guess I have to agree. We were all pretty ready to give a positive vote, I think, but the question kept getting deferred and buried. Anyway, if we confirm it here on the list, that's what counts. toby.moncaster@bt.com wrote: > Sorry for delay in responding (been on vacation and training). > > I may be being blind but I can't find any mention in the minutes of the > consensus question on adopting my baseline encoding draft as WG item > (which was definitely asked and has already been posted to the general > list). > > Toby > >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On >> Behalf Of Steven Blake >> Sent: 05 August 2008 13:40 >> To: pcn >> Subject: [PCN] **DRAFT** PCN IETF72 Meeting Minutes >> >> Please review the attached draft meeting minutes from Dublin and send >> comments/corrections to the list within the next week. >> >> Thanks to Peter McCann and Tom Taylor for taking such >> detailed minutes! >> >> >> Regards, >> >> // Steve >> > _______________________________________________ > 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 Aug 18 20:24:30 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 031633A6A96; Mon, 18 Aug 2008 20:24: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 AF6363A6A8E for ; Mon, 18 Aug 2008 20:24:28 -0700 (PDT) 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=1.207, 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 6PRnE0PbBJjC for ; Mon, 18 Aug 2008 20:24:27 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id D25F63A6A96 for ; Mon, 18 Aug 2008 20:24:27 -0700 (PDT) Received: from cpe-071-077-048-179.nc.res.rr.com ([71.77.48.179]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1KVHpe-0006he-SM; Mon, 18 Aug 2008 23:24:31 -0400 From: Steven Blake To: toby.moncaster@bt.com In-Reply-To: References: Date: Mon, 18 Aug 2008 23:24:33 -0400 Message-Id: <1219116273.5586.4.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Cc: pcn@ietf.org Subject: Re: [PCN] **DRAFT** PCN IETF72 Meeting Minutes 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-08-18 at 16:25 +0100, toby.moncaster@bt.com wrote: > Sorry for delay in responding (been on vacation and training). > > I may be being blind but I can't find any mention in the minutes of the > consensus question on adopting my baseline encoding draft as WG item > (which was definitely asked and has already been posted to the general > list). Yes, I believe that this is my mistake. Toward the end of the meeting minutes for Ruediger Geib's presentation, there is the following text: > Steve Blake: 2 questions:/ > > Q1: How many people think we should adopt > draft-eardley-pcn-marking-behavior-01 as WG document? > > 12 yes, 0 no. I believe that this should say draft-moncaster-pcn-baseline-encoding-02. I will fix it in the official minutes. Good catch! // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Aug 19 00:28:44 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AED393A689E; Tue, 19 Aug 2008 00:28: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 3CCA63A689C for ; Tue, 19 Aug 2008 00:28:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.797 X-Spam-Level: X-Spam-Status: No, score=-2.797 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, J_CHICKENPOX_91=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 KcPuxquxnFou for ; Tue, 19 Aug 2008 00:28:42 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 264643A689E for ; Tue, 19 Aug 2008 00:28:41 -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); Tue, 19 Aug 2008 08:28:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Aug 2008 08:28:29 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC0329F953@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <1219116273.5586.4.camel@tachyon> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] **DRAFT** PCN IETF72 Meeting Minutes Thread-Index: AckBqx7/TPYDAcCgSe2z64EGXRj5XgAIZ75A From: To: , X-OriginalArrivalTime: 19 Aug 2008 07:28:29.0880 (UTC) FILETIME=[2D6CD380:01C901CD] Cc: pcn@ietf.org Subject: Re: [PCN] **DRAFT** PCN IETF72 Meeting Minutes 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 Steve Just wanted to make sure the minutes say moncaster-baseline-encoding is in addition to eardley-marking (not instead of) - there was a similar size vote in favour of both these drafts becoming WG docs. phil { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { Steven Blake { Sent: 19 August 2008 04:25 { To: Moncaster,T,Toby,CXR9 R { Cc: pcn@ietf.org { Subject: Re: [PCN] **DRAFT** PCN IETF72 Meeting Minutes { { On Mon, 2008-08-18 at 16:25 +0100, toby.moncaster@bt.com wrote: { { > Sorry for delay in responding (been on vacation and training). { > { > I may be being blind but I can't find any mention in the minutes of the { > consensus question on adopting my baseline encoding draft as WG item { > (which was definitely asked and has already been posted to the general { > list). { { Yes, I believe that this is my mistake. { { Toward the end of the meeting minutes for Ruediger Geib's presentation, { there is the following text: { { > Steve Blake: 2 questions:/ { > { > Q1: How many people think we should adopt { > draft-eardley-pcn-marking-behavior-01 as WG document? { > { > 12 yes, 0 no. { { I believe that this should say draft-moncaster-pcn-baseline-encoding-02. { I will fix it in the official minutes. { { Good catch! { { // Steve { { _______________________________________________ { 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 Aug 19 01:12:08 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 452A43A6AD6; Tue, 19 Aug 2008 01:12:08 -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 BB6543A6900 for ; Tue, 19 Aug 2008 01:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.903 X-Spam-Level: ** X-Spam-Status: No, score=2.903 tagged_above=-999 required=5 tests=[AWL=0.393, BAYES_40=-0.185, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_47=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdOrdBmZyO2O for ; Tue, 19 Aug 2008 01:12:05 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id EA9FA28C164 for ; Tue, 19 Aug 2008 01:11: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 m7J8BAX1014839; Tue, 19 Aug 2008 10:11:15 +0200 (MEST) From: "Georgios Karagiannis" To: , , References: <000301c9013f$c6f8eea0$810c5982@dynamic.ewi.utwente.nl> <4A916DBC72536E419A0BD955EDECEDEC0329F951@E03MVB1-UKBR.domain1.systemhost.net> Date: Tue, 19 Aug 2008 10:11:06 +0200 Message-ID: <000001c901d3$25357f40$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC0329F951@E03MVB1-UKBR.domain1.systemhost.net> Thread-Index: Acj30xA3vhH+zhrERBS741ha0TCfJgABTgdgAljd/RAAAbLnQAAj5JMg 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, 19 Aug 2008 10:11:15 +0200 (MEST) Cc: Lars.Westberg@ericsson.com, Attila.Bader@ericsson.com Subject: Re: [PCN] regarding lc-pcn features and 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 Hi Phil At the time I have checked this draft and I have also followed the presentation given by Michael during the IETF 71. From the discussions that we have had then, I did realise that the algorithm provided in http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt cannot achieve the same behaviour as the algorithm that is marking every N-th packet when the percentage of overload in an interior node is higher than 100% of the capacity of the link. Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: maandag 18 augustus 2008 17:04 > To: karagian@cs.utwente.nl; slblake@petri-meat.com; pcn@ietf.org > Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com > Subject: RE: [PCN] regarding lc-pcn features and consensus > > { > - marking every Nth pkt is not supported. > { Thus you mean that the option of marking every Nth pkt is precluded. > { Without this option the LC-PCN algorithm will become very > slow { in situations of high overloads that are above the > capacity of a link. > { > { Therefore, we would very much appreciate if an experimental > extesion of { this { feature will be allowed { to support the > option that marked excess rate represents { high levels of { > excess rate). This can be implemented by marking every { > N-th packet (or { byte)instead { of marking each packet (or > byte). N is a constant that is { equal or { higher { than 1. > > Georgios > > We had quite some discussion between a couple of IETFs > several months ago, which led to the draft > http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt > > This came out of the desire to achieve marked flow > termination. The original suggestion was to do this by > marking every Nth pkt. However, it was realised that this > could be achieved by marking every pkt, but then altering the > edge behaviour (every time it sees a pkt, it terminates that > flow with a probability of 1/N). This was shown by simulation (see > i-d) and analysis (see email I sent to list) to achieve > exactly the same behaviour. > Hence marking every Nth pkt was shown to be an unnecessary > complication > - it's clearly a good thing to eliminate (all other things > being equal) since it adds complexity to the marking > algorithm and is another parameter to configure. > > I believe this gives you the system behaviour you want. > > Best wishes > phil > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Aug 19 01:55:59 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 182D03A680A; Tue, 19 Aug 2008 01:55:59 -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 65B193A680A for ; Tue, 19 Aug 2008 01:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, 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 lAPVUWODkQy3 for ; Tue, 19 Aug 2008 01:55:57 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id F0C6C3A67D1 for ; Tue, 19 Aug 2008 01:55:56 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Aug 2008 09:55:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Aug 2008 09:55:05 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC0329F955@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <000001c901d3$25357f40$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] regarding lc-pcn features and consensus Thread-Index: Acj30xA3vhH+zhrERBS741ha0TCfJgABTgdgAljd/RAAAbLnQAAj5JMgAAGHpwA= From: To: , , X-OriginalArrivalTime: 19 Aug 2008 08:55:06.0125 (UTC) FILETIME=[46A0E3D0:01C901D9] Cc: Lars.Westberg@ericsson.com, Attila.Bader@ericsson.com Subject: Re: [PCN] regarding lc-pcn features and 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 Hi Georgios i think what you're referring to (please correct) is that if the interior node is massively overloaded, then you're saying that the I-D's approach might terminate slower, essentially because of a saturation effect (you can't have more than 100% marked pkts) - whereas this saturation effect doesn't appear until (much) higher loads with the 'marking every Nth pkt' algorithm. Sure, at first glance I can believe there's a theoretical saturation effect. Question is whether it's important in practice. Please can you point me to the earlier comparative analysis / simulations that shows when it starts becoming important (eg link to the right mail - sorry my memory for old discussions is often bad!). Thanks Phil/ { -----Original Message----- { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] { Sent: 19 August 2008 09:11 { To: Eardley,PL,Philip,CXR9 R; slblake@petri-meat.com; pcn@ietf.org { Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { Subject: RE: [PCN] regarding lc-pcn features and consensus { { Hi Phil { { At the time I have checked this draft and I have also followed the { presentation given by Michael during the { IETF 71. From the discussions that we have had then, I did realise that { the { algorithm provided in { http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt { cannot achieve the same behaviour as the algorithm that is marking every { N-th packet { when the percentage of overload in an interior node is higher than 100% of { the capacity of the link. { { Best regards, { Georgios { { { { { { > -----Original Message----- { > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] { > Sent: maandag 18 augustus 2008 17:04 { > To: karagian@cs.utwente.nl; slblake@petri-meat.com; pcn@ietf.org { > Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > Subject: RE: [PCN] regarding lc-pcn features and consensus { > { > { > - marking every Nth pkt is not supported. { > { Thus you mean that the option of marking every Nth pkt is precluded. { > { Without this option the LC-PCN algorithm will become very { > slow { in situations of high overloads that are above the { > capacity of a link. { > { { > { Therefore, we would very much appreciate if an experimental { > extesion of { this { feature will be allowed { to support the { > option that marked excess rate represents { high levels of { { > excess rate). This can be implemented by marking every { { > N-th packet (or { byte)instead { of marking each packet (or { > byte). N is a constant that is { equal or { higher { than 1. { > { > Georgios { > { > We had quite some discussion between a couple of IETFs { > several months ago, which led to the draft { > http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt { > { > This came out of the desire to achieve marked flow { > termination. The original suggestion was to do this by { > marking every Nth pkt. However, it was realised that this { > could be achieved by marking every pkt, but then altering the { > edge behaviour (every time it sees a pkt, it terminates that { > flow with a probability of 1/N). This was shown by simulation (see { > i-d) and analysis (see email I sent to list) to achieve { > exactly the same behaviour. { > Hence marking every Nth pkt was shown to be an unnecessary { > complication { > - it's clearly a good thing to eliminate (all other things { > being equal) since it adds complexity to the marking { > algorithm and is another parameter to configure. { > { > I believe this gives you the system behaviour you want. { > { > Best wishes { > phil { > { _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Aug 19 02:08:58 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 232E13A6880; Tue, 19 Aug 2008 02:08: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 5E0B03A6880 for ; Tue, 19 Aug 2008 02:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.81 X-Spam-Level: X-Spam-Status: No, score=0.81 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35, J_CHICKENPOX_47=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7Q21IazmnVV for ; Tue, 19 Aug 2008 02:08:51 -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 5CA613A682F for ; Tue, 19 Aug 2008 02:08:50 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 76CE9198DFE; Tue, 19 Aug 2008 11:08:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 69F5D198DF6; Tue, 19 Aug 2008 11:08:57 +0200 (CEST) Received: from [92.228.79.140] (g228079140.adsl.alicedsl.de [92.228.79.140]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 0A47FA0637; Tue, 19 Aug 2008 11:08:57 +0200 (CEST) Message-ID: <48AA8D58.7030800@informatik.uni-wuerzburg.de> Date: Tue, 19 Aug 2008 11:07:36 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: philip.eardley@bt.com References: <4A916DBC72536E419A0BD955EDECEDEC0329F955@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC0329F955@E03MVB1-UKBR.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org, Attila.Bader@ericsson.com, Lars.Westberg@ericsson.com Subject: Re: [PCN] regarding lc-pcn features and 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi, we've done simulations on marked flow termination (MFT) with packet loss and reported them in IV.D.4 of http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/Menth08-PCN-MFT.pdf They show that packet loss with MFT is no problem at all as long as marked packets are not preferentially dropped. PCN traffic rate: 16 Mbit/s, bottleneck capacity 9 Mbit/s with supportable rate 8 Mbit/s. This is a loss rate of 43.75%. Experiments with even higher loss rates are not covered in the paper because this seemed not very realistic to us, but experiments have shown that there are no problems either. It takes a bit longer, but it works. Regards, Michael philip.eardley@bt.com wrote: > Hi Georgios > > i think what you're referring to (please correct) is that if the > interior node is massively overloaded, then you're saying that the I-D's > approach might terminate slower, essentially because of a saturation > effect (you can't have more than 100% marked pkts) - whereas this > saturation effect doesn't appear until (much) higher loads with the > 'marking every Nth pkt' algorithm. > > Sure, at first glance I can believe there's a theoretical saturation > effect. Question is whether it's important in practice. Please can you > point me to the earlier comparative analysis / simulations that shows > when it starts becoming important (eg link to the right mail - sorry my > memory for old discussions is often bad!). > > Thanks > Phil/ > > { -----Original Message----- > { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > { Sent: 19 August 2008 09:11 > { To: Eardley,PL,Philip,CXR9 R; slblake@petri-meat.com; pcn@ietf.org > { Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com > { Subject: RE: [PCN] regarding lc-pcn features and consensus > { > { Hi Phil > { > { At the time I have checked this draft and I have also followed the > { presentation given by Michael during the > { IETF 71. From the discussions that we have had then, I did realise > that > { the > { algorithm provided in > { http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt > { cannot achieve the same behaviour as the algorithm that is marking > every > { N-th packet > { when the percentage of overload in an interior node is higher than > 100% of > { the capacity of the link. > { > { Best regards, > { Georgios > { > { > { > { > { > { > -----Original Message----- > { > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > { > Sent: maandag 18 augustus 2008 17:04 > { > To: karagian@cs.utwente.nl; slblake@petri-meat.com; pcn@ietf.org > { > Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com > { > Subject: RE: [PCN] regarding lc-pcn features and consensus > { > > { > { > - marking every Nth pkt is not supported. > { > { Thus you mean that the option of marking every Nth pkt is > precluded. > { > { Without this option the LC-PCN algorithm will become very > { > slow { in situations of high overloads that are above the > { > capacity of a link. > { > { > { > { Therefore, we would very much appreciate if an experimental > { > extesion of { this { feature will be allowed { to support the > { > option that marked excess rate represents { high levels of { > { > excess rate). This can be implemented by marking every { > { > N-th packet (or { byte)instead { of marking each packet (or > { > byte). N is a constant that is { equal or { higher { than 1. > { > > { > Georgios > { > > { > We had quite some discussion between a couple of IETFs > { > several months ago, which led to the draft > { > http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt > { > > { > This came out of the desire to achieve marked flow > { > termination. The original suggestion was to do this by > { > marking every Nth pkt. However, it was realised that this > { > could be achieved by marking every pkt, but then altering the > { > edge behaviour (every time it sees a pkt, it terminates that > { > flow with a probability of 1/N). This was shown by simulation (see > { > i-d) and analysis (see email I sent to list) to achieve > { > exactly the same behaviour. > { > Hence marking every Nth pkt was shown to be an unnecessary > { > complication > { > - it's clearly a good thing to eliminate (all other things > { > being equal) since it adds complexity to the marking > { > algorithm and is another parameter to configure. > { > > { > I believe this gives you the system behaviour you want. > { > > { > Best wishes > { > 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 Tue Aug 19 02:34:04 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC7863A68D3; Tue, 19 Aug 2008 02:34: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 6257A3A68D3 for ; Tue, 19 Aug 2008 02:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.099 X-Spam-Level: *** X-Spam-Status: No, score=3.099 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_47=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePnwu3+htUid for ; Tue, 19 Aug 2008 02:34:03 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id DFCBE3A67D1 for ; Tue, 19 Aug 2008 02:34: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 m7J9Y2If029804; Tue, 19 Aug 2008 11:34:06 +0200 (MEST) From: "Georgios Karagiannis" To: , , References: <000001c901d3$25357f40$810c5982@dynamic.ewi.utwente.nl> <4A916DBC72536E419A0BD955EDECEDEC0329F955@E03MVB1-UKBR.domain1.systemhost.net> Date: Tue, 19 Aug 2008 11:33:55 +0200 Message-ID: <001601c901de$b6e57bb0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC0329F955@E03MVB1-UKBR.domain1.systemhost.net> Thread-Index: Acj30xA3vhH+zhrERBS741ha0TCfJgABTgdgAljd/RAAAbLnQAAj5JMgAAGHpwAAAXORYA== 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, 19 Aug 2008 11:34:07 +0200 (MEST) Cc: Lars.Westberg@ericsson.com, Attila.Bader@ericsson.com Subject: Re: [PCN] regarding lc-pcn features and 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 Hi Phil Yes I am refering to the situation that you are mentioning. Please note that in severe congestion situations the overload can easily and most of the times go above 100% of the capacity of the link. The mentioned issues were pointed out during Michael presentation (IETF 71) by Anna and by me. I am not sure if they were included in the PCN minutes of IETF 71. Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: dinsdag 19 augustus 2008 10:55 > To: karagian@cs.utwente.nl; slblake@petri-meat.com; pcn@ietf.org > Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com > Subject: RE: [PCN] regarding lc-pcn features and consensus > > Hi Georgios > > i think what you're referring to (please correct) is that if > the interior node is massively overloaded, then you're saying > that the I-D's approach might terminate slower, essentially > because of a saturation effect (you can't have more than 100% > marked pkts) - whereas this saturation effect doesn't appear > until (much) higher loads with the 'marking every Nth pkt' algorithm. > > Sure, at first glance I can believe there's a theoretical > saturation effect. Question is whether it's important in > practice. Please can you point me to the earlier comparative > analysis / simulations that shows when it starts becoming > important (eg link to the right mail - sorry my memory for > old discussions is often bad!). > > Thanks > Phil/ > > { -----Original Message----- > { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > { Sent: 19 August 2008 09:11 { To: Eardley,PL,Philip,CXR9 R; > slblake@petri-meat.com; pcn@ietf.org { Cc: > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > Subject: RE: [PCN] regarding lc-pcn features and consensus { > { Hi Phil { { At the time I have checked this draft and I > have also followed the { presentation given by Michael during > the { IETF 71. From the discussions that we have had then, I > did realise that { the { algorithm provided in { > http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt > { cannot achieve the same behaviour as the algorithm that is > marking every { N-th packet { when the percentage of overload > in an interior node is higher than 100% of { the capacity of the link. > { > { Best regards, > { Georgios > { > { > { > { > { > { > -----Original Message----- > { > From: philip.eardley@bt.com > [mailto:philip.eardley@bt.com] { > Sent: maandag 18 augustus > 2008 17:04 { > To: karagian@cs.utwente.nl; > slblake@petri-meat.com; pcn@ietf.org { > Cc: > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > > Subject: RE: [PCN] regarding lc-pcn features and consensus { > > { > { > - marking every Nth pkt is not supported. > { > { Thus you mean that the option of marking every Nth pkt > is precluded. > { > { Without this option the LC-PCN algorithm will become > very { > slow { in situations of high overloads that are > above the { > capacity of a link. > { > { > { > { Therefore, we would very much appreciate if an > experimental { > extesion of { this { feature will be allowed > { to support the { > option that marked excess rate > represents { high levels of { { > excess rate). This can be > implemented by marking every { { > N-th packet (or { > byte)instead { of marking each packet (or { > byte). N is a > constant that is { equal or { higher { than 1. > { > > { > Georgios > { > > { > We had quite some discussion between a couple of IETFs { > > several months ago, which led to the draft { > > http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt > { > > { > This came out of the desire to achieve marked flow { > > termination. The original suggestion was to do this by { > > marking every Nth pkt. However, it was realised that this { > > could be achieved by marking every pkt, but then altering the > { > edge behaviour (every time it sees a pkt, it terminates > that { > flow with a probability of 1/N). This was shown by > simulation (see { > i-d) and analysis (see email I sent to > list) to achieve { > exactly the same behaviour. > { > Hence marking every Nth pkt was shown to be an > unnecessary { > complication { > - it's clearly a good thing > to eliminate (all other things { > being equal) since it adds > complexity to the marking { > algorithm and is another > parameter to configure. > { > > { > I believe this gives you the system behaviour you want. > { > > { > Best wishes > { > phil > { > > { > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Aug 19 02:46:42 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5BAA3A6A03; Tue, 19 Aug 2008 02:46: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 6C8B53A6A03 for ; Tue, 19 Aug 2008 02:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.165 X-Spam-Level: *** X-Spam-Status: No, score=3.165 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_47=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08Dncd1oIH0F for ; Tue, 19 Aug 2008 02:46: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 17F173A696F for ; Tue, 19 Aug 2008 02:46: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 m7J9jrdc002377; Tue, 19 Aug 2008 11:45:58 +0200 (MEST) From: "Georgios Karagiannis" To: , References: <4A916DBC72536E419A0BD955EDECEDEC0329F955@E03MVB1-UKBR.domain1.systemhost.net> <48AA8D58.7030800@informatik.uni-wuerzburg.de> Date: Tue, 19 Aug 2008 11:45:47 +0200 Message-ID: <001701c901e0$5fa3eb50$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <48AA8D58.7030800@informatik.uni-wuerzburg.de> Thread-Index: AckB34xNlwMVcGUgQ/6WO/T2ywOXVwAAC6mw 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, 19 Aug 2008 11:45:59 +0200 (MEST) Cc: pcn@ietf.org, Attila.Bader@ericsson.com, Lars.Westberg@ericsson.com Subject: Re: [PCN] regarding lc-pcn features and 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 Hi Michael The pointed issue was related to fact that the recovery time it will be too high (more than 1 - 2 seconds) for the situation that very high losses occur (more than 100% of the capacity of the link). Best regards, Georgios > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: dinsdag 19 augustus 2008 11:08 > To: philip.eardley@bt.com > Cc: karagian@cs.utwente.nl; slblake@petri-meat.com; > pcn@ietf.org; Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com > Subject: Re: [PCN] regarding lc-pcn features and consensus > > Hi, > > we've done simulations on marked flow termination (MFT) with > packet loss and reported them in IV.D.4 of > http://www3.informatik.uni-wuerzburg.de/staff/menth/Publicatio ns/Menth08-PCN-MFT.pdf > They show that packet loss with MFT is no problem at all as > long as marked packets are not preferentially dropped. > PCN traffic rate: 16 Mbit/s, bottleneck capacity 9 Mbit/s > with supportable rate 8 Mbit/s. This is a loss rate of 43.75%. > Experiments with even higher loss rates are not covered in > the paper because this seemed not very realistic to us, but > experiments have shown that there are no problems either. It > takes a bit longer, but it works. > > Regards, > > Michael > > > philip.eardley@bt.com wrote: > > Hi Georgios > > > > i think what you're referring to (please correct) is that if the > > interior node is massively overloaded, then you're saying that the > > I-D's approach might terminate slower, essentially because of a > > saturation effect (you can't have more than 100% marked pkts) - > > whereas this saturation effect doesn't appear until (much) higher > > loads with the 'marking every Nth pkt' algorithm. > > > > Sure, at first glance I can believe there's a theoretical > saturation > > effect. Question is whether it's important in practice. > Please can you > > point me to the earlier comparative analysis / simulations > that shows > > when it starts becoming important (eg link to the right > mail - sorry > > my memory for old discussions is often bad!). > > > > Thanks > > Phil/ > > > > { -----Original Message----- > > { From: Georgios Karagiannis > [mailto:karagian@cs.utwente.nl] { Sent: > > 19 August 2008 09:11 { To: Eardley,PL,Philip,CXR9 R; > > slblake@petri-meat.com; pcn@ietf.org { Cc: > Lars.Westberg@ericsson.com; > > Attila.Bader@ericsson.com { Subject: RE: [PCN] regarding lc-pcn > > features and consensus { { Hi Phil { { At the time I have > checked this > > draft and I have also followed the { presentation given by Michael > > during the { IETF 71. From the discussions that we have had then, I > > did realise that { the { algorithm provided in { > > http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt > > { cannot achieve the same behaviour as the algorithm that > is marking > > every { N-th packet { when the percentage of overload in an > interior > > node is higher than 100% of { the capacity of the link. > > { > > { Best regards, > > { Georgios > > { > > { > > { > > { > > { > > { > -----Original Message----- > > { > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] { > > > Sent: maandag 18 augustus 2008 17:04 { > To: > karagian@cs.utwente.nl; > > slblake@petri-meat.com; pcn@ietf.org { > Cc: > > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > > Subject: RE: > > [PCN] regarding lc-pcn features and consensus { > { > { > - marking > > every Nth pkt is not supported. > > { > { Thus you mean that the option of marking every Nth pkt is > > precluded. > > { > { Without this option the LC-PCN algorithm will become very { > > > slow { in situations of high overloads that are above the { > capacity > > of a link. > > { > { > > { > { Therefore, we would very much appreciate if an > experimental { > > > extesion of { this { feature will be allowed { to support the { > > > option that marked excess rate represents { high levels of { { > > > excess rate). This can be implemented by marking every { { > N-th > > packet (or { byte)instead { of marking each packet (or { > > byte). N is > > a constant that is { equal or { higher { than 1. > > { > > > { > Georgios > > { > > > { > We had quite some discussion between a couple of IETFs > { > several > > months ago, which led to the draft { > > > http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt > > { > > > { > This came out of the desire to achieve marked flow { > > > termination. The original suggestion was to do this by { > marking > > every Nth pkt. However, it was realised that this { > could be > > achieved by marking every pkt, but then altering the { > edge > > behaviour (every time it sees a pkt, it terminates that { > > flow with > > a probability of 1/N). This was shown by simulation (see { > > i-d) and > > analysis (see email I sent to list) to achieve { > exactly the same > > behaviour. > > { > Hence marking every Nth pkt was shown to be an unnecessary { > > > complication { > - it's clearly a good thing to eliminate > (all other > > things { > being equal) since it adds complexity to the marking { > > > algorithm and is another parameter to configure. > > { > > > { > I believe this gives you the system behaviour you want. > > { > > > { > Best wishes > > { > 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 Tue Aug 19 02:57:10 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBB9A3A6A03; Tue, 19 Aug 2008 02:57:10 -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 018E83A6B12 for ; Tue, 19 Aug 2008 02:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.81 X-Spam-Level: X-Spam-Status: No, score=0.81 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_DE=0.35, J_CHICKENPOX_47=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F+OzfjudNQL9 for ; Tue, 19 Aug 2008 02:57: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 384BF3A69B6 for ; Tue, 19 Aug 2008 02:57:07 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 92BF0A05EF; Tue, 19 Aug 2008 11:57:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 86AD5A05EE; Tue, 19 Aug 2008 11:57:14 +0200 (CEST) Received: from [92.228.79.140] (g228079140.adsl.alicedsl.de [92.228.79.140]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 16A1F198DAD; Tue, 19 Aug 2008 11:57:14 +0200 (CEST) Message-ID: <48AA98A8.8010703@informatik.uni-wuerzburg.de> Date: Tue, 19 Aug 2008 11:55:52 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Georgios Karagiannis References: <4A916DBC72536E419A0BD955EDECEDEC0329F955@E03MVB1-UKBR.domain1.systemhost.net> <48AA8D58.7030800@informatik.uni-wuerzburg.de> <001701c901e0$5fa3eb50$810c5982@dynamic.ewi.utwente.nl> In-Reply-To: <001701c901e0$5fa3eb50$810c5982@dynamic.ewi.utwente.nl> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org, Attila.Bader@ericsson.com, Lars.Westberg@ericsson.com Subject: Re: [PCN] regarding lc-pcn features and 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Georgios, traffic loss can never go beyond 100%. In our setting, approximatley half of the traffic was lost, i.e. PCN traffic was twice the line rate. It works fine and terminates in spite of extreme packet loss within 1.5 s. This comprises the time meters and markers require to detect SR-overload. Regards, Michael Georgios Karagiannis wrote: > Hi Michael > > The pointed issue was related to fact that the recovery time it will be too > high (more than 1 - 2 seconds) > for the situation that very high losses occur (more than 100% of the > capacity of the link). > > Best regards, > Georgios > > > > > >> -----Original Message----- >> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >> Sent: dinsdag 19 augustus 2008 11:08 >> To: philip.eardley@bt.com >> Cc: karagian@cs.utwente.nl; slblake@petri-meat.com; >> pcn@ietf.org; Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com >> Subject: Re: [PCN] regarding lc-pcn features and consensus >> >> Hi, >> >> we've done simulations on marked flow termination (MFT) with >> packet loss and reported them in IV.D.4 of >> http://www3.informatik.uni-wuerzburg.de/staff/menth/Publicatio >> > ns/Menth08-PCN-MFT.pdf > >> They show that packet loss with MFT is no problem at all as >> long as marked packets are not preferentially dropped. >> PCN traffic rate: 16 Mbit/s, bottleneck capacity 9 Mbit/s >> with supportable rate 8 Mbit/s. This is a loss rate of 43.75%. >> Experiments with even higher loss rates are not covered in >> the paper because this seemed not very realistic to us, but >> experiments have shown that there are no problems either. It >> takes a bit longer, but it works. >> >> Regards, >> >> Michael >> >> >> philip.eardley@bt.com wrote: >> >>> Hi Georgios >>> >>> i think what you're referring to (please correct) is that if the >>> interior node is massively overloaded, then you're saying that the >>> I-D's approach might terminate slower, essentially because of a >>> saturation effect (you can't have more than 100% marked pkts) - >>> whereas this saturation effect doesn't appear until (much) higher >>> loads with the 'marking every Nth pkt' algorithm. >>> >>> Sure, at first glance I can believe there's a theoretical >>> >> saturation >> >>> effect. Question is whether it's important in practice. >>> >> Please can you >> >>> point me to the earlier comparative analysis / simulations >>> >> that shows >> >>> when it starts becoming important (eg link to the right >>> >> mail - sorry >> >>> my memory for old discussions is often bad!). >>> >>> Thanks >>> Phil/ >>> >>> { -----Original Message----- >>> { From: Georgios Karagiannis >>> >> [mailto:karagian@cs.utwente.nl] { Sent: >> >>> 19 August 2008 09:11 { To: Eardley,PL,Philip,CXR9 R; >>> slblake@petri-meat.com; pcn@ietf.org { Cc: >>> >> Lars.Westberg@ericsson.com; >> >>> Attila.Bader@ericsson.com { Subject: RE: [PCN] regarding lc-pcn >>> features and consensus { { Hi Phil { { At the time I have >>> >> checked this >> >>> draft and I have also followed the { presentation given by Michael >>> during the { IETF 71. From the discussions that we have had then, I >>> did realise that { the { algorithm provided in { >>> http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt >>> { cannot achieve the same behaviour as the algorithm that >>> >> is marking >> >>> every { N-th packet { when the percentage of overload in an >>> >> interior >> >>> node is higher than 100% of { the capacity of the link. >>> { >>> { Best regards, >>> { Georgios >>> { >>> { >>> { >>> { >>> { >>> { > -----Original Message----- >>> { > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] { > >>> Sent: maandag 18 augustus 2008 17:04 { > To: >>> >> karagian@cs.utwente.nl; >> >>> slblake@petri-meat.com; pcn@ietf.org { > Cc: >>> Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > >>> >> Subject: RE: >> >>> [PCN] regarding lc-pcn features and consensus { > { > { > - marking >>> every Nth pkt is not supported. >>> { > { Thus you mean that the option of marking every Nth pkt is >>> precluded. >>> { > { Without this option the LC-PCN algorithm will become very { > >>> slow { in situations of high overloads that are above the { >>> >> capacity >> >>> of a link. >>> { > { >>> { > { Therefore, we would very much appreciate if an >>> >> experimental { > >> >>> extesion of { this { feature will be allowed { to support the { > >>> option that marked excess rate represents { high levels of { { > >>> excess rate). This can be implemented by marking every { { > N-th >>> packet (or { byte)instead { of marking each packet (or { > >>> >> byte). N is >> >>> a constant that is { equal or { higher { than 1. >>> { > >>> { > Georgios >>> { > >>> { > We had quite some discussion between a couple of IETFs >>> >> { > several >> >>> months ago, which led to the draft { > >>> http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt >>> { > >>> { > This came out of the desire to achieve marked flow { > >>> termination. The original suggestion was to do this by { > marking >>> every Nth pkt. However, it was realised that this { > could be >>> achieved by marking every pkt, but then altering the { > edge >>> behaviour (every time it sees a pkt, it terminates that { > >>> >> flow with >> >>> a probability of 1/N). This was shown by simulation (see { >>> i-d) and >>> analysis (see email I sent to list) to achieve { > exactly the same >>> behaviour. >>> { > Hence marking every Nth pkt was shown to be an unnecessary { > >>> complication { > - it's clearly a good thing to eliminate >>> >> (all other >> >>> things { > being equal) since it adds complexity to the marking { > >>> algorithm and is another parameter to configure. >>> { > >>> { > I believe this gives you the system behaviour you want. >>> { > >>> { > Best wishes >>> { > 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 Tue Aug 19 03:03:07 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B55923A6A4F; Tue, 19 Aug 2008 03:03: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 BCE4C3A6AA9 for ; Tue, 19 Aug 2008 03:03:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.198 X-Spam-Level: *** X-Spam-Status: No, score=3.198 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_47=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9j1VbvlEEjfz for ; Tue, 19 Aug 2008 03: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 2130C3A6882 for ; Tue, 19 Aug 2008 03: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 m7JA2st7005726; Tue, 19 Aug 2008 12:02:57 +0200 (MEST) From: "Georgios Karagiannis" To: References: <4A916DBC72536E419A0BD955EDECEDEC0329F955@E03MVB1-UKBR.domain1.systemhost.net> <48AA8D58.7030800@informatik.uni-wuerzburg.de> <001701c901e0$5fa3eb50$810c5982@dynamic.ewi.utwente.nl> <48AA98A8.8010703@informatik.uni-wuerzburg.de> Date: Tue, 19 Aug 2008 12:02:48 +0200 Message-ID: <001801c901e2$bf62a700$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <48AA98A8.8010703@informatik.uni-wuerzburg.de> Thread-Index: AckB4fXO0EqBGR41RsCRkIF7ulkHSAAABTqg 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, 19 Aug 2008 12:02:58 +0200 (MEST) Cc: pcn@ietf.org, Attila.Bader@ericsson.com, Lars.Westberg@ericsson.com Subject: Re: [PCN] regarding lc-pcn features and 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 Hi Michael Traffic loss can go above 100% when e.g., a link with capacity higher than C fails and its traffic is rerouted through a link with capacity C, which is fully utilised before the re-route takes place. Best regards, Georgios > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: dinsdag 19 augustus 2008 11:56 > To: Georgios Karagiannis > Cc: philip.eardley@bt.com; slblake@petri-meat.com; > pcn@ietf.org; Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com > Subject: Re: [PCN] regarding lc-pcn features and consensus > > Hi Georgios, > > traffic loss can never go beyond 100%. In our setting, > approximatley half of the traffic was lost, i.e. PCN traffic > was twice the line rate. > It works fine and terminates in spite of extreme packet loss > within 1.5 s. This comprises the time meters and markers > require to detect SR-overload. > > Regards, > > Michael > > Georgios Karagiannis wrote: > > Hi Michael > > > > The pointed issue was related to fact that the recovery > time it will > > be too high (more than 1 - 2 seconds) for the situation > that very high > > losses occur (more than 100% of the capacity of the link). > > > > Best regards, > > Georgios > > > > > > > > > > > >> -----Original Message----- > >> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > >> Sent: dinsdag 19 augustus 2008 11:08 > >> To: philip.eardley@bt.com > >> Cc: karagian@cs.utwente.nl; slblake@petri-meat.com; pcn@ietf.org; > >> Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com > >> Subject: Re: [PCN] regarding lc-pcn features and consensus > >> > >> Hi, > >> > >> we've done simulations on marked flow termination (MFT) > with packet > >> loss and reported them in IV.D.4 of > >> http://www3.informatik.uni-wuerzburg.de/staff/menth/Publicatio > >> > > ns/Menth08-PCN-MFT.pdf > > > >> They show that packet loss with MFT is no problem at all > as long as > >> marked packets are not preferentially dropped. > >> PCN traffic rate: 16 Mbit/s, bottleneck capacity 9 Mbit/s with > >> supportable rate 8 Mbit/s. This is a loss rate of 43.75%. > >> Experiments with even higher loss rates are not covered in > the paper > >> because this seemed not very realistic to us, but experiments have > >> shown that there are no problems either. It takes a bit > longer, but > >> it works. > >> > >> Regards, > >> > >> Michael > >> > >> > >> philip.eardley@bt.com wrote: > >> > >>> Hi Georgios > >>> > >>> i think what you're referring to (please correct) is that if the > >>> interior node is massively overloaded, then you're saying > that the > >>> I-D's approach might terminate slower, essentially because of a > >>> saturation effect (you can't have more than 100% marked pkts) - > >>> whereas this saturation effect doesn't appear until (much) higher > >>> loads with the 'marking every Nth pkt' algorithm. > >>> > >>> Sure, at first glance I can believe there's a theoretical > >>> > >> saturation > >> > >>> effect. Question is whether it's important in practice. > >>> > >> Please can you > >> > >>> point me to the earlier comparative analysis / simulations > >>> > >> that shows > >> > >>> when it starts becoming important (eg link to the right > >>> > >> mail - sorry > >> > >>> my memory for old discussions is often bad!). > >>> > >>> Thanks > >>> Phil/ > >>> > >>> { -----Original Message----- > >>> { From: Georgios Karagiannis > >>> > >> [mailto:karagian@cs.utwente.nl] { Sent: > >> > >>> 19 August 2008 09:11 { To: Eardley,PL,Philip,CXR9 R; > >>> slblake@petri-meat.com; pcn@ietf.org { Cc: > >>> > >> Lars.Westberg@ericsson.com; > >> > >>> Attila.Bader@ericsson.com { Subject: RE: [PCN] regarding lc-pcn > >>> features and consensus { { Hi Phil { { At the time I have > >>> > >> checked this > >> > >>> draft and I have also followed the { presentation given > by Michael > >>> during the { IETF 71. From the discussions that we have > had then, I > >>> did realise that { the { algorithm provided in { > >>> http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt > >>> { cannot achieve the same behaviour as the algorithm that > >>> > >> is marking > >> > >>> every { N-th packet { when the percentage of overload in an > >>> > >> interior > >> > >>> node is higher than 100% of { the capacity of the link. > >>> { > >>> { Best regards, > >>> { Georgios > >>> { > >>> { > >>> { > >>> { > >>> { > >>> { > -----Original Message----- > >>> { > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] { > > >>> Sent: maandag 18 augustus 2008 17:04 { > To: > >>> > >> karagian@cs.utwente.nl; > >> > >>> slblake@petri-meat.com; pcn@ietf.org { > Cc: > >>> Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > > >>> > >> Subject: RE: > >> > >>> [PCN] regarding lc-pcn features and consensus { > { > { > > - marking > >>> every Nth pkt is not supported. > >>> { > { Thus you mean that the option of marking every Nth pkt is > >>> precluded. > >>> { > { Without this option the LC-PCN algorithm will > become very { > > >>> slow { in situations of high overloads that are above the { > >>> > >> capacity > >> > >>> of a link. > >>> { > { > >>> { > { Therefore, we would very much appreciate if an > >>> > >> experimental { > > >> > >>> extesion of { this { feature will be allowed { to support the { > > >>> option that marked excess rate represents { high levels of { { > > >>> excess rate). This can be implemented by marking every { > { > N-th > >>> packet (or { byte)instead { of marking each packet (or { > > >>> > >> byte). N is > >> > >>> a constant that is { equal or { higher { than 1. > >>> { > > >>> { > Georgios > >>> { > > >>> { > We had quite some discussion between a couple of IETFs > >>> > >> { > several > >> > >>> months ago, which led to the draft { > > >>> http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt > >>> { > > >>> { > This came out of the desire to achieve marked flow { > > >>> termination. The original suggestion was to do this by { > > marking > >>> every Nth pkt. However, it was realised that this { > could be > >>> achieved by marking every pkt, but then altering the { > edge > >>> behaviour (every time it sees a pkt, it terminates that { > > >>> > >> flow with > >> > >>> a probability of 1/N). This was shown by simulation (see { > >>> i-d) and > >>> analysis (see email I sent to list) to achieve { > > exactly the same > >>> behaviour. > >>> { > Hence marking every Nth pkt was shown to be an > unnecessary { > > >>> complication { > - it's clearly a good thing to eliminate > >>> > >> (all other > >> > >>> things { > being equal) since it adds complexity to the > marking { > > >>> algorithm and is another parameter to configure. > >>> { > > >>> { > I believe this gives you the system behaviour you want. > >>> { > > >>> { > Best wishes > >>> { > 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 Tue Aug 19 03:25:47 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 929B53A69A3; Tue, 19 Aug 2008 03:25: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 D232A3A6954 for ; Tue, 19 Aug 2008 03:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, 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 EPK6Ul-8fWZD for ; Tue, 19 Aug 2008 03:25:45 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 726533A69A3 for ; Tue, 19 Aug 2008 03:25:45 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Aug 2008 11:25:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Aug 2008 11:25:23 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC0329F958@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <001601c901de$b6e57bb0$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] regarding lc-pcn features and consensus Thread-Index: Acj30xA3vhH+zhrERBS741ha0TCfJgABTgdgAljd/RAAAbLnQAAj5JMgAAGHpwAAAXORYAAB4Wrg From: To: , , X-OriginalArrivalTime: 19 Aug 2008 10:25:24.0262 (UTC) FILETIME=[E416FC60:01C901E5] Cc: Lars.Westberg@ericsson.com, Attila.Bader@ericsson.com Subject: Re: [PCN] regarding lc-pcn features and 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 Georgios I notice you avoided my question " Please can you point me to the earlier comparative > analysis / simulations that shows when it starts becoming > important" so I assume you have haven't done comparative analysis / simulations? Anyway, Michael's simulations seem to show that the problem is not big enough to worry about. Thanks phil { -----Original Message----- { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] { Sent: 19 August 2008 10:34 { To: Eardley,PL,Philip,CXR9 R; slblake@petri-meat.com; pcn@ietf.org { Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { Subject: RE: [PCN] regarding lc-pcn features and consensus { { Hi Phil { { Yes I am refering to the situation that you are mentioning. { Please note that in severe congestion situations the overload can easily { and { most of the times { go above 100% of the capacity of the link. { { The mentioned issues were pointed out during Michael presentation (IETF { 71) { by Anna and by me. I am not sure if they were included in the PCN minutes { of { IETF 71. { { Best regards, { Georgios { { { { { > -----Original Message----- { > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] { > Sent: dinsdag 19 augustus 2008 10:55 { > To: karagian@cs.utwente.nl; slblake@petri-meat.com; pcn@ietf.org { > Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > Subject: RE: [PCN] regarding lc-pcn features and consensus { > { > Hi Georgios { > { > i think what you're referring to (please correct) is that if { > the interior node is massively overloaded, then you're saying { > that the I-D's approach might terminate slower, essentially { > because of a saturation effect (you can't have more than 100% { > marked pkts) - whereas this saturation effect doesn't appear { > until (much) higher loads with the 'marking every Nth pkt' algorithm. { > { > Sure, at first glance I can believe there's a theoretical { > saturation effect. Question is whether it's important in { > practice. Please can you point me to the earlier comparative { > analysis / simulations that shows when it starts becoming { > important (eg link to the right mail - sorry my memory for { > old discussions is often bad!). { > { > Thanks { > Phil/ { > { > { -----Original Message----- { > { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] { > { Sent: 19 August 2008 09:11 { To: Eardley,PL,Philip,CXR9 R; { > slblake@petri-meat.com; pcn@ietf.org { Cc: { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { { > Subject: RE: [PCN] regarding lc-pcn features and consensus { { > { Hi Phil { { At the time I have checked this draft and I { > have also followed the { presentation given by Michael during { > the { IETF 71. From the discussions that we have had then, I { > did realise that { the { algorithm provided in { { > http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt { > { cannot achieve the same behaviour as the algorithm that is { > marking every { N-th packet { when the percentage of overload { > in an interior node is higher than 100% of { the capacity of the link. { > { { > { Best regards, { > { Georgios { > { { > { { > { { > { { > { { > { > -----Original Message----- { > { > From: philip.eardley@bt.com { > [mailto:philip.eardley@bt.com] { > Sent: maandag 18 augustus { > 2008 17:04 { > To: karagian@cs.utwente.nl; { > slblake@petri-meat.com; pcn@ietf.org { > Cc: { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > { > Subject: RE: [PCN] regarding lc-pcn features and consensus { { > > { > { > - marking every Nth pkt is not supported. { > { > { Thus you mean that the option of marking every Nth pkt { > is precluded. { > { > { Without this option the LC-PCN algorithm will become { > very { > slow { in situations of high overloads that are { > above the { > capacity of a link. { > { > { { > { > { Therefore, we would very much appreciate if an { > experimental { > extesion of { this { feature will be allowed { > { to support the { > option that marked excess rate { > represents { high levels of { { > excess rate). This can be { > implemented by marking every { { > N-th packet (or { { > byte)instead { of marking each packet (or { > byte). N is a { > constant that is { equal or { higher { than 1. { > { > { > { > Georgios { > { > { > { > We had quite some discussion between a couple of IETFs { { > > several months ago, which led to the draft { > { > http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt { > { > { > { > This came out of the desire to achieve marked flow { > { > termination. The original suggestion was to do this by { > { > marking every Nth pkt. However, it was realised that this { > { > could be achieved by marking every pkt, but then altering the { > { > edge behaviour (every time it sees a pkt, it terminates { > that { > flow with a probability of 1/N). This was shown by { > simulation (see { > i-d) and analysis (see email I sent to { > list) to achieve { > exactly the same behaviour. { > { > Hence marking every Nth pkt was shown to be an { > unnecessary { > complication { > - it's clearly a good thing { > to eliminate (all other things { > being equal) since it adds { > complexity to the marking { > algorithm and is another { > parameter to configure. { > { > { > { > I believe this gives you the system behaviour you want. { > { > { > { > Best wishes { > { > phil { > { > { > { { > { _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Aug 19 04:42:20 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06D563A6811; Tue, 19 Aug 2008 04:42: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 1CD143A6811 for ; Tue, 19 Aug 2008 04:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.217 X-Spam-Level: *** X-Spam-Status: No, score=3.217 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_47=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xz+TkP8rscOu for ; Tue, 19 Aug 2008 04:42:17 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id F27E23A67A3 for ; Tue, 19 Aug 2008 04:42:16 -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 m7JBgFwm024177; Tue, 19 Aug 2008 13:42:20 +0200 (MEST) From: "Georgios Karagiannis" To: , , References: <001601c901de$b6e57bb0$810c5982@dynamic.ewi.utwente.nl> <4A916DBC72536E419A0BD955EDECEDEC0329F958@E03MVB1-UKBR.domain1.systemhost.net> Date: Tue, 19 Aug 2008 13:42:10 +0200 Message-ID: <000601c901f0$a1fb7580$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC0329F958@E03MVB1-UKBR.domain1.systemhost.net> Thread-Index: Acj30xA3vhH+zhrERBS741ha0TCfJgABTgdgAljd/RAAAbLnQAAj5JMgAAGHpwAAAXORYAAB4WrgAAKNjLA= 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, 19 Aug 2008 13:42:21 +0200 (MEST) Cc: Lars.Westberg@ericsson.com, Attila.Bader@ericsson.com Subject: Re: [PCN] regarding lc-pcn features and 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 Hi Phil Specific simulation results on the PCN context on the question that you had I do not have. However, if you expect to see simulation results on this matter I expect that these results should be shown by Michael since you are in favour of adopting that solution. Michael mentioned already that results associated with the dicussed case were not presented yet. Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: dinsdag 19 augustus 2008 12:25 > To: karagian@cs.utwente.nl; slblake@petri-meat.com; pcn@ietf.org > Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com > Subject: RE: [PCN] regarding lc-pcn features and consensus > > Georgios > > I notice you avoided my question " Please can you point me to > the earlier comparative > > analysis / simulations that shows when it starts becoming important" > so I assume you have haven't done comparative analysis / simulations? > Anyway, Michael's simulations seem to show that the problem > is not big enough to worry about. > > Thanks > phil > > { -----Original Message----- > { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > { Sent: 19 August 2008 10:34 { To: Eardley,PL,Philip,CXR9 R; > slblake@petri-meat.com; pcn@ietf.org { Cc: > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > Subject: RE: [PCN] regarding lc-pcn features and consensus { > { Hi Phil { { Yes I am refering to the situation that you are > mentioning. > { Please note that in severe congestion situations the > overload can easily { and { most of the times { go above 100% > of the capacity of the link. > { > { The mentioned issues were pointed out during Michael > presentation (IETF { 71) { by Anna and by me. I am not sure > if they were included in the PCN minutes { of { IETF 71. > { > { Best regards, > { Georgios > { > { > { > { > { > -----Original Message----- > { > From: philip.eardley@bt.com > [mailto:philip.eardley@bt.com] { > Sent: dinsdag 19 augustus > 2008 10:55 { > To: karagian@cs.utwente.nl; > slblake@petri-meat.com; pcn@ietf.org { > Cc: > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > > Subject: RE: [PCN] regarding lc-pcn features and consensus { > > { > Hi Georgios { > { > i think what you're referring to > (please correct) is that if { > the interior node is > massively overloaded, then you're saying { > that the I-D's > approach might terminate slower, essentially { > because of a > saturation effect (you can't have more than 100% { > marked > pkts) - whereas this saturation effect doesn't appear { > > until (much) higher loads with the 'marking every Nth pkt' > algorithm. > { > > { > Sure, at first glance I can believe there's a theoretical > { > saturation effect. Question is whether it's important in > { > practice. Please can you point me to the earlier > comparative { > analysis / simulations that shows when it > starts becoming { > important (eg link to the right mail - > sorry my memory for { > old discussions is often bad!). > { > > { > Thanks > { > Phil/ > { > > { > { -----Original Message----- > { > { From: Georgios Karagiannis > [mailto:karagian@cs.utwente.nl] { > { Sent: 19 August 2008 > 09:11 { To: Eardley,PL,Philip,CXR9 R; { > > slblake@petri-meat.com; pcn@ietf.org { Cc: > { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { { > Subject: RE: [PCN] regarding lc-pcn features and consensus { > { > { Hi Phil { { At the time I have checked this draft and I > { > have also followed the { presentation given by Michael > during { > the { IETF 71. From the discussions that we have > had then, I { > did realise that { the { algorithm provided > in { { > > http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt > { > { cannot achieve the same behaviour as the algorithm > that is { > marking every { N-th packet { when the percentage > of overload { > in an interior node is higher than 100% of { > the capacity of the link. > { > { > { > { Best regards, > { > { Georgios > { > { > { > { > { > { > { > { > { > { > { > { > -----Original Message----- > { > { > From: philip.eardley@bt.com > { > [mailto:philip.eardley@bt.com] { > Sent: maandag 18 > augustus { > 2008 17:04 { > To: karagian@cs.utwente.nl; { > > slblake@petri-meat.com; pcn@ietf.org { > Cc: > { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > > { > Subject: RE: [PCN] regarding lc-pcn features and > consensus { { > > { > { > - marking every Nth pkt is not supported. > { > { > { Thus you mean that the option of marking every Nth > pkt { > is precluded. > { > { > { Without this option the LC-PCN algorithm will > become { > very { > slow { in situations of high overloads > that are { > above the { > capacity of a link. > { > { > { > { > { > { Therefore, we would very much appreciate if an { > > experimental { > extesion of { this { feature will be allowed > { > { to support the { > option that marked excess rate { > > represents { high levels of { { > excess rate). This can be { > implemented by marking every { { > N-th packet (or { { > > byte)instead { of marking each packet (or { > byte). N is a { > > constant that is { equal or { higher { than 1. > { > { > > { > { > Georgios > { > { > > { > { > We had quite some discussion between a couple of > IETFs { { > > several months ago, which led to the draft { > > { > http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt > { > { > > { > { > This came out of the desire to achieve marked flow { > > { > termination. The original suggestion was to do this by > { > { > marking every Nth pkt. However, it was realised that > this { > { > could be achieved by marking every pkt, but then > altering the { > { > edge behaviour (every time it sees a > pkt, it terminates { > that { > flow with a probability of > 1/N). This was shown by { > simulation (see { > i-d) and > analysis (see email I sent to { > list) to achieve { > > exactly the same behaviour. > { > { > Hence marking every Nth pkt was shown to be an { > > unnecessary { > complication { > - it's clearly a good thing > { > to eliminate (all other things { > being equal) since it > adds { > complexity to the marking { > algorithm and is > another { > parameter to configure. > { > { > > { > { > I believe this gives you the system behaviour you want. > { > { > > { > { > Best wishes > { > { > phil > { > { > > { > { > { > > { > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Aug 19 04:58:46 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AC733A69E4; Tue, 19 Aug 2008 04:58: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 E93813A68D9 for ; Tue, 19 Aug 2008 04:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, 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 KOrneYguEe2T for ; Tue, 19 Aug 2008 04:58:42 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 2DF993A6A12 for ; Tue, 19 Aug 2008 04:58:42 -0700 (PDT) Received: from cpe-071-077-048-179.nc.res.rr.com ([71.77.48.179]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1KVPqo-00035i-Cs; Tue, 19 Aug 2008 07:58:14 -0400 From: Steven Blake To: philip.eardley@bt.com In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC0329F953@E03MVB1-UKBR.domain1.systemhost.net> References: <4A916DBC72536E419A0BD955EDECEDEC0329F953@E03MVB1-UKBR.domain1.systemhost.net> Date: Tue, 19 Aug 2008 07:58:14 -0400 Message-Id: <1219147094.5586.6.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Cc: pcn@ietf.org Subject: Re: [PCN] **DRAFT** PCN IETF72 Meeting Minutes 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-08-19 at 08:28 +0100, philip.eardley@bt.com wrote: > Steve > Just wanted to make sure the minutes say moncaster-baseline-encoding is > in addition to eardley-marking (not instead of) - there was a similar > size vote in favour of both these drafts becoming WG docs. They do; check the bottom of the minutes for your presentation. // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Aug 19 05:57:24 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6504A28C10A; Tue, 19 Aug 2008 05:57: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 13B3828C10A for ; Tue, 19 Aug 2008 05:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=-0.099, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, 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 GtfZtp6Ou-lB for ; Tue, 19 Aug 2008 05:57: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 3DA683A6B3B for ; Tue, 19 Aug 2008 05:57:20 -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); Tue, 19 Aug 2008 13:57:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Aug 2008 13:57:27 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC0329F959@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <000601c901f0$a1fb7580$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] regarding lc-pcn features and consensus Thread-Index: Acj30xA3vhH+zhrERBS741ha0TCfJgABTgdgAljd/RAAAbLnQAAj5JMgAAGHpwAAAXORYAAB4WrgAAKNjLAAAshu8A== From: To: , , X-OriginalArrivalTime: 19 Aug 2008 12:57:27.0446 (UTC) FILETIME=[21EE6360:01C901FB] Cc: Lars.Westberg@ericsson.com, Attila.Bader@ericsson.com Subject: Re: [PCN] regarding lc-pcn features and 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 In the absence of evidence, which was anyway due by the last ietf, I see no justification for any change to the consensus decision reached by the WG & re-confirmed at the last ietf. Best wishes Phil { -----Original Message----- { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] { Sent: 19 August 2008 12:42 { To: Eardley,PL,Philip,CXR9 R; slblake@petri-meat.com; pcn@ietf.org { Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { Subject: RE: [PCN] regarding lc-pcn features and consensus { { Hi Phil { { Specific simulation results on the PCN context on the question that you { had { I do not have. { However, if you expect to see simulation results on this matter I expect { that these results { should be shown by Michael since you are in favour of adopting that { solution. { Michael mentioned already that results associated with the dicussed case { were not presented yet. { { Best regards, { Georgios { { { { > -----Original Message----- { > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] { > Sent: dinsdag 19 augustus 2008 12:25 { > To: karagian@cs.utwente.nl; slblake@petri-meat.com; pcn@ietf.org { > Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > Subject: RE: [PCN] regarding lc-pcn features and consensus { > { > Georgios { > { > I notice you avoided my question " Please can you point me to { > the earlier comparative { > > analysis / simulations that shows when it starts becoming important" { > so I assume you have haven't done comparative analysis / simulations? { > Anyway, Michael's simulations seem to show that the problem { > is not big enough to worry about. { > { > Thanks { > phil { > { > { -----Original Message----- { > { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] { > { Sent: 19 August 2008 10:34 { To: Eardley,PL,Philip,CXR9 R; { > slblake@petri-meat.com; pcn@ietf.org { Cc: { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { { > Subject: RE: [PCN] regarding lc-pcn features and consensus { { > { Hi Phil { { Yes I am refering to the situation that you are { > mentioning. { > { Please note that in severe congestion situations the { > overload can easily { and { most of the times { go above 100% { > of the capacity of the link. { > { { > { The mentioned issues were pointed out during Michael { > presentation (IETF { 71) { by Anna and by me. I am not sure { > if they were included in the PCN minutes { of { IETF 71. { > { { > { Best regards, { > { Georgios { > { { > { { > { { > { { > { > -----Original Message----- { > { > From: philip.eardley@bt.com { > [mailto:philip.eardley@bt.com] { > Sent: dinsdag 19 augustus { > 2008 10:55 { > To: karagian@cs.utwente.nl; { > slblake@petri-meat.com; pcn@ietf.org { > Cc: { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > { > Subject: RE: [PCN] regarding lc-pcn features and consensus { { > > { > Hi Georgios { > { > i think what you're referring to { > (please correct) is that if { > the interior node is { > massively overloaded, then you're saying { > that the I-D's { > approach might terminate slower, essentially { > because of a { > saturation effect (you can't have more than 100% { > marked { > pkts) - whereas this saturation effect doesn't appear { > { > until (much) higher loads with the 'marking every Nth pkt' { > algorithm. { > { > { > { > Sure, at first glance I can believe there's a theoretical { > { > saturation effect. Question is whether it's important in { > { > practice. Please can you point me to the earlier { > comparative { > analysis / simulations that shows when it { > starts becoming { > important (eg link to the right mail - { > sorry my memory for { > old discussions is often bad!). { > { > { > { > Thanks { > { > Phil/ { > { > { > { > { -----Original Message----- { > { > { From: Georgios Karagiannis { > [mailto:karagian@cs.utwente.nl] { > { Sent: 19 August 2008 { > 09:11 { To: Eardley,PL,Philip,CXR9 R; { > { > slblake@petri-meat.com; pcn@ietf.org { Cc: { > { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { { { > Subject: RE: [PCN] regarding lc-pcn features and consensus { > { > { Hi { Phil { { At the time I have checked this draft and I { > { > have also followed the { presentation given by Michael { > during { > the { IETF 71. From the discussions that we have { > had then, I { > did realise that { the { algorithm provided { > in { { > { > http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt { > { > { cannot achieve the same behaviour as the algorithm { > that is { > marking every { N-th packet { when the percentage { > of overload { > in an interior node is higher than 100% of { { > the capacity of the link. { > { > { { > { > { Best regards, { > { > { Georgios { > { > { { > { > { { > { > { { > { > { { > { > { { > { > { > -----Original Message----- { > { > { > From: philip.eardley@bt.com { > { > [mailto:philip.eardley@bt.com] { > Sent: maandag 18 { > augustus { > 2008 17:04 { > To: karagian@cs.utwente.nl; { > { > slblake@petri-meat.com; pcn@ietf.org { > Cc: { > { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > { > { > Subject: RE: [PCN] regarding lc-pcn features and { > consensus { { > > { > { > - marking every Nth pkt is not supported. { > { > { > { Thus you mean that the option of marking every Nth { > pkt { > is precluded. { > { > { > { Without this option the LC-PCN algorithm will { > become { > very { > slow { in situations of high overloads { > that are { > above the { > capacity of a link. { > { > { > { { > { > { > { Therefore, we would very much appreciate if an { > { > experimental { > extesion of { this { feature will be allowed { > { > { to support the { > option that marked excess rate { > { > represents { high levels of { { > excess rate). This can be { { > implemented by marking every { { > N-th packet (or { { > > byte)instead { { { of marking each packet (or { > byte). N is a { { > > constant that is { equal or { higher { than 1. { > { > { > { > { > { > Georgios { > { > { > { > { > { > We had quite some discussion between a couple of { > IETFs { { > > several months ago, which led to the draft { > { > { > http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt { > { > { > { > { > { > This came out of the desire to achieve marked flow { { > > { > termination. The original suggestion was to do this by { > { > { > marking every Nth pkt. However, it was realised that { > this { > { > could be achieved by marking every pkt, but then { > altering the { > { > edge behaviour (every time it sees a { > pkt, it terminates { > that { > flow with a probability of { > 1/N). This was shown by { > simulation (see { > i-d) and { > analysis (see email I sent to { > list) to achieve { > { > exactly the same behaviour. { > { > { > Hence marking every Nth pkt was shown to be an { > { > unnecessary { > complication { > - it's clearly a good thing { > { > to eliminate (all other things { > being equal) since it { > adds { > complexity to the marking { > algorithm and is { > another { > parameter to configure. { > { > { > { > { > { > I believe this gives you the system behaviour you want. { > { > { > { > { > { > Best wishes { > { > { > phil { > { > { > { > { > { { > { > { > { { > { _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Aug 19 06:04:03 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CF093A6B1F; Tue, 19 Aug 2008 06: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 2878728C154 for ; Tue, 19 Aug 2008 06:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.137 X-Spam-Level: *** X-Spam-Status: No, score=3.137 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_40=-0.185, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_47=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRX3BWeqqO2c for ; Tue, 19 Aug 2008 06:03:56 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 270953A6B1F for ; Tue, 19 Aug 2008 06:03:55 -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 m7JD3nOP012766; Tue, 19 Aug 2008 15:03:53 +0200 (MEST) From: "Georgios Karagiannis" To: , , References: <000601c901f0$a1fb7580$810c5982@dynamic.ewi.utwente.nl> <4A916DBC72536E419A0BD955EDECEDEC0329F959@E03MVB1-UKBR.domain1.systemhost.net> Date: Tue, 19 Aug 2008 15:03:45 +0200 Message-ID: <000a01c901fc$06504500$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC0329F959@E03MVB1-UKBR.domain1.systemhost.net> Thread-Index: Acj30xA3vhH+zhrERBS741ha0TCfJgABTgdgAljd/RAAAbLnQAAj5JMgAAGHpwAAAXORYAAB4WrgAAKNjLAAAshu8AAAIh1Q 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, 19 Aug 2008 15:03:54 +0200 (MEST) Cc: Lars.Westberg@ericsson.com, Attila.Bader@ericsson.com Subject: Re: [PCN] regarding lc-pcn features and 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 Hi Phil This is an additional evidence request from you! Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: dinsdag 19 augustus 2008 14:57 > To: karagian@cs.utwente.nl; slblake@petri-meat.com; pcn@ietf.org > Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com > Subject: RE: [PCN] regarding lc-pcn features and consensus > > In the absence of evidence, which was anyway due by the last > ietf, I see no justification for any change to the consensus > decision reached by the WG & re-confirmed at the last ietf. > > Best wishes > Phil > > { -----Original Message----- > { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > { Sent: 19 August 2008 12:42 { To: Eardley,PL,Philip,CXR9 R; > slblake@petri-meat.com; pcn@ietf.org { Cc: > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > Subject: RE: [PCN] regarding lc-pcn features and consensus { > { Hi Phil { { Specific simulation results on the PCN context > on the question that you { had { I do not have. > { However, if you expect to see simulation results on this > matter I expect { that these results { should be shown by > Michael since you are in favour of adopting that { solution. > { Michael mentioned already that results associated with the > dicussed case { were not presented yet. > { > { Best regards, > { Georgios > { > { > { > { > -----Original Message----- > { > From: philip.eardley@bt.com > [mailto:philip.eardley@bt.com] { > Sent: dinsdag 19 augustus > 2008 12:25 { > To: karagian@cs.utwente.nl; > slblake@petri-meat.com; pcn@ietf.org { > Cc: > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > > Subject: RE: [PCN] regarding lc-pcn features and consensus { > > { > Georgios { > { > I notice you avoided my question " > Please can you point me to { > the earlier comparative { > > > analysis / simulations that shows when it starts becoming important" > { > so I assume you have haven't done comparative analysis / > simulations? > { > Anyway, Michael's simulations seem to show that the > problem { > is not big enough to worry about. > { > > { > Thanks > { > phil > { > > { > { -----Original Message----- > { > { From: Georgios Karagiannis > [mailto:karagian@cs.utwente.nl] { > { Sent: 19 August 2008 > 10:34 { To: Eardley,PL,Philip,CXR9 R; { > > slblake@petri-meat.com; pcn@ietf.org { Cc: > { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { { > Subject: RE: [PCN] regarding lc-pcn features and consensus { > { > { Hi Phil { { Yes I am refering to the situation that you > are { > mentioning. > { > { Please note that in severe congestion situations the { > > overload can easily { and { most of the times { go above > 100% { > of the capacity of the link. > { > { > { > { The mentioned issues were pointed out during Michael { > > presentation (IETF { 71) { by Anna and by me. I am not sure > { > if they were included in the PCN minutes { of { IETF 71. > { > { > { > { Best regards, > { > { Georgios > { > { > { > { > { > { > { > { > { > { > -----Original Message----- > { > { > From: philip.eardley@bt.com > { > [mailto:philip.eardley@bt.com] { > Sent: dinsdag 19 > augustus { > 2008 10:55 { > To: karagian@cs.utwente.nl; { > > slblake@petri-meat.com; pcn@ietf.org { > Cc: > { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > > { > Subject: RE: [PCN] regarding lc-pcn features and > consensus { { > > { > Hi Georgios { > { > i think what you're > referring to { > (please correct) is that if { > the interior > node is { > massively overloaded, then you're saying { > that > the I-D's { > approach might terminate slower, essentially { > > because of a { > saturation effect (you can't have more > than 100% { > marked { > pkts) - whereas this saturation > effect doesn't appear { > { > until (much) higher loads with > the 'marking every Nth pkt' > { > algorithm. > { > { > > { > { > Sure, at first glance I can believe there's a > theoretical { > { > saturation effect. Question is whether > it's important in { > { > practice. Please can you point me > to the earlier { > comparative { > analysis / simulations > that shows when it { > starts becoming { > important (eg link > to the right mail - { > sorry my memory for { > old > discussions is often bad!). > { > { > > { > { > Thanks > { > { > Phil/ > { > { > > { > { > { -----Original Message----- > { > { > { From: Georgios Karagiannis > { > [mailto:karagian@cs.utwente.nl] { > { Sent: 19 August > 2008 { > 09:11 { To: Eardley,PL,Philip,CXR9 R; { > { > > slblake@petri-meat.com; pcn@ietf.org { Cc: > { > { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com > { { { > Subject: RE: [PCN] regarding lc-pcn features and > consensus { > { > { Hi { Phil { { At the time I have checked > this draft and I { > { > have also followed the { > presentation given by Michael { > during { > the { IETF 71. > From the discussions that we have { > had then, I { > did > realise that { the { algorithm provided { > in { { > { > > http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt > { > { > { cannot achieve the same behaviour as the algorithm > { > that is { > marking every { N-th packet { when the > percentage { > of overload { > in an interior node is higher > than 100% of { { > the capacity of the link. > { > { > { > { > { > { Best regards, > { > { > { Georgios > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > -----Original Message----- > { > { > { > From: philip.eardley@bt.com > { > { > [mailto:philip.eardley@bt.com] { > Sent: maandag 18 { > augustus { > 2008 17:04 { > To: karagian@cs.utwente.nl; { > > { > slblake@petri-meat.com; pcn@ietf.org { > Cc: > { > { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com > { > { > { > Subject: RE: [PCN] regarding lc-pcn features and > { > consensus { { > > { > { > - marking every Nth pkt is not > supported. > { > { > { > { Thus you mean that the option of marking every > Nth { > pkt { > is precluded. > { > { > { > { Without this option the LC-PCN algorithm will { > become { > very { > slow { in situations of high overloads { > > that are { > above the { > capacity of a link. > { > { > { > { > { > { > { > { Therefore, we would very much appreciate if an > { > { > experimental { > extesion of { this { feature will be > allowed { > { > { to support the { > option that marked > excess rate { > { > represents { high levels of { { > excess > rate). This can be { { > implemented by marking every { { > > N-th packet (or { { > > byte)instead { { { of marking each > packet (or { > byte). N is a { { > > constant that is { equal > or { higher { than 1. > { > { > { > > { > { > { > Georgios > { > { > { > > { > { > { > We had quite some discussion between a couple of > { > IETFs { { > > several months ago, which led to the draft > { > { > { > > http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt > { > { > { > > { > { > { > This came out of the desire to achieve marked > flow { { > > { > termination. The original suggestion was to > do this by { > { > { > marking every Nth pkt. However, it was > realised that { > this { > { > could be achieved by marking > every pkt, but then { > altering the { > { > edge behaviour > (every time it sees a { > pkt, it terminates { > that { > > flow with a probability of { > 1/N). This was shown by { > > simulation (see { > i-d) and { > analysis (see email I sent > to { > list) to achieve { > { > exactly the same behaviour. > { > { > { > Hence marking every Nth pkt was shown to be an { > > { > unnecessary { > complication { > - it's clearly a good > thing { > { > to eliminate (all other things { > being equal) > since it { > adds { > complexity to the marking { > algorithm > and is { > another { > parameter to configure. > { > { > { > > { > { > { > I believe this gives you the system behaviour you want. > { > { > { > > { > { > { > Best wishes > { > { > { > phil > { > { > { > > { > { > { > { > { > > { > { > { > > { > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Aug 19 06:47:58 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3340F3A6B34; Tue, 19 Aug 2008 06:47: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 672BF3A6B01 for ; Tue, 19 Aug 2008 06:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, 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 EC2U0xsfvkhJ for ; Tue, 19 Aug 2008 06:47:56 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id BB4133A6843 for ; Tue, 19 Aug 2008 06:47:54 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Aug 2008 14:47:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 19 Aug 2008 14:47:48 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC0329F95A@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <000a01c901fc$06504500$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] regarding lc-pcn features and consensus Thread-Index: Acj30xA3vhH+zhrERBS741ha0TCfJgABTgdgAljd/RAAAbLnQAAj5JMgAAGHpwAAAXORYAAB4WrgAAKNjLAAAshu8AAAIh1QAAGn0YA= From: To: , , X-OriginalArrivalTime: 19 Aug 2008 13:47:49.0282 (UTC) FILETIME=[2B15F820:01C90202] Cc: Lars.Westberg@ericsson.com, Attila.Bader@ericsson.com Subject: Re: [PCN] regarding lc-pcn features and 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 ??????? it's you who needs to provide evidence for any change!!!!!!! { -----Original Message----- { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] { Sent: 19 August 2008 14:04 { To: Eardley,PL,Philip,CXR9 R; slblake@petri-meat.com; pcn@ietf.org { Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { Subject: RE: [PCN] regarding lc-pcn features and consensus { { Hi Phil { { This is an additional evidence request from you! { { Best regards, { Georgios { { { { > -----Original Message----- { > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] { > Sent: dinsdag 19 augustus 2008 14:57 { > To: karagian@cs.utwente.nl; slblake@petri-meat.com; pcn@ietf.org { > Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > Subject: RE: [PCN] regarding lc-pcn features and consensus { > { > In the absence of evidence, which was anyway due by the last { > ietf, I see no justification for any change to the consensus { > decision reached by the WG & re-confirmed at the last ietf. { > { > Best wishes { > Phil { > { > { -----Original Message----- { > { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] { > { Sent: 19 August 2008 12:42 { To: Eardley,PL,Philip,CXR9 R; { > slblake@petri-meat.com; pcn@ietf.org { Cc: { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { { > Subject: RE: [PCN] regarding lc-pcn features and consensus { { > { Hi Phil { { Specific simulation results on the PCN context { > on the question that you { had { I do not have. { > { However, if you expect to see simulation results on this { > matter I expect { that these results { should be shown by { > Michael since you are in favour of adopting that { solution. { > { Michael mentioned already that results associated with the { > dicussed case { were not presented yet. { > { { > { Best regards, { > { Georgios { > { { > { { > { { > { > -----Original Message----- { > { > From: philip.eardley@bt.com { > [mailto:philip.eardley@bt.com] { > Sent: dinsdag 19 augustus { > 2008 12:25 { > To: karagian@cs.utwente.nl; { > slblake@petri-meat.com; pcn@ietf.org { > Cc: { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > { > Subject: RE: [PCN] regarding lc-pcn features and consensus { { > > { > Georgios { > { > I notice you avoided my question " { > Please can you point me to { > the earlier comparative { > > { > analysis / simulations that shows when it starts becoming important" { > { > so I assume you have haven't done comparative analysis / { > simulations? { > { > Anyway, Michael's simulations seem to show that the { > problem { > is not big enough to worry about. { > { > { > { > Thanks { > { > phil { > { > { > { > { -----Original Message----- { > { > { From: Georgios Karagiannis { > [mailto:karagian@cs.utwente.nl] { > { Sent: 19 August 2008 { > 10:34 { To: Eardley,PL,Philip,CXR9 R; { > { > slblake@petri-meat.com; pcn@ietf.org { Cc: { > { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { { { > Subject: RE: [PCN] regarding lc-pcn features and consensus { > { > { Hi { Phil { { Yes I am refering to the situation that you { > are { > mentioning. { > { > { Please note that in severe congestion situations the { { > > overload can easily { and { most of the times { go above { > 100% { > of the capacity of the link. { > { > { { > { > { The mentioned issues were pointed out during Michael { { > > presentation (IETF { 71) { by Anna and by me. I am not sure { > { > if they were included in the PCN minutes { of { IETF 71. { > { > { { > { > { Best regards, { > { > { Georgios { > { > { { > { > { { > { > { { > { > { { > { > { > -----Original Message----- { > { > { > From: philip.eardley@bt.com { > { > [mailto:philip.eardley@bt.com] { > Sent: dinsdag 19 { > augustus { > 2008 10:55 { > To: karagian@cs.utwente.nl; { > { > slblake@petri-meat.com; pcn@ietf.org { > Cc: { > { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > { > { > Subject: RE: [PCN] regarding lc-pcn features and { > consensus { { > > { > Hi Georgios { > { > i think what you're { > referring to { > (please correct) is that if { > the interior { > node is { > massively overloaded, then you're saying { > that { > the I-D's { > approach might terminate slower, essentially { { > > because of a { > saturation effect (you can't have more { > than 100% { > marked { > pkts) - whereas this saturation { > effect doesn't appear { > { > until (much) higher loads with { > the 'marking every Nth pkt' { > { > algorithm. { > { > { > { > { > { > Sure, at first glance I can believe there's a { > theoretical { > { > saturation effect. Question is whether { > it's important in { > { > practice. Please can you point me { > to the earlier { > comparative { > analysis / simulations { > that shows when it { > starts becoming { > important (eg link { > to the right mail - { > sorry my memory for { > old { > discussions is often bad!). { > { > { > { > { > { > Thanks { > { > { > Phil/ { > { > { > { > { > { > { -----Original Message----- { > { > { > { From: Georgios Karagiannis { > { > [mailto:karagian@cs.utwente.nl] { > { Sent: 19 August { > 2008 { > 09:11 { To: Eardley,PL,Philip,CXR9 R; { > { > { > slblake@petri-meat.com; pcn@ietf.org { Cc: { > { > { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > { { { > Subject: RE: [PCN] regarding lc-pcn features and { > consensus { > { > { Hi { Phil { { At the time I have checked { > this draft and I { > { > have also followed the { { > presentation given by Michael { > during { > the { IETF 71. { > From the discussions that we have { > had then, I { > did { > realise that { the { algorithm provided { > in { { > { > { > http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt { > { > { > { cannot achieve the same behaviour as the algorithm { > { > that is { > marking every { N-th packet { when the { > percentage { > of overload { > in an interior node is higher { > than 100% of { { > the capacity of the link. { > { > { > { { > { > { > { Best regards, { > { > { > { Georgios { > { > { > { { > { > { > { { > { > { > { { > { > { > { { > { > { > { { > { > { > { > -----Original Message----- { > { > { > { > From: philip.eardley@bt.com { > { > { > [mailto:philip.eardley@bt.com] { > Sent: maandag 18 { { > augustus { > 2008 17:04 { > To: karagian@cs.utwente.nl; { > > { > { slblake@petri-meat.com; pcn@ietf.org { > Cc: { > { > { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > { > { > { > Subject: RE: [PCN] regarding lc-pcn features and { > { > consensus { { > > { > { > - marking every Nth pkt is not { > supported. { > { > { > { > { Thus you mean that the option of marking every { > Nth { > pkt { > is precluded. { > { > { > { > { Without this option the LC-PCN algorithm will { { > become { > very { > slow { in situations of high overloads { > > that { are { { > above the { > capacity of a link. { > { > { > { > { { > { > { > { > { Therefore, we would very much appreciate if an { > { > { > experimental { > extesion of { this { feature will be { > allowed { > { > { to support the { > option that marked { > excess rate { > { > represents { high levels of { { > excess { > rate). This can be { { > implemented by marking every { { > { > N-th packet (or { { > > byte)instead { { { of marking each { > packet (or { > byte). N is a { { > > constant that is { equal { > or { higher { than 1. { > { > { > { > { > { > { > { > Georgios { > { > { > { > { > { > { > { > We had quite some discussion between a couple of { > { > IETFs { { > > several months ago, which led to the draft { > { > { > { > { > http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt { > { > { > { > { > { > { > { > This came out of the desire to achieve marked { > flow { { > > { > termination. The original suggestion was to { > do this by { > { > { > marking every Nth pkt. However, it was { > realised that { > this { > { > could be achieved by marking { > every pkt, but then { > altering the { > { > edge behaviour { > (every time it sees a { > pkt, it terminates { > that { > { > flow with a probability of { > 1/N). This was shown by { > { > simulation (see { > i-d) and { > analysis (see email I sent { > to { > list) to achieve { > { > exactly the same behaviour. { > { > { > { > Hence marking every Nth pkt was shown to be an { { > > { > unnecessary { > complication { > - it's clearly a good { > thing { > { > to eliminate (all other things { > being equal) { > since it { > adds { > complexity to the marking { > algorithm { > and is { > another { > parameter to configure. { > { > { > { > { > { > { > { > I believe this gives you the system behaviour you want. { > { > { > { > { > { > { > { > Best wishes { > { > { > { > phil { > { > { > { > { > { > { > { { > { > { > { > { > { { > { > { > { { > { _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Aug 22 06:07:39 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE8B93A6AB7; Fri, 22 Aug 2008 06:07: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 39EEC3A6ABD for ; Fri, 22 Aug 2008 05:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.267 X-Spam-Level: X-Spam-Status: No, score=-1.267 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUU7qbi8BP-d for ; Fri, 22 Aug 2008 05:40:50 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 780D43A6A94 for ; Fri, 22 Aug 2008 05:40:50 -0700 (PDT) Received: from cpe-071-077-048-179.nc.res.rr.com ([71.77.48.179]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1KWVwC-000864-84 for pcn@ietf.org; Fri, 22 Aug 2008 08:40:20 -0400 From: Steven Blake To: pcn Date: Fri, 22 Aug 2008 08:40:20 -0400 Message-Id: <1219408820.32328.9.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Subject: [PCN] IETF 72 WG minutes 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 official meeting minutes from Dublin have been uploaded to http://www.ietf.org/proceedings/08jul/minutes/pcn.txt. Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Aug 22 06:28:48 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F199E3A694D; Fri, 22 Aug 2008 06:28: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 DE24A3A6884 for ; Fri, 22 Aug 2008 06:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=0.534, 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 He54M6-RoKCu for ; Fri, 22 Aug 2008 06:12:33 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 2071E3A67A5 for ; Fri, 22 Aug 2008 06:12:33 -0700 (PDT) Received: from cpe-071-077-048-179.nc.res.rr.com ([71.77.48.179]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1KWVrL-0006vE-AZ for pcn@ietf.org; Fri, 22 Aug 2008 08:35:19 -0400 From: Steven Blake To: pcn In-Reply-To: <1218240220.16668.6.camel@tachyon> References: <1218240220.16668.6.camel@tachyon> Date: Fri, 22 Aug 2008 08:35:19 -0400 Message-Id: <1219408519.32328.6.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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-08-08 at 20:03 -0400, Steven Blake wrote: > This message starts a 2+-week PCN working group last call for advancing > > Title : Pre-Congestion Notification Architecture > Author(s) : P. Eardley > Filename : draft-ietf-pcn-architecture-05.txt > Pages : 54 > Date : 2008-08-07 > > as an Informational RFC. Substantive comments and statements of support > for this draft should be sent to the pcn mailing list. Editorial > suggestions can be sent directly to the document editor. > The last call will end on Wednesday August 27. A reminder that this last call closes next Wednesday. Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sat Aug 23 06:48:09 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A0763A6C0F; Sat, 23 Aug 2008 06:48: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 358A73A6C03 for ; Sat, 23 Aug 2008 06:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.67 X-Spam-Level: X-Spam-Status: No, score=-2.67 tagged_above=-999 required=5 tests=[AWL=0.930, 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 dG1Y5st5kBhn for ; Sat, 23 Aug 2008 06:48:07 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 2564B3A6C08 for ; Sat, 23 Aug 2008 06:48:06 -0700 (PDT) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.64]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 23 Aug 2008 14:48:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 23 Aug 2008 14:47:20 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt Thread-Index: AckEWws66toyjTxMTyW1oRWrYXOTRAAy7iMh References: <1218240220.16668.6.camel@tachyon> <1219408519.32328.6.camel@tachyon> From: To: , X-OriginalArrivalTime: 23 Aug 2008 13:48:03.0497 (UTC) FILETIME=[DD360190:01C90526] Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 support this document going to RFC in its current form (obviously allowing for any nits other people may have picked up). Toby ________________________________ From: pcn-bounces@ietf.org on behalf of Steven Blake Sent: Fri 22/08/2008 13:35 To: pcn Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt On Fri, 2008-08-08 at 20:03 -0400, Steven Blake wrote: > This message starts a 2+-week PCN working group last call for advancing > > Title : Pre-Congestion Notification Architecture > Author(s) : P. Eardley > Filename : draft-ietf-pcn-architecture-05.txt > Pages : 54 > Date : 2008-08-07 > > as an Informational RFC. Substantive comments and statements of support > for this draft should be sent to the pcn mailing list. Editorial > suggestions can be sent directly to the document editor. > The last call will end on Wednesday August 27. A reminder that this last call closes next Wednesday. Regards, // Steve _______________________________________________ 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 Aug 25 07:54:30 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08E1F3A6D05; Mon, 25 Aug 2008 07:54: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 B754128C2A2 for ; Mon, 25 Aug 2008 07:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, 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 HVoVfO+4U9Dm for ; Mon, 25 Aug 2008 07:54:27 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 586813A6CFE for ; Mon, 25 Aug 2008 07:54:27 -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, 25 Aug 2008 16:53:07 +0200 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, 25 Aug 2008 16:53:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 25 Aug 2008 16:53:07 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C01AB51D0@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <1219408519.32328.6.camel@tachyon> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt thread-index: AckEWwmZnRaGhFW2Sm2lzUqWyj3JQgCY/dug References: <1218240220.16668.6.camel@tachyon> <1219408519.32328.6.camel@tachyon> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 25 Aug 2008 14:53:07.0345 (UTC) FILETIME=[48E97010:01C906C2] Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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, thanks for the reminder. I agree to publish draft-ietf-pcn-architecture-05.txt as an informational RFC. My thanks to Phil and the other contributors for their work. Regards, Ruediger One proposed rewording and some editorials I found: Section 4. Deployment scenarios, Page 10, top section, last sentence: "The drawback of this approach would be that until PCN-traffic naturally departs to relieve the congestion, all PCN-flows as well as lower priority services will be adversely affected." May sound better with the following: The drawback of this approach would be that until PCN-traffic naturally drops below PCN ^^^^^^^^^^^^^^^^ scheduler rate, all PCN-flows as well as lower priority services will ^^^^^^^^^^^^^^ be adversely affected. ----- Same page (page 10), last section, last sentence: "A similar example would use NSIS signalling is used instead of RSVP." ^^^^^^^^ Delete the marked words. ------- Section 5.2 Assumption 2: Real-time.... 2nd sentence: "We assume that PCN-packets come from real time applications generating inelastic traffic, ie it sends packets..." ^^^^^^^^^^^^ ^^ Does singular "it" refer to plural "applications"? ------ Section 7.2 PCN-ingress-node functions 2nd bullet point, last sentence: "Similarly, police packets that are part of a previously admitted flow, to check that the flow keeps to the agreed rate or flowspec (eg RFC1633 [RFC1633] for a microflow and its NSIS equivalent). If PCN" ^^^^^^^^ Delete the two words or make it a sentence. -------- Section 9.1.2 Parameters Page 32, 3rd section from top, last sentence "It will be preferable for their to be ^^^^^^^^^^^^ rules to set defaults for these parameters, but then allow operators to change them, for instance if average traffic characteristics change over time." Something is missing at the marked part of that sentence. -------- A general obeservation: On lists, "." terminates the last sentence or not. Doesn't bother me, just be aware if anybody cares for such minor issues. -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Steven Blake Sent: Friday, August 22, 2008 2:35 PM To: pcn Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt On Fri, 2008-08-08 at 20:03 -0400, Steven Blake wrote: > This message starts a 2+-week PCN working group last call for advancing > > Title : Pre-Congestion Notification Architecture > Author(s) : P. Eardley > Filename : draft-ietf-pcn-architecture-05.txt > Pages : 54 > Date : 2008-08-07 > > as an Informational RFC. Substantive comments and statements of support > for this draft should be sent to the pcn mailing list. Editorial > suggestions can be sent directly to the document editor. > The last call will end on Wednesday August 27. A reminder that this last call closes next Wednesday. Regards, // Steve _______________________________________________ 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 Aug 25 09:31:16 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7DCE28C4A0; Mon, 25 Aug 2008 09:31: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 D021728C49A for ; Mon, 25 Aug 2008 09:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.201 X-Spam-Level: * X-Spam-Status: No, score=1.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_47=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyP9NECF52vJ for ; Mon, 25 Aug 2008 09:31:14 -0700 (PDT) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.185]) by core3.amsl.com (Postfix) with ESMTP id 3713028C498 for ; Mon, 25 Aug 2008 09:31:13 -0700 (PDT) Received: by nf-out-0910.google.com with SMTP id b11so782301nfh.39 for ; Mon, 25 Aug 2008 09:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=vOadMZs+/MP/o1VS3QSVMUF8WtE+I/JFPdXbMpq8iuE=; b=kEK9yPbGnylYvvQIyHJFmceZfAqjAF20uRzXTry5DZQvdAyUe873g1zX2vnfZ8XLWU EQ/zsjeJqGBK2I5g3ir0aBDI0dLlkirZbqjkOP9srNf76aBY7JBoKDUVmZh5sqkWIWAu 1UAvJOcZxlnftSEG9yV5eRVlT93Xc74Fii6VI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; b=tNNOQifszWM3LlImsIEbCyockefeyEQ/IJKvePNo5qz7I6NzjUzTTMc3f5NQR33vVy cDnDQNmwUrGyahVcZFyczRQkSpLUxZ6zH7C/Pi5ydLN+9YQQQK0aC1+Fido15LNJW6dM cCX+qj/QTTv3BGCjnTvBX3Os/Yc0bWNjZiuFU= Received: by 10.210.113.16 with SMTP id l16mr2678748ebc.108.1219681844875; Mon, 25 Aug 2008 09:30:44 -0700 (PDT) Received: from HeinoLaptop ( [130.89.124.152]) by mx.google.com with ESMTPS id 7sm5141357eyb.1.2008.08.25.09.30.05 (version=SSLv3 cipher=RC4-MD5); Mon, 25 Aug 2008 09:30:42 -0700 (PDT) From: "Hein Mekkes" To: References: <001601c901de$b6e57bb0$810c5982@dynamic.ewi.utwente.nl> <4A916DBC72536E419A0BD955EDECEDEC0329F958@E03MVB1-UKBR.domain1.systemhost.net> <000601c901f0$a1fb7580$810c5982@dynamic.ewi.utwente.nl> In-Reply-To: <000601c901f0$a1fb7580$810c5982@dynamic.ewi.utwente.nl> Date: Mon, 25 Aug 2008 18:29:57 +0200 Message-ID: <000601c906cf$dc165da0$944318e0$@com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0007_01C906E0.9F9F2DA0" X-Mailer: Microsoft Office Outlook 12.0 thread-index: Acj30xA3vhH+zhrERBS741ha0TCfJgABTgdgAljd/RAAAbLnQAAj5JMgAAGHpwAAAXORYAAB4WrgAAKNjLABN8nEEA== Content-Language: en-us Subject: Re: [PCN] regarding lc-pcn features and 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: , Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multipart message in MIME format. ------=_NextPart_000_0007_01C906E0.9F9F2DA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all We had done some simulation experiments to emphasize the need of using the variable N in situations where the overload is higher than 100% of the capacity of a link. Two sets of experiments are used. In those experiments the single bottleneck topology with 10 ingresses is used, see the SM draft for more details. The used RTT (on an unloaded network) is set to be 4 ms. The capcity of the botleneck link is 45 Mbs. The flows are generating CBR traffic, with a holding time of 1 minute. The used solution is LC-PCN trunk (using ingress-egress-aggregates). In the first set of experiments an overload of 180% is simulated. Graphs 1 and 2 show the results of the first set of experiments. Graph 1 shows the situation where N = 1 is used and Graph 2 shows the situation where N = 2 is used. >From these graphs can be seen that the recovery time when N = 1 is equal to +/- 1500 ms, while when N = 2 the recovery time is +/- 300 ms. In the second set of experiments an overload of 250% is simulated. Graphs 3 and 4 show the results of the second set of experiments. Graph 3 shows the situation where N = 1 is used and Graph 4 shows the situation where N = 3 is used. >From this graph can be seen that the recovery time when N = 1 is equal to +/- 1500 ms, while when N = 3 the recovery time is +/- 400 ms. >From these graphs can be seen that by using the required N value the recovery time can be decreased with a factor of up to 5 times. Kind regards, Hein > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Georgios Karagiannis > Sent: dinsdag 19 augustus 2008 13:42 > To: philip.eardley@bt.com; slblake@petri-meat.com; pcn@ietf.org > Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com > Subject: Re: [PCN] regarding lc-pcn features and consensus > > Hi Phil > > Specific simulation results on the PCN context on the question that you > had > I do not have. > However, if you expect to see simulation results on this matter I > expect > that these results > should be shown by Michael since you are in favour of adopting that > solution. > Michael mentioned already that results associated with the dicussed > case > were not presented yet. > > Best regards, > Georgios > > > > > -----Original Message----- > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > Sent: dinsdag 19 augustus 2008 12:25 > > To: karagian@cs.utwente.nl; slblake@petri-meat.com; pcn@ietf.org > > Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com > > Subject: RE: [PCN] regarding lc-pcn features and consensus > > > > Georgios > > > > I notice you avoided my question " Please can you point me to > > the earlier comparative > > > analysis / simulations that shows when it starts becoming > important" > > so I assume you have haven't done comparative analysis / simulations? > > Anyway, Michael's simulations seem to show that the problem > > is not big enough to worry about. > > > > Thanks > > phil > > > > { -----Original Message----- > > { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > { Sent: 19 August 2008 10:34 { To: Eardley,PL,Philip,CXR9 R; > > slblake@petri-meat.com; pcn@ietf.org { Cc: > > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > > Subject: RE: [PCN] regarding lc-pcn features and consensus { > > { Hi Phil { { Yes I am refering to the situation that you are > > mentioning. > > { Please note that in severe congestion situations the > > overload can easily { and { most of the times { go above 100% > > of the capacity of the link. > > { > > { The mentioned issues were pointed out during Michael > > presentation (IETF { 71) { by Anna and by me. I am not sure > > if they were included in the PCN minutes { of { IETF 71. > > { > > { Best regards, > > { Georgios > > { > > { > > { > > { > > { > -----Original Message----- > > { > From: philip.eardley@bt.com > > [mailto:philip.eardley@bt.com] { > Sent: dinsdag 19 augustus > > 2008 10:55 { > To: karagian@cs.utwente.nl; > > slblake@petri-meat.com; pcn@ietf.org { > Cc: > > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > > > Subject: RE: [PCN] regarding lc-pcn features and consensus { > > > { > Hi Georgios { > { > i think what you're referring to > > (please correct) is that if { > the interior node is > > massively overloaded, then you're saying { > that the I-D's > > approach might terminate slower, essentially { > because of a > > saturation effect (you can't have more than 100% { > marked > > pkts) - whereas this saturation effect doesn't appear { > > > until (much) higher loads with the 'marking every Nth pkt' > > algorithm. > > { > > > { > Sure, at first glance I can believe there's a theoretical > > { > saturation effect. Question is whether it's important in > > { > practice. Please can you point me to the earlier > > comparative { > analysis / simulations that shows when it > > starts becoming { > important (eg link to the right mail - > > sorry my memory for { > old discussions is often bad!). > > { > > > { > Thanks > > { > Phil/ > > { > > > { > { -----Original Message----- > > { > { From: Georgios Karagiannis > > [mailto:karagian@cs.utwente.nl] { > { Sent: 19 August 2008 > > 09:11 { To: Eardley,PL,Philip,CXR9 R; { > > > slblake@petri-meat.com; pcn@ietf.org { Cc: > > { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { { > > Subject: RE: [PCN] regarding lc-pcn features and consensus { > { > { > Hi > Phil { { At the time I have checked this draft and I > > { > have also followed the { presentation given by Michael > > during { > the { IETF 71. From the discussions that we have > > had then, I { > did realise that { the { algorithm provided > > in { { > > > http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt > > { > { cannot achieve the same behaviour as the algorithm > > that is { > marking every { N-th packet { when the percentage > > of overload { > in an interior node is higher than 100% of { > > the capacity of the link. > > { > { > > { > { Best regards, > > { > { Georgios > > { > { > > { > { > > { > { > > { > { > > { > { > > { > { > -----Original Message----- > > { > { > From: philip.eardley@bt.com > > { > [mailto:philip.eardley@bt.com] { > Sent: maandag 18 > > augustus { > 2008 17:04 { > To: karagian@cs.utwente.nl; { > > > slblake@petri-meat.com; pcn@ietf.org { > Cc: > > { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > > > { > Subject: RE: [PCN] regarding lc-pcn features and > > consensus { { > > { > { > - marking every Nth pkt is not supported. > > { > { > { Thus you mean that the option of marking every Nth > > pkt { > is precluded. > > { > { > { Without this option the LC-PCN algorithm will > > become { > very { > slow { in situations of high overloads > > that are { > above the { > capacity of a link. > > { > { > { > > { > { > { Therefore, we would very much appreciate if an { > > > experimental { > extesion of { this { feature will be allowed > > { > { to support the { > option that marked excess rate { > > > represents { high levels of { { > excess rate). This can be { > > implemented by marking every { { > N-th packet (or { { > > > byte)instead { > of marking each packet (or { > byte). N is a { > > > constant that is { equal or { higher { than 1. > > { > { > > > { > { > Georgios > > { > { > > > { > { > We had quite some discussion between a couple of > > IETFs { { > > several months ago, which led to the draft { > > > { > http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt > > { > { > > > { > { > This came out of the desire to achieve marked flow { > > > { > termination. The original suggestion was to do this by > > { > { > marking every Nth pkt. However, it was realised that > > this { > { > could be achieved by marking every pkt, but then > > altering the { > { > edge behaviour (every time it sees a > > pkt, it terminates { > that { > flow with a probability of > > 1/N). This was shown by { > simulation (see { > i-d) and > > analysis (see email I sent to { > list) to achieve { > > > exactly the same behaviour. > > { > { > Hence marking every Nth pkt was shown to be an { > > > unnecessary { > complication { > - it's clearly a good thing > > { > to eliminate (all other things { > being equal) since it > > adds { > complexity to the marking { > algorithm and is > > another { > parameter to configure. > > { > { > > > { > { > I believe this gives you the system behaviour you want. > > { > { > > > { > { > Best wishes > > { > { > phil > > { > { > > > { > { > > { > > > { > > > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn ------=_NextPart_000_0007_01C906E0.9F9F2DA0 Content-Type: application/pdf; name="N-experiments.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="N-experiments.pdf" JVBERi0xLjQNJeLjz9MNCjI3IDAgb2JqDTw8L0xpbmVhcml6ZWQgMS9MIDU1MDk5L08gMjkvRSAz NjI4Ny9OIDIvVCA1NDUxMi9IIFsgNTk2IDE5N10+Pg1lbmRvYmoNICAgICAgICAgICAgICAgICAg DQp4cmVmDQoyNyAxNQ0KMDAwMDAwMDAxNiAwMDAwMCBuDQowMDAwMDAwOTYwIDAwMDAwIG4NCjAw MDAwMDExMDcgMDAwMDAgbg0KMDAwMDAwMTM4NCAwMDAwMCBuDQowMDAwMDAxNzg2IDAwMDAwIG4N CjAwMDAwMDE4MzIgMDAwMDAgbg0KMDAwMDAwMjA3OSAwMDAwMCBuDQowMDAwMDAyNTA5IDAwMDAw IG4NCjAwMDAwMDMyMTggMDAwMDAgbg0KMDAwMDAwMzMzMSAwMDAwMCBuDQowMDAwMDAzMzkzIDAw MDAwIG4NCjAwMDAwMjM0OTIgMDAwMDAgbg0KMDAwMDAyOTk1OCAwMDAwMCBuDQowMDAwMDAwNzkz IDAwMDAwIG4NCjAwMDAwMDA1OTYgMDAwMDAgbg0KdHJhaWxlcg0KPDwvU2l6ZSA0Mi9QcmV2IDU0 NTAxL1hSZWZTdG0gNzkzL1Jvb3QgMjggMCBSL0luZm8gOCAwIFIvSURbPEYwNEY0N0I2ODIzMDQ2 NENCMDA0MzFCMTlBODYwNTg1PjxGQTM3RTUwRDZBMzVEODRFOTU3RTQ3M0JGQTc3MzM4Qz5dPj4N CnN0YXJ0eHJlZg0KMA0KJSVFT0YNCiAgDQo0MSAwIG9iag08PC9MZW5ndGggMTEwL0MgMTA3L0Zp bHRlci9GbGF0ZURlY29kZS9JIDEyOS9TIDYwPj5zdHJlYW0NCnjaYmBgYGFgYO5jYGZgMH3BwM+A APxAMRYg5HiwnIOB4Q9QhMlErIKBIaOBga0DJIQEuKGYgUGPgZ/xHOsEBgaeCQYMSw8oNgjMWZUS cCQCLMnKwHDoEZBmBKIrcM1Aoy5bQUQZngEEGADupxOFDQplbmRzdHJlYW0NZW5kb2JqDTQwIDAg b2JqDTw8L0xlbmd0aCAyMC9GaWx0ZXIvRmxhdGVEZWNvZGUvV1sxIDEgMV0vSW5kZXhbOSAxOF0v RGVjb2RlUGFybXM8PC9Db2x1bW5zIDMvUHJlZGljdG9yIDEyPj4vU2l6ZSAyNy9UeXBlL1hSZWY+ PnN0cmVhbQ0KeNpiYmJlYGJgYKQUAwQYAAm9AD0NCmVuZHN0cmVhbQ1lbmRvYmoNMjggMCBvYmoN PDwvTWFya0luZm88PC9NYXJrZWQgdHJ1ZT4+L01ldGFkYXRhIDcgMCBSL1BhZ2VzIDYgMCBSL1Bh Z2VMYXlvdXQvT25lQ29sdW1uL1N0cnVjdFRyZWVSb290IDkgMCBSL1R5cGUvQ2F0YWxvZy9MYW5n KP7/AEUATgAtAFUAUyk+Pg1lbmRvYmoNMjkgMCBvYmoNPDwvQ3JvcEJveFswLjAgNjE3My4wMyA1 OTUuMzIgNzAxNC45NV0vUGFyZW50IDYgMCBSL1N0cnVjdFBhcmVudHMgMC9Db250ZW50cyAzNCAw IFIvUm90YXRlIDAvTWVkaWFCb3hbMC4wIDYxNzMuMDMgNTk1LjMyIDcwMTQuOTVdL1Jlc291cmNl czw8L1hPYmplY3Q8PC9JbTAgMzggMCBSL0ltMSAzOSAwIFI+Pi9Db2xvclNwYWNlPDwvQ1MwIDMx IDAgUj4+L0ZvbnQ8PC9UVDAgMzAgMCBSPj4vRXh0R1N0YXRlPDwvR1MwIDM1IDAgUj4+Pj4vVHlw ZS9QYWdlPj4NZW5kb2JqDTMwIDAgb2JqDTw8L1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0 b3IgMzIgMCBSL0xhc3RDaGFyIDExOS9XaWR0aHNbMjI2IDAgMCAwIDAgNzE1IDAgMCAwIDAgNDk4 IDAgMjUwIDAgMCAwIDUwNyA1MDcgNTA3IDUwNyA1MDcgNTA3IDAgMCA1MDcgMCAyNjggMCAwIDQ5 OCAwIDAgMCAwIDU0NCAwIDAgMCAwIDYzMSAwIDAgMCAwIDQyMCAwIDY0NiAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA0NzkgMCAwIDUyNSAwIDAgMCA1MjUgMjI5IDAgNDU1IDAg MCA1MjUgNTI3IDUyNSAwIDM0OSAwIDMzNSAwIDAgNzE1XS9CYXNlRm9udC9PRlhMRUIrQ2FsaWJy aS9GaXJzdENoYXIgMzIvVG9Vbmljb2RlIDMzIDAgUi9FbmNvZGluZy9XaW5BbnNpRW5jb2Rpbmcv VHlwZS9Gb250Pj4NZW5kb2JqDTMxIDAgb2JqDVsvSW5kZXhlZC9EZXZpY2VSR0IgMyAzNiAwIFJd DWVuZG9iag0zMiAwIG9iag08PC9TdGVtViA4MC9Gb250TmFtZS9PRlhMRUIrQ2FsaWJyaS9Gb250 RmlsZTIgMzcgMCBSL0ZvbnRTdHJldGNoL05vcm1hbC9Gb250V2VpZ2h0IDQwMC9GbGFncyAzMi9E ZXNjZW50IC0xOTQvRm9udEJCb3hbLTQ3NiAtMTk0IDEyMTQgOTUyXS9Bc2NlbnQgOTUyL0ZvbnRG YW1pbHkoQ2FsaWJyaSkvQ2FwSGVpZ2h0IDYzMi9YSGVpZ2h0IDQ2Ny9UeXBlL0ZvbnREZXNjcmlw dG9yL0l0YWxpY0FuZ2xlIDA+Pg1lbmRvYmoNMzMgMCBvYmoNPDwvTGVuZ3RoIDM2MC9GaWx0ZXIv RmxhdGVEZWNvZGU+PnN0cmVhbQ0KSIlcktuKgzAQhu/zFLlsL4qHWNOCCK1twYs9sO4+gE3GrrBG ifbCt98Zp3RhA5ovZOafP5MERXkqXTvJ4N33poJJNq2zHsb+7g3IK9xaJ6JY2tZMj9XyN109iACT q3mcoCtd04ssk8EHbo6Tn+XqYPsrrEXw5i341t3k6quo1jKo7sPwAx24SYYyz6WFBoVe6uG17kAG S9qmtLjfTvMGc/4iPucBZLysIzZjegvjUBvwtbuByEIcucwuOHIBzv7bj3ecdm3Md+1FFlNwGOKE vGXeEh+YD8QFc4GsOF5RvIqYI+KYOSZWzIo4YU6IWV+Rvtox74i5lqJa6sR8Qk5YMyHNRDNrYvaT kJ/kzHxGTtlPSn5SrptS3ZRrpVQr3TPviY/MR2LWSRedCzM2MNN8Xk3n1exHkx/N+pr0NXvDiRr+ 6Cy1Hl+IfN6ruXuPV7o8o+Uu6RZbB8+XNvSDxCz6xK8AAwBHPK7NDQplbmRzdHJlYW0NZW5kb2Jq DTM0IDAgb2JqDTw8L0xlbmd0aCA2MzkvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJ1FZN bxMxEL37V/hSyUaN4xl/o6aHNKUqohUVK3FAHFBTkoLS0gDi7zP2JiXZLFSC3Ugo0sjrdTxv/Mbv 7fA1PzoaXpycT7jmx8fjyQlnD0zzoMGq5LhLXgU0fBAtqIR8ecPe8js2rmhN/i1nbFhVmgOvPrKB Vtrw6poDKO19WZCHlrZTyfvEfTJGBU0bVwv2TpzJASaxLPFDiV8oBjEvkcuBQQEUrXhOM2Y1cynf Vy/ZacWu/h7qDkKApAxqvw2RMlafOk+FoKL1rpFq1EuqoExIzVQdVJW5DthKNmBSITpssk1MBi8O KWJm0hvxqgMmMxCirRWIdcpoCE0g93IAmBvOiWkvveRRoYceTr0llVXeB9xHL9ElRq2bqTqoKsuG bWcwoPLa7QgHSKNFlBaEziMurREHvVCZci+n2M8FahdL1KgMuJ22fVbUj24OAt2crIq3RTPvilp+ phlYKeR4Q1Hrt1NqeS9+lLf1v6Zl/luZmfdxdBiSgrAjc+ujO70gqxn+sh9Y20+XGGwE0j+g/vGA T2PADjAQrRD/bIIuaQU2pbUJQvZAyIRBdkCid54Dl0QZSsjuh65+vJTFBmk0yoFL4rAsOZQQ68e9 iep2GfsT1c28fVvZo7xuFzsiE7MrE6ttLdLYkRr1UXlMylpnu6+8Re7o08QBNFId9JJqrax98PmU sm7T+d8qa+vRNVXN9Kus6NPvMLy4nX1f3jwCsZtAyNkdQi3MHh23OpI8Om60U4l2W8F5YMOzN5rP vrJ6AXgdU8FhSKDKJvR9kOxqIxcQCef1gg3PF5pP7ilXKxbXhqWUEuDfseSNUAPkA6qxwAaWK/ZT gAEAlafAFw0KZW5kc3RyZWFtDWVuZG9iag0zNSAwIG9iag08PC9PUE0gMS9CTS9Ob3JtYWwvQ0Eg MS4wL09QIGZhbHNlL1NNYXNrL05vbmUvY2EgMS4wL0FJUyBmYWxzZS9vcCBmYWxzZS9UeXBlL0V4 dEdTdGF0ZS9TQSB0cnVlPj4NZW5kb2JqDTM2IDAgb2JqDTw8L0xlbmd0aCAxMj4+c3RyZWFtDQr/ ///AAP+goKAAAAANCmVuZHN0cmVhbQ1lbmRvYmoNMzcgMCBvYmoNPDwvTGVuZ3RoIDIwMDEzL0Zp bHRlci9GbGF0ZURlY29kZS9MZW5ndGgxIDQyODQ5Pj5zdHJlYW0NCkiJpJd5dNXVEce/d+a+7CQQ QoCwPWIMKUUMFFPQQCWyI0nYFxEJLxvwspi8QOAIeiAWDC6URSIotpZNoVCwArKpgIoINLW0CqKl CIiIyt5Kqen85v1O5VR7SO0f7zNv7p07d52Z92AAROMRMMb3HTo842Jt5EZpOQc082YNvb2zv7Bs K9A8StrG+4pySsv6fHhEdD8QdtI3JeDdsHDL10BiNuCJyC8tKLp6dZDYthsDhCcU+Kfln/0oKhJI DQBtkwvzcnJP9NlwChi8VPylFUpDg/WR6aLXip5UWBSovC3v+BnRLwONqvwlvhz0flZ0X6Xoc4ty KktTDDcAKsQc3uKcorzkwqzzontlE/GlJeWBuhb4OTA7zekvLcsrrTt7+rjoI8R9JJy9Rpg7Q/aD fdPK/IgrKMubjGJ/TqAYSxEBM3RIhhedgbo6NEIUQtACbRGL9khFF9yJe5CF4eKjP+5DDgpcuwYI RUskojF+jE64A3ehF7IxQmYbgLGYgEJYZ7lqG40wtMItiEMHmScN6eiNwRgJwkDcDx8moiFoSNYg L9KHDRnoxSQd1xgxCEdrNEMSmuA2/BTdcTf6YAhGyb21w70Yh1zXNk48RKANmuNWxKMjfoKu6IGe 6IuhGC0rScEgPIA8THY9N0IkvEhAMpridnTDz5CBfhiGMfDgR8jEeOTDjyJf53IfzVcuVa5Qrldu Ve725fgDdEB5WHlMeVJ5TnnZl1OeR9cdMinDlNHKOGWCz1dUyl5lsrKDsrOyq7JHrn9iAfdSDlBm 5xaXFPEI5VjlBGWhslgZyC/L8fF0ZZXySWWN8gXlOnGWw5uVO5S7/cUVRbxPeUh5WHlUeVx5Wt6q n88pLyqvObSQzjIbooxSxiqbKVsrk0pE2PbKVGWaMl2ZoexXUpZbbDOVw5RjSp328cp8pV9ZpqxU ziyXM7dVymrlAmWNcrlyVfnE4ny7TrlJuVW5S7lXub+8yFdqa5UfK88przn0hCnjyysmlHuSlO2V qco0Zboyo7yitNzTT5mpHKYcoxyvzA/Iyj1+ZZmyUjlTWaWslnBiicumEhE/5BtJZIf+D9JILNyc th5s+R1G3pQsOSNcYvqHfDOSwf6TDetB0t2TeHI0o4QyrB6MqQcTvsPoerCRrotVmhvorPfGtqib 0iO5L06yafBF/H9avKvVZ14jmfnmbHATJkr2z5QaM06yczGmYKZUvSfxNJZjFdZjM3bhLRzCn/Ex TuNLXMU3JsREm3jT2iSbjibN9DB9TGbwXk1DVya40uvKNHn9jkwP6uQN6jTf1WuDkhOC7ezac7bb Pt2VT7vyUFDaJFe6/fYlVx4NSk+XoAxdobdqwo8F9Yg0V94dnCdigKtXu/J6UEalBGMt6lhQxoQE 22MKXbnflYdd6c4bc1Xmi5CPzyzWCJhgFgnDZKfLnBgwV0SLhuXe3Jf7cX8nPiiWYuXxxVG8jhBb jnZs5TcKixwnn1g3dlpJf5Q5b86LekV8GXPNXAOZOlMHJg95YCmSIuGhhtQQIdSEmiCUEigBYZRI iQinFEpBBPeXmSPFV1PZ3Sxn2SYGD5sE0wqPmBSTgiozxozFo8ZvijDXlJgSVJsHTQDzTLWpxlOm xjyD+ZRK2VhAAarAyzSVpuIVmk7TsZlm0ExsoSqqwqs0h+ZgGy2iRdhOS2gJdtAKeh87uYHs8QJ3 4S64xBncC5dlNR3QmJ7nezmL87mAJ/FkLucKnsrTeAbP5ce4mufx4/wEP+ecAi2n5ZKkBvJAOalM zgRxLueBuZAnwsNlXIZQDnAAYTyFpyCcK7lSdv4QP4RInsmzEcXLeJmcLGvu+PaMWzu3QHeRczeh 1Ik6yd2kkbwb6kbdpCed0uWse1EvOesBNEDOOlvOIUSsm8n5ptId1FVG30P9KYu600BpD6+/F5pF s2TWhbRQ3gHJuiJsa9vGem1bm2hvsUn2Vpts20mP4W28R7O0kXm/XX0bfTl+x0JGtnMtWt5g4b2h T7Ig+8UaNs62ktYUm6Lvwpk3zjax8bapbWab2wTbwra0rW6Yl+RXZIyNtY2tx4bYUBtmw22EjbRR toGNtjG2oW0kNlZO+mFZgjOGbHfbA1G2p+0pEUDyu7UZr+I1vI438F5+k9/it3kfv8P7+V0+wAf5 HH/BX/JXfJ4v8EW+xJfZiZ0QXskrxeNqXi1rWctr5d7X83rZhzOH5RP8+b+9rxSrtdK7jbfzDt7J u/g1fp3f4N28R+w+4ZN8ik/zp3yGP+OzMs7xvopXifc1vEa8r+N14n0DbxDve/mgeD8na3C8d0Tc 93r9nn3omZ2QcXDHfc/M/2Wvzlkf1HGJiDbDzUgz2owyI0yheY8qaCbNpcW8lF/kTU7OMdlmmFxw gSmAx9SaWnlLAQrIW5pBMyT6nTgM1ziM4BqukRhwTjCKN/JGqQRkruLvmI0qPCo1YA7m4jFUYx4e xxNSEZ7CfPwCC7AQi7BY6sMS1OAZ+a+zDM/iOakWz+OX+BVewK+xAiuldqzGGryIl7AW6/AbqSQb 8FtsxCa8jN/hFakrW7AVr2IbtmMHdkqVeQ2v4w3sxh7sxZtSc97GPryD/XgXB3BQKtDvUYs/4D38 EYfxJ6lH7+MDHMFRfIhj+Eiq019wHH/FCXyCkzgltepTnMFnOIvP5R/oF1K5vsJ5XMBFXJIsc0Xq 2N9kr1/jGv6B6/gnvkGdk5hpMA2hoTSMhtMIGkmjaDSNoftoLN1P4+gBGk85NIF8lEt5lE8FVEgT aRJNJj8VUTGVUCk9SB/QkX8RXyXQVVVX9Az3J4EwhCEMIYSXz2BIIAzBQoKMhimAhYACgQxkoESm EIJMQcJcBCNTbRMoxQGqFpEiAraF2tYlS0oRKyIFgvLDLFbEApog6X43MSi62tXBNn/lnP/e//+d e889Z+995ISclFNSIqflfflAzohPSuWsnJPzckEuyiW5LB/KFa0pH8lfNVA+lqvyiVyTT+Vvcl1u yE35TD6XMimXW/KF3JYKJWUVVTXqUT/11wCtocM1UUfoSB2nyZqm43WKTtclulSX6XJdp0W6UXfg XHfqy7pL9+qreljf0iP6tv5Z39Gj+q4e0/dMd3Mfqia4Ev8tki+wyLxZE4CoR3UoEPWYJulYOq4p mkonLE6c0hzNoRJ09UI6rWt1LflsNZVaLD1re/OcrazzqMvn6YLt0Iu2Qy/pbt1Dl22fXjGxJg4n IbwfZ/jd1N3Xq+67qrmS/0rVfbPuvqy8b6+9O9Xn1t+dCtxsa/B/U4VFbv2wcDBQJwSaoaFFoJZW OURwCmdRlEWjGM7mbOrCk6Al7oWWmEvdOB/qKJ6L+KeUwq/wW5QhucCnR2WFFNF6y+xbtJbWp63a UBvSi9pII2m7ttMO9AftBLVwwFbdSfBZHJi3PhgwjNpAP3TBmrbg5Vpwgn2/3V7tq7rah6sSvID1 HMVRWHs0R+MgunE3VOMAHoCtDubBZKBxfgJlXqnmtuMFVcDJPKHqzu6v3LlbQYRbBTFOHrYKIlES 0WGjZBS4P0mS8EmyJIP7syQL3D9JJoH7p8t0qyCA83cpiOGoijF4VibOO8fVjv+ClnAj+9vIATZy DRu5po0caCPXspGB/+iwAfwOH+V3+Ri/x8f5L3yCT/IpLuHT/D5/wGfYx6V8ls/xeb7AF/kSX+YP +YpRY/SG3tTP9HMt03K9pV/oba34T+4ZJN+4c2MIqkusOg1yJwvMForZIwwfuxrVg3rDLlFvSeSP c0imAFtpNaBaJ4MPXdUayDP5ESjm+TwfDLqCV1BdXsmrKIhX82qqz8VcTA1Qga+gel/j36Ge3+AD 1JgP8SFqarVLiOXgUMvgHa2CibcKpj/WF4cV/hs5q+qb/+POUDmRVjMkoWv+2QR4CCh4HIh3Fth2 FTh2C2sPwBzYEOt2MAm2487onp4czwkciX1EYFftrU9CT7k+mWOtT+E461O5u/VpmApdP557WJ/O Pa3P4F7WZ1b7PtZP4Hjrs7m/9ZPRp66fxm3RiXXRzYKrdrBJ6Gm3NzvApnBH2FTuBJvGnWHHcwxs OgMtEOte2EzMqcJZ3BV2AveFzeb7YSdxP9jJQAVBlIGwOYy5ALNQAmwuD4EtZswevIGHwm7ERNWR ulFvGkjDaDSl0UTKodlUAGYrRI8Vg7G2gp12go32g3kO8gvYQTFW/Qvrk3mb9Sn8ovWpvN36NP6l 9eP5JevTeYf1GbzT+kx+2fos3mX9BN5kc/Ezm4XNNgtP2Sw8bbOwxWbhGZuFZ20Wttos/Nxm4Tmb hefdvVmMi7D+AWiFOhRBnQmnhumkDiqrkc11Y5ujJlXfN9y0+t1EN5Mu1qJSn7S5stadDDgItU8c DP5gW+NiK1fxWRi+/Qnf4HKAgJ/UknrSSJpJS2mr7kxWi6/yVfzyOl/HL8u4DL+s4AogoEc8QMBA CQQCBkkQEDBYgoGAIRICBPSKFwgYIRFQwIPwpMBKJLcz2p2JL8CdgqpnqH8wB1VPUO4zUmRyNear 8cc+PBTgKfLEYJ1hlV6P0DL38VLXIyJGxeBYPu5Nzjyq+hs6wnFQOU658YM84Nf9N0kbh6By3CFu j6eOnd3UTnSV/6GWbcjvhGUg99r47YfPx1M8OKVHeQGv5Qrk7oC8KSVg7wCXVTVYIzReZwLfHtNV +pQeNqkmw8w0a8KWhn3qBDnBTogT5nidNk5HJ87p4cQ7OU6hsy3cE94gvHG4E+4NbxMeHZ4aXoSU +nnreut7Q7xh3ijvQG+aN6v1wXJTUWHXuhnRy6SJvIHox6Eh/LSmjd4G0fMQfQmiF+ozwPt0k2tW hxWEXUP0Bk4TJ9RxbPTYquh5VdEbVUcfEb66Kno9b9Pq6JmITjY6SbPKrFbEf5nfiua3r8COqYiu aEl0ey/d9VeaXv0u5mzN0qjSBqVnS5cR+cp8O0q7wS/yLcDdUPcbvsG+BJ99si/a1/JM+RnfmdLT Ky3/5wP1CErqthock9E6UC8h9gxDKp+uTfDv1YG6yYwzKSbTTDA5RCbH5JnZJv+rKzJ5Vf7p6jsb za6qd6+Z33/tu+5+FOr9x7pHnzOxUEhPugymhaaHPqi5OhoK/lvmTB2lDxmX0/pB829Aj9ezeioU zHAPFFUHsNx9BNajfjSYRtEYSgJbZALXZlAezaG5tEALMBUs1PU6lz9iF4eDwAxhQI1hwIZkIOlk YCfYCly1wuUo9HkxmAms5HISH9JFOlUX64+w+sH6gm7TZ/UlnaZrxF838RGdaAZh9ZulNiqlv6sV +JpJxOyRL5F6k9/WbNPORJrOmFc8wBl/tFgNqkV1gcTNgSQtoMY6UiegVhdqBlQeQkOBZN+nYaYX jaRsepgm0RR0zGjoPWXDHvZjf67JtYFMLcBv4dwS2JkKzEzn5jyH3Z4q4IW8yPTmZbyb9/Be/hW/ yY/xH8GnAeDlGuDjWuDeesDH+tSIG4J7G1BTbga1EEpebgWN3JpacRtqzfeQw16o5eHUlhMpkkdA M4+k9jyWoqGiY3g8FHMGfY8zoZmzqCu0ZiwUdXeeRD14Ck+lXpxDfTiXevN0up/zqC/PoP48iwZB ZQ/g2TyPEjifhvNiSuQlNIKX0kP8QxrLj1MyP0HjuJBSeQ2l8VpK5/U0ntfRBHBYFm+gH0CbT+ZX aSr/mqbxbyiH99F0TGu5/Fuaxa/TfD4ItVDAf6JF0O8L+TAXUW0OhP6oQw/ycsqAwsez+CbfkvrS ShpLO8BeC2D3dWCCi8/BwOJAYLMXCBUtUdJeimUj1O0maNtYaNoEqNhFUMOdJUa6QBN3hSqOA0r3 lF7SW/pIXyjkftJfBshAKOUhMlQegF4GmssMmSP5UiDrMFXkySMyS2bLXJkn82WBLJYlslSWyXLM GitllRTK4/KErJa/U1+twU1cV/jsvdeWLdtFPErcqi2rLnLt2MY0vBzigGJJfsTh4QftroEgWTa1 Z5qEpsObUAfamojQ8AgJaVJImgTyAq4gATkv3ilNQgKkLT/6hx/905mSmbaT6Uymsfvdu5KxnUCn PyutVud859y7555z9tu9j7Mn2JNsD3uY7WRJtoM9xV5jB9kf2UvsMjvNjrLX2Rusn73N/sSOsyPs HHufvcBeZPvZAfYKe5UdYoeZZCl2jKXZm+wt9g47wU6yU+wMOwvuPQ/++4B9yC6wj9jH7CK7xD5h fwATF/Ex3IcdzkT+Df5N7uff4gFu8SD4sZTfit1OJa/Cbmc6n8Fn8mp+O5/N7+A1/E4+h4f4XfwW Xsxr+Vg+l0/h3+GTuMkn8+/xMJjl2/w2Potd4RH2Li9j7/Fp7GXspVYap2mVcYbWGOdovXEeDLyK r+HtfDHv4PfyZTzBH+Pb+fovv4mrd3zjqsgRucIj8kS+8IoCUSiKxNfEGOETY8U4MZ4f4/tEuZgq KsX3xTQxQ0wRM0WVmC5miWpRJn4gbPFD4YDtlonFoh28t1S0iTl8g1iAXdgU7Luq8S6Xy7zkbqGM UdSMZyu+mtZHs/aXPOn/ngdJM9gtYC/1FnkfWImDlzxgJi9YyQQvKVZaBl5SrLQWjLQRnLQJrHQc jAQ+QiWf10y6A/Xcaezhz/K9/DnjH8wjasGMbeIeUSfqRQM/LFrEPFSilW0V842LxiXRDOb7JZ/P m0SjWMAPirBYyLt5D3fwjoF3GjAnGET3juoZdI8IiUXgvo2ilO/nnbxLVRN9tAFdlRCzwceTwMoB cLHLwVM1/xJ4WDFvD94z/wVeKMpwxK1sEqsw/k3k2Ysn9K4RlV2IET/Fm3Qv9ijbaBedoD9TB22G 9JR+q36ZJJ2i39OV/9Ih/9NnYG3OfVTIj2MN4/Hu8PngtYH9+KXxNnYd2QVtvDCvI4O+wU9HYZ8O 7Br0DaRzx5FXjy1il4H+0/hi8HM2V+mDM5XO+iCP0SP+7tk7cHjgwKgcNKPvFtMSWoq9RRzrVx3o PsV+jOfY/Vq7H7Yf4bwc2jJ4JeCl5OteD2BX8gA9iM5diV3fKmgP6j5WmrL9ROsraTW+a3R3r8cz 8qHMebVGNsCyTutr8NtIP0NlHqZNWsr+u8hm+jn9AlXrwy7okZtqjwxJSdpKj6LOv6LHbihvG6Ft x3cH7UQ/PE67sYfdg754mp4ZhT6p8V9jh7sPPaNsu4Hs05Kyvo0d7xt0iA7TMZ3LBLLmZiSbl+U6 hyuQgw1Y4eZhEbv5Wz2UrY1Yu1pbMrPSNcA3DRuxKpNH5bkZnu4sbh3ULA+NysR2rMGVr6/I1Xbr 9V9Hh2flZmg2H88My8zTWlPSaPRG8hP0G9yBz+Gssqqk30J2pX1aHo7vHfJ9VuvP0wv0ImpxQEvZ fxfZD/kAvYR7+xV6lV7D97o8XHL/D9FBXTlJKTpCR+l1VPIYHae0xm9m+yr8aAY/MoT005v0Fjrk XToJpjmNbxZ5B9iJDHpWY65+ms5AV16u9h79Dgz1Pn1AH9LHdA7aR/p8HtpFukyf0BWjCNIl+ivO X9DFUH3nsnuXLlnc7tiL2lpbmhcumD/vnqa7Gxvq66KRcO1doblz7qy5Y/bt1bNmzqiaUllRWhKc bH13UvGEsb4xRQXe/DxPbg72mgZVRK26mClLYlKUWA0NlUq34gDiw4CYNAHVjfSRZky7mSM9Q/Bc Psoz5HqGhjwNn1lDNZUVZtQy5YWIZaaN9mYb8raI5ZjympbnaVmUaKUISiCAEWa0uDtiSiNmRmXd qu5kNBbBfKkCb9gKd3krKyjlLYBYAEmWWitSRukcQwusNDo7xSivSF1W8mA03ikXNtvRiD8QcDRG YT2XzA1Lj57L7FEx01YzVXEy+WjaRx2x8sJOqzO+xJY8jkFJHk0m++TYcllmRWTZur8UY8ldssKK RGW5hcmaWoYuYMicoM8yk58Rgreu/W0kEs8guUHfZ6REtcShNMGelQmxIUKsLxBQsWxNh6gDiuxt tl3dpA7/EQpVlTuSxZTlZNby9UXK0pu1DA2PWQFVqmgsc6zqLpa9HWZlBbKvjyAO2E3JS2IdiW71 H+9KWpGIm7c2W4YiEELxzFqjqalV8I/HsIgelYZmW1ZZK+QEq9Z1AGCqGvS02npIZpicEJYUS2RG yapoRMVlRpOxiBugmstqtvtp2uDV1HTTf3Qa3h0cFYecGEZRSqJJu3O5nBTzd6I/l5u2PyBDDtLn WHaXo6pk+WTZVVwuoK+oR2Fto7yzzmrlnmCeaTM/d1S1AJh1OFm1NTD4UC6tqorW1pg2NnNZN1wl 46GkEfNA4cFwgzJxNTTc4A84Afdzk5D8mZhygjJv2Fw+AEMxude5YWiutwqozIx2RYYFOGLSnEyA mdm+Ok6mcpG5MEbkqXI2ZE08iDsXGMM0GlJVLDYlLTRtq8tyLPRQaKGt1qZyrevb1Go1NbfbutqZ Lmkbobn2aleTFIA5q7AwerCu3J8tq9brtT6kNowyN2bNZjLPampNqsmtzIRk4g7ConNLGuNbq8dN x61ZB3az6uKW6TPrkvH0YG9HMhUKJVdEY92z1RxWY2fSarVr/DrWFvsh/zp1qXHUZDS11VZWgHtq U5axpTkVMra0ttv9PiJzS5t9hBksHKt1UpNhs/tNopBGmUIVqBRTKWqmFih52t/fHyLq1VahAa0n 0gZpLC+LGZRIMxfzZTEGTLhYSGPqgyIVdyPFoNuo2anKs8HpTsYcdXPRRJQShyENaw5JZs1JGSy3 UHqtrlpZYNUqfK7C57p4rsI9aAxjooHkKE5KxizwFBrKJr/htiJXU5rpwcE2O3DBf80JoNWW4Ndu y/xycH9O8G741atfDHC97E3EVRy0yFZjPcHGhIO2zU4Il0aZjxnyMzPAo06PUe2IQQnUBgXU43uh yF5HOuXqonaPo9vZJ6nBmo2yu3PmlKgLVTnJcdZt+t7EreAN9qm/fMRGrbaL+KHiYo6bJE8hIk9Y MCViJrItKNGKVne51Ot3kS5Qoijp0j+vP2MktSweLCjyyvwpmBCHkgumqFsyJ+hxHDd4rfVlHHBt nyxARCXDUpkZgOzA1KhiwdGHUJXrKTVNc5parDVgFhW0nskDsywKNsZB/u74AiBWdXZwnuKIgswc Z13Uo1ZeiLzzYFt68IC1NjDsU1lhqYeDakzy/4fxco9t27jj+B1JiZRImaQo6mU9bMmWLEsWo4cf smOTfteOHdeO46ZO5OXRZBvaNQsS9OnmjzQdtrQBWiDr1q1/ZA8MbVcUSewsajJk+cMDigELgsDY H9saJH8MKIq6SLth65xI3h11dtKsQydA9zvenQT+Pvf9/o58HwkbPHriwYEzO5MtKe7BUYc5fOIE 5/jqH1R5cY6NiAfrBtGpgd5GQeUwfR29TdHoLbNgvlfu/C1wwCngBp3w/Hl1YIBrYS/DfmSDOjiN Xl4h7DdEhnJc8Pv16IVW60laHinBlkWdPUlRQC/fKF/VyjdWnAVtBWof3rpxS/rsqlzQcreWb2U2 QbleNr+uGoplXdZoJE21xmNtuVy2h2rNx6KRGsocy7e199C5bIiiXesjPRS+hvT1u7P0RNlKHY3q MzlLyC+6HFYLFfA6WzY3Stt2Nm5OB1matdIWjm1q74tseWIw8mdWDqruoJPjnEG3GpTZ8l8sNauf W2ru9DNP3DlFW7t26Q30j+0cxVitpZDX19xVPzIjKhLDK5Ls5linLDQN7Cp/Tw3g/wioavW/yuOI 27sAMBARDIEk6AAfGP6wV4LjYUnEjQM1XgE1dTxqSlTaaPKrBppXDTSvqnwKL07hxSm8OIUXp/Di 1EUqi95hr5xHfRDLldY+WkArUby9IJLoMOM/FwQzfrTA40hJhuM0f4WneH/8H5kM21CCtnPSZL4E +bPsNNBXdHNvClAr3kriT3Y5We2g4WSyUO2jrXLVMNH6SKxVzrfl6hF5Fe9ZiIb5NBWNynjDlHtd BoY7JvYdGqm850kkPDB25NS+rDvZ29y6a7CpUvZ3zI6eW+qfavNtbRx+fPLqateO/hg83P3NqZ5m NRxnjsXDqennxtPTwx1Oe+vUkxTUxloDlWK0a6L8YeeOzeFKR6B9ClXnnWufMs9Y6oAOfm4EAwHR i+l5MT0vpue1C7iHOHhLlGw4wO/isC5uxHfH6bhICIqEIIqfYIIofooJioSgWKKyi1oe5r0laF+M RApazyVoR06xw8S5wjZXCabOajOYY3l5Ra7KnJBcLhaXNlCaBE3pYlGrrhCSb1u7jIliKZtEZcz4 nrgZ5hmGE1ihY+7F2cffeUoffO7t/Zufb60syzJjE2zwp7zbaXd27tr7WOb1T34xU3x75dXRY/sH /XZmTgkqXCwd23ri8sH5K8cHgkH4bKRBqZU5Tgo4K4o/Fox4heK7t0/9ZPXMHn804Y8gmki59BaL C/jBQ+8DtYpHJXhUIjCVCEwleFQEdhHYxCm1BJNnraagoPbHddU04pyrqqn6VZVxpvQWxuawlZc8 Cc4V8frqXRy8hgaYLa5axYYE8B5K22JhBe7Oz2xyAOB7W1tljlpk0A1eWoiLoovsnhlFEh1mvI1v z0Vuz4X3PRSyp9NZLI2sV8QNWpiVBNxDS7J4iQRCHVP2tBhnfJFJ33ach647PQWUyzKxhZyTSE/L kcTwXsVhLBaPut1486qVCRsEp+qBIdqTi92XO3PUofod7f54NKpWvlXXG0APKpwS9nrDTi7lnwrG w0EZdgbbshkvpCCa8bnrnNywC1UZPpiNUzcLL3Q99Pro3b+zDozHwTLvNEXsnkS4/EF+3+6iNvHr CeoyK9gYJA8WoBK9a22F1uk/gBwq/meMOrEv3Kf10bzNkxdQ+nnskTxmkJdECY6hmvAvowbE4yKA AsAuAp2EZyfh20m44riIf9NZojjDJXt+D/JSnuq6kocAeSWf7m0uwVpDvBaBkQgT/Dg92v1XYZwB Gqk3RdMqxUNzRWQXE+tScq5Y0KqIs4XMprlio8uKDgTEr9Vq3XBFrjVfdRAZYUywbNVTbmwpWpcC tf5wTddrk8OHJ1t6jrz17Xl3Zmuhe89IRuAQHLa2b+ZAfs/3p2O/PDnwWF/40Yd7D3Z7BcFqFYRZ fahx6EDv2HdHG4fyD7fWBqNBTvKJvqA/GlRS249OL3la9MTQtr4BRHc3ovum5Tsghk7Kl42w3gX5 2gJmWsB1pyBJuEEUCxhx4RL8NzqItbWbmKNG9KsRe2mEs0b4aiXKbtiV+iG+EK9lahBMyznvKNog ZqFm3DKG1Ik5mvoktYZoE5ErNq4r8X5wWbdnQ4d0LHavCPVQ7fSbrBxw4cNs+I2d+155pCm797Vv TLxosK6w11fntP2q/4UBfUe7T83P9NZ3G0NxH/InwyB/Pj0+M/7i2b1HLh0fHuyn+HVdlge3PbJ5 77wxcGx/t7O5P4Md/MbaKn3acghkwbOLeh42KyRVFG+bUlJIaVFIqVFK8AvDE+IxTB5j5TFH3pQq j+fswEBTINTsk0rQeqFltGHIN2bC0bHIoKZVT7KqqL5ERjZVZGXvM+16fWprqzI6zTnrcPacNz2y qWd+AF36vHUKyyrV4eFXR2afH6v3cTzHMKihxPG5gYYd28svr49YOjgB9wSu/LctI90HfrAHe/Kl tVU4adGACurBKxf06ET0YJR2E3+5CQPzWjHjTawTN9GJm0BzX6IOgQAq0v+jKBOkqCh/8Rt7GD9b hEuwZ9EnjZh8/rSSJMIhukl+GQ5hoeAnMnQ+ISJu2PMgACXV1ZnE3w0E9HG2mjALN3U2Jwrou77z 82jn8+CHhqC3wUQGZgwnHM+U1q6Zt5kpVV2B4sc4D/Ma5ZG5RMVBBAgkG4EIQyDpCiRdAYvB725p ATjRqijcEd7SNBIYktcF4SwgQSwhGWjSZ6ZTbq7nvZF4HH6FHGD1uVN1WVkI3W56nlMi/tqoV7RW jj9IBE5zTh86zyKqzSFWLsInHbwfS4BmHTb4ecXx38K4ex0+ZXfYaJrlbYJXqlysNMrqhltQ5c6C U4boxI8wCm6IcW5jTShEE/f8suEfYiyEpTbE4zpU9Q8uRlU7mU5C8xeIhbCBDHvLaLOvYWTdQ86C vrLhIWIi00Ugmfw/jKR+nZGszoDHHZTYsR+Nf42R6OMcjxjZeO7p7RPIR7uxj2ZR9b2BCCkgDt4y AnoCNjlhQoYxB4wJMMbBGAubaZigYIgU2xABFiJyC5FHvRABFsJFN6TZod31H76rLbiJ8wrvv6vd 1a4uu6vb6mJJK0vWxWvJdmRJlrGtxZfY8qWEqyG1cTEEJuaW4mmSQkoIl0yaKUPLhIcQJmQy0zKZ SQADJYbQKQ90eOi4T0DTF6Z9SNNkhunwUlqoTc+/WhnVzXQ1s2f/fy/6z/ef853vYLHgwnC5FKwq HFhSYMxc10keq/DPBWL0Fdgm3xxCl4Sh6BwiZ+lRXU2D/DMgq+pAHGPGgZa1L2xbrR7sJqn7HTOf 7dv7yz354synM2AL5wPd06vKL/dFAqXpVYPTfQr6as+1t4d7Dl7ZB3YI7Bvlw1PFtsnDo0OHtxTb Nh8GbN5ffI+6C9g0gl469OtSCUXyvBElvBElfJUjeMN7Xqdbt4odVrHDqhffVrHbKkaGI9x8Phcx 0S1Qja7GhwJlcVURLg3HS3pBquqlZ4V8yefEd8RIJbmqKLCSx6OjcDe79eTmZN9KLVYTLC53wMGm RkZXp6feHUued2c3aEo3FKO+/b3dmwp+9M2rN44MiPVt0cXuanqZvoGYoSiInh83dqfcI0cv/Kj/ rW2dzlRv6+LptRs7t71h5Bp5TldJW6+8kkNxwYDoWQtgQCUYGAoYKgehOTHbSHDCmBF+QLBB49Sh uOBWym6cQ0A6OCCAdtSlGlTbBnxX2uiQMOQ5kuHMZjkYc/tach3R5UnTsLKjGLRFYkGriULUlCck cRxndmVGCgsX/zdtjuT7EgJl5nnOHsAeR57+ndxt+ozoIMavpAgpmjYyI204mDYQSBuZkzaQSGPH rbIt/SA6GLQ9kAdbQZHMspXAn8euZg0dMn/rOV0kV/oZKWq0Odnckp8Gq0LD6NI3HY/J3WZRSWXk 57dpwYOCgzbbzD+pkuvXWLs5hK8LA3KszmWmOdr0/WC9aOeYhuGZ75F2Jeb0S+y9qvy9x0p+Z0xZ 5CcmOZ6j7V7sd+7pY/oodYPoJ+5fIwae3tS6wGkgYzSaakcFbBsyKB5BcQXFwygeQvEgStShpAml KNSxAq3oQCvSqLMJiYobjYpGccZW4wE2UYEviIIxja1mxeGCp4WVZf05Bf6xJK4S94pviiZRc3gG xWy5odzx8ybUhO81zcGyRKdncEfTa01kP8zKIxyOpbsTE6o6catUmlcnVNB9mGAq7ELozLLEMXBb Rbhc2Sk97agESxmX0KtUN0B2ygVnJf1qLumjJnrxEWWTk6Fwo89K/YYkL1A2fyoUTsBo8V+0yexU 5Lp6h5n6E0neJjlH2Ie7F/KPJLpHcs6I3xuUWOos6xL+/YnFbqZMZjtPHue4hZnqiBoTXCxnYUlc FRf8HEf+lbOxUAFBJnmrI9LM4/1qXLyPZog/EwGCv2SR6wjxznyl9WLZikcFZ9UfNMPYZemntM3p c0oyj0zHLN6Y3xeTLSfCbZm07w8sb9b/BDkPBRSRYUQFV5Evnj5Cx6lTehUJzBLQLx74nA9FoQYK g0RpvjSPQxpCeTlxS8vG6DjnS4aVJHjgTSrhpI9bPqYUpSlgsQSalPo0tumFZKQyEYmk/VarP409 /pA8Q43R7xDNhFezh5LhRLPMCiLDW6IWorkZCBaW4mFYhkkknB6szgrACfFEPF4oJOL5Qj4vy1Qc 6zWWKuQ9ssfDslTZTspy0Hq3jlIyGYWqu2MNyTKyP3xoR7Icst6pzt+1BmWZtD+kzjHRRNLBfbD4 WBChCDIfcI5kIsrsnGajiYSDO41oEY7FJ6dhPh5lpwmKWAPV+DodARQLxAA6fI3IY86U0Egekydk wUhuzpjJVWfaqjNt1Zks5h8g1KzBR2VIhqsCOfqDMmqpPtNSZePaGV0utsyRPs3nSop4Mqn3Cca1 AneTc6RX84eEaCjkxYVdP4VcIb5df6YdxKjmDgId6C8ak/jF9utkL9T8O5dhIQT+KywyYWGXXYYV DWur2CvwDtEDi9N4/I2eFvhoT3XRPdVF9xiL7pkjezWJ13AFznXR6QXfpv4FelJnVF2zGmLiTkWn VwZwA4QZNmJNtYXiohKqcdQGbCFDLfEuTp4QRVVkG5Ydcj7vhFHCTrkxEeep650//NXObR/u6UgO 7+nvHNcirVvf3z51YqIpok10DuwdTnwZbF+b27U3UBzrfGlXY33/jr7SZFf42NFDR9DIuiMvZhrX vD7atX3DcH24f/V4vu+1jdnm1XtK2c3rykp0aP0kOdnY1+KbWp/o7SyG2w4ufJwZXtkVCXf3lJu2 TO+EnByEWLoNseQkVOJbzbdM1jVUZV0aM2UDjo40qhFsHizYsMh14c1zefHVFyQkF6FUipliBJeC uw2bbvViB/ZvV8HGFKTMkWmN4xWihdAICksljYM3mvlVPEngQMEjXqwExE2Nxxc8waebAnOIvySs bQAzS2/QN1FyoMpuAS9PiH+ZqFXT+pb9H21oqtGGJup28+6Lb+0/t11t2XXx0AGwF+0BtXO0Zf10 lye08qXB9vVdwDfku6f+Mbtl7JNHH733SLefbjn96vqC74Wf3dj1i98f6oj1bt53DJjmPEFQZ2mZ yBBfabFYCMWCKFaHogEU86OYD8W9KC6jlI69QxFxdoGnNgx3CyIwtETKUAcpA9CUoR5SBqBg/4lD PDVHSkBmXvyS14LPFsnII7B6XklGHtXM38SfkHTo4Y2PJCQ5HXOodDm6JgXdCjvLrAN4nystzGPB rR/z6i01qzd36u+MZHhWFStdXqSKb0QCDq1Uw0KD0eJJ+EydZXgbuzDOWi0Mw9nMyP7YKdtpirFw qNFkdXgdXsXBfGu2c3Sf0y+yrOh3OvwSR315ijfZQrLkFa3MbymTCZlYC/PkBCf5Ma/vA7TPQEx3 Qz9nS+WRGkKpIFYYGoZVxrBqyIOj2KMzjwfD5IEwvJptgB9RNLAuXiffJCwVcCxYT1hwTye1FxWl CMGXuZr1MJm1IujyZBUhYIkHUrG5QiZAIPM4HPUA1DHSlcN/gYPFQM6Q5EZAMkvcwUYwSGdoTuAW cna3wFK8YH0y9nLRUZd7oa1rS7nVylpYE0mbvSs27Vyx+fhExjPw9t55MmsWLPSQo87JsWLI44IS ZEP8+MnXp1R1tKO+PllvdoTcgke0u2NRb258f3/3gRMX9t3jHLpi3QGccBLw24joa9D63dTqMGQv olYzgNKKE79Vx+0/jJcLcFTVGce/c8+9u5vXPrIPEja7ye4mmwVCQkJeJJBuQ3hEIAmERwjyiLzk IQFblCoKKog40FYGobFFCJ0+xKhDR5EinUqHvtFOK9B2xnaqnTLBklGnSIeS7O3/nHuTwIYZ2ckv 3znfPefc3fOd73FKxb6VnlYq4qlNrdGmpizU6Nji3ngUQ6KiwIpDG41zu1/M9IuZfjnTL2b6zSPr x86/RbY0GdF73xT+bTePpt087XZhODfMYK+No1srSr3ZJbVMHl3zCBsZoNZV6/JVnmZp8dTG1qL/ 5OVpja0+dM0IkTmppG+SEyaSUUIUbyVGvDdj/SjohcaVOWk4zpvBwlJRXilMIwpoabKhADKkuZsR vcgAB+q+fmLDV7e01ThsFm7PSKlo7WyoX9UQHtf6jTmPw1ZWS5o9ZUv9usbC0eVzK2o6ZpelwrBc sdjcNQs64+3PLRmfV9deO7WzZTx7ePG31lR5A7l2uyfgzc/JK8gL1y0oq2qLh+EeXne2wxqOL66K NVbmRmIRzeH3OUa57G7YuXj+1hlT1s2dlKZYK1pE7J+g/49/oHlwcy2mW/EaUY6PZ4VFLL+Q5UdZ QQ6L+llEBqiCLFYwikV9LOplUQ+LOnFxY/kay1fZOD+T0SrTiFbjfVlo+EQQ85lGFPJt2M6XU1yM srw/HsAIp3A/UfDgn6jmRRJxOnEGnO8oLlQ2qhGrVCQA4X6qLPvxWFUnlBT6i6WB1XEhpzM1NC91 gbz+wesm9pWViRwgTGjejsaVuSa+J+WwByZ9mHEzGrwdDrkmG45VPhZhIf6BJ/OAzWNcDgc+SXdm aIol1cr+pLmDRcFQadB5wOVNdCuJJexHbHMomvhs8HbInBZnMMsdzB6VwTNt6TaO21ZK/68iytWB GuFxq+FxhzQ7Ita5eEZhFSusFNk3ymXEOmUErCozKlWJqiYNR73qDHYqhq2PQRsTfhGzN5d1lu0o 42UBsb0Bsb0B6XAB4XCBM8pEFFe9ZnH17luiuIq70XpblEtudxYcpyieXlRzPS/MwmGtaG7WHa6z tE+4Tsk45rxsesz5pRcN5zE2V+zusLcYqXXYOUQJXeGCE4XM62jIVSk9ih+avvPkxskb51c6LJrC bWnW1LEz1s2cunluceHc7QuntEVzsnIDyhSbI1XzZCYCkcYJnT/snMSOPXi8s8aVnWVPd43OdPld tuzA6LyGtffVLf9KbvroAsURyktBEMyPJV7UlIqO53V9sHZWLPwCiTtJtf65slo5JO8k4Ximh4Kp zmyW/YZjR26ERd7QnsZP34I/VnLu4rmRVxOr6fVm3aAoq8PTN8xsfLA+N9SwobF5Q3z0PmeosiBS HnK6IxXh2MTcDDZjzpOLy4oXPdHSuL29vHLJY43Vi2oCOdWt1Q1LKrzB2lZi+iz9Q75JqyAvjfkp uVHmSvuY9a7bJmwH+9qcGu4piGAlYv/lLS2Ke4k8tj5cXMKa3ZPj8fnTuI3v0uxev9frT+c2W0qK ldsy3Olaii3Nwq12TxphZ2bqH2qb8c5C1UNOZY+QPA17ZFVjbLvcq2Wsmh/hjZSBO2LgTbJbvWln WSqp5ML/LCrpu9yHG9x78gYH48LY0tY+1x09fmSUYyDd4fO4lOuZntvbnMdyc2P54XBiUSwYjBWE w8I3iDSib984+/fljslfULaNxOedf28X9qNz9b0p/aWJr6Wcsr6Mbgq+pZgBLJQgdj61CU/3pZyS 2ts+aodqH+6xP0DTTZF7xeLXLwjUdupRG6jjrlzDs2t0WNXJL+C91AOmmXK6yUqwHDxl6nv4a9Sj pdOSZNR+rAe0OOUpKvUoqn4fZAxyEigFLaAZPA59EBSqBzBuP1mV/foragzzAV8qeYo/YLY3U466 jHosf8baY++CFcymlV9Ks4HlU1qphvEuoD2AdhvaBq1C4vfNMPGCrKH+FXLcjhamE/eK+jyFrUGa koxaSBOwVnAEP6dak9FSXifnvaLdr38sUFXq5r+nh+6Gupq6wXr1USoT8J0YuxPfxZB5JkVgDKg3 9d28BfOepo0j2Ab9NtqnHqE4u0bd7JreBpkNORMUggVgHtgCvQtkqX7qVurgtnX6Pv5brA2Uf0j2 KFfM9mf4bpeo22LB+i8M0QW2yfYacILWfClnDLDOGv5LvAuoJ9HuQ9tgmpTN1GigfwFuDPUXUw5f rCcMifO4n46C75nyMNhqtkfAByhkqaOqZBDfK/kzsFky66jBxCblJbo/ieBddBJLiYFaTl3wn3aT JrBosG/tpHbL3wAzwNgV6j6wHpRTB79FS+8FZQsVWF6iAtslKlBfRfu7ZntyEs1JmHrLI0nsTcLU 3zE+Be+Yetvazww/U/sMNDcVWGNUwM9TRTLyt46kSy3XX1On6jfZZdrNLuubIB2Q7SAPPAzawFro XaCLv0u71SA9xz7RL5ms5N+H3kSMAWOVHClnsVuUowxQl2WVeNcdNEl5XD8iZTXscSfNI3STDSwX pO0G11mh/I66DPSbkJt4iOYa4NyG9IHBvva6AdbqYp9j/OsUUs4DIc9SVL1CIXXrvYG9Dlln4Xz/ 9d7A9zwIvmnKZ8EcsNdsH7wdfoTC2mmqSIY/iph0lMIjGEOLTaxSVtPDvINW8W04qz3UoPyLNipN Us5UTtMMdo7ylcOw0VXayFZSB3tI/wv6G9kyxLOFGHtFMk3Owxx2A3IC1bN/UkTMUXZTLv+UipQn keOepVyliuqV+YhnW8FBkbUHUAr09yoLR+rw/YgvB1LXfxSsTdIdAeuYjv5L4Dj4sdSvBit4Ptb7 ArrpYK3UHwNP8kL0G8H6oTWe4OnoO4BL6nrAK8oLmP8dcEzqroKPFdQYyi/AWxh7DnyEmkNWH/3z QCl7H3XIZfC+AX7LHAF+2y7Ix5QdUj7C/ku7lNLBekXfK2oQ3or8uotqjBoi8WuR04x6IfGyyM1G vZD4CWqDebIOeJHyB/M99rjVyOG6T85B3uavojYx8jDyZWKTkBY33ol8akExprXQMq0lcdPIifpW kQuVWzLHRIxclvijiK1G3kpcVN+kNUbeSvwMOWq+zEcfkWsw7/A9tMzIJXqtmCNzyBKaJfOBjNuJ 40Jq2CkR17U22iPyi3pSX4vc3yGJw0/LcB4PIPdNwLgf4IwC5TeIAbPxTPB/9qs9RqrqjH9zHzO7 AyyU566xesRWVsDddS0bsr6ALYUFlsAuy8vHcnfm7ux159V77+wrocEWGylCmgZRNJTW1CY0INiH tqmxjxgTNG1MH/GPJtLGpmmtNsZqKmTj9ne+c2Z21gWDCqEpO5Pf3O9+5zvf+V7nnG+W4zwapKjR SAeMxtE3gWFgOp8rP4Z/PXg+glo3qM00sXeKZ0Kaaq2Z1I/525D/u80aMq1O+qbGTmCu3USd9q3U Cb9n2kfpgP0tSkoYeziXccRK5rrJsOmREj6Huh+lrATns42Ocz7zGv3I0QIyy3pHJ9qLNV6itbbs rzR0P7hB9nqlfut1MqNngVdV3xgzx/o464zKs+xTi70X/FT4Kc6FAyrX9tWQeQ/wKYy+Ax3XgP4n TY9W47kM6KZ7LIe6YxWgv4z+bhTz30HvhsLm2vgXPcF90myNBcj3Lqoq64cW24O4g3fRFmsPxvbQ QeBh3eN0yv4Fvn5XArmNcL0M6p7kKHCfrhXZdxX7iMOo2cPouevhR1zVi7UfczzInaVM9Hr0Oyvx 3kXz7K+B93fgr9Rnvo3+pRH0KO73LrrWSgDYgbjDI8zH/W+1IC6ytv6Ic/0FDdCoiVb0efPkPVF+ h0P/HegJ1lodqL0O9FQduNPUHejLe818BnMBaw7NjRo0y/aoy1qFe6xW31U3AwvH7jPuMeQ9U0Nx edfps7na/B3Ntz4AH2c3avGQdQvfoSvsP9Ah+wO8r6G4vQm8XwN7Udv7YNuLoF+mpVbH6Bl5NyPf 1WYWvmmgVp+UMB6PxI3H6RcS5k/oAeBexmuo7R30FvC0maRh3AVdqOOFsqaBn8v6tr9OB8F7SPKL T+ToQWBR8al5i4xnKAR+WXxaNej5arAf9NOcRxHjNO6EE5FvmCORp/A+Be83GQHuEMAcQT8JxO6g h8sB3hlzhH5V2nMZegAYNkL4FNJ2YzdtBgrGMpyry8BfQyeB1PnkoOvbwAAwCPRbJ6nPuh39wAjd B9weeYH2mktor407ycbdFPsPgHsjdpt6Ro/TCQn8/9xlf4/utI9RG/wlzL3T+hHqqArxGMF+qOLe aSvonwFr8N6BZwaxWAT6C+a/cVcfwf59Hv8fj0DuCPq066i14hacFSM4319HjX+GPmsdoC7jZZzL b1I3sBH1Md98Fc8m+or5Q/RsTTgPmlDbVbQaeArwgRQgABfoAxJAO6MFsdlHNeb9OAcDnIfH6Aaz F3Y8ixi0Uj1qY635HLXDng3APsAFuoFmIMU2H0H9HEG9QmaCfbUXbF/DuezD/lgdeR89xElaaxyn 5caf6PPG91Ejp+ku3MuNxl/AP40+5Q3aiOdG4xXaEnmOdgBbP81c4zAtjbxHNxvtdJvRirpcQ7ON L2HORmowltJ8Ywt0tUH3hco9PbrWnEVftLsA3KX2PP2sAzqAU7SekaJV9rPAE8BvaIG9k1aCXom7 XfZzqyvW02rw7o6dQr5GcK+P0DpgB7AIuFfT2wDsIeRKjXcCm2U92/+gxZZNS6K/Jw+5d4y30P+N UIXsN2QfIO/MqIuzeBPdZc2lNdhzjwEHgVOMKjoRq4o0F5/x9fRYdCn+u/VQLbc/FFnx6YHu+pIA nl4yWI+eH/ZvJzGJKwuxxZcWFduvbFR2jyG+6ZNjyoMXhqk/OD+mvfjxUPXuGKb/7ZNhxmv/u5i5 fxKTmMQkJjGJi4C3FWbt+v/F7KVXJubuvryY9wZRzVaiq/A/9Wrk4Zo40bVhGXZfXoirLjL2XwSc /Ghcd8NlRYTIcug4xegYYNAMqieX6PrqyFfJkqN0kzEfvybJT5J/JR2hKn6TtEFVpqVpkxrMmZq2 ymRsqjZXaDpaxo/RWXO7pitoofmKpitJWJs0HTe+U5KfQputUNNTaaH1kqanGY9a72q6itKxh9h2 +WmMva/pCMUqFmraoFjlsKZNqq68X9NWmYxNUysPaTpaxo/RzsonNV1Bcyr/rOlKmhGfr+l4ZENJ fgotijdqeirNid+j6WmRdXFf01XUNOV5WBKxKnWcFa3irGgVZ0WrOCvaKpNRcVZ0tIyv4qxoFWdF qzgrWsVZ0SrOilZxVrSKs6JVnI+SoEZqwLcJVBt5lCCfchQAPRSC1wLKpzz/OuB4oLJUh5HllMZX UDt4KerFWMBvLp4upPvxm4RkC+alIdMNngcJj+UcIANdSZbN4i0AL8tjar4HCwTgQM6DhiG8DYAK sZaUKUBjCL6LN2lzAbOTGM/CGqklp7WGkMjoNaWEgI85XlOuErAvrexrDzjSxwL4Ls/wmZNmq0Pt RwIji1lzhjlp1uggRopfXCUDPWmOWF5bmQUnw6sqndLPsMwCuWKefVHxLkZb2S5XyiECAv6riEur MpB1sH7Ib9LjsJQPFTO1imDbs9qvHMe2myXHLC73SEZtkOcpr/vwXsf1UJ7NBawtwxqGOA4Fnfny eMuMKf9dtl/6r/LiczXIp1pR5lpAR77kjbIxpWUCvA1r7SG8UBnqL2XJ4RpxwM2M86tYzQlY4vD6 Cb1+HVdsinMlRybugeYJXjeXds0S2qyryNP1tgQa5ci5q97V9au8cbT9KR5V9rg6YtLGJFeutKqP c1acc+7Rno+1g8eqReWmE28e2yDX7+BqD8flsV5bkCvzIKH3XcheulzL68BJUC3n+EbIJFn/KrZK zQ3xzSOK9fgO8LeO9/h4y+tYewYyIWpL2p9iD/LQMASuzGAP+yJ3znitRb48PVQG+kr6trHNqmqH uNoCtjDkfRXwOaBmC/ZB7kmXK8rjNVSEunluMXorEb91OBHVXL9sRO3nJMdkbI8O8FoJ3sPnWle9 S9kEqqjAMUyWaj7J43mu2KGyOs+zp1ld6UqXy79y537YbzmuTohazLqRqzMDv9zSnp1oVXaC5guP 0Zj24ikt9Dmrqicx7ryb6PtYvY6369ayCEhPlC/q1C9WvV+6QZJ8hmb5LHXO66mKszMupq6u/g/v ARlVWXkFnpnk80h645b0SMk0n2kflaGLtS/G9kQ9WyP3gLqJ6jhXeRo8KhobGppEm5fwc0GuJxQt OT+f853Qy2XrxPJ0WrR7qd4wEO1u4Pr9brKuxUl73b4nvEA4IpNLun5WBE42EBj3ekSPk/HSQ2LA C3tFUOgO067wc4Vs0sumApGDaOhmMDObFImcn3X9oE60hqLHdcKC7wbCd5208EKskQgWiyDjwIKE kwctp2QK6dDLQ2W2kHF9SAZuyAoCkfdzsFuaDe3pdG5A9MJw4WXyTiIUXlaE0g9Yhiki7WWxVq5H dHspVqwWCt3BEJO9PrdOaDcXBCLjZIdEogDnld1hL9Z3B4TvwBffg9uY6GREIS+XgcYUOIE3DPEw B4f6pUuOGHD8jFpLhjnR6/gwzPXr2t1UIe34pQw0F5dulqn5L+NlGd1Utobhblwa2kBSCqU9wYu1 uEuhOMUpbmmStqGSkKSU4jID4+7urhtmBnd3d3d31/ulL+9c1l38uKz18Txbzzn7nJaXRv3liOSh bI3i6tZ96uhdcr5yGbvsn+YO3odLbsxnd7qy7L4Mmyc48lQz9dkvOP9Y5GmSs90BWd83YA/gGeNl A0/+BRzy7gI+t8sfl5TjiLX7a9icLlsnn0dGAwFv8/j43NzcuCxuHufwZMUH8ryeNJ/dm54X7wik erID/idTg55qlwfICM4b5MmRo82z5fhdchPySMFhm13epMuX5Q4EbyglL//2OiQntZVRX35D3rMz B280N93tSH9qrdCd7cjMcQbPwmNzuv3eTLlA8My9PrdMcMgsV3YgzsZre7Llg4h117C5slKCi/67 VTYnP/OO8qcHP2k5fr8cjwPf3b9Xzz/XJ3u1yL+BWLdcRT794NH7gj8gTk9udqbH/vRF5Z7tuFM5 +H/fgCcn4M0JyLGPcTtcwTnprkzv/zzQ//Mu8t9EvNOVapcfoji73zv2yf8GQx5HhswIecYfXbyg bU6B52YXj1RdRaZTplGmUqZQJlMmUSZSJlDGU8ZR8ihjKbmUMZQcSoDip4ymeCkeSjYli5JJyaCM orgp6ZQ0SirFRXFSHJQUip0ykjKCMpwyjDKUMoQymDKIMpAygNKfkkzpR+lL6UPpTelF6UnpQelO SaJ0o3SldKF0pnSidKR0oLSnJFLaUdpSEihtKK0prSgtKS0ozSnNKE0pTSiNKY0oDSkNKPUp9Sh1 KfGUOEodSm1KLUpNSg1KLKU6pRqlKqUKpTKlEqUixUYxKDGUaEoFShSlPKUcJZJSlhJBsVIslDKU 0hQzJZwSRilFMVFCKSUpJSjFKcUoRSlFKIUphSgFKQUoihLyRNRjyiPKQ8oDyn3KPcpdyh3Kbcot yk3KDcp1yjXKVcoVymXKJcpFygXKeco5ylnKGcppyinKScoJynHKMcpRyhHKYcohykHKAcp+yj7K Xsoeym7KLspOyg7Kdso2ylbKFspmyibKRsoGynrKOspayhrKasoqykrKCspyyjLKUsoSymLKIspC ygLKfMo8ylzKHMo/lL8pf1FmU2ZRNOVPyh+U3ym/UX6l/EL5mfIT5UfKD5TvKd9RvqV8Q/ma8hXl S8oXlM8pn1E+pXxC+ZjyEeVDygeU9ynvUd6lvEN5m/IW5U3KG5TXKa9RXqW8QnmZ8hLlRcoLlJmU GZTnKYw9irFHMfYoxh7F2KMYexRjj2LsUYw9irFHMfYoxh7F2KMYexRjj2LsUYw9irFH+SjMP4r5 RzH/KOYfxfyjmH8U849i/lHMP4r5RzH/KOYfxfyjmH8U849i/lHMP4r5RzH/KOYfxfyjmH8U849i /lHMP4r5RzH/KOYfxfyjmH8U849i/lGMPYqxRzH2KKYdxbSjmHYU045i2lFMO4ppRzHtKKYdlTgr KJKadUxrQzKzjrEKpqE1Vcc0F0xBazIwSceECiaiNQEYD4wD8nR0W8FYHZ0oyAXGADkYC6DlB3zo HK2j2wm8gAfIxpQsIBPI0BU6CEYBbiAdSANSdYX2AhdaTsABpAB2YCQwAhiOdcPQGgoMAQYDg4CB wACgP5AM9AP6An2A3kAvoCfQA+gOJAHdgK46qougC9BZR3UVdAI66qhugg46KknQHkgE2mGsLdYl AG2wrjXQCmiJmS2A5ljeDGgKNAEaA42wWUOgAXapD9QD6mKzeCAO6+oAtYFaQE2gBhALVMfW1YCq 2LMKUBmohK0rAjasM4AYIBqoAEQB5XX5HoJyQKQu31NQFohApxWwoLMMUBowYywcCENnKcAEhGKs JFACKI6xYkBRoIgu10tQWJfrLSgEFERnAbQUEJIP9Rh4lD9FPUTrAXAfuIexu2jdAW4Dt4CbOrKf 4IaO7Cu4jtY14CpwBWOX0boEXAQuYOw8cA6dZ4EzwGngFKacROsEWsfROgYcBY5g7DBwCJ0HgQPA fmAfpuxFaw+wW5cdINily/YX7AR2oHM7sA3YCmzBlM3AJnRuBDYA64F1mLIWWIPO1cAqYCWwAliO mcvQWgosARZjbBGwEJ0LgPnAPGAuMAcz/0Hrb+AvYDYwS0e0EWgdMUTwJ/AH8DvwG/Ar8AvwM/CT jpDf1+pH7PID8D3GvgO+Bb4Bvga+Ar4EvgA+x2afYZdPgU8w9jHwEfAh8AEWvI/We8C7wDsYexu7 vAW8ibE3gNeB14BXgVcw82W0XgJeBF4AZgIztNUueF5bUwTPAdO1NVUwDZiqrcmCKdoqv4zVZG1t LJgETMTyCVg3HhinrU5BHpaPBXKBMUAOEAD82NqH5aMBr7Y6BB5slo2ZWUAmkAGMAtxYlw6k4c5S sdwFODHTAaQAdmAkMAIYjocehjsbCgzBQw/G1oNwoYHAANxuf1woGbv0A/oCfYDe2pIg6KUtwSv0 1Jbg591DW6YLumtLHUESpnQDumqL5ALVBa3OQCd0dtSWSYIO2jJT0F5bJgsStWWKoJ0u3VHQFkgA 2gCtdWn59121QqulNg8StACaa3Pw02gGNNXmToIm2jxQ0FibBwsaYawh0ECbawvqY2Y9bQ4+WF1t Dv5sxgNxWF4HV6gN1MJmNYEa2CwWqA5UA6pqc/CUqgCVsWcl7FkRm9mwiwHEYF00UAGIAsoD5XT4 MEGkDh8uKKvDRwgiACtgAcoApbHAjAXh6AwDSgEmIBQzS2JmCXQWB4oBRYEimFkYMwuhsyBQAFBA SMLjsBQjWI/CHMbDMKfxQPy+1D2pu9J3R/puS92Suil1Q/qvS12TsavSviJ1WeqS1EXpvyB1XsbO Sfus1Bmp01KnSqUZJ0ulGyekjksdkzoqfUeEh6UOSR2U9gHhfql9Unul9pgyjN2mesYu4U5TprHD VM3YLrVNfKuplrFFarPUJhnfKH0bTFnGevF14mvF15hGGatNbmOVKd1YaUozVsja5bLfMqmlUgmP l8jfi6UWSS0MHW0sCPUZ80P9xrzQgDFXas5/qKnv8KaqOIzj95cUrA1tUqCLtNwqAtYAFhWJojZt IYzQRXugLdAyCmUIhbRhlAbKUlTK3rPscRkpW0XBva17oVL3FlTco35T/Jt/kdN87jn35N773DxP 3xfH2T+Go3x3hO8Os3cIdQjgoGW6fsBSqe+3VOn7LH7dsMzU92IPdmMXdmKHpbO+nXkbtnLPFuZa y3h9M+tNrDdiA+v1PGsdz1rLs9awtxqrsBIrsBzLuG8pz1sSlqkvDsvSF4WV6jVhO/SFYbv0+eb2 +jyzU58rTn2OqlazjWo1S/nVTMOvLH6x+O1+j3+G3/Cf8bsymodVqUo1w6hU09VUNc2YqqYYPhXi a+2r8Jkv+MTwSU+fJPvEpPlsvkSfuUWF8qpyw6s0b7a32hvwhvQIeBu8Js0rYScaTx/22tu6mV1V 3nCbe7IqU5OMMjVx9AQ1jtca6yxVY4xSNdpZokYZJWqkc4Qa7hymip1DVZExVA1xFqrBRqEqcOar QVw/0JmnlJGncp05aoCRo7KcmSqT/QynR/U3PKqfs4/qa/RRvZ1u1YufrMXb4hPjzbbgC2TG8yaa XdKS7S57g/28PUSzB+yn7eaW1jZ6G1OSNU7Ss+KkLG5W3OI4szW2Ptbkik3q5LbG1MecjTkXE9LK FZPUxa1F26ITo81Rwd8WnZHnbppTel6cu3Zr+q0Z0e06uK1RYo3So0y99CjRIhsiz0eao07Z6m0m q1Ws1karyWXlcmuEHmEKHhojzK6Irt3d1nA93BQ8NIabo13h7ASf2LFFdp7batEtJpViybKYXJaU dLfL0jnZrZklUUQTG5M5lGuPSJTuNp9kS9OaaSJL6vJyHQ7PiVBtgCcQmj04IAsC7XODR1dOYaD5 goCmCgfn14ksKqgTU3peoLUnp/Di+fyaGi0hzRNIyM0/ZK6tTUgr8ASqg2uXq2ndGFxrXFLgKCr3 lTscFUUcisorHE0fzsQXPHMEN4Of8grOg3++pnPNcclx8TKm4nJGxX97FZe+6f8+5HK/wJU/6jT+ TfNTG03ztBLTXMzBbFRjFmbCjyrMQCWmYxqmYgp8qEA5JmMSyjARE3A3xmMcxmIMSjEao1CCkRiB 4RiGYhRhKIZgMApRgHwMwkAo5CEXA5CDbGQhExnoDw/6oS/6oDfc6IWeSEcaUuFCCu7CnbgDPXA7 boMT3XEruuEW3Iyb0BXJuBFd0Bmd4MANSML16IgOaI/r0A7X4hokQkdbJCAedrRBHGIRg2hEoTVa oSUiYYMVEQhHC1gQhqsRiqvQHM0QktrI0QwTBJpWIuzJP/gbf+FP/IHf8Rt+xS/4GRfwE37EDziP c/ge3+FbfIOv8RW+xBf4HJ/hU3yCj/ERGnAWH+IDvI8zeA/v4h28jbfwJt7A63gNr+IV1ONlvIQX 8QKex3N4Fs/gaTyFJ/EEHsdjOI1TeBSP4CQexkN4ECdwHMdwFEdwGIdQhwAO4gD2Yx8M7MUe7MYu 7MQObMc2bMUW1GIzNmEjNmA91mEt1mA1VmElVmA5lmEplmAxFqEGC/EA7sd9WIB7cQ/mayWp1UL+ hfwL+RfyL+RfyL+QfyH/Qv6F/Av5F/Iv5F/Iv5B/If9C/oX8ixd0gNABQgcIHSB0gNABQgcIHSB0 gNABQgcIHSB0gNABQgcIHSB0gNABQgcIHSB0gNABQgcIHSB0gNABQgcIHSB0gNABQgcIHSDkX8i/ kH8h+0L2hewL2ReyL2RfyL6QfSH7QvYvdw9f4aPgcr/AFT5ii4v+FWAAV9hl5w0KZW5kc3RyZWFt DWVuZG9iag0zOCAwIG9iag08PC9TdWJ0eXBlL0ltYWdlL0xlbmd0aCA2Mjg1L0ZpbHRlci9GbGF0 ZURlY29kZS9OYW1lL1gvQml0c1BlckNvbXBvbmVudCA4L0NvbG9yU3BhY2UgMzEgMCBSL1dpZHRo IDY0MC9IZWlnaHQgNDgwL1R5cGUvWE9iamVjdC9EZWNvZGVbMC4wIDI1NS4wXT4+c3RyZWFtDQpI ieyXi7ajIAxFVf7/n+sDLSgKYsBDPHtNaWsxMNcNCV1HCCGEEEIIIYQQQgghhBDybczI/42QqkzW jS/7RkhdrHT0j7yCWRLvvAUa7yIhEUT82+Rz/Dt2S4iUMlq1MO3NWGWYeIxQ/Uf/GEYmTDwG/WOY cmESgix53Evn9I9hZMLkcQw8xG9K6FIxDNiMVUL/IIZ64t+tM+Scou4+dHeE7bNTaj2QqKJ/JIpf Qp9/Ptx09YtXHZnOnN5gvALqZATPv3WAswnEoX9ImOUYZ6wJ5qZ/xjdo9c49Hc4jOPe6D2pv//XQ 9E8fvn8muPH4hz3PON8/e7vvX7fTZT+C1d78I9u5/H/rnItez6z/ceZ9GYGxqimsoWyX3QYW8s/Z pDyrQrj51+59+5gHfbc79/tm99fZsXE3pZE+hj/F+N8mD/qXEWZNkP+9599l55+/La1dAvq6iXdv 696/QOjb/t2D+ReJdP8OWXX57co/+/G8qgyG/uvrTIn+6WT/JG/6Fwp3vME9gITOH/f8i04i8j/O u+3FwJq52s7Wb/7B46L2D9ywCHd5w/buZ+Nuu3d/OHlj/1sPaJenrz2s/56FUUmuf4GP/hKgf9Jh VPJg/7OfAhfzA5NzsFaDUJj8/e9/9jlcXL6NDNMU2Mg0g0iX8SXRRaK5qF0T+J+G9heXT9mByYeo 6B/Wxo81FOu/e3cZP91uLtK/cmFUkrn/2cy9HULsN54/CoK1GoTCyGgSKCPpnzRY4kD5VzMw0URF /7AWHtZQrP/KB8Z6mlhD0b9mAn8WrNXA+u9rYIlD/4gCWP9BDMX6r3xgrKeJNRT9aybwZ8FaDUD1 n5lZ3wQDExcscaD8c98EAxP1iO1/29tpYKyFhzUU678nMWb51rft4sgw/V3XZui8r6Emocv4kuhS sxlEuuhr/A3rGYcczPwrDdZuDFT/zXHoX2mwxAHyL5x/BQIT9YhoYvM4zx9Fw6ik2DZF/6TDqKSi f+QZWKsBqP6rG/izYIlD/4gCWP9BDMX6r3xgrKeJNRT9aybwZ8FaDaz/vgaWOPSPKCBPEzOzvB8u ngXGWnhYQ7H+u3eX2d4c47xY9E86jEoe7H9H/7zd8PnciAfWani1/nPE8/e/nY3DNAU2Ms0g0mV8 SXSRaPwN6y7zrfsAV/UfIQee+XfQl+ePcmFU8ij/brbZvZD+lQyjksz9bz1//N+3i88Ck1OwVoNQ GBlNAmUk/ZMGSxwo/2oGJpqo6B/WwsMaivVf+cBYTxNrKPrXTODPgrUaWP99DSxx6B9RAOs/iKFY /5UPjPU0sYaif80E/ixYqwGo/jMzy7toYOKCJQ6Uf9vbX0D6RxIQ2//i/mEtPKyhWP89ibGIN//7 +zcxTH/XtRk672uoSegyviS61GwGkS76GuMVbM+w8jH/lgNrNwaq/+Y4hvVfYbDEAfLvn3/pH7mH iCY2j3vpnOcP6TAqKbZN0T/pMCqp6B95BtZqAKr/6gb+LFji0D+iANZ/EEOx/isfGOtpYg1F/5oJ /FmwVgPrv6+BJQ79Iwpg/QcxFOu/+3ea8d/E/4L37XAD1tPEGor+3b7Rqub6JxKYnIC1Gl6u/9at zpHO2/7onzhY4rzr35x87QfnWrfLxsM0BTZsgo2/Yd1hU21/P+u/cmFUkuufVZf+1QujkvwyzU23 m4tX/pFnYK0GoTAi/m2bIc8fBcES53X/vCjHMPSPJFBME9Z/0mFUQv8ghqJ/zQT+LFirAar+qxn4 s2CJQ/+IAlj/QQzF+q98YKyniTUU/Wsm8GfBWg2s/74Gljhg/hkz/puQDkxUI6SJmf27Doy18LCG Yv33LIpZ97+LwFhPE2so+vcoiLH/nD1wtnGY/q7JTV+QG9NAbQaRLuNLootE429Y+TjiZdZ/qyPF KBm7Fli7MdD5wzl43PavuHnrOOWHIBlIHVOP+ffQ5bgcDuaVW3gH/9rbKlQi6F93+/xRUQr6h4mU f1mBKyZFBfkXazUA1X/ZgWtK0b6AWOLQv3u0759KKvr3av13GKu9rUIl9E9+qEJhVPKZ/Nt+AsZa DQrqv7pG0D/EMPSPvMmb9d/RiJILr0/oIzRUmTAq+Y5/u+HoHwT5/hkzvYxxLrhf4fJv8wkYazW8 Xf9Nqi0K/q/cDEz/boElzsv+mZB/3m4Yj1FbiNYF1Eimf1a+br//7WwcpiWwNkPnfR198L+GugSa IbtLH7mtVDOIdNHX+BvWHTbV9gGu6r+3zx/+eO2lKpXk+reoe9AX+fzRev7FWg1vnz+cFLztheD+ NS4gljgY/q3b4JqMoc8fjfunknz/vCjHMID1nzdge1uFSmT8SwpM/56FUUlF//a8kA2bTsBYq+H1 +u9xYPp3Dyxx6F8GTfunkhfrv4AMpRden9BHaCj5MCr5ln/OmPQPgm/l36YTMNZqYP2XA/0DCyPl nzHTy/zD0T+SgJB/k3mLgueBEeq//6DtbRUqkfHP0L/yYVQi4t8i3/zv79/EMP1dz5r+8tdCTV9/ SKlmEOkyviS6SDTGK9jysRvfugfai9Hb3qnF2q0AsXZjoTAy/iXl3z30j0idP7pW6r9t1Pa2CpUI +td56Zz+SYdRiZR/9wO/lQibTcBYqwGo/ssLTP9ugiUO/cukWf9UUtG/3XIIeVBj4fX1hpINo5Lv +WcHpn8QfC//NpuAsVYD679c6B9QmJgmxmQaSv9IAteamAWZwCj13zJye1uFSi7dWtTLE5D+SYdR ybV/p52WXdHfHXffYiO/lwYbTcBYq+HV88ci3/ax231KCvyiBW0KiCXOq/7Nd5p/ay+4mZr+kQSi mphgn001zz9/NxwZpiWwNkPnfe39r6EuwWZ43qWPBZBtBpEu+pqUs+3Y4aSTPZsELi6fDjf423Fw D6q08ff1hhIMo5Kof9M/Gf98Xs2BTSZgrNVQqf4zwQS8ptpVt81F+lcOLHFq+Tcn4NBlZ/vbvt04 f9A/0mWfP/adAoYeruDUf9Pg7W0VKom7JRYYyL9xdPoHwaV/4YOvQODu7RTYYgLGWg016j+voLsJ /ZMGS5w65498AekfSSB+/sg0ELv+6/r2tgqVpJxtswykf9JhVJKilpB/Pi9nwAYTMNZqqFP/5UP/ pMESp6J/WY6C+/f6+GQmpsn0ezT/LiWiMW6pGKn/wo+/4sJL8Q9rq1BJin+xTot8O03pn3QYlVyr ZYy/qV317PyekXveT3/vz+AmWKuhSv2XqN+af91UPd84TFMINv3ZD9Wa92dwsxlEuowviS4STYpb qWcPG+iq/vN4f/d5fwYk82wbihP3D6v+GxIExEpVKknyL/38Qf/KhVGJhH+2/uvaOn8gTOEWWKuh xvljPdTmJGl8/yDmcAMscejfYxDm8HWiqTWlU1pgtPovLiDWVqESkfov7R769yyMSnLUkggMkfsg JpEM1mqoUf/NHfLKvyb8A5lFIljiVPJP8/kDZRZf5qXzx8mDr71+I/5hbRUq+bZ/EQHpX3Eu1TIr 0oFhEh/KPFLAWg016r9z/+xF7ze/K/2TBkucSuePk7vM/LJvzsXUwDDPHWYiHyXq32n+Dfjn7YaH GxDrv2v/sLYKlUTPH5f5t9vvfzsbh+nvujZD9//auz+Eu5w1g0iXtekT+z1pBpEu+pqUo8V5j7UA PF5cPl2GxUl7ODOJgbUb16r/Lv07/Ej/yoElTiX/wvnXOX9s3/f59zIszlPHmckneVT/rT/aLi2e Py4FxNoqVBLNv2lRAoYertC/Z2FUIuPf7cBIWQ9pLldgrYYa9Z9J6ZQTGOqZI83lCixxqvi3lnUJ gW4FhnrkUJP5GtdqmZPjR1ZgZzmcPfJ31u+pgFhbhUpibmXaR//kw6jknfMHVsrDms0pWKuhRv33 hIb8Q5vOCVji0D85wKbzJUT8s2cU76jSUP33ZDqs/54h4d9k3fiyb6eBcf07mw/9K45U/k3wzwEt 4aHNJwjWakCq/5bEOyto3GtmmKYQaPqzH15q+tdnkNAMIl3Gl0QXicZ4BdszrHyN7n94E/oKFfMv cP13MiGsVKWSS//MSiRG8+cP+vcWEv7Z+q/zeraVfwFndABrNQiFiaqV0ul2YLynjTejA1jitOwf 4sNGnNMHSEmt0fybFvi/HE6f9YvrNzQnrK1CJVG1MvWjf+JhVJLl1tPAkLkOclIuWKuhUv3XyeXf P5CPGnJSLlji1Dp/0D9SkKh/U48vnD9Cs8LaKlRC/zb6w7ToX3ES/PtI/u0mA1FnNoG1GmqdP6YS MHRtuuoXh7tvFxGBnzKwglji1PMvdJfZtHT9Sw0M+4hngBXUR9S/YPr9++f86G1/DdZ/DlZBrK1C JdH6z5zVfwH//N1wZJj+rmszbJ/6zvsh1OW8GUS6RJtRQYEonZ2MQBd9zalaDmZrdtcP+nX+93bz 70aPlYmxduNK9d+Jf6tnWf4hPdQYQA5iiVPLv+Amuddvft/l3/OYKA80FSAH1ZF7/lgu259sn9Tz x/nDxFq/bp8zB3n+eEbUv7QoAUUPV5r2b6JfKDEU/XvcKf2expNZ34dELA9W4Vap/kvvlH5P4/5t VLYQS5wa/pmVhEA3Amvxb4FnkydU9K/5+u+sS8xA1n/nXPuX0ik5sFr/YgbSv3NY/8lQoRDEKtxq nj9y+Jh/XflCEEsc+ocHjyK3qeif4vpvI2gg679zRPwzI0trtnjf9G8uBPf/P/p3joR/i3yd8WJ9 Mf+u9H3AwsdgFW5A9d/mn7P9XQRWr59F2kIscYD8m+OYVcPtwsgwTWHf9IFreptFwtengdj4G9YT tjgp9d/FloC1fuWGim6DrP+ufo92MoFPh14f9m/eBp+GUUmKWrFN0v6+y7+n3b9S/+15WgtiFW5C YaL5NyFHG5vIef6I8MxALHFq+Rfd/W4H/q5/0TT8PS7lMisigT9d//0JGsj6L/gj/SsRpp+5HUYl ecn1UWBmoJl+JfUGrMKt5vlDZv9boX8+/TVbPyxxKvknmH9X6N8tInpGpEUn6p9cYNZ/z8LcIUva NzSmfxBDgZ4/yhtZP/+2kxvAgFgNQtvo9hP9awYI/7LCXBiZmV+tlJ6bvqr0jySQ5N+h06TZ+LJv zsWrwHY5XPmHtX7BdhyViPrn7YaHKPTvWRiVXPo3K3ZW/9mr/v63s3GY/q67pg9cY5PQDCJdxpdE F4kmerS48M9e3P/G+q8cWLuxUJhY/jXhTofNz79+FZj+kT/59V/n2DZ/2OXfQxTWf8/CqCTJv+Nd S1Zek7NN0Tx/FA2jkrz979AhkKHP+jL/ZoK1GirVf+mdUu+hf5lgiUP/iAIq+sf671kYlVyrZcyP /bJRdxSEgagr7//OW6tWfqJSAe8Uz9nv0lXjQO2QxPUVo4Iw/iuT6ZIb/TdD+b2K1m64s/+7Av6r jZZx8B90wI3+m7fDof+09q9YqugS/CcxFf4rEplfUYI3FepvbbR2g1D/N7nu9bd8nAjjv6toGQf/ QQfU6v9m/3kFeCrGbpy2wDqM7//9C85Fw7h3wRvGKiF3DmOVkP4GFzRsJbg597nD/Mf7R5lMl1R6 /1hH6m87tHaDWP834L/WaBlHyn9uLcCbHP6DDGq9f2QI0/+VyXTJ3f47Tn9apsB/7bnRf28ov5fR 2g1C/d83wvjvMlrGwX/QAfR/ElPR/7UXxn9lMl1C/f0ZtHYD/d/T0DLOH/vPufcwsZ0Kjuz78B/4 XPTfZjTff8fC9H9lMl1yzX/uYzbPdEH6w3/VZbqkqP4Okf/CbPhinJ5rMPwb0nMMWcNYJeT1VyOk xhAmrO9Ybozvp/9rh1Y2riSD/+AvKfNfUIWj+pvcMm2HE/tp7V+xVNElF98/ltL9yYKLAU/fP/Df dZkuuZr/IpVUxham/F5Hazf8cf93URj/XUfLOPgPOuBG/9H/lcl0Cf6TmAr/3SNM/b2O1m6g/3sa WsbBf9AB9H8SU9H/tRfGf2UyXVLHf869h4ljYervdbR2g1L/5xb/nQvjv+toGUfIf87LfyfC+A8C qtZfPwe+3ThOW2AdXv/+eYfWMB5enYexSsidw1glpL8hTFglfGSO+r/xPP1p1Q+xUtUlN/pvoPwW obUbhPo/u/5acfivAC3jCPnPLYX8/P0D/0FInfyXJUz/VybTJfhPYir8d4sw9bcArd0g1P/lC+O/ ArSMg/+gA+j/JKai/2svjP/KZLqE+vszaO0G+r+noWWcX/Qf9oOIq/5zbh6d8075h1b/d+o/rf0r liq65KL/ZqNNg+e4QAv/1Zbpkmv+c4PpvyAbGrdRf0vQ2g1/3P99nBbmv8iN47SEbfgXHjJ8NYxV Ql5/NUJqDGHC+o7lxljgqP8j/0FC6fuHedoWpv8rk+mSIv+FRTiqv8kt+K9Mpksuvn/MpXv5GJY6 zvtHU7R2wx+/f0QqqQz+q42WcaT8lymM/yDiRv/R/5XJdAn+k5gK/90hTP0tQWs30P89DS3j/KD/ sB/E3Nn/nftPa/+KpYouwX8SU+G/G4Spv0Vo7Qap/s+5eXSbHP6rjZZxlPw3+24aNgPiP8ighv/c kOU/+r8ymS6pWH+dG7wCPBVjN07PdR3Gf8GhNYyHV+dhrBJy5zBWCelvcEHDVsLiP0f9bYhWNlbq //LqL/4rQ8s4+A86oMr7x1LIg3LO+0dtmS6pk/+yhPFfmUyX3Og/6m8ZWrtBqv/LEsZ+ZWgZB/9B B2j5T2v/iqWKLsF/ElPhv/bC1N8ytHYD/d/T0DIO/oMOaOe/fwnnN2ntX7FU0SVF/nNvdo6SaK1f U2sq/HdZwKX/qyIMEVq7QaT/80wXpD/8Vx0t4yj6L8yGL8ZpCQwM5hAmrEvE99P/tZPpEvwnMRX+ u3a38z6j+lskDClau6GSTBX/LXWc94+maBlHwn8flVQG/0EGzWxC/1dbpkvwn8RU+O9nhB+L1m6Q 6v/uFH4sWsbBf9AB9H8SU9H/tRfW+jW1psJ/PyP8WLR2g17/5940EIY3WsZR9F8jYeiX2vnvQFhr 42lNRf9XQcr5OfDtxnF6ruswDsGhNWSEvP5qhNw5jFVC+hvChFUF+r92aGVjvf7vLYf/mqFlHD3/ RfW3njD0S02b8P7RVKZLmqUp/Fdbpktu9B+UobUb9Pq/m4Qfi5Zx8B90AP2fxFT0f+2FtX5Nranw 388IPxat3UD/9zS0jIP/oAPo/ySmov+7dveL4GA7xH+1ZbqkyH+T2zzHBVrU39po7QaF/i/2X5AN S4TBQMs4Cv57CwT5L3LjOC2BgcEcwoR1iViA/q+dTJeUvn/snsB/tWW6pLj/2/4T1d8SYTDQ2g2V ZAr9N1fwpY7z/tEULeMo+G9TSWXwH2TQzCb0f7VlugT/SUyF/35G+LFo7Qap/u9O4ceiZRz8Bx1A /ycxFf1fe2GtX1NrKvz3M8KPRWs3/F7/lzFVzmruk/m9FXcpk417cSD8e1/851bcpUwuk/k2A+I/ ZOrI5IL/kGkhk8vLe14BdgAZ1PSfG2rqAXxDWH8B7gX/wZ9St5wDAAAAAAAA/B7uzfyZdy09Mu/f Dq/LWIv6hA7Z1+ypkvvTFX8vk/8YDy8GRxmP+LrMF4tqxmuSebaca0akdX+08ksyu4tartjPJrlm T5Xcn674e5n8x3h4MQ3NeMSXZL5YVDPWaayp0mvml0rORjvHlvl+Kv/CkTWjtZgrTs6lK05kvp9q 77sdXjSsdvqIc57xl4/Y1KjPsgYzn9jXzC8e5nrz+Tn/i1vVJJHZ99hRakyvWeuPV5isOP290xWn OenrX9O+aKwmOBkv2IhJVmzKHDzGW+rvOpP1cMxr1pcKY9KtehqSFeOHHv+YSW47iTFXfBySFRNF Hq448vFxyP5q9mNyZMLQO/Lf8sPvP7jompla4qweN7lGiO2/nOLwrf92kmGS3Br7b+entC7mJdqT hL3jv8OQZAHN/bctKp0qurYNJzFDGLcnYz+b/ZhI+ei5+d7YsV/iH2OPxTKGRQ9j4u9mEF20VmyF xIp7MubPcLbgQ1NU5vP49n/p5dr8sZspvBjv/G6IuX2PY4LQJAEY145WHMaYK45CdhLOUcz5gnNW nLHgnNXkL/jQFH9HzmIyYirJ5NDlim/8UgAAAAAAAAAAAAAA8Bc4Z50zTpqR34Sc3p8xAfSCW0x2 brX14MAeGSHF9oWemH7q/Z/b9N+JWoUY/PcYtozl5qPVkOvxsKZI59YY4+RHxAtZxIYgZJ1wi0w/ MOCDCOqvmx0U+W8I0+Tnih/pXdoT80PC2xMx/PckNqvZ/nNrrovCc/0X5Ujvw5vPvx3/PQrff6Gr /JMX/LfV4Hi2IZDcQkh/D8O02q7/9iM/amch1jVzWngE3nuE//LhV87gtcI/ORjmssXCGT/T7n3c 9/UBAADgKfwfAMXEiogNCmVuZHN0cmVhbQ1lbmRvYmoNMzkgMCBvYmoNPDwvU3VidHlwZS9JbWFn ZS9MZW5ndGggNjE0OC9GaWx0ZXIvRmxhdGVEZWNvZGUvTmFtZS9YL0JpdHNQZXJDb21wb25lbnQg OC9Db2xvclNwYWNlIDMxIDAgUi9XaWR0aCA2NDAvSGVpZ2h0IDQ4MC9UeXBlL1hPYmplY3QvRGVj b2RlWzAuMCAyNTUuMF0+PnN0cmVhbQ0KSInsl4uWqyAMRa38/z+P7wFEQAh4jGevW9paDL3TTRKG gRBCCCGEEEIIIYQQQggh5NuYif8nQroyWzc9tidC+rJJR//II5i18C4p0DgXCUkg4t8hn+XfeVpG pJzVuoV53zdWGSYdI9T/0T+GkQmTjkH/GKZdmIwgax13yjn9YxiZMGWcA4/pmzKmdAwD9o1VQv8g lqrx79YZcilRd390e4XjtdVqVUjU0T+SxG2hvYbm6i96/fOvnzjdkRnM5Q3GWe9iBce/fYGrL5CG /iFh1mOcWU3wDnRp/4zxjDWDfzpc4lr32j+UZ39oBe8i/dNFjn/uYc8xzvVvS3Suf4Oni5/a1sc+ /q9gfTZYF52ZRf/jwvsKAmN1U1hLbVPM6ac8+WdJeVLUx66/W+7zjTvpe9zp583hX2fLRu8rTfxS uF8x/bcpg/4VhNkLpJV7jimef+EU6err5r+Arb5/gdC3/bsH6y8Snn+hSnmhxfZZzL/t5XCeYr2+ Es/aEgP900q443PexfwLhTvfYB9AQuePe/4lv0Tif1x224OBNRNLZ/9JcS/N/7XyItjphlW46A3H s1uNh+Ne/3DyRP47Dmix05cP+7+6MCop9S/w0isXp5uwfk2spejfvbuOTOeY6BzX6r4XOYG1G4TC lOe//7PP6eL6bmKcvwIHmWEUmTI9JKZIDJHeNYP/05B/cX1VHJh8iI7+YSV+rKXY/927y7jl9nCR /rULo5LC/LdV7uMQsr3j+aMhWLtBKIyMJoE2kv5JgyUOlH89AxNNdPQPa+NhLcX+r31grF8Tayn6 95rAnwVrN7D/+xpY4tA/ogD2fxBLsf9rHxjr18Raiv69JvBnwdoNQP2fWdifBAMTGyxxoPyznwQD E/WI5b/j6TIw1sbDWor9X02MRb796bg4Mc5/130YB+dtaMiYMj0kpvQcRpEp+gY3YdVxqsGsv9Jg ZWOg/m+JQ/9agyUOkH/h+isQmKhHRJOtjvP80TSMSpqlKfonHUYlHf0jdWDtBqD+r2/gz4IlDv0j CmD/B7EU+7/2gbF+Tayl6N9rAn8WrN3A/u9rYIlD/4gCyjQxC+vz6eJVYKyNh7UU+797d5njyTLO iUX/pMOopCL/nf1zsmH9dyMOWLvh0f7PEs/Nf56N4/wVOMgMo8iU6SExRWJwE9Zdllv9ALH+j5AT df6d9OX5o10YlVTV38O2LRfSv5ZhVFKY//bzx//zcbEuMLkEazcIhZHRJNBG0j9psMSB8q9nYKKJ jv5hbTyspdj/tQ+M9WtiLUX/XhP4s2DtBvZ/XwNLHPpHFMD+D2Ip9n/tA2P9mlhL0b/XBP4sWLsB qP8zC+uzaGBigyUOlH/H07+A9I9kIJb/0v5hbTyspdj/1cRYxVv+/fs3M85/130YB+dtaMiYMj0k pvQcRpEp+gbjNGx1bPKx/rYDKxsD9X9LHMP+rzFY4gD5919/6R+5h4gmWx13yjnPH9JhVNIsTdE/ 6TAq6egfqQNrNwD1f30DfxYscegfUQD7P4il2P+1D4z1a2ItRf9eE/izYO0G9n9fA0sc+kcUwP4P Yin2f/fvNNO/mf8LzrvTDVi/JtZS9O/2jZtqtn8igckFWLvh4f5vT3WWdE76o3/iYInzrH9L8d1e WNcGrxqP81fgwCE4uAnrDodq/v3s/9qFUUmpf5u69K9fGJWUt2l2uT1cjPlH6sDaDUJhRPw7kiHP Hw3BEudx/5wo5zD0j2TQTBP2f9JhVEL/IJaif68J/FmwdgNU/9cz8GfBEof+EQWw/4NYiv1f+8BY vybWUvTvNYE/C9ZuYP/3NbDEAfPPmOnfjHRgohohTcziXzww1sbDWor9X10Us+e/SGCsXxNrKfpX FcRs/6wcuNg4zn/X7OFXyo01XjyMIlOmh8QUicFNWOVY4hX2f7tGZRTf+C6wsjHQ+cM6eNz2r868 PUjl/eQxpI6p5/p7mnLeDifzCjee7x/7v9cg6N9w+/xxylv072tI+VcUWKpufqP+Yu0GoP6vOLCY N58QEEsc+tciEOlMR//a9X9+IPZ/r4H+1c2hf3XoqL+fKMBYu0FB/ycoDf3LnQIWhv6RJ3my/ztL U7zxfukpUks9FkYlSvxzY9G/11DunzHzwxjrgv22b/39QgHG2g1P93+zaquC/1duBqZ/t8AS52H/ TMg/JxumY9A/UujfJt/g5z/PxnHeAvswDs7byRn3bWhKYBjDH/zSU54aRpEp+gY3Yd3hUM0PEOv/ mp4/nGA8f7yGUv9WdU/6Pnb++EABxtoNT58/rBJ85EL61xIscTD829PgXowfO398QUCNlPvnRDmH 6d3/2dHY/70GGf+yAtO/ujAq6eifj3DBVF9/sXbD4/1fdWBpYbQLiCUO/Wsdj3Tgwf4v4EvVxvul p0gt9UgYldC/ujn0rw5F9Vd7AcbaDez/2gfEAkscMP+MmR/mPxz9IxkI+Tebtyp4Hbh1//cfkP3f a5Dxz0D4d0Skf69BxL9VvuXfv38z4/x3vRp+0U9Lhp9wPKxhFJkyPSSmSAzGadjK2RLfngO3i8nb 5Ns13Q0gVjYWCiPjX1b99aF/ROr8MUD0f3tI9n+vQdC/wSnn9E86jEqk/LsfuEWxVF2AsXYDUP9X Fpj+3QRLHPrXLShpR0f/vO0QUqV64/1kwuTPYf9XB/2rm0P/6mD9fQ1Yu4H9X8eoEGCJ08k/YwoN pX8kg7gmZkUmcI/+b43K/u81RN1a1SsTkP5Jh1FJ3L/LSWtWdLOj9y61cqNKqbcAY+2GR88fq3zH y8F7lRWY/t0ES5xH/VvuNP/jdsGu1PSPZJDUxATnHKo5/rnZcGKct8A+jIPz9ue+DU0JDmN8yi89 pfcwikzRN+ScbacJF5O2s0ng4vrqdIObjoN5SiLx/3j+eBFJ/+Z/Mv65NKuTagsw1m7o1P+ZYAHe S+2u2+Ei/WsHlji9/FsKcOiylf6OdzfOH/SPDMXnD39SwNDTlU7933ywkQiTN4f9Xx1pt8QC07+6 MCqJ+hc++AoEHlqWSa0FGGs39Oj/nIbuJvRPGixx+pw/ygV8zj+1Amokff4oNPC5/m/4sf97DTln 2yID6Z90GJXkqCXknwvr712wdkOf/q+cB/1TKiCWOB39K3KU/pEMUprMnyfr79oiGmO3ion+L6yI 0MbL8e99qUIlOf6lJq3yeZrSP+kwKomrZYyb1GIzB3dm4p62JVJlAcbaDV36v0z99vprl+rlxnH+ CsHhd/WByPBrFvnBYRSZMj0kpkgMOW7lnj22QLH+z4H5j8wUnW1DcdL+9ev/xgz/3leqVJLlX/75 A8S/jARI/yCQ8G/r/wac84fKAoy1G3qcP/ZDbUmRpn/SYIlD/x4MT6RIltacSXmBe/Z/aQHflypU ItL/5d1D/+rCqKRELYnArQukwgKMtRt69H/LhLL2j/6JgyVOJ/9eev5QKaBGHjp/XNghuPFS/r0v VaiE/tUv1SmMSqJqmR3pwB2qo776i7UbevR/1/5tF53P3KlP+6dPQCxxOp0/Lu4yy2N7si7mBqZ/ ZCHp32X9DfjnZMPTDX37v5R/70sVKkmeP6L1d/Dzn2fjOP9d92Ec/t/+7A/CU66GMXPKLz2v0zCK TNE35BwtrmfsDeD54voqGrZHcdRWgLGyca/+L+rf6UP61w4scTr5F66/1vnjeO/X32hY+kcWqvq/ /cNtCtb5I+Hf+1KFSpL1Ny9KwNDTld7+xQWkfxDI+Hc7cJfaqKwAY+2GHv2fyZlUEpj+FYAlThf/ 9rYuI9CtwH3MUOafSuJqmYvjR1FgaztcmSG88WICvi9VqCTlVqF99E8+jEqeOX90qoy6CjDWbujR /9VA/6TBEof+ZaBLQI2I+LedUZyjCkL/F/PvfalCJRL+zdZNj+3pMjD9qwujEqn6m+GfRbe6qKkA Y+0GpP5vLbyLgsa+Zsb5KwSG39UH0kO3hToMo8iU6SExRWIwTsNWxyYf8x+5Rcf6+0D/F/HvfaVK JVH/zE4iBuz5IyIg/YNAwr+t/xucmRj1V1MBxtoNQmGSauVMuh2Y/hWAJc6b/esohSL/VJJTWpP1 Ny9wxqmgwcbr12q2DqOSpFqF+tE/8TAqKXKrNnDPoqinAGPthk793yBXf/+hfyVgidPr/PF2/xQJ qJGkf/OMN58/rhZ7X6pQCf0TXKptGJVk+Mf6iwHWbuh1/phbwNC1+arbHHrvIhH7KqFFQCxx+vkX usscWtr+5Qamf2Qj6V+w/P77Z33opD+c/u9itfelCpUk+z9z1f8F/HOz4cQ4/133YTxe/Qbng9CU 62G8O+VytV7DKDJF33CploU5Bu/6Sb/BfY9Tf7UUYKxs3Kn/u/Bv96zIv94+0D/cMGX119dvefbq 73VM+kd2Ss8f6+Xto21O7vnj2oc2Gy+43vtShUqS/uVFCSh6uvKYf8EF6R8EWf6VSApUf5UUYKzd 0Kn/y5+Ufw/9KwJLnB7+mZ2MQDcC0z+y09G/5/q/0IrvSxUqifuXMyk7MP2rC6OST/R/Ogow1m7o ef4ogf5JgyUO/buDCgE10tG/B/u/4VdHxlJ1cdn/VQWZWEdzxMPyr3JOlaKRperc14CEf6t8g3Fi YdXfFyOdRvX1f4d/VvqLBKZ+ZdSl0SKKvs2dKWL935b/rPo7M85fwR9+gWscIIezkZLh3YRVwxEn p//L6eYjPNH/QYSBQDrDpvwzxxCbZAKvTrPoX10YleSolUqS2+de/b2czv6vDKzd0Kv/y6jRZivk PH80BUucXv4ls9/twPSPHETlMjsigdn/1YVRCf2DWIr+9QvM+lsG1m7oef6QyX879K8MLHE6+SdY f3foHzlI+icXmP1fXRiV0D+Ipejf1efi9ZfltxCs3fDa/o/+FYIlTif/rm5bpXTcdFWlfySDLP9O k2bNpsf2ZF2MBd62Q8w/rP0LlipUIuqfkw1PUehfXRiVRP1bFLvq/7arbv7zbBznv6s3/ALXOGQM o8iU6SExRWJIHi0i/m0X/c/Y/7UDKxsLhUnVXxOedEp+7vVYYPpH/inv/wbLtuWFV39PUdj/1YVR SZZ/57vWqrwX561E8/zRNIxKyvLfaUKgQl/NZf0tBGs3dOr/8ifl3kP/CsESh/4RBXT0j/1fXRiV xNUyZj9iCASmf3VhVNLRvxWW31KwdkPP/q8E+icNljj0jyigo3/rdoj6h7V/wVKFSugfxFL0ryrI ekRxTiqsv9Jg7Qag/m+2bnpsT4nA9K8ULHHoH1GAVP+3+mcV4LkYm3HeAvswLq/+2C8bNVdBGIi6 8v7vvLW1lZ+oKGCneM79ll41DtQOSfwLzkXDuHbBG8YqIVcOY5WQ/gYXNGwluFfuc5v5j/ePMpku qfT+8R6pv+3Q2g1i/d+A/1qjZRwp/7l3AV7k8B9kUOv9I0OY/q9Mpkuu9t92+tMyBf5rz4X+e0L5 PY3WbhDq/44I47/TaBkH/0EH0P9JTEX/114Y/5XJdAn192fQ2g30f3dDyzhf9p9zz2FiORUc2ffh P/A56b/FaL7/toXp/8pkuuSc/9zHbJ7pgvSH/6rLdElR/R0i/4XZ8ME4Pddg+BvScwxZw1gl5PFX I6TGECasY8w3xvfT/7VDKxtXksF/8E3K/BdU4aj+JrdM22HHflr7VyxVdMnJ94+5dH+y4GzA3fcP /HdepkvO5r9IJZWxhSm/59HaDV/u/04K47/zaBkH/0EHXOg/+r8ymS7BfxJT4b9rhKm/59HaDfR/ d0PLOPgPOoD+T2Iq+r/2wvivTKZL6vjPuecwsS1M/T2P1m5Q6v/c7L99Yfx3Hi3jCPnPeflvRxj/ QUDV+uvnwKcbx2kLvIfHvz/v0BrGzauvYawScuUwVgnpbwgTVgkfma3+b9xPf1r1Q6xUdcmF/hso v0Vo7Qah/s+uv1Yc/itAyzhC/nNzId9//8B/EFIn/2UJ0/+VyXQJ/pOYCv9dIkz9LUBrNwj1f/nC +K8ALePgP+gA+j+Jqej/2gvjvzKZLqH+/gxau4H+725oGecX/Yf9IOKs/5x7jc55p/xDq//b9Z/W /hVLFV1y0n8vo02D57hAC//VlumSc/5zg+m/IBsat1F/S9DaDV/u/z5OC/Nf5MZxWsIy/IWHDIeG sUrI469GSI0hTFjHmG+MBbb6P/IfJJS+f5inbWH6vzKZLinyX1iEo/qb3IL/ymS65OT7x6t0zx/D XMd5/2iK1m748vtHpJLK4L/aaBlHyn+ZwvgPIi70H/1fmUyX4D+JqfDfFcLU3xK0dgP9393QMs4P +g/7QcyV/d++/7T2r1iq6BL8JzEV/rtAmPpbhNZukOr/nHuNbpHDf7XRMo6S/16+m4bFgPgPMqjh Pzdk+Y/+r0ymSyrWX+cGrwBPxdiN03N9D+NfcGgN4+bV1zBWCblyGKuE9De4oGErYfafo/42RCsb K/V/efUX/5WhZRz8Bx1Q5f1jLuRBOef9o7ZMl9TJf1nC+K9Mpksu9B/1twyt3SDV/2UJY78ytIyD /6ADtPyntX/FUkWX4D+JqfBfe2Hqbxlau4H+725oGQf/QQe0899fwv5NWvtXLFV0SZH/3JOVoyRa 69fUmgr/nRZw6f+qCEOE1m4Q6f880wXpD/9VR8s4iv4Ls+GDcVoCA4M5hAnrFPH99H/tZLoE/0lM hf/O3e28z6j+FglDitZuqCRTxX9zHef9oylaxpHw30cllcF/kEEzm9D/1ZbpEvwnMRX++xnh26K1 G6T6vyuFb4uWcfAfdAD9n8RU9H/thbV+Ta2p8N/PCN8Wrd2g1/+5Jw2E4YmWcRT910gY+qV2/tsQ 1tp4WlPR/1WQcn4OfLpxnJ7rexiH4NAaMkIefzVCrhzGKiH9DWHCqgL9Xzu0srFe//eUw3/N0DKO nv+i+ltPGPqlpk14/2gq0yXN0hT+qy3TJRf6D8rQ2g16/d9FwrdFyzj4DzqA/k9iKvq/9sJav6bW VPjvZ4Rvi9ZuoP+7G1rGwX/QAfR/ElPR/527+0FwsBziv9oyXVLkv8ltnuMCLepvbbR2g0L/F/sv yIYlwmCgZRwF/z0FgvwXuXGclsDAYA5hwjpFLED/106mS0rfP1ZP4L/aMl1S3P8t/4nqb4kwGGjt hkoyhf57VfC5jvP+0RQt4yj4b1FJZfAfZNDMJvR/tWW6BP9JTIX/fkb4tmjtBqn+70rh26JlHPwH HUD/JzEV/V97Ya1fU2sq/PczwrdFazf8Xv+XMVXOaq6T+b0VdymTjXuwIfx7X/znVtylTC6T+RYD 4j9k6sjkgv+QaSGTy8N7XgF2ABnU9J8bauoBHCGsvwDXgv/gq9Qt5wAAAAAAAAC/h3vy+sy7lh6Z 9y+H52WsRX1Ch+xr9lTJ/emKj8vkP8bNi8FRxiM+L3NgUc14TPKaLeeaEWndH638lMzqouYr9rNJ rtlTJfenKz4uk/8YNy+moRmP+JTMgUU14z2NNVV6zfxSydlo59gyx6fyL2xZM1qLueLkXLriROb4 VGvfbfOiYbXdR5zzjA8+YlOjPvMazHxiXzO/eJjrzefn/C9uVZNEZt1jW6kxvWatP15hsuL0905X nOakw7+mfdFYTXAyXrARk6zYlNl4jJfU3/dM1sMxr1lfKoxJt+puSFaMH7r9Yya5bSfGXPF2SFZM FLm54sjH2yHrq1mPyZEJQ6/If/MPv/7gomtmaomzetzkGiG2/3KKw1H/rSTDJLk19t/KT2ldzEu0 Owl7xX+bIckCmvtvWVQ6VXRtGXZihjBuTcZ+NusxkfLWc/O9sWK/xD/GHotlDItuxsTfzSC6aK3Y CokV12TMn2FvwZumqMzn8a3/0vO118dqpvBivPOrIeb23Y4JQpMEYFzbWnEYY644CllJOFsx+wvO WXHGgnNWk7/gTVN8j5zFZMRUksmhyxVf+KUAAAAAAAAAAAAAAOAbOGedM06akUdCdu/PmAB6wc0m 27fa+2DDHhkhxfaFnph+6vWf2/TfjlqFGPx3G5aM5V5Hb0O+j4d3inTuHWOc/Ih4IbPYEIS8J1wi 0w8MeCOC+uteDor8N4Rp8nPFj/QurYn5IeHtiRj+uxOL1Wz/uXeui8Jz/RflSO/Dm8+/Hf/dCt9/ oav8kyf8t9TgeLYhkFxCSH83w7Taqv/WIz9qeyHWNXNauAXee4T/8uFXzuC1wj85GOayxcIZP9Ou fVz39QEAAOAu/A8ANhCKrw0KZW5kc3RyZWFtDWVuZG9iag0xIDAgb2JqDTw8L0Nyb3BCb3hbMC4w IDYxNzMuMDMgNTk1LjMyIDcwMTQuOTVdL1BhcmVudCA2IDAgUi9TdHJ1Y3RQYXJlbnRzIDEvQ29u dGVudHMgMiAwIFIvUm90YXRlIDAvTWVkaWFCb3hbMC4wIDYxNzMuMDMgNTk1LjMyIDcwMTQuOTVd L1Jlc291cmNlczw8L1hPYmplY3Q8PC9JbTAgMyAwIFIvSW0xIDQgMCBSPj4vQ29sb3JTcGFjZTw8 L0NTMCAzMSAwIFI+Pi9Gb250PDwvVFQwIDMwIDAgUj4+L0V4dEdTdGF0ZTw8L0dTMCAzNSAwIFI+ Pj4+L1R5cGUvUGFnZT4+DWVuZG9iag0yIDAgb2JqDTw8L0xlbmd0aCA2NjkvRmlsdGVyL0ZsYXRl RGVjb2RlPj5zdHJlYW0NCkiJ1FZNbxMxEL37V/hSaRexzsz4GzU99IOqiFZUrMQBcUBNSQpqSwOI v8/Ym5Rks2kP3S1CkUYbr9fveeZ5nkfv5O7u6PTg5FCC3NvbPzyQ4k6A9IBGRSttdMqTllUwqCLJ +aX4IG/Efs1z0m8+FaO6Bomy/iIqUKBlfSERFTiXJ6RHw8up6FyULmqtPPDC9bX4WByXFcVinuPn HL9z9MUsR1lWmgpdfqrfiKNanD+NmHWdzBCcCojYpvaqrExMFGwoznqgsAmMUWkCtw7MiPXX3qEI VTDOtqDGg0B5pX1sQ/Wwq1RDT901pKh8sNSuIZaVd8VLjpQq6XTxticxwRYxGas0oG8TuS0rpKRw W0wG0ZIjRQ4HyHoHlFHOeXoOLXHXIIA2VA+7Sn3KdFfQk3JgNzoVlRoK25N6tsk4MGKkDRlDlnEj 4J1B5BPT+YlhmEPb7QgEpDTajaPyIjd93iwhn9ZKm+IqG8NNtoRvPIILY9hfsY3m7YSPmSt+57fN V5M8/jOPzIZIHfmo0G+01mXqjk7ZT0d/PRaXHtsnBxOQey6yZh3S4xyoBw5cVgwPO72NoNDEuHR6 TEaPqWCYbJ7LO0tBllwyU6JhxyXb/D0rSTdP4xRkyTXs6xqw7expq4wOts37n5jHOoXnM49V3KEt +95G1jc75nybRb4p970+mu4DrXZtzzCEi4WojLGm//R29HG+59l0l12D2hkEamkZQ4jmMctY18x/ axmdqWu3az2sZZCL2zi8vpr+ml/eEzGrRPiaZAkbx3FkpYHAfd9KDVZFXm1B506Mjt+DnP4QzQR0 EGLmobkL5kX4shXNYiHriZjnxbUYnVyDPLxlrE4utotL3orHp3NJCxEgpgQ1XHCFy7n4I8AA5bsb tQ0KZW5kc3RyZWFtDWVuZG9iag0zIDAgb2JqDTw8L1N1YnR5cGUvSW1hZ2UvTGVuZ3RoIDYyNzEv RmlsdGVyL0ZsYXRlRGVjb2RlL05hbWUvWC9CaXRzUGVyQ29tcG9uZW50IDgvQ29sb3JTcGFjZSAz MSAwIFIvV2lkdGggNjQwL0hlaWdodCA0ODAvVHlwZS9YT2JqZWN0L0RlY29kZVswLjAgMjU1LjBd Pj5zdHJlYW0NCkiJ7JeLtqMgDEVV/v+f67uAgAgRj/HsNaWtxcBcNyF0HSGEEEIIIYQQQgghhBBC yLcxI/83QpoyWTe+1jdC2rJKR//II5hl451ToHEuEnKCiH+7fJZ/x24ZkXJGaxbmfTNWGeY8Rqj+ o38MIxPmPAb9Y5j7wmQEWfZxZzunfwwjE6aMY+Dh/KaMLg3DgM1YJfQPYqga/y6dIect6upDt0fY P1ulVoVEDf0jp7gldPzz4abID0u8//v0WEz0BuMUUJERHP+WL/RPC2Y5xlnK2L9Fb7JuN25aMrtt +zdjPxonGfr2p4emf/pw/TPBxOMe9jzjgv6ZTZWALv4IVqZ0RrB+66yLTs+i/3HhfQWBsaoprKHW LsZ7lIHPVpKytIjx77LmPj/mQd/Afc5Ae+MK/Y/Sn+FO8PxvUwb9KwizbZD/3PPv4vnnpqWti6+v 8eIesl8gYbqhL/t3De6/SOT752ux/ub455i1KxOvKoOh7V2c/inHf5IX/TsGC91gH0BC549r/mUU Acn/cdltDwbWTCqdbd/cg0ei9g/csAiXvGF/d3fjbr/XP5w8kf+Mdf6J/bkON7H+qwujklL/Ah/d JUD/pMOopCL/rZ8CF8sDkzhYq0EoTHn++599DheXbyPDNAU2Ms0g0mV8SXSRaBK1awb/05B/cflU HJh8iIb+YSV+rKFY/127y7jb7e4i/bsvjEoK89+6c++HkPUbzx83grUahMLIaBIoI+mfNFjiQPnX MjDRREP/sBYe1lCs/+4PjPU0sYaif68J/FmwVgPrv6+BJQ79Iwpg/QcxFOu/+wNjPU2soejfawJ/ FqzVAFT/mZntTTAwscESB8o/+00wMFGPWP7b36KBsRYe1lCs/2pizPJtb/vFkWH6u27N0DlfQ01G l/El0aVlM4h00de4CauOwx7M/VcarGwMVP/Ncejf3WCJA+RfeP8VCEzUI6LJuo/z/HFrGJXclqbo n3QYlTT0j9SBtRqA6r+2gT8Lljj0jyiA9R/EUKz/7g+M9TSxhqJ/rwn8WbBWA+u/r4ElDv0jCijT xMws74eLscBYCw9rKNZ/1+4y+5tlnBOL/kmHUUlF/jv652TD+rkRB6zV8Gj9Z4nn5j/PxmGaAhuZ ZhDpMr4kukg0bsK6ynyrHyBV/xFyoM6/g748f9wXRiVV++9u25oL6d+dYVRSmP+288f/fb9YF5hE wVoNQmFkNAmUkfRPGixxoPxrGZhooqF/WAsPayjWf/cHxnqaWEPRv9cE/ixYq4H139fAEof+EQWw /oMYivXf/YGxnibWUPTvNYE/C9ZqAKr/zMzyLhqY2GCJA+Xf/vYXkP6RDMTy37l/WAsPayjWfzUx FvHmf3//Jobp77o1Q+d8DTUZXcaXRJeWzSDSRV9jnIKtjlU+7r/3gZWNgeq/OY5h/XczWOIA+fff f+kfuYaIJus+7mznPH9Ih1HJbWmK/kmHUUlD/0gdWKsBqP5rG/izYIlD/4gCWP9BDMX67/7AWE8T ayj695rAnwVrNbD++xpY4tA/ogDWfxBDsf67fqcZ/038LzjfDjdgPU2soejf5RtX1Wz/RAKTCFir 4eH6b0t1lnRO+qN/4mCJ86x/8+a7frCudd5uPExTYMMm2LgJ6wq7av79rP/uC6OSUv9WdelfuzAq KS/T7O12dzHlH6kDazUIhRHxb0+GPH/cCJY4j/vnRDmGoX8kg9s0Yf0nHUYl9A9iKPr3msCfBWs1 QNV/LQN/Fixx6B9RAOs/iKFY/90fGOtpYg1F/14T+LNgrQbWf18DSxww/4wZ/01IByaqEdLEzP6l A2MtPKyhWP/VRTFb/ksExnqaWEPRv6ogZv1n5cDZxmH6u2Y3fVMuTQ2hGUS6jC+JLhKNm7DKscQr rP8WIwSmcmHIpqNJgJWNgc4f1sHjsn8PmLeN/MSgxEPqmHrcfw9djsvhYF7L9ZvhH1aqUImgf93l 88dBAfr3NaT8Kwr86Bb4uv0XazUA1X/FgZ9V4G0CYolD/2p5m38qaegfWP2X4R9WqlDJh/07F5D+ 3c6T++/TG+DT418EazUoqP+efv5Pj38RLHHoXzVPj0+erf+Oz7/x+j0TECtVqIT+tRlKIIxKyv0z ZnoZY12wv75g/31+ApfAWg1P13+TaouC/ysXAz//+J+fwQWwxHnYPxPyz8mG5zGef/rPz+DrFPq3 ytf5+c+zcZiWwNYMnfN1fPru11CXQDOIdInN4I5mEOmir3ET1hV21fwAqfoP7/xxlgCxtiqVlPq3 qHvQ913nD4gpZIO1Gp4+f1hb8J4L6d+dYImD4d+WBrfN+GXnD4QpfJty/5woxzDn9V/g2bdfv0kB sVKFSmT8ywpM/+rCqKShfz4Qex/EJPLAWg2P13/VgTEePcYscsASh/7JgDGLz/L1+i/pH1aqUAn9 azdUZRiVfH7/RZnGOVirgfWfECDTOAdLHDD/jJle5h+O/pEMhPybzFsUjAfGrP9SAmKlCpXI+Gfo X10f+lcVxOz//v5NDNPfNdb0yV/bNf3jM8hrBpEu40uii0RjnIKtnDXxbTlwvXh6G0rhhTKPM7Cy sVAYGf+y9l8PnMeOM5PvIXT+6K7Xf6Gn/sz6jfqHlSpUIuhf52zn9E86jEqk/LseGGjXA5pKAqzV AFT/lQUGeuhAU0mAJQ79kwNoKl+joX+w9V/UP6xUoRL6F5vLTUOVh1EJ998JpLlEwVoNrP8EQZpL FCxxGvlnTKGhr/IPazJfIq2JWZAJDFz/RfzDShUqSbq1qFcmIP2TDqOStH/RTktWdLOj9+1kYLAd D2w6IbBWw6Pnj0W+/WPnfcoJDPbAwaYTAkucR/2b7zT/dr1g79T0j2Rw6p8J9tlVc/xzs+HIMC2B rRk6+2vfOV9DXcLNINLFb/rLd+Q3g0gXfU3O2XbsEOm0nk0CF5dPhxsyKv4H94/C4xDPH3Wc+jf9 k/HPBW3DQ5vPEazV0Kj+M8ENeNtqN912F+nffWCJ08q/eQMOXbbS3/7tvecPwAl9gsLzh98pYOjh Cnb9F5oQVqpQyblbYoHpX10YlST9Cx98BQJ3gNsd3IR8sFZDi/rPKegu8jr/AGfkgiVOm/NHuYD0 j2Rwfv4oNPCk/gs/7EfX73FKWKlCJTln2yID3+ffcU7073Zy1BLyzwFxs0OckwXWamhT/5VD/6TB Eqehf0WOvtA/zEnp5syt6ffT/XcpEY2xS8UX1n+HSWGlCpXk+HfWaZHP05T+SYdRSVotY9yklurZ uT25/0qDtRqa1H+Z+m37r71VzzcO0xSCTR/74dEGc1ZrM4h0GV8SXSSaHLdyzx5roFT954CZajBn pZmis20ozrl/+PWfPyusrUolWf7lnz9e7p83Lfp3OxL+rfVf9/rzB+y0ZrBWQ4vzx3aoLdmk6Z80 WOK82z/Y5ww7MaWcbq05nfIC28sh8pifX799Rh+hoa6GUYlI/Zd3D/2rC6OSErUEAuNuc7gzw1oN Leq/uUNZ+Uf/xMESp5F/Xzt/AM9MJTx/+PQZfYSGuhZGJfTPh/61JKmW2ZAOjLzLwU4NazW0qP/i /q0Xnd/crvRPGixxGp0/IneZ+bW+WRdzA8M+5A57buo49S+6/wb8c7Lh4YaX1H/W3LBShUpOzx/J /bfz859n4zD9Xbdm6P5fe/uHcJdYM4h0STR9xb3BZhDpoq/JOVrEe2wF4PHi8ikVFXuLA50dVjZu Vf8l/Tv8SP/uA0ucRv6F91/r/LF/9/ffVFTQJ7yCPTtdVNV/249rl/zzR+wJg6zfPqOP0FAXwqjk dP/NixIw9HCF/tWFUYmMf1cDg+9wmNPDWg0t6j+T06kkMOYD/gM5Pyxxmvi3lXUZgS4Fhny+Fujz 00NaLRM5fhQFfk/9t80PK1Wo5MytQvvo37U+9K9pYPj9DXGCWKuhRf1XA/2TBksc+ncn8BPUgoh/ 6xnFOaqk6r/o08VZv327oXLDqETCv8m68bW+RQPTv7owKpHafzP8+/OC3Q1wilirAan+WzbeWUFj XzPDNIVj0weuoTX94zPwm0Gky/iS6CLRGKdgq2OVT03+e8UcFdBw/31V/TfPEWurUknSP7NxEkPh +WOeJP27HQn/1vqvc3q+ff/FmyTWamh0/jA5na4Ghnu0IeAmiSUO/bubd8zy5eRsraf7b17gl9V/ 4yyxUoVKTtUq1I/+XepD/1oGfsfOhjZLrNXQqP7r5PbfHbQHGwNsnljitDp/0D9yI6f+TT2Ezx/x 54q1fnusVKES+pcgIwHSvzoy/Pvs/tv1UDPFysatzh9TCRi6Nl11i0PvWzwg1FNNg2Qgljjt/Avd ZXYtbf8yAwM903N6JAX1cepfcPv9+2f96KQ/FfXf2idlIOu/Ok7rPxOr/wL+udlwZJj+rlszbJ/6 /zWvGWI/WM0g0uVaMxtYHGAQ6aKviaplYfbGu37Qr3O/a9l/VwC2YazCrVH9F/Fv8+wz/nXPn0Ww xGnlXzBJ+vrN797+G4/5Uv/mJPjauYNSev5YLq8/rX20nj8c+t6xkOePOk79y4sSUPRwRYd/C7uF 9K+OLP9KJI3fo2cL83LhzWAVbo3qv/xO2ffo8W+hlYVY4rTwz2xkBMoPrM2/hba5UA0N/duWQ+Ih Ya3fgqGCDrL+i5P2L6dTduAv+DdxMJD+xWH9dwP37MNYhVvL80cJX/bvHgOxxKF/2PAskkVD/75S /230GX2uzEYlIv6ZkaU1ezz6t6dA+hdHwr9Fvs44sb6+/86IbsJYhRtQ/bf7Z6U/+rcgaCCWOED+ zXHMpuF+YWSYpuA3feCa4qb/2P83v3ETVg17nIz6L5UQsNav1FB9lEthVHLmn8nqZAKfDr0+61+8 T8LIj5Cj1lmSXH/39t9Y78/9iS8Rz5WV7CO8rP7L2KPNupHnnT/oXyF1T/yKo0j+nWa/q4HpHyzx pHkbSbnMhkhg1n91YR4gsY0LQf8ghgL178ilUjODss21JjD330KwVsOVUjMRJuv8IZP/ttkVBCPd i/w7dEnkytyz7WXoH8ng1D+5wKz/6sKohP5BDEX/Yr9z/0UBazUIhWnuH/UrBUucRv7FblukdNx0 VaV/JIMs/w6dJs3G1/pmXUwFXpZD0j+s9QuWKlQi6p+TDQ9R6F9dGJUk/ZsVi9V/61U3/3k2DtPf 1W36wDU2Oc0g0mV8SXSRaE6PFgn/1ov+b6z/7gMrGwuFOdt/TbjTIfm51xOB6R+xKK//Osu2+YO3 /x6isP6rC6OSLP+Ody278rY5r1s0zx+3hlFJWf47dAjs0JGu3H9LwVoNjeq//E6Z99C/UrDEoX9E AQ39Y/1XF+bHfrloOQoCQTQr///PG6NGHq2igFPBe88ZMkpboBZN2yX71nJu+cSoIPx5xvvpT8sU +K89N/rvA9vvZbRWw5313xXwX220jIP/oANu9B/1X5lMl+A/iaHwX5HI9IkSfKmw/9ZGazUI1X+j 695/88++MP67jJZx8B90QK36b/KftwGPm7EbxiWwNMPY/HsF56Jm2O2dmqFKyJ3NUCWkv8YFBVsJ bsp9bjf/8f1RJtMllb4/lpb9tx1aq0Gs/nvhv9ZoGUfKf27ZgFc5/AcZ1Pr+yBAel8OB/bTWr1iq 6BL8JzEU/rtHmO33OlqrQaj+OyGM/66jZRz8Bx1A/ScxFPVfe2H8VybTJey/P4PWaqD+expaxvlj /zn3aUbWU8GReRn+g4CL/luN5vtvX5j6r0ymS675z33N5pkuSH/4r7pMlxTtv6/If2E2fDOMz9Vv /oWHNCeaoUrI+69GSI0mTFjnmC+Mrz+o/yj/CtDKxpVk8B/8JWX+C3bhaP9NLhmO/ae1fsVSRZdc /P6Yt+5vFpwNePT9gf8KZLrkav6LVFIZ9t/aaK2GP67/rgnjvwK0jIP/oANu9B/1X5lMl+A/iaHw 3y3C7L8FaK0G6r+noWUc/AcdQP0nMRT1X3vh4Tj9aZkC/7Wnjv+c+zQje8JsvyVorQal+s/N/jsS xn8laBlHyH/Oy3+7wvgPIqruv34O/LhxGJfA0rzrP//Qaobd3qkZqoTc2QxVQvprwoRVwldmr/7j +6NMpktu9B/7bxlaq0Go/rP3XyMM/5WgZRwh/7l5I+f7A85SJ/9lCVP/lcl0Cf6TGAr/3SHM/luC 1moQqv+yhfFfCVrGwX/QAXfWf8f201q/YqmiS/CfxFD47wZhtt8itFbDD9Z/+K8ILePgP+iAq/5z bmqd8075h9R/tWW65KL/JqONjee4QAv/1Zbpkmv+cy/Tf0E2TK9i/y1CazX8cf33dVqY/yI3DuMU vs2/8JDmXDNUCXn/1Qip0YQJ6xzzhbHAXv1H/oOE0u8P87QtTP1XJtMlRf4LN+Fo/00uwX9lMl1y 8ftj2rrnn9e8j/P90RSt1fDH3x+RSiqTnsF+ZWgZR8p/WcL4DxK0/Ke1fsVSRZfgP4mh8F97Yfbf MrRWA/Xf09Ayjrz//iW0Ggp+lxvzn9bC0xqK+q+9sNbb1BoK//2M8GPRWg1S9Z9zU+tWOfxXGy3j KPlv8t3YrAbEf5BBDZu4V5b/tBae1lDUf2Uqs/+8DXjcjN0wPtelGV7BodVkhLz/aoTc2QxVQvpr XFCwlTD7z7H/NkQrGyvVf3n7L5ShZRz8Bx1Q5ftj3siD7Zzvj9oyXdIsTeG/2jJdcqP/oAyt1SBV /90p/Fi0jIP/oAOo/ySGov5rL6z1NrWGwn8/I/xYtFYD9d/T0DIO/oMOoP6TGIr679LFHzaOkmit t6k1FP67LODS/6oIQ4TWahCp/zzTBekP/1VHyziK/guz4ZthnAINjdmECesS8fXUf+1kugT/SQyF /65d7bzfaP8tEoYUrdVQSaaK/+Z9nO+PpmgZR8J/X5VUBv9BBs1sQv1XW6ZL8J/EUPjvZ4Qfi9Zq kKr/7hR+LFrGwX/QAdR/EkNR/7UX1nqbWkPhv58Rfixaq0Gv/nMfGgjDBy3jKPqvkTD0S+38tyOs tfC0hqL+qyDl/Bz4ceMwPtelGV7BodVkhLz/aoTc2QxVQvprwoRVBeq/dmhlY7367yOH/5qhZRw9 /0X7bz1h6JeaNuH7o6lMlzRLU/ivtkyX3Og/KENrNejVfzcJPxYt4+A/6ADqP4mhqP/aC2u9Ta2h 8N/PCD8WrdVA/fc0tIyD/6ADqP8khqL+u3b1m+BgPcR/tWW6pMh/o9s8xwVa7L+10VoNCvVf7L8g G5YIg4GWcRT89xEI8l/kxmGcAg2N2YQJ6xKxAPVfO5kuKf3+2DyB/2rLdElx/bf+E+2/JcJgoLUa KskU+m/awed9nO+PpmgZR8F/q0oqg/8gg2Y2of6rLdMl+E9iKPz3M8KPRWs1SNV/dwo/Fi3j4D/o AOo/iaGo/9oLa71NraHw388IPxat1fB79V/GUDmzuU/m92bcpUw27s2O8O/d+M/NuEuZXEbzrQbE f8jUkckF/yHTQiaXt/e8DdgBZFDTf+5VUw/gDOH+C3Av+A/+lLrbOQAAAAAAAMDv4T5Mv3l96ZF5 /Xp4Xcaa1Df0ld1nD5Vcn874vEz+Y9ztDI4yHvF1mROTasZ7kGm0nD4j0ro+mvklmc1JzT32s0n6 7KGS69MZn5fJf4y7nWloxiO+JHNiUs1YhrGGSvvMm0rORivHljk/lN+xZ81oLuaMk3PpjBOZ80Nt 3dtup2G1w0ec84xPPmJToz7zHMx8YveZNx7mevP5Of/Grd0kkdn22F5qTPus+cczTGacvu90xmlO Ov027U5jNsHJeMJGTDJjU2bnMd6y/y4jWQ/H7LNuKoxJl+phSFaMH7r/MpPcdhBjzng/JCsmityd ceTj/ZDt2WzH5MiEoXfkv/nFbz+4qM9MLXFWj4tcI8T2X87mcNZ/G8kwSW6N/bfxKq3OvER7kLA3 /Lcbkkyguf/WSaVDRX1rcxDzCuO2ZOxnsx0TKe89N98bG/ZL/GOssVjGsOhuTHxvBlGnNWMrJFbc kjFfw9GEd01Rme/j237Tc9/0s5kpvBjv/GaIuXz3Y4LQJAEYfXszDmPMGUchGwlnL+Z4wjkzzphw zmzyJ7xrir8jZzIZMZVkcuhyxjfeFAAAAAAAAAAAAAAA/AXOWeeMk2bkmZDD6zMGgF5ws8mOrbYc 7NgjI6TYvtAT46veft2m/w7UKsTgv8ewZiw3HS2GXI5fS4p0bokxTn5FvJBZ7BWELAOukekPBnwQ wf7rJgdF/nuFafLb40d6XVtifkh4eSKG/57EajXbf27JdVF4rv+iHOn9eOP5l+O/R+H7L3SVf/KC /9Y9OB7tFUiuIaS/h2FabdN/25FftaMQq88cFh6B9x3hf3z4O2fwWeGffBnmssXCEb/Dbv3cd/sA AADwFP4PAOqJimQNCmVuZHN0cmVhbQ1lbmRvYmoNNCAwIG9iag08PC9TdWJ0eXBlL0ltYWdlL0xl bmd0aCA2MTU4L0ZpbHRlci9GbGF0ZURlY29kZS9OYW1lL1gvQml0c1BlckNvbXBvbmVudCA4L0Nv bG9yU3BhY2UgMzEgMCBSL1dpZHRoIDY0MC9IZWlnaHQgNDgwL1R5cGUvWE9iamVjdC9EZWNvZGVb MC4wIDI1NS4wXT4+c3RyZWFtDQpIieyXi5aDIAxErfz/P7c+C8pLCDjGmbPFqnHotpckDANFURRF URRFURRFURRFURRFUdS7ZX76Hyiqqybqfq/1QFF9tUJH/qhbZJbCO6dA41ykqIRE+Nvhs/g7h2U4 5czWzeZ5n1ilTdrD1/+RP9rI2KQ9yB9t2tlkmCx13Cnn5I82MjZlOhuP6YcyQjragH1ilSJ/EFPV 8HdpDzmXqKs/uj3D/t5qtSog6sgflZTbQh8amtA3Grmx+P2P089igg8YZ77ADA5/ywn50yKzbONW ZA4bujR/xiHI2hbaZ8b+aZxkeKDfN8PhIvnTJZe/5cr/3h5j3EOKP7Oh4sHlmNqsTOnMYN0brItO ZNF/XPhcgTFWN4U11RriAuStv1aSOqXIs/4ha+47EnfC1/OcM9E+uED/XT4puR8w/d2UifwV2GwF MpL/7CR1LtFuJnJx8tDqTZiu9WX+ron1F0n5/B2xWO8Fdix2AR0OiLrvQ+Dt1uRPsY44XeTvbOZ7 wN6A+PYf1/jLaAKi/3HZYzcaa9bhlzw1g1t13E6jvb/ngQW46AP70a3Gw/7scXNyR/4z1v4nkP3Z /0nbqFQpf5637hIgf9I2KlWR/9Z3novlxlRYWKtByKY8//33PqeLy9lP4/QROMgMo0jI7yURIjFE etcM/XdDx4vLu2Jj6kXqyB9W4seaiv3ftaeMW253FslfOxuVKsx/a+XeNyHrGfcfDYW1GoRsZDDx tJHkT1pY4EDx19OY0qSO/GEtPKyp2P+1N8b6NbGmIn+PMX6tsFYD+7+3CQsc8kcpEPs/iKnY/7U3 xvo1saYif48xfq2wVgNQ/2dmbQdBY8oWFjhQ/NkHQWNKvcTy334IGmMtPKyp2P/VeMzwbYf94k/j 9L1uwzg4p74hI+T3kgjpOYwiIfoGN2HV6VSDWX+lhZWNgfq/2Yf8tRYWOED8+euvgDGlXiKYrHWc +4+mNirVLE2RP2kblerIH1UnrNUA1P/1NX6tsMAhf5QCsf+DmIr9X3tjrF8Tayry9xjj1wprNbD/ e5uwwCF/lAKVYWJmLcfTxZAx1sLDmor937WnzH6wiHO8yJ+0jUpV5L8zf042rP9slCOs1XBr/2eB 5+a/A43j9BE4yAyjSMjvJREiMbgJ66rmR48Gsf6Pok6q4++EL/cf7WxUqqr+7rStuZD8tbRRqcL8 t+0//sf9Yp0xFRTWahCykcHE00aSP2lhgQPFX09jSpM68oe18LCmYv/X3hjr18Saivw9xvi1wloN 7P/eJixwyB+lQOz/IKZi/9feGOvXxJqK/D3G+LXCWg1A/Z+ZtRxFjSlbWOBA8bcf/gCSPypDYvkv zR/WwsOaiv1fjccC3vz352/SOH2v2zAOzqlvyAj5vSRCeg6jSIi+wTgNW51W+Fh/2wkrGwP1f7OP Yf/XWFjgAPH3r7/kj7omEUzWOu6Uc+4/pG1UqlmaIn/SNirVkT+qTlirAaj/62v8WmGBQ/4oBWL/ BzEV+7/2xli/JtZU5O8xxq8V1mpg//c2YYFD/igFYv8HMRX7v+tPmt/fpP8F5+z0ANaviTUV+bv8 4IqazZ+IMRUQ1mq4uf/bUp0FnZP+yJ+4sMC5l7+5+K5vrGvDoRqP00fgwME7uAnrinbUjs+z/2tn o1Kl/K3okr9+NipV3qbZ5XZnMcYfVSes1SBkI8Lfngy5/2goLHBu589xOduQPypDzTBh/ydto1Lk D2Iq8vcY49cKazVA9X89jV8rLHDIH6VA7P8gpmL/194Y69fEmor8Pcb4tcJaDez/3iYscMD4M+b3 N0namFItIUzMzF/cGGvhYU3F/q/OxWz5L2KM9WtiTUX+qkzM+mflwJnGcfpes4dPqS7M8eBhFAn5 vSRCJAY3YZXLAq+w/9swKlPxg88SVjYG2n9YG4/L/NWRt5lUPk/dJqlt6rn+nkLOy+FEXuHCO/LH /u8xEuRvuLz/OOUt8vc2SfFXZCxVN99Rf7FWA1D/V2wsxs0rAMQCh/y1MKI6qyN/7fq/oxH7v8eI /NXFkL863Vl/BavmGwow1mpQ0P+Rv0vCAof8NbKieurO/u8MTfnC+6RDpKa6y0alyF9dDPmrUzl/ xkwvY6wL9mnf+vuGAoy1Gu7u/ybUFgT/Vy4ak79LwgLnZv6Mjz8nG6Y9RJl5AYAaVcjfCt9wzH8H GsdpCWzDODinP2TcU1+IZxj9Nz7pkLuGUSRE3+AmrCvaUTsaxPq/pvsPx4z7j8eolL8F3RO+t+0/ XlB/sVbD3fsPqwTvufBO/vQDiAUOBn9bGtyK8X37D/38qVQ5f47L2Sbd/3mAqVl4n3SI1FT32KiU DH9ZxuSvzkalOvJ3lHTB1F6AsVbD7f1ftTH5uyYscMhfaz+qg/T0f5Yh+7/HiPzVxZC/Oimqv9oL MNZqYP/X3hBLWOCA8WfM9DJ/uxv40w6gRgnxN5G3IBg2bt7/7Y7s/x4jGf4M+Wtvo1Ii/C3wzX9/ /iaN0/caGj7RuyXDR9gPaxhFQn4viRCJwTgNW7nWxLflwPVi8rEG3ZrqBhArGwvZyPCXVX8PasGK av5USmj/MVzv/3ys1C68j4zNhRj2f3US5G9wyvkt/K2m5O8xkuLvunGTWqm5AGOtBqD+r8yY/F0U Fjjkr5sp1U4d+evR/y2u7P8eI/JXF0P+6qSs/mouwFirgf1fR1cIYYHTiT9jCgm9iT/NAGpUHBOz SMa4S/8327L/e4yibC3olQFI/qRtVCrOXzBoyYpudjycJSZuVSf11l+s1XDr/mOBb387HN7lGDfj RC2AWODcyt/8pPmP6wW7UpM/KkNJ/ow3ZkfN4c/Nhj+N0xLYhnGwTz+Dc+oL8Q9jIuSTDuk8jCIh +oacve0vIBC07k08F5d3pwfcdOxNUyKJ/8P9x3OU5G/6k+HPVbsyqbUAY62GTv2f8RbgrdRuuO0s kr92wgKnF39zAfZdttLffoaw/1DLn0oV7j+OQR5CT1d69X/Dh/3fY5RmS8yY/NXZqFSUP//GV8B4 aFollRZgrNXQo/9zGrqLIn/SwgKnz/6jHMAb+dMKoEal9x+FBCb6Pz8iQgsvh7/npQqVytnbFhFI /qRtVCoHLSH+HDUtkTrrL9Zq6NP/letO/nQCiAVOR/6KGCV/VIZSbE33k/V3aRGNsVvFO/u/MYO/ 56UKlcrhLxW0wHfAlPxJ26hUHC1j3KQWixzcyFvrr8oCjLUauvR/mfht9dcu1fOD4/QRvMMndENm aGx/yzCKhPxeEiESQw5buXuP1SjW/zli/qMmFe1tfT5p/jr2fxn8Pa9UqVQWf/n7DxT+0gCSPwhJ 8Lf2fwPQ/kNjAcZaDT32H9umtqRIkz9pYYHzbP6a46GQP5VKltacoDxjezkE8GD/9zaJ9H95z3Tl Lwkg+YNQCVoCxu3Lo74CjLUaevR/c0BZ+0f+xIUFTif+nrr/UMifSmndfyQBfF6qUCnyJzBVHxuV iqJlNkkb96iO6gow1mro0f+F+VsvOvfcUPInLSxwOu0/Ak+Z+bUerIu5xuSPmpXkL1h/Pfw52fD0 QOf+LwHg81KFSiX3H9H6Oxzz34HGcfpet2Ec/qcf+4Y/JDSMuSGBOfoPo0iIviFnaxGO2BrA88Xl Xcy1S23UVoCxsnGv/i/K3+km+WsnLHA68eevv9b+Yz8/1t+Yax80tAGoUVX933ZzDcnff4TIkF14 Uf6elypUKll/81w8hJ6ukL86G5WS4e+qMetvgbBWQ4/+z+QElRh3IkMXgFjgdOFva+syjC4Zkz9q URwtE9h+FBl37/+i/D0vVahUiq1C+sifvI1Kad5/KKu/WKuhR/9XIwT+dAGIBQ75y5Aq/lRKhL91 j+JsVWL9XxAL6YUX4e95qUKlJPibqPu91kPQmPzV2aiUVP3N4O+vfmVRUwHGWg1I/d9SeGcEjX3N jNNHOA8fz7U2w6fXRB2GUSTk95IIkRiM07DVaYWP+Y+6pI7194b+L8Lf80qVSkX5M5sSHrD7D/KH Lgn+1v5vcCIx6q+mAoy1GoRskmjlBF01Jn8lwgKH/GVJEX8qlVNak/U3z/iO/q/nVK1tVCqJViF+ KPwF5yJ/ECpiq9a4Z1HUU4CxVkOn/m+Qq7+7uiJB/qBtOvZ/u8gftSnJ3xQhvP8II9Fi4QVme16q UCnyJzhVWxuVyuDv2fVXTwHGWg299h9TC+i7Nl11m8PDWdiQ/BUJC5x+/PmeMjuWNn+ZxuSP2pTk z1t+//xZN530h9P/BaZ7XqpQqWT/Z0L9n4c/Nxv+NE7f6zaM27vP/9phGEM3rGG8GvLJMG06jCIh +oYgWpbMPhyun/Ab3HOY+qumAGNl4079X4C/jTPy109Y4PTiz5skj/jNx0P9DXv2BkILgBpVuv9Y Lq+31hjQ/Yd/vuelCpVK8pfn4kH0dIX81dmoVBZ/JZCGn+leDpXUX6zV0Kn/yw/Kfob8lQkLnB78 mU0ZRvnG/XFQAqBGdeRvWw4RGhotPN+Mz0sVKhXnLyco25j81dmo1Bv6PyX1F2s19Nx/lAiJPx0A YoFD/i5IBX8q1ZG/+/o/35TPSxUqJcKf+WkZze5H/qRtpPU56QYbCf4W+AbjeEHVXxUFOMzoGYEc Cflk2ET+KVH+rPRH/gJqAcUeC5rUIx9dqv9b859VfyeN00c4Dh/PtdbD/v82m8NHhe8TJKw8Nr2/ q26Dm7BqtPtk9H+xVNR+/WZkk1iCCdukpqr+p3QqxZ/JCjKed6coCP7KYsK0PXj/AaEctFJJcr1/ qL+haJxW7GG6oXFrb5Osvxk12qyFPG//Qf4KhQVOL/6S2e+qMfmj/orCZTaJGD+4/4OwUSnyBzEV +etmzPpbKKzV0HP/IZP/VpG/QmGB04k/wfq7ivxRfyX5kzNm/1dno1LkD2Iq8he6z/qLIqzV8NT+ j/iVCgucTvyFHlugdNh0USV/VIay+DsFTZj9XuvBuhgzXpZDlD+s9QuWKlRKlD8nG55cyF+djUpF +ZsRC/V/61U3/x1oHKfv1R0+nmsccoZRJOT3kgiRGJJbiwh/68XjPfZ/7YSVjYVsUvXX+INOyc+9 HjEmf5Sl8v5vsGib3xzq78mF/V+djUpl8Xd+aqnKW3FeSzT3H01tVKos/50CPBU6EMr6Wyqs1dCp /8sPynyG/JUKCxzyRylQR/7Y/9XZqFQcLWO2LYaA8fwdx9MfFhTkr7068jeL5bdYWKuhZ/9XIvIn LSxwyB+lQB35Y/9XZ6NS5A9iKvJXZbJsUZydCuuvtLBWA1D/N1H3e62HuDH5KxYWOOSPUiCp/m/h zyrAUzE247QEtmGchs/wZb9ctBwFgSDqyv//88bERB6tooBT4r3nDBmlLVCLpg3ORc242ftpxioh VzZjlZD+GhcUbCW4T+5zm/mP748ymS6p9P3xbdl/26G1GsTqvwH/tUbLOFL+c98NeJHDf5BBre+P DOFpOezYT2v9iqWKLsF/EkPhv2uE2X7Po7UahOq/A8L47zxaxsF/0AHUfxJDUf+1F8Z/ZTJdwv57 G7RWA/Xf09Ayzh/7z7l3M7GcCo7My/AfBJz032I033/bwtR/ZTJdcs5/7mc2z3RB+sN/1WW6pGj/ HSL/hdnwxTg9V7/5Fx7SHGjGKiGvvxohNZowYR1jvjC+fqf+o/wrQCsbV5LBf/CXlPkv2IWj/Te5 ZNz3n9b6FUsVXXLy+2Peun9ZcDbg3vcH/iuQ6ZKz+S9SSWXYf2ujtRr+uP47J4z/CtAyDv6DDrjQ f9R/ZTJdgv8khsJ/lwiz/xagtRqo/56GlnHwH3QA9Z/EUNR/7YXH/fSnZQr81546/nPu3UxsCbP9 lqC1GpTqPzf7b08Y/5WgZRwh/zkv/20K4z+IqLr/+jnw7cZxWgLf5lX/+YdWM272fpqxSsiVzVgl pL8mTFgl/GS26j++P8pkuuRC/7H/lqG1GoTqP3v/NcLwXwlaxhHyn5s3cr4/4Ch18l+WMPVfmUyX 4D+JofDfFcLsvyVorQah+i9bGP+VoGUc/AcdcGX9t28/rfUrliq6BP9JDIX/LhBm+y1CazXcsP7D f0VoGQf/QQec9Z9zn9Y575R/SP1XW6ZLTvrvY7Sp8RwXaOG/2jJdcs5/bjD9F2TD9Cr23yK0VsMf 138/p4X5L3LjOE3h1/wLD2mONWOVkNdfjZAaTZiwjjFfGAts1X/kP0go/f4wT9vC1H9lMl1S5L9w E4723+QS/Fcm0yUnvz8+W/f8M8z7ON8fTdFaDX/8/RGppDLpGexXhpZxpPyXJYz/IEHLf1rrVyxV dAn+kxgK/7UXZv8tQ2s1UP89DS3jyPvvX0KroeC+XJj/tBae1lDUf+2Ftd6m1lD47zbCj0VrNUjV f859WrfI4b/aaBlHyX8f303NYkD8BxnUsIkbsvyntfC0hqL+K1OZ/edtwNNm7MbpuX6bcQgOrSYj 5PVXI+TKZqwS0l/jgoKthNl/jv23IVrZWKn+y9t/oQwt4+A/6IAq3x/zRh5s53x/1JbpkmZpCv/V lumSC/0HZWitBqn670rhx6JlHPwHHUD9JzEU9V97Ya23qTUU/ruN8GPRWg3Uf09Dyzj4DzqA+k9i KOq/Uxe/WTlKorXeptZQ+O+0gEv/qyIMEVqrQaT+80wXpD/8Vx0t4yj6L8yGL8ZpCjQ0ZhMmrFPE 11P/tZPpEvwnMRT+O3e1836j/bdIGFK0VkMlmSr+m/dxvj+aomUcCf/9VFIZ/AcZNLMJ9V9tmS7B fxJD4b/bCD8WrdUgVf9dKfxYtIyD/6ADqP8khqL+ay+s9Ta1hsJ/txF+LFqrQa/+c28aCMMbLeMo +q+RMPRL7fy3Iay18LSGov6rIOX8HPh24zg9128zDsGh1WSEvP5qhFzZjFVC+mvChFUF6r92aGVj vfrvLYf/mqFlHD3/RftvPWHol5o24fujqUyXNEtT+K+2TJdc6D8oQ2s16NV/Fwk/Fi3j4D/oAOo/ iaGo/9oLa71NraHw322EH4vWaqD+expaxsF/0AHUfxJDUf+du/pFcLAc4r/aMl1S5L/JbZ7jAi32 39porQaF+i/2X5ANS4TBQMs4Cv57CwT5L3LjOE2BhsZswoR1iliA+q+dTJeUfn+snsB/tWW6pLj+ W/6J9t8SYTDQWg2VZAr999nB532c74+maBlHwX+LSiqD/yCDZjah/qst0yX4T2Io/Hcb4ceitRqk 6r8rhR+LlnHwH3QA9Z/EUNR/7YW13qbWUPjvNsKPRWs13K/+yxgqZzbXydxvxl3KZONebAjf78Zv N+MuZXKZzLcYEP8hU0cmF/yHTAuZXF7e8zZgB5BBTf+5oaYewBHC/RfgWvAf/Cl1t3MAAAAAAACA ++HefH7z+tIj8/rl8LyMNalf6JDdZw+VXJ/O+LhM/mPc7AyOMh7xeZkDk2rGa5DPaDl9RqR1fTTz UzKrk5p77GeT9NlDJdenMz4uk/8YNzvT0IxHfErmwKSa8R3GGirtM28qORutHFvm+FB+x5Y1o7mY M07OpTNOZI4PtXZvm52G1XYfcc4zPviITY36zHMw84ndZ954mOvN5+f8G7d2k0Rm3WNbqTHts+Yf zzCZcfq+0xmnOenw27Q7jdkEJ+MJGzHJjE2Zjcd4yf77Hcl6OGafdVNhTLpUd0OyYvzQ7ZeZ5Lad GHPG2yFZMVHk5owjH2+HrM9mPSZHJgy9Iv/NL379wUV9ZmqJs3pc5Bohtv9yNoej/ltJhklya+y/ lVdpdeYl2p2EveK/zZBkAs39t0wqHSrqW5qdmCGMW5Oxn816TKS89dx8b6zYL/GPscZiGcOimzHx vRlEndaMrZBYcU3GfA17E940RWV+j2/9Tc99n5/VTOHFeOdXQ8zlux0ThCYJwOjbmnEYY844CllJ OFsx+xPOmXHGhHNmkz/hTVP8HTmTyYipJJNDlzO+8KYAAAAAAAAAAAAAAOAvcM46Z5w0I4+E7F6f MQD0gptNtm+178GGPTJCiu0LPTG96vXXbfpvR61CDP57DEvGcp+jryG/x8M3RTr3jTFO/kS8kFls CEK+Ay6R6Q8GfBDB/us+Dor8N4Rp8tfjR3pda2J+SHh5Iob/nsRiNdt/7pvrovBc/0U50vvxxvMv x3+Pwvdf6Cr/5An/LXtwPNoQSC4hpL+HYVpt1X/rkT+1vRCrzxwWHoH3HeF/fPg7Z/BZ4Z8cDHPZ YuGIv2HXfq67fQAAAHgK/wcA9LmKiQ0KZW5kc3RyZWFtDWVuZG9iag01IDAgb2JqDTw8L0ZpcnN0 IDEyMi9MZW5ndGggMzcyL0ZpbHRlci9GbGF0ZURlY29kZS9OIDE4L1R5cGUvT2JqU3RtPj5zdHJl YW0NCnjalFDBSsNAEN1PmaMedLOzm00CJdCDBSmG0PQWeqh1qYWYlJhC+/Pq7G4Ui3bRyz523ps3 My+DCEQEqQYhQGQIAgGRahLQFhVIzEDEIBPiNKiIIAElCVJQmiADRX3UE+sEUIBW1gJ0QhYSkkgB KkhkDBhDojWghpQkkwmf29ERLHi57k07LHtj7BrnlcIch7k5AfJF15iH9d6uaCXL097waugPG6db dN2Q59a1pkEksIMs0ILuF3kQHtCD9KC80veJsS/xkFpY8RKcD694ZTZ+UnF4ea1dVk5o07JSx923 za411fOalpzttofe8CVd8tgd+bQfdpvG8Lv2qe0Gwwv7zGj9r1+e16E9z+5b1YG1z49fucwjOmXM veIlL7fgRvnsQARZDLIyyKrv7BjJp4RPm+Hq7Z0JFrEbegW9hXuRxVS7ZXvWsu31aBX/20pesvqZ BmbBOM5oDNMyTF9IxGsuRyJY+udIQl74i9eHAAMAeazq2w0KZW5kc3RyZWFtDWVuZG9iag02IDAg b2JqDTw8L0NvdW50IDIvVHlwZS9QYWdlcy9LaWRzWzI5IDAgUiAxIDAgUl0+Pg1lbmRvYmoNNyAw IG9iag08PC9TdWJ0eXBlL1hNTC9MZW5ndGggMzU4MS9UeXBlL01ldGFkYXRhPj5zdHJlYW0NCjw/ eHBhY2tldCBiZWdpbj0i77u/IiBpZD0iVzVNME1wQ2VoaUh6cmVTek5UY3prYzlkIj8+Cjx4Onht cG1ldGEgeG1sbnM6eD0iYWRvYmU6bnM6bWV0YS8iIHg6eG1wdGs9IkFkb2JlIFhNUCBDb3JlIDQu MC1jMzE2IDQ0LjI1MzkyMSwgU3VuIE9jdCAwMSAyMDA2IDE3OjE0OjM5Ij4KICAgPHJkZjpSREYg eG1sbnM6cmRmPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4K ICAgICAgPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6eGFw PSJodHRwOi8vbnMuYWRvYmUuY29tL3hhcC8xLjAvIj4KICAgICAgICAgPHhhcDpNb2RpZnlEYXRl PjIwMDgtMDgtMjVUMTg6MjE6MDMrMDI6MDA8L3hhcDpNb2RpZnlEYXRlPgogICAgICAgICA8eGFw OkNyZWF0ZURhdGU+MjAwOC0wOC0yNVQxODoyMTowMSswMjowMDwveGFwOkNyZWF0ZURhdGU+CiAg ICAgICAgIDx4YXA6TWV0YWRhdGFEYXRlPjIwMDgtMDgtMjVUMTg6MjE6MDMrMDI6MDA8L3hhcDpN ZXRhZGF0YURhdGU+CiAgICAgIDwvcmRmOkRlc2NyaXB0aW9uPgogICAgICA8cmRmOkRlc2NyaXB0 aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4bWxuczp4YXBNTT0iaHR0cDovL25zLmFkb2Jl LmNvbS94YXAvMS4wL21tLyI+CiAgICAgICAgIDx4YXBNTTpEb2N1bWVudElEPnV1aWQ6ZjRkYjJl ODItM2RjNC00OTAxLTg3NzgtNDBjZGMwMjgxYjdhPC94YXBNTTpEb2N1bWVudElEPgogICAgICAg ICA8eGFwTU06SW5zdGFuY2VJRD51dWlkOmZlMDE0YjRkLTE3ZTQtNDc4OS05OTEyLTMxNmI1ZWQ4 NWRhODwveGFwTU06SW5zdGFuY2VJRD4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgICAgIDxy ZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOmRjPSJodHRwOi8v cHVybC5vcmcvZGMvZWxlbWVudHMvMS4xLyI+CiAgICAgICAgIDxkYzpmb3JtYXQ+YXBwbGljYXRp b24vcGRmPC9kYzpmb3JtYXQ+CiAgICAgICAgIDxkYzpjcmVhdG9yPgogICAgICAgICAgICA8cmRm OlNlcT4KICAgICAgICAgICAgICAgPHJkZjpsaT5IZWluIE1la2tlczwvcmRmOmxpPgogICAgICAg ICAgICA8L3JkZjpTZXE+CiAgICAgICAgIDwvZGM6Y3JlYXRvcj4KICAgICAgPC9yZGY6RGVzY3Jp cHRpb24+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHht bG5zOnBkZj0iaHR0cDovL25zLmFkb2JlLmNvbS9wZGYvMS4zLyI+CiAgICAgICAgIDxwZGY6UHJv ZHVjZXI+QWRvYmUgUERGIExpYnJhcnkgOC4wPC9wZGY6UHJvZHVjZXI+CiAgICAgIDwvcmRmOkRl c2NyaXB0aW9uPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAg ICB4bWxuczpwZGZ4PSJodHRwOi8vbnMuYWRvYmUuY29tL3BkZngvMS4zLyI+CiAgICAgICAgIDxw ZGZ4OkNvbXBhbnk+VE9TSElCQTwvcGRmeDpDb21wYW55PgogICAgICA8L3JkZjpEZXNjcmlwdGlv bj4KICAgPC9yZGY6UkRGPgo8L3g6eG1wbWV0YT4KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgIAo8P3hwYWNrZXQgZW5kPSJ3Ij8+DQplbmRzdHJlYW0N ZW5kb2JqDTggMCBvYmoNPDwvQ3JlYXRpb25EYXRlKEQ6MjAwODA4MjUxODIxMDErMDInMDAnKS9B dXRob3IoSGVpbiBNZWtrZXMpL0NyZWF0b3Io/v8AQQBjAHIAbwBiAGEAdAAgAFAARABGAE0AYQBr AGUAcgAgADgALgAxACAAZgBvAHIAIABXAG8AcgBkKS9Qcm9kdWNlcihBZG9iZSBQREYgTGlicmFy eSA4LjApL01vZERhdGUoRDoyMDA4MDgyNTE4MjEwMyswMicwMCcpL0NvbXBhbnkoVE9TSElCQSk+ Pg1lbmRvYmoNeHJlZg0KMCAyNw0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDM2Mjg3IDAwMDAw IG4NCjAwMDAwMzY1NjAgMDAwMDAgbg0KMDAwMDAzNzI5OCAwMDAwMCBuDQowMDAwMDQzNzQ5IDAw MDAwIG4NCjAwMDAwNTAwODcgMDAwMDAgbg0KMDAwMDA1MDU1NSAwMDAwMCBuDQowMDAwMDUwNjEz IDAwMDAwIG4NCjAwMDAwNTQyNzEgMDAwMDAgbg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KdHJhaWxlcg0K PDwvU2l6ZSAyNz4+DQpzdGFydHhyZWYNCjExNg0KJSVFT0YNCg== ------=_NextPart_000_0007_01C906E0.9F9F2DA0 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_000_0007_01C906E0.9F9F2DA0-- From pcn-bounces@ietf.org Mon Aug 25 20:45:39 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 708673A67CF; Mon, 25 Aug 2008 20:45: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 73FD23A67C0 for ; Mon, 25 Aug 2008 20:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.74 X-Spam-Level: X-Spam-Status: No, score=-2.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9tRNzNHNoEQ for ; Mon, 25 Aug 2008 20:45:38 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 508963A67B5 for ; Mon, 25 Aug 2008 20:45:38 -0700 (PDT) Received: from cpe-071-077-048-179.nc.res.rr.com ([71.77.48.179]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1KXpUo-0006T3-7p for pcn@ietf.org; Mon, 25 Aug 2008 23:45:30 -0400 From: Steven Blake To: pcn Date: Mon, 25 Aug 2008 23:45:32 -0400 Message-Id: <1219722332.20944.4.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Subject: [PCN] ITU-T liaison letter 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 ITU-T has asked the PCN working group for a response to their liaison letter https://datatracker.ietf.org/liaison/461/ by September 1. Needless to say, there hasn't been much discussion on the mailing list. Please read the statement and send any comments by Friday. Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Aug 26 01:30:25 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75C753A6A67; Tue, 26 Aug 2008 01:30: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 7E2803A6A67 for ; Tue, 26 Aug 2008 01:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljYeWdb23lKK for ; Tue, 26 Aug 2008 01:30:20 -0700 (PDT) Received: from smail6.alcatel.fr (colt-na5.alcatel.fr [62.23.212.5]) by core3.amsl.com (Postfix) with ESMTP id 0869A3A6A0F for ; Tue, 26 Aug 2008 01:30:19 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m7Q8UBoH026657 for ; Tue, 26 Aug 2008 10:30:13 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.54]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Tue, 26 Aug 2008 10:30:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Aug 2008 10:30:09 +0200 Message-ID: <713A7C5347A4344A8671770DFE2B2EA7017CC2CE@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Request for clarification of Other and priority traffic - see draft-eardley-pcn-marking-behaviour-01 Thread-Index: AckHVfNfByaoB9vRTiaa/aj4wzcElg== From: "HUBLET Christian" To: X-OriginalArrivalTime: 26 Aug 2008 08:30:11.0237 (UTC) FILETIME=[F47F5550:01C90755] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: [PCN] Request for clarification of Other and priority traffic - see draft-eardley-pcn-marking-behaviour-01 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="===============0000865824==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0000865824== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C90755.F49BD704" This is a multi-part message in MIME format. ------_=_NextPart_001_01C90755.F49BD704 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, >From draft-eardley-pcn-marking-behaviour-01, I understand that the to be metered traffic is : - PCN traffic + Other traffic + Priority traffic. >From the draft it is not clear to me what priority traffic basically means: - In the definitions of section 1.1, priority traffic shares the same capacity. - I wonder what the meaning is of capacity: 1. sharing the same physical interface (read capacity) or=20 2. the bandwidth (read capacity) is configured for the 2 (or 3) types of traffic. (no separate capacity (bandwidth) is specified per traffic type) I suppose that for the "other traffic" also both definitions can be applicable. In the first definition, I see an issue for admittance control. If not all other and priority traffic is actually present in the network,=20 there could be an overadmittance of the PCN traffic. A practical example could be coexistance of business traffic and residential traffic in the same diffserv network.=20 The residential traffic is controlled via PCN, the business traffic is controlled via a policer at the edge of the network. If not all sessions for the business traffic are active, the PCN traffic could take capacity which was meant to be used for business traffic. =20 In the second definition, I do not understand why lower priority traffic should not be taken into account if the same capacity (read bandwidth) is shared with PCN traffic. I have the impression that there is a strict requirement to take into account other traffic and priority traffic if present (metered packet (see section 2.4) is part of meter traffic (see section 1.1)). If the first definition is applied, this strict requirement can have a huge impact on the number of applications that can be supported in the diffserv domain and the accuracy with which the PCN bandwidth is controlled. In the second definition, it is the wish of the operator to share the bandwidth for a number of applications which is basically a normal policy. But in this last case, it is not clear why lower priority traffic can't share the same bandwidth. Thanks for clarifying. Kr, Chris _________________________________ Christian hublet Bell Labs - Fixed Access Copernicuslaan 50 B2018 Antwerp Belgium Tel. +32 3 2408789;=20 Email : Christian.Hublet@alcatel-lucent.be =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 Alcatel-Lucent Bell NV Fortis 220-0002334-42 VAT BE 0404 621 642 Register of Legal Entities Antwerp=20 DISCLAIMER: This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited without the prior consent of its author. ------_=_NextPart_001_01C90755.F49BD704 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Request for clarification of Other and priority traffic - see = draft-eardley-pcn-marking-behaviour-01

Hello,

From = draft-eardley-pcn-marking-behaviour-01, I understand that the to be = metered traffic is :
        - PCN traffic + Other traffic + Priority traffic.

From the draft it is not clear to me = what priority traffic basically means:
        - In the definitions of section 1.1, priority traffic = shares the same capacity.
        - I wonder what the meaning is of capacity:
        =         1. sharing the same physical interface (read capacity) or =
        =         2. the bandwidth (read capacity) is configured for the 2 = (or 3) types of traffic. (no separate capacity (bandwidth) is specified = per traffic type)

I suppose that for the "other = traffic" also both definitions can be applicable.

In the first definition, I see an issue = for admittance control. If not all other and priority traffic is = actually present in the network,

there could be an overadmittance of the = PCN traffic. A practical example could be coexistance of business = traffic and residential traffic in the same diffserv network. =

The residential traffic is controlled = via PCN, the business traffic is controlled via a policer at the edge of = the network. If not all sessions for the business traffic are active, = the PCN traffic could take capacity which was meant to be used for = business traffic.

 
In the second definition, I do not = understand why lower priority traffic should not be taken into account = if the same capacity (read bandwidth) is shared with PCN = traffic.

I have the impression that there is a = strict requirement to take into account other traffic and priority = traffic if present (metered packet (see section 2.4) is part of meter = traffic (see section 1.1)). If the first definition is applied, this = strict requirement can have a huge impact on the number of applications = that can be  supported  in the diffserv domain and the = accuracy with which the PCN bandwidth is controlled. In the second = definition, it is the wish of the operator to share the bandwidth for a = number of applications which is basically a normal policy. But in this = last case, it is not clear why lower priority traffic can't share the = same bandwidth.

Thanks for clarifying.

Kr,

Chris



_________________________________
Christian hublet
Bell Labs - Fixed Access
Copernicuslaan 50
B2018 Antwerp
Belgium
Tel. +32 3 2408789;
Email : = Christian.Hublet@alcatel-lucent.be


=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Alcatel-Lucent = Bell NV
Fortis = 220-0002334-42
VAT BE 0404 = 621 642 Register of Legal Entities Antwerp

DISCLAIMER: = This message (including any attachments) contains confidential = information intended for a specific individual and purpose, and is = protected by law. If you are not the intended recipient, you should = delete this message. Any disclosure, copying, or distribution of this = message, or the taking of any action based on it, is strictly prohibited = without the prior consent of its author.



------_=_NextPart_001_01C90755.F49BD704-- --===============0000865824== 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 --===============0000865824==-- From pcn-bounces@ietf.org Tue Aug 26 02:36:45 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BD0C3A688C; Tue, 26 Aug 2008 02:36:45 -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 CB6093A6804 for ; Tue, 26 Aug 2008 02:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.201 X-Spam-Level: X-Spam-Status: No, score=0.201 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_47=0.6, 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 X6IVMXph3TYm for ; Tue, 26 Aug 2008 02:36:41 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 4B7C43A688C for ; Tue, 26 Aug 2008 02:36:41 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Aug 2008 10:36:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Aug 2008 10:36:03 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA1B6@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <000601c906cf$dc165da0$944318e0$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] regarding lc-pcn features and consensus Thread-Index: Acj30xA3vhH+zhrERBS741ha0TCfJgABTgdgAljd/RAAAbLnQAAj5JMgAAGHpwAAAXORYAAB4WrgAAKNjLABN8nEEAAj22MA From: To: , X-OriginalArrivalTime: 26 Aug 2008 09:36:04.0724 (UTC) FILETIME=[28F59340:01C9075F] Subject: Re: [PCN] regarding lc-pcn features and 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 Hein Couple of quick questions - what does N=1 mean? I thought it meant marking every Nth pkt & terminating every flow. But this doesn't seem to make sense? - have you done the comparison with the EMFT method? thanks phil { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Hein { Mekkes { Sent: 25 August 2008 17:30 { To: pcn@ietf.org { Subject: Re: [PCN] regarding lc-pcn features and consensus { { Dear all { { We had done some simulation experiments to emphasize the need of using the { variable N in situations where the overload is higher than 100% of the { capacity of a link. { { Two sets of experiments are used. { { In those experiments the single bottleneck topology with 10 ingresses is { used, see the SM draft for more details. The used RTT (on an unloaded { network) is set to be 4 ms. The capcity of the botleneck link is 45 Mbs. { The { flows are generating CBR traffic, with a holding time of 1 minute. The { used { solution is LC-PCN trunk (using ingress-egress-aggregates). { { In the first set of experiments an overload of 180% is simulated. { { Graphs 1 and 2 show the results of the first set of experiments. { Graph 1 shows the situation where N = 1 is used and Graph 2 shows the { situation where N = 2 is used. { { From these graphs can be seen that the recovery time when N = 1 is equal { to { +/- 1500 ms, while when N = 2 the recovery time is +/- 300 ms. { { In the second set of experiments an overload of 250% is simulated. { { Graphs 3 and 4 show the results of the second set of experiments. { Graph 3 shows the situation where N = 1 is used and Graph 4 shows the { situation where N = 3 is used. { { From this graph can be seen that the recovery time when N = 1 is equal to { +/- 1500 ms, while when N = 3 the recovery time is +/- 400 ms. { { From these graphs can be seen that by using the required N value the { recovery time can be decreased with a factor of up to 5 times. { { Kind regards, { Hein { { { > -----Original Message----- { > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { > Georgios Karagiannis { > Sent: dinsdag 19 augustus 2008 13:42 { > To: philip.eardley@bt.com; slblake@petri-meat.com; pcn@ietf.org { > Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > Subject: Re: [PCN] regarding lc-pcn features and consensus { > { > Hi Phil { > { > Specific simulation results on the PCN context on the question that you { > had { > I do not have. { > However, if you expect to see simulation results on this matter I { > expect { > that these results { > should be shown by Michael since you are in favour of adopting that { > solution. { > Michael mentioned already that results associated with the dicussed { > case { > were not presented yet. { > { > Best regards, { > Georgios { > { > { > { > > -----Original Message----- { > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] { > > Sent: dinsdag 19 augustus 2008 12:25 { > > To: karagian@cs.utwente.nl; slblake@petri-meat.com; pcn@ietf.org { > > Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > > Subject: RE: [PCN] regarding lc-pcn features and consensus { > > { > > Georgios { > > { > > I notice you avoided my question " Please can you point me to { > > the earlier comparative { > > > analysis / simulations that shows when it starts becoming { > important" { > > so I assume you have haven't done comparative analysis / simulations? { > > Anyway, Michael's simulations seem to show that the problem { > > is not big enough to worry about. { > > { > > Thanks { > > phil { > > { > > { -----Original Message----- { > > { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] { > > { Sent: 19 August 2008 10:34 { To: Eardley,PL,Philip,CXR9 R; { > > slblake@petri-meat.com; pcn@ietf.org { Cc: { > > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { { > > Subject: RE: [PCN] regarding lc-pcn features and consensus { { > > { Hi Phil { { Yes I am refering to the situation that you are { > > mentioning. { > > { Please note that in severe congestion situations the { > > overload can easily { and { most of the times { go above 100% { > > of the capacity of the link. { > > { { > > { The mentioned issues were pointed out during Michael { > > presentation (IETF { 71) { by Anna and by me. I am not sure { > > if they were included in the PCN minutes { of { IETF 71. { > > { { > > { Best regards, { > > { Georgios { > > { { > > { { > > { { > > { { > > { > -----Original Message----- { > > { > From: philip.eardley@bt.com { > > [mailto:philip.eardley@bt.com] { > Sent: dinsdag 19 augustus { > > 2008 10:55 { > To: karagian@cs.utwente.nl; { > > slblake@petri-meat.com; pcn@ietf.org { > Cc: { > > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > { > > Subject: RE: [PCN] regarding lc-pcn features and consensus { { > > > { > Hi Georgios { > { > i think what you're referring to { > > (please correct) is that if { > the interior node is { > > massively overloaded, then you're saying { > that the I-D's { > > approach might terminate slower, essentially { > because of a { > > saturation effect (you can't have more than 100% { > marked { > > pkts) - whereas this saturation effect doesn't appear { > { > > until (much) higher loads with the 'marking every Nth pkt' { > > algorithm. { > > { > { > > { > Sure, at first glance I can believe there's a theoretical { > > { > saturation effect. Question is whether it's important in { > > { > practice. Please can you point me to the earlier { > > comparative { > analysis / simulations that shows when it { > > starts becoming { > important (eg link to the right mail - { > > sorry my memory for { > old discussions is often bad!). { > > { > { > > { > Thanks { > > { > Phil/ { > > { > { > > { > { -----Original Message----- { > > { > { From: Georgios Karagiannis { > > [mailto:karagian@cs.utwente.nl] { > { Sent: 19 August 2008 { > > 09:11 { To: Eardley,PL,Philip,CXR9 R; { > { > > slblake@petri-meat.com; pcn@ietf.org { Cc: { > > { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { { { > > Subject: RE: [PCN] regarding lc-pcn features and consensus { > { > { { > Hi { > Phil { { At the time I have checked this draft and I { > > { > have also followed the { presentation given by Michael { > > during { > the { IETF 71. From the discussions that we have { > > had then, I { > did realise that { the { algorithm provided { > > in { { > { > > http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt { > > { > { cannot achieve the same behaviour as the algorithm { > > that is { > marking every { N-th packet { when the percentage { > > of overload { > in an interior node is higher than 100% of { { > > the capacity of the link. { > > { > { { > > { > { Best regards, { > > { > { Georgios { > > { > { { > > { > { { > > { > { { > > { > { { > > { > { { > > { > { > -----Original Message----- { > > { > { > From: philip.eardley@bt.com { > > { > [mailto:philip.eardley@bt.com] { > Sent: maandag 18 { > > augustus { > 2008 17:04 { > To: karagian@cs.utwente.nl; { > { > > slblake@petri-meat.com; pcn@ietf.org { > Cc: { > > { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > { > > { > Subject: RE: [PCN] regarding lc-pcn features and { > > consensus { { > > { > { > - marking every Nth pkt is not supported. { > > { > { > { Thus you mean that the option of marking every Nth { > > pkt { > is precluded. { > > { > { > { Without this option the LC-PCN algorithm will { > > become { > very { > slow { in situations of high overloads { > > that are { > above the { > capacity of a link. { > > { > { > { { > > { > { > { Therefore, we would very much appreciate if an { > { > > experimental { > extesion of { this { feature will be allowed { > > { > { to support the { > option that marked excess rate { > { > > represents { high levels of { { > excess rate). This can be { { > > implemented by marking every { { > N-th packet (or { { > > { > byte)instead { { > of marking each packet (or { > byte). N is a { { > > > constant that is { equal or { higher { than 1. { > > { > { > { > > { > { > Georgios { > > { > { > { > > { > { > We had quite some discussion between a couple of { > > IETFs { { > > several months ago, which led to the draft { > { > > { > http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt { > > { > { > { > > { > { > This came out of the desire to achieve marked flow { { > > > { > termination. The original suggestion was to do this by { > > { > { > marking every Nth pkt. However, it was realised that { > > this { > { > could be achieved by marking every pkt, but then { > > altering the { > { > edge behaviour (every time it sees a { > > pkt, it terminates { > that { > flow with a probability of { > > 1/N). This was shown by { > simulation (see { > i-d) and { > > analysis (see email I sent to { > list) to achieve { > { > > exactly the same behaviour. { > > { > { > Hence marking every Nth pkt was shown to be an { > { > > unnecessary { > complication { > - it's clearly a good thing { > > { > to eliminate (all other things { > being equal) since it { > > adds { > complexity to the marking { > algorithm and is { > > another { > parameter to configure. { > > { > { > { > > { > { > I believe this gives you the system behaviour you want. { > > { > { > { > > { > { > Best wishes { > > { > { > phil { > > { > { > { > > { > { { > > { > { > > { { > > { > { > { > _______________________________________________ { > 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 Aug 26 04:06:09 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 679D33A6ACD; Tue, 26 Aug 2008 04:06: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 F28503A6ACD for ; Tue, 26 Aug 2008 04:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CM4-T51q67i8 for ; Tue, 26 Aug 2008 04:06:06 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id D17D03A690A for ; Tue, 26 Aug 2008 04:06:05 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 9so300649eyd.31 for ; Tue, 26 Aug 2008 04:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=+1av1C7YaVEq+2tqF4rhsGa80hFMijEG5mITt6jvgkQ=; b=iq+2IbZGZm1vUVyD42t+ikRYnzXp8C90B8kCdAfc3lmy2OyyasvYvgzsLnnrCCuunc w+Fwvldms+Se0/TtpsmB2IFrLam0HH3Deah44rYQbEuuCslSTjry0rKl5SrIr6woapCC hOf9BA2E3d5qtInzWG/GR+Qa87sk8e0jrh9+g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=gJj3YytjEwlmuNlMGy7q4drnUapuOYp94JzTYI9giIVmsQCD1SI9kdovyVte1EKi9F kpTm1YB7MkRrTjkDTeYDqRf1H5oqXeyttakpsCvpdG+34f44VVyy7MqbKsU5MTW8qPm+ 715kg/SzKGkmLTNoysWUjMv1l35LpS35fc2pk= Received: by 10.210.121.8 with SMTP id t8mr8266349ebc.31.1219748233046; Tue, 26 Aug 2008 03:57:13 -0700 (PDT) Received: from HeinoLaptop ( [130.89.124.152]) by mx.google.com with ESMTPS id 3sm6292480eyj.3.2008.08.26.03.57.10 (version=SSLv3 cipher=RC4-MD5); Tue, 26 Aug 2008 03:57:11 -0700 (PDT) From: "Hein Mekkes" To: , References: <000601c906cf$dc165da0$944318e0$@com> <4A916DBC72536E419A0BD955EDECEDEC03DAA1B6@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA1B6@E03MVB1-UKBR.domain1.systemhost.net> Date: Tue, 26 Aug 2008 12:57:08 +0200 Message-ID: <004101c9076a$7d0ad700$77208500$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acj30xA3vhH+zhrERBS741ha0TCfJgABTgdgAljd/RAAAbLnQAAj5JMgAAGHpwAAAXORYAAB4WrgAAKNjLABN8nEEAAj22MAAAJ+etA= Content-Language: en-us Subject: Re: [PCN] regarding lc-pcn features and 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 Hi Phil, We have not done a comparison with EMFT since this was not the goal of the experiments. We tried to show that using different values than N = 1 is useful, since in many cases it provides a decrease in recovery time of up to 5 times. This is evidence that shows that a different proportionality than N = 1 on marking bytes and measured excess bytes is very useful. The SM draft supports only the N = 1 proportionality between marking bytes and measured excess bytes. Hein > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: dinsdag 26 augustus 2008 11:36 > To: heinmekkes@gmail.com; pcn@ietf.org > Subject: RE: [PCN] regarding lc-pcn features and consensus > > Hein > > Couple of quick questions > > - what does N=1 mean? I thought it meant marking every Nth pkt & > terminating every flow. But this doesn't seem to make sense? > - have you done the comparison with the EMFT method? > > thanks > phil > > { -----Original Message----- > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Hein > { Mekkes > { Sent: 25 August 2008 17:30 > { To: pcn@ietf.org > { Subject: Re: [PCN] regarding lc-pcn features and consensus > { > { Dear all > { > { We had done some simulation experiments to emphasize the need of > using > the > { variable N in situations where the overload is higher than 100% of > the > { capacity of a link. > { > { Two sets of experiments are used. > { > { In those experiments the single bottleneck topology with 10 ingresses > is > { used, see the SM draft for more details. The used RTT (on an unloaded > { network) is set to be 4 ms. The capcity of the botleneck link is 45 > Mbs. > { The > { flows are generating CBR traffic, with a holding time of 1 minute. > The > { used > { solution is LC-PCN trunk (using ingress-egress-aggregates). > { > { In the first set of experiments an overload of 180% is simulated. > { > { Graphs 1 and 2 show the results of the first set of experiments. > { Graph 1 shows the situation where N = 1 is used and Graph 2 shows the > { situation where N = 2 is used. > { > { From these graphs can be seen that the recovery time when N = 1 is > equal > { to > { +/- 1500 ms, while when N = 2 the recovery time is +/- 300 ms. > { > { In the second set of experiments an overload of 250% is simulated. > { > { Graphs 3 and 4 show the results of the second set of experiments. > { Graph 3 shows the situation where N = 1 is used and Graph 4 shows the > { situation where N = 3 is used. > { > { From this graph can be seen that the recovery time when N = 1 is > equal > to > { +/- 1500 ms, while when N = 3 the recovery time is +/- 400 ms. > { > { From these graphs can be seen that by using the required N value the > { recovery time can be decreased with a factor of up to 5 times. > { > { Kind regards, > { Hein > { > { > { > -----Original Message----- > { > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf > Of > { > Georgios Karagiannis > { > Sent: dinsdag 19 augustus 2008 13:42 > { > To: philip.eardley@bt.com; slblake@petri-meat.com; pcn@ietf.org > { > Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com > { > Subject: Re: [PCN] regarding lc-pcn features and consensus > { > > { > Hi Phil > { > > { > Specific simulation results on the PCN context on the question that > you > { > had > { > I do not have. > { > However, if you expect to see simulation results on this matter I > { > expect > { > that these results > { > should be shown by Michael since you are in favour of adopting that > { > solution. > { > Michael mentioned already that results associated with the dicussed > { > case > { > were not presented yet. > { > > { > Best regards, > { > Georgios > { > > { > > { > > { > > -----Original Message----- > { > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > { > > Sent: dinsdag 19 augustus 2008 12:25 > { > > To: karagian@cs.utwente.nl; slblake@petri-meat.com; pcn@ietf.org > { > > Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com > { > > Subject: RE: [PCN] regarding lc-pcn features and consensus > { > > > { > > Georgios > { > > > { > > I notice you avoided my question " Please can you point me to > { > > the earlier comparative > { > > > analysis / simulations that shows when it starts becoming > { > important" > { > > so I assume you have haven't done comparative analysis / > simulations? > { > > Anyway, Michael's simulations seem to show that the problem > { > > is not big enough to worry about. > { > > > { > > Thanks > { > > phil > { > > > { > > { -----Original Message----- > { > > { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > { > > { Sent: 19 August 2008 10:34 { To: Eardley,PL,Philip,CXR9 R; > { > > slblake@petri-meat.com; pcn@ietf.org { Cc: > { > > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > { > > Subject: RE: [PCN] regarding lc-pcn features and consensus { > { > > { Hi Phil { { Yes I am refering to the situation that you are > { > > mentioning. > { > > { Please note that in severe congestion situations the > { > > overload can easily { and { most of the times { go above 100% > { > > of the capacity of the link. > { > > { > { > > { The mentioned issues were pointed out during Michael > { > > presentation (IETF { 71) { by Anna and by me. I am not sure > { > > if they were included in the PCN minutes { of { IETF 71. > { > > { > { > > { Best regards, > { > > { Georgios > { > > { > { > > { > { > > { > { > > { > { > > { > -----Original Message----- > { > > { > From: philip.eardley@bt.com > { > > [mailto:philip.eardley@bt.com] { > Sent: dinsdag 19 augustus > { > > 2008 10:55 { > To: karagian@cs.utwente.nl; > { > > slblake@petri-meat.com; pcn@ietf.org { > Cc: > { > > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > > { > > Subject: RE: [PCN] regarding lc-pcn features and consensus { > { > > > { > Hi Georgios { > { > i think what you're referring to > { > > (please correct) is that if { > the interior node is > { > > massively overloaded, then you're saying { > that the I-D's > { > > approach might terminate slower, essentially { > because of a > { > > saturation effect (you can't have more than 100% { > marked > { > > pkts) - whereas this saturation effect doesn't appear { > > { > > until (much) higher loads with the 'marking every Nth pkt' > { > > algorithm. > { > > { > > { > > { > Sure, at first glance I can believe there's a theoretical > { > > { > saturation effect. Question is whether it's important in > { > > { > practice. Please can you point me to the earlier > { > > comparative { > analysis / simulations that shows when it > { > > starts becoming { > important (eg link to the right mail - > { > > sorry my memory for { > old discussions is often bad!). > { > > { > > { > > { > Thanks > { > > { > Phil/ > { > > { > > { > > { > { -----Original Message----- > { > > { > { From: Georgios Karagiannis > { > > [mailto:karagian@cs.utwente.nl] { > { Sent: 19 August 2008 > { > > 09:11 { To: Eardley,PL,Philip,CXR9 R; { > > { > > slblake@petri-meat.com; pcn@ietf.org { Cc: > { > > { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { { > { > > Subject: RE: [PCN] regarding lc-pcn features and consensus { > { > > > { > { > Hi > { > Phil { { At the time I have checked this draft and I > { > > { > have also followed the { presentation given by Michael > { > > during { > the { IETF 71. From the discussions that we have > { > > had then, I { > did realise that { the { algorithm provided > { > > in { { > > { > > http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt > { > > { > { cannot achieve the same behaviour as the algorithm > { > > that is { > marking every { N-th packet { when the percentage > { > > of overload { > in an interior node is higher than 100% of { > { > > the capacity of the link. > { > > { > { > { > > { > { Best regards, > { > > { > { Georgios > { > > { > { > { > > { > { > { > > { > { > { > > { > { > { > > { > { > { > > { > { > -----Original Message----- > { > > { > { > From: philip.eardley@bt.com > { > > { > [mailto:philip.eardley@bt.com] { > Sent: maandag 18 > { > > augustus { > 2008 17:04 { > To: karagian@cs.utwente.nl; { > > { > > slblake@petri-meat.com; pcn@ietf.org { > Cc: > { > > { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > > { > > { > Subject: RE: [PCN] regarding lc-pcn features and > { > > consensus { { > > { > { > - marking every Nth pkt is not > supported. > { > > { > { > { Thus you mean that the option of marking every Nth > { > > pkt { > is precluded. > { > > { > { > { Without this option the LC-PCN algorithm will > { > > become { > very { > slow { in situations of high overloads > { > > that are { > above the { > capacity of a link. > { > > { > { > { > { > > { > { > { Therefore, we would very much appreciate if an { > > { > > experimental { > extesion of { this { feature will be allowed > { > > { > { to support the { > option that marked excess rate { > > { > > represents { high levels of { { > excess rate). This can be { > { > > implemented by marking every { { > N-th packet (or { { > > > { > byte)instead { > { > of marking each packet (or { > byte). N is a { > { > > > constant that is { equal or { higher { than 1. > { > > { > { > > { > > { > { > Georgios > { > > { > { > > { > > { > { > We had quite some discussion between a couple of > { > > IETFs { { > > several months ago, which led to the draft { > > { > > { > http://www.watersprings.org/pub/id/draft-menth-pcn-emft- > 00.txt > { > > { > { > > { > > { > { > This came out of the desire to achieve marked flow { > { > > > { > termination. The original suggestion was to do this by > { > > { > { > marking every Nth pkt. However, it was realised that > { > > this { > { > could be achieved by marking every pkt, but then > { > > altering the { > { > edge behaviour (every time it sees a > { > > pkt, it terminates { > that { > flow with a probability of > { > > 1/N). This was shown by { > simulation (see { > i-d) and > { > > analysis (see email I sent to { > list) to achieve { > > { > > exactly the same behaviour. > { > > { > { > Hence marking every Nth pkt was shown to be an { > > { > > unnecessary { > complication { > - it's clearly a good thing > { > > { > to eliminate (all other things { > being equal) since it > { > > adds { > complexity to the marking { > algorithm and is > { > > another { > parameter to configure. > { > > { > { > > { > > { > { > I believe this gives you the system behaviour you want. > { > > { > { > > { > > { > { > Best wishes > { > > { > { > phil > { > > { > { > > { > > { > { > { > > { > > { > > { > { > > > { > > { > > { > _______________________________________________ > { > 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 Aug 26 04:26:16 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82A8C3A6ABB; Tue, 26 Aug 2008 04:26: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 AC0523A6A62 for ; Tue, 26 Aug 2008 04:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_47=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zoIqKsVE2eN for ; Tue, 26 Aug 2008 04:26:09 -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 D77003A6ABB for ; Tue, 26 Aug 2008 04:26:08 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id D0B19198DF7; Tue, 26 Aug 2008 13:26:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id C30C4198DEB; Tue, 26 Aug 2008 13:26:07 +0200 (CEST) Received: from [132.187.12.123] (win3123.informatik.uni-wuerzburg.de [132.187.12.123]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 8F1ED198DEE; Tue, 26 Aug 2008 13:26:07 +0200 (CEST) Message-ID: <48B3E7FA.8010405@informatik.uni-wuerzburg.de> Date: Tue, 26 Aug 2008 13:24:42 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Hein Mekkes References: <000601c906cf$dc165da0$944318e0$@com> <4A916DBC72536E419A0BD955EDECEDEC03DAA1B6@E03MVB1-UKBR.domain1.systemhost.net> <004101c9076a$7d0ad700$77208500$@com> In-Reply-To: <004101c9076a$7d0ad700$77208500$@com> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] regarding lc-pcn features and 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 Hein, when I was looking at lc-pcn method, I found that it works only when excess marking is used based on the supportable rate. It does not work for excess marking based on the admissible rate because then the egress node must determine the edge-to-edge supportable rate per ingress-egress aggregate using the rate of unmarked packets multiplied by u. In case of packet loss (and no preferential dropping of marked packets), this rate is underestimated which then leads to overtermination. Thus, this method is only applicable in case of excess marking based on the supportable rate. Is that true? Regards, Michael Hein Mekkes wrote: > Hi Phil, > > We have not done a comparison with EMFT since this was not the goal of the > experiments. > > We tried to show that using different values than N = 1 is useful, since in > many cases it provides a decrease in recovery time of up to 5 times. > > This is evidence that shows that a different proportionality than N = 1 on > marking bytes and measured excess bytes is very useful. The SM draft > supports only the N = 1 proportionality between marking bytes and measured > excess bytes. > > Hein > > > >> -----Original Message----- >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >> Sent: dinsdag 26 augustus 2008 11:36 >> To: heinmekkes@gmail.com; pcn@ietf.org >> Subject: RE: [PCN] regarding lc-pcn features and consensus >> >> Hein >> >> Couple of quick questions >> >> - what does N=1 mean? I thought it meant marking every Nth pkt & >> terminating every flow. But this doesn't seem to make sense? >> - have you done the comparison with the EMFT method? >> >> thanks >> phil >> >> { -----Original Message----- >> { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >> Hein >> { Mekkes >> { Sent: 25 August 2008 17:30 >> { To: pcn@ietf.org >> { Subject: Re: [PCN] regarding lc-pcn features and consensus >> { >> { Dear all >> { >> { We had done some simulation experiments to emphasize the need of >> using >> the >> { variable N in situations where the overload is higher than 100% of >> the >> { capacity of a link. >> { >> { Two sets of experiments are used. >> { >> { In those experiments the single bottleneck topology with 10 ingresses >> is >> { used, see the SM draft for more details. The used RTT (on an unloaded >> { network) is set to be 4 ms. The capcity of the botleneck link is 45 >> Mbs. >> { The >> { flows are generating CBR traffic, with a holding time of 1 minute. >> The >> { used >> { solution is LC-PCN trunk (using ingress-egress-aggregates). >> { >> { In the first set of experiments an overload of 180% is simulated. >> { >> { Graphs 1 and 2 show the results of the first set of experiments. >> { Graph 1 shows the situation where N = 1 is used and Graph 2 shows the >> { situation where N = 2 is used. >> { >> { From these graphs can be seen that the recovery time when N = 1 is >> equal >> { to >> { +/- 1500 ms, while when N = 2 the recovery time is +/- 300 ms. >> { >> { In the second set of experiments an overload of 250% is simulated. >> { >> { Graphs 3 and 4 show the results of the second set of experiments. >> { Graph 3 shows the situation where N = 1 is used and Graph 4 shows the >> { situation where N = 3 is used. >> { >> { From this graph can be seen that the recovery time when N = 1 is >> equal >> to >> { +/- 1500 ms, while when N = 3 the recovery time is +/- 400 ms. >> { >> { From these graphs can be seen that by using the required N value the >> { recovery time can be decreased with a factor of up to 5 times. >> { >> { Kind regards, >> { Hein >> { >> { >> { > -----Original Message----- >> { > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf >> Of >> { > Georgios Karagiannis >> { > Sent: dinsdag 19 augustus 2008 13:42 >> { > To: philip.eardley@bt.com; slblake@petri-meat.com; pcn@ietf.org >> { > Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com >> { > Subject: Re: [PCN] regarding lc-pcn features and consensus >> { > >> { > Hi Phil >> { > >> { > Specific simulation results on the PCN context on the question that >> you >> { > had >> { > I do not have. >> { > However, if you expect to see simulation results on this matter I >> { > expect >> { > that these results >> { > should be shown by Michael since you are in favour of adopting that >> { > solution. >> { > Michael mentioned already that results associated with the dicussed >> { > case >> { > were not presented yet. >> { > >> { > Best regards, >> { > Georgios >> { > >> { > >> { > >> { > > -----Original Message----- >> { > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >> { > > Sent: dinsdag 19 augustus 2008 12:25 >> { > > To: karagian@cs.utwente.nl; slblake@petri-meat.com; pcn@ietf.org >> { > > Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com >> { > > Subject: RE: [PCN] regarding lc-pcn features and consensus >> { > > >> { > > Georgios >> { > > >> { > > I notice you avoided my question " Please can you point me to >> { > > the earlier comparative >> { > > > analysis / simulations that shows when it starts becoming >> { > important" >> { > > so I assume you have haven't done comparative analysis / >> simulations? >> { > > Anyway, Michael's simulations seem to show that the problem >> { > > is not big enough to worry about. >> { > > >> { > > Thanks >> { > > phil >> { > > >> { > > { -----Original Message----- >> { > > { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >> { > > { Sent: 19 August 2008 10:34 { To: Eardley,PL,Philip,CXR9 R; >> { > > slblake@petri-meat.com; pcn@ietf.org { Cc: >> { > > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { >> { > > Subject: RE: [PCN] regarding lc-pcn features and consensus { >> { > > { Hi Phil { { Yes I am refering to the situation that you are >> { > > mentioning. >> { > > { Please note that in severe congestion situations the >> { > > overload can easily { and { most of the times { go above 100% >> { > > of the capacity of the link. >> { > > { >> { > > { The mentioned issues were pointed out during Michael >> { > > presentation (IETF { 71) { by Anna and by me. I am not sure >> { > > if they were included in the PCN minutes { of { IETF 71. >> { > > { >> { > > { Best regards, >> { > > { Georgios >> { > > { >> { > > { >> { > > { >> { > > { >> { > > { > -----Original Message----- >> { > > { > From: philip.eardley@bt.com >> { > > [mailto:philip.eardley@bt.com] { > Sent: dinsdag 19 augustus >> { > > 2008 10:55 { > To: karagian@cs.utwente.nl; >> { > > slblake@petri-meat.com; pcn@ietf.org { > Cc: >> { > > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > >> { > > Subject: RE: [PCN] regarding lc-pcn features and consensus { >> { > > > { > Hi Georgios { > { > i think what you're referring to >> { > > (please correct) is that if { > the interior node is >> { > > massively overloaded, then you're saying { > that the I-D's >> { > > approach might terminate slower, essentially { > because of a >> { > > saturation effect (you can't have more than 100% { > marked >> { > > pkts) - whereas this saturation effect doesn't appear { > >> { > > until (much) higher loads with the 'marking every Nth pkt' >> { > > algorithm. >> { > > { > >> { > > { > Sure, at first glance I can believe there's a theoretical >> { > > { > saturation effect. Question is whether it's important in >> { > > { > practice. Please can you point me to the earlier >> { > > comparative { > analysis / simulations that shows when it >> { > > starts becoming { > important (eg link to the right mail - >> { > > sorry my memory for { > old discussions is often bad!). >> { > > { > >> { > > { > Thanks >> { > > { > Phil/ >> { > > { > >> { > > { > { -----Original Message----- >> { > > { > { From: Georgios Karagiannis >> { > > [mailto:karagian@cs.utwente.nl] { > { Sent: 19 August 2008 >> { > > 09:11 { To: Eardley,PL,Philip,CXR9 R; { > >> { > > slblake@petri-meat.com; pcn@ietf.org { Cc: >> { > > { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { { >> { > > Subject: RE: [PCN] regarding lc-pcn features and consensus { > { >> >> { >> { > Hi >> { > Phil { { At the time I have checked this draft and I >> { > > { > have also followed the { presentation given by Michael >> { > > during { > the { IETF 71. From the discussions that we have >> { > > had then, I { > did realise that { the { algorithm provided >> { > > in { { > >> { > > http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt >> { > > { > { cannot achieve the same behaviour as the algorithm >> { > > that is { > marking every { N-th packet { when the percentage >> { > > of overload { > in an interior node is higher than 100% of { >> { > > the capacity of the link. >> { > > { > { >> { > > { > { Best regards, >> { > > { > { Georgios >> { > > { > { >> { > > { > { >> { > > { > { >> { > > { > { >> { > > { > { >> { > > { > { > -----Original Message----- >> { > > { > { > From: philip.eardley@bt.com >> { > > { > [mailto:philip.eardley@bt.com] { > Sent: maandag 18 >> { > > augustus { > 2008 17:04 { > To: karagian@cs.utwente.nl; { > >> { > > slblake@petri-meat.com; pcn@ietf.org { > Cc: >> { > > { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > >> { > > { > Subject: RE: [PCN] regarding lc-pcn features and >> { > > consensus { { > > { > { > - marking every Nth pkt is not >> supported. >> { > > { > { > { Thus you mean that the option of marking every Nth >> { > > pkt { > is precluded. >> { > > { > { > { Without this option the LC-PCN algorithm will >> { > > become { > very { > slow { in situations of high overloads >> { > > that are { > above the { > capacity of a link. >> { > > { > { > { >> { > > { > { > { Therefore, we would very much appreciate if an { > >> { > > experimental { > extesion of { this { feature will be allowed >> { > > { > { to support the { > option that marked excess rate { > >> { > > represents { high levels of { { > excess rate). This can be { >> { > > implemented by marking every { { > N-th packet (or { { > > >> { > byte)instead { >> { > of marking each packet (or { > byte). N is a { >> { > > > constant that is { equal or { higher { than 1. >> { > > { > { > >> { > > { > { > Georgios >> { > > { > { > >> { > > { > { > We had quite some discussion between a couple of >> { > > IETFs { { > > several months ago, which led to the draft { > >> { > > { > http://www.watersprings.org/pub/id/draft-menth-pcn-emft- >> 00.txt >> { > > { > { > >> { > > { > { > This came out of the desire to achieve marked flow { >> { > > > { > termination. The original suggestion was to do this by >> { > > { > { > marking every Nth pkt. However, it was realised that >> { > > this { > { > could be achieved by marking every pkt, but then >> { > > altering the { > { > edge behaviour (every time it sees a >> { > > pkt, it terminates { > that { > flow with a probability of >> { > > 1/N). This was shown by { > simulation (see { > i-d) and >> { > > analysis (see email I sent to { > list) to achieve { > >> { > > exactly the same behaviour. >> { > > { > { > Hence marking every Nth pkt was shown to be an { > >> { > > unnecessary { > complication { > - it's clearly a good thing >> { > > { > to eliminate (all other things { > being equal) since it >> { > > adds { > complexity to the marking { > algorithm and is >> { > > another { > parameter to configure. >> { > > { > { > >> { > > { > { > I believe this gives you the system behaviour you want. >> { > > { > { > >> { > > { > { > Best wishes >> { > > { > { > phil >> { > > { > { > >> { > > { > { >> { > > { > >> { > > { >> { > > >> { > >> { > >> { > _______________________________________________ >> { > 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 Aug 26 04:44:43 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11C983A6B11; Tue, 26 Aug 2008 04:44:43 -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 704E33A6AED for ; Tue, 26 Aug 2008 04:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QQXuwsKN1Cig for ; Tue, 26 Aug 2008 04:44:41 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 569C23A6B0E for ; Tue, 26 Aug 2008 04:44:41 -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 m7QBiYjE013506 for ; Tue, 26 Aug 2008 13:44:34 +0200 (MEST) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Tue, 26 Aug 2008 11:44:33 +0000 To: pcn@ietf.org Date: Tue, 26 Aug 2008 11:44:33 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: <88M1zluY.1219751073.4526280.karagian@ewi.utwente.nl> In-Reply-To: <1219408519.32328.6.camel@tachyon> 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, 26 Aug 2008 13:44:34 +0200 (MEST) Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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, Hi all Here are some comments on the PCN architecture draft: 1) Thank you for clarifying the bullet in Setion 3.2 about flow termination. 2) From what I understand the PCN architecture draft mentions that PCN supports only the trunk (ingress-egress-aggregate) and not the HOSE model. Is the PCN architecture draft excluding solutions that support the HOSE model? If not, please emphasize in the PCN architecture draft that "solutions that are based on other types of flow aggregation than the ingress-egress-aggregate method of flow aggregation, are not excluded from the PCN WG activities." 3) The architecture draft excludes the possibility of using the PCN-Affected marking encoding. From a previous email driscussion I have understood from you that the PCN WG does not exclude the possibility of extending the three encoding states (mentioned currently in the PCN architecture draft) with one additional encoding state. Therefore, please emphasize in the PCN architecture draft that a fourth encoding state can be definedas an extension, e.g., PCN-Affected marking if the PCN WG decides to provide solutions tothe ECMP solution. 4) From what I understood the PCN architecture draft emphasizes that the selected encoding is implemented by a combination of the DSCP and ECN bits. Has this point been decided by the PCN WG. Best regards, Georgios On 8/22/2008, "Steven Blake" wrote: >On Fri, 2008-08-08 at 20:03 -0400, Steven Blake wrote: > >> This message starts a 2+-week PCN working group last call for advancing >> >> Title : Pre-Congestion Notification Architecture >> Author(s) : P. Eardley >> Filename : draft-ietf-pcn-architecture-05.txt >> Pages : 54 >> Date : 2008-08-07 >> >> as an Informational RFC. Substantive comments and statements of support >> for this draft should be sent to the pcn mailing list. Editorial >> suggestions can be sent directly to the document editor. >> The last call will end on Wednesday August 27. > >A reminder that this last call closes next Wednesday. > > >Regards, > >// Steve > >_______________________________________________ >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 Aug 26 04:59:28 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23F9B28C141; Tue, 26 Aug 2008 04:59: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 A45B13A6A94 for ; Tue, 26 Aug 2008 04:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=1.900, 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 U+AJpVbv5x4O for ; Tue, 26 Aug 2008 04:59:25 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 6B3C73A6B23 for ; Tue, 26 Aug 2008 04:59:25 -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); Tue, 26 Aug 2008 12:59:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Aug 2008 12:59:21 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA1BB@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <88M1zluY.1219751073.4526280.karagian@ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt Thread-Index: AckHcSXrCPrWnifWRSunfodLpR2oCgAACn6g From: To: , X-OriginalArrivalTime: 26 Aug 2008 11:59:21.0366 (UTC) FILETIME=[2CF50B60:01C90773] Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 { Georgios Karagiannis { Sent: 26 August 2008 12:45 { To: pcn@ietf.org { Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt { { Hi Phil, Hi all { { Here are some comments on the PCN architecture draft: { { 1) Thank you for clarifying the bullet in Setion 3.2 about flow { termination. { { 2) From what I understand the PCN architecture draft mentions that PCN { supports only the trunk (ingress-egress-aggregate) and not the HOSE { model. { Is the PCN architecture draft excluding solutions that support the HOSE { model? If not, please emphasize in the PCN architecture draft that { "solutions that are based on other types of flow aggregation than the { ingress-egress-aggregate method of flow aggregation, are not excluded { from the PCN WG activities." Could you explain a bit more what you mean here please? Not quite sure what your model is. 2 geeneral points: [1] I'm not sure we should raise possibilities that haven't been analysed & had simulations behind them. [2] this is an INFO architectural draft - people are can use the STDS pieces in other ways. { { { 3) The architecture draft excludes the possibility of using the { PCN-Affected marking encoding. From a previous email driscussion I have { understood from you that { the PCN WG does not exclude the possibility of extending the three { encoding states (mentioned currently in the PCN architecture draft) with { one additional encoding state. Therefore, please emphasize in the PCN { architecture draft that a fourth encoding state can be definedas an { extension, e.g., PCN-Affected marking if the PCN WG decides to provide { solutions tothe ECMP solution. Encoding states are little mentioned in the draft. I tried to only assume what's in the baseline encoding, which involved some changes in the -04 to -05 version. I'm not sure what part you think needs changing. Perhaps near the end of S1: I could add to this sentence:- "or perhaps further encoding states as suggested in [LC-PCN]" { { { 4) From what I understood the PCN architecture draft emphasizes that the { selected encoding is implemented by a combination of the DSCP and ECN { bits. Has this point been decided by the PCN WG. Well the WG has decided on the baseline encoding, which does indeed use a combination of dscp & ecn bits. Thanks for the comments phil { { { Best regards, { Georgios { { { { On 8/22/2008, "Steven Blake" wrote: { { >On Fri, 2008-08-08 at 20:03 -0400, Steven Blake wrote: { > { >> This message starts a 2+-week PCN working group last call for advancing { >> { >> Title : Pre-Congestion Notification Architecture { >> Author(s) : P. Eardley { >> Filename : draft-ietf-pcn-architecture-05.txt { >> Pages : 54 { >> Date : 2008-08-07 { >> { >> as an Informational RFC. Substantive comments and statements of { support { >> for this draft should be sent to the pcn mailing list. Editorial { >> suggestions can be sent directly to the document editor. { >> The last call will end on Wednesday August 27. { > { >A reminder that this last call closes next Wednesday. { > { > { >Regards, { > { >// Steve { > { >_______________________________________________ { >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 Aug 26 05:13:03 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C170F28C133; Tue, 26 Aug 2008 05:13: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 5DBEF28C173 for ; Tue, 26 Aug 2008 05:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, 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 Ck9rhxQTjUkP for ; Tue, 26 Aug 2008 05:13: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 44C733A68B8 for ; Tue, 26 Aug 2008 05:13:00 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Aug 2008 13:13:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Aug 2008 13:12:29 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA1BD@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <004101c9076a$7d0ad700$77208500$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] regarding lc-pcn features and consensus Thread-Index: Acj30xA3vhH+zhrERBS741ha0TCfJgABTgdgAljd/RAAAbLnQAAj5JMgAAGHpwAAAXORYAAB4WrgAAKNjLABN8nEEAAj22MAAAJ+etAAAs57UA== From: To: , X-OriginalArrivalTime: 26 Aug 2008 12:13:00.0987 (UTC) FILETIME=[157D48B0:01C90775] Subject: Re: [PCN] regarding lc-pcn features and 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 Thanks Hein, { { We have not done a comparison with EMFT since this was not the goal of the { experiments. This is unfortunate. The work to date (analysis & simulations) has shown that the EMFT approach is just as good as the 'marking every Nth pkt' approach. So we need evidence that demonstrates to what extent and in what circumstances this becomes untrue. Only if this evidence shows a significant concern do I see any reason to re-visit our consensus decision. Also, a side comment: Earlier discussion also seemed to show that if speed of termination is your most important criterion, then you should choose CL rather than EMFT /marked flow. { { We tried to show that using different values than N = 1 is useful, since { in { many cases it provides a decrease in recovery time of up to 5 times. { { This is evidence that shows that a different proportionality than N = 1 on { marking bytes and measured excess bytes is very useful. The SM draft { supports only the N = 1 proportionality between marking bytes and measured { excess bytes. Sorry, I don't understand. N=1 means every pkt is marked. And the edge behaviour is to discard every marked pkt. So N=1 maximises the speed of termination. Yet your results seem to show the opposite. phil { { Hein { { { > -----Original Message----- { > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] { > Sent: dinsdag 26 augustus 2008 11:36 { > To: heinmekkes@gmail.com; pcn@ietf.org { > Subject: RE: [PCN] regarding lc-pcn features and consensus { > { > Hein { > { > Couple of quick questions { > { > - what does N=1 mean? I thought it meant marking every Nth pkt & { > terminating every flow. But this doesn't seem to make sense? { > - have you done the comparison with the EMFT method? { > { > thanks { > phil { > { > { -----Original Message----- { > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { > Hein { > { Mekkes { > { Sent: 25 August 2008 17:30 { > { To: pcn@ietf.org { > { Subject: Re: [PCN] regarding lc-pcn features and consensus { > { { > { Dear all { > { { > { We had done some simulation experiments to emphasize the need of { > using { > the { > { variable N in situations where the overload is higher than 100% of { > the { > { capacity of a link. { > { { > { Two sets of experiments are used. { > { { > { In those experiments the single bottleneck topology with 10 ingresses { > is { > { used, see the SM draft for more details. The used RTT (on an unloaded { > { network) is set to be 4 ms. The capcity of the botleneck link is 45 { > Mbs. { > { The { > { flows are generating CBR traffic, with a holding time of 1 minute. { > The { > { used { > { solution is LC-PCN trunk (using ingress-egress-aggregates). { > { { > { In the first set of experiments an overload of 180% is simulated. { > { { > { Graphs 1 and 2 show the results of the first set of experiments. { > { Graph 1 shows the situation where N = 1 is used and Graph 2 shows the { > { situation where N = 2 is used. { > { { > { From these graphs can be seen that the recovery time when N = 1 is { > equal { > { to { > { +/- 1500 ms, while when N = 2 the recovery time is +/- 300 ms. { > { { > { In the second set of experiments an overload of 250% is simulated. { > { { > { Graphs 3 and 4 show the results of the second set of experiments. { > { Graph 3 shows the situation where N = 1 is used and Graph 4 shows the { > { situation where N = 3 is used. { > { { > { From this graph can be seen that the recovery time when N = 1 is { > equal { > to { > { +/- 1500 ms, while when N = 3 the recovery time is +/- 400 ms. { > { { > { From these graphs can be seen that by using the required N value the { > { recovery time can be decreased with a factor of up to 5 times. { > { { > { Kind regards, { > { Hein { > { { > { { > { > -----Original Message----- { > { > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf { > Of { > { > Georgios Karagiannis { > { > Sent: dinsdag 19 augustus 2008 13:42 { > { > To: philip.eardley@bt.com; slblake@petri-meat.com; pcn@ietf.org { > { > Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > { > Subject: Re: [PCN] regarding lc-pcn features and consensus { > { > { > { > Hi Phil { > { > { > { > Specific simulation results on the PCN context on the question that { > you { > { > had { > { > I do not have. { > { > However, if you expect to see simulation results on this matter I { > { > expect { > { > that these results { > { > should be shown by Michael since you are in favour of adopting that { > { > solution. { > { > Michael mentioned already that results associated with the dicussed { > { > case { > { > were not presented yet. { > { > { > { > Best regards, { > { > Georgios { > { > { > { > { > { > { > { > > -----Original Message----- { > { > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] { > { > > Sent: dinsdag 19 augustus 2008 12:25 { > { > > To: karagian@cs.utwente.nl; slblake@petri-meat.com; pcn@ietf.org { > { > > Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > { > > Subject: RE: [PCN] regarding lc-pcn features and consensus { > { > > { > { > > Georgios { > { > > { > { > > I notice you avoided my question " Please can you point me to { > { > > the earlier comparative { > { > > > analysis / simulations that shows when it starts becoming { > { > important" { > { > > so I assume you have haven't done comparative analysis / { > simulations? { > { > > Anyway, Michael's simulations seem to show that the problem { > { > > is not big enough to worry about. { > { > > { > { > > Thanks { > { > > phil { > { > > { > { > > { -----Original Message----- { > { > > { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] { > { > > { Sent: 19 August 2008 10:34 { To: Eardley,PL,Philip,CXR9 R; { > { > > slblake@petri-meat.com; pcn@ietf.org { Cc: { > { > > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { { > { > > Subject: RE: [PCN] regarding lc-pcn features and consensus { { > { > > { Hi Phil { { Yes I am refering to the situation that you are { > { > > mentioning. { > { > > { Please note that in severe congestion situations the { > { > > overload can easily { and { most of the times { go above 100% { > { > > of the capacity of the link. { > { > > { { > { > > { The mentioned issues were pointed out during Michael { > { > > presentation (IETF { 71) { by Anna and by me. I am not sure { > { > > if they were included in the PCN minutes { of { IETF 71. { > { > > { { > { > > { Best regards, { > { > > { Georgios { > { > > { { > { > > { { > { > > { { > { > > { { > { > > { > -----Original Message----- { > { > > { > From: philip.eardley@bt.com { > { > > [mailto:philip.eardley@bt.com] { > Sent: dinsdag 19 augustus { > { > > 2008 10:55 { > To: karagian@cs.utwente.nl; { > { > > slblake@petri-meat.com; pcn@ietf.org { > Cc: { > { > > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > { > { > > Subject: RE: [PCN] regarding lc-pcn features and consensus { { > { > > > { > Hi Georgios { > { > i think what you're referring to { > { > > (please correct) is that if { > the interior node is { > { > > massively overloaded, then you're saying { > that the I-D's { > { > > approach might terminate slower, essentially { > because of a { > { > > saturation effect (you can't have more than 100% { > marked { > { > > pkts) - whereas this saturation effect doesn't appear { > { > { > > until (much) higher loads with the 'marking every Nth pkt' { > { > > algorithm. { > { > > { > { > { > > { > Sure, at first glance I can believe there's a theoretical { > { > > { > saturation effect. Question is whether it's important in { > { > > { > practice. Please can you point me to the earlier { > { > > comparative { > analysis / simulations that shows when it { > { > > starts becoming { > important (eg link to the right mail - { > { > > sorry my memory for { > old discussions is often bad!). { > { > > { > { > { > > { > Thanks { > { > > { > Phil/ { > { > > { > { > { > > { > { -----Original Message----- { > { > > { > { From: Georgios Karagiannis { > { > > [mailto:karagian@cs.utwente.nl] { > { Sent: 19 August 2008 { > { > > 09:11 { To: Eardley,PL,Philip,CXR9 R; { > { > { > > slblake@petri-meat.com; pcn@ietf.org { Cc: { > { > > { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { { { > { > > Subject: RE: [PCN] regarding lc-pcn features and consensus { > { { > > { > { { > { > Hi { > { > Phil { { At the time I have checked this draft and I { > { > > { > have also followed the { presentation given by Michael { > { > > during { > the { IETF 71. From the discussions that we have { > { > > had then, I { > did realise that { the { algorithm provided { > { > > in { { > { > { > > http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt { > { > > { > { cannot achieve the same behaviour as the algorithm { > { > > that is { > marking every { N-th packet { when the percentage { > { > > of overload { > in an interior node is higher than 100% of { { > { > > the capacity of the link. { > { > > { > { { > { > > { > { Best regards, { > { > > { > { Georgios { > { > > { > { { > { > > { > { { > { > > { > { { > { > > { > { { > { > > { > { { > { > > { > { > -----Original Message----- { > { > > { > { > From: philip.eardley@bt.com { > { > > { > [mailto:philip.eardley@bt.com] { > Sent: maandag 18 { > { > > augustus { > 2008 17:04 { > To: karagian@cs.utwente.nl; { > { > { > > slblake@petri-meat.com; pcn@ietf.org { > Cc: { > { > > { > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > { > { > > { > Subject: RE: [PCN] regarding lc-pcn features and { > { > > consensus { { > > { > { > - marking every Nth pkt is not { > supported. { > { > > { > { > { Thus you mean that the option of marking every Nth { > { > > pkt { > is precluded. { > { > > { > { > { Without this option the LC-PCN algorithm will { > { > > become { > very { > slow { in situations of high overloads { > { > > that are { > above the { > capacity of a link. { > { > > { > { > { { > { > > { > { > { Therefore, we would very much appreciate if an { > { > { > > experimental { > extesion of { this { feature will be allowed { > { > > { > { to support the { > option that marked excess rate { > { > { > > represents { high levels of { { > excess rate). This can be { { > { > > implemented by marking every { { > N-th packet (or { { > > { > { > byte)instead { { > { > of marking each packet (or { > byte). N is a { { > { > > > constant that is { equal or { higher { than 1. { > { > > { > { > { > { > > { > { > Georgios { > { > > { > { > { > { > > { > { > We had quite some discussion between a couple of { > { > > IETFs { { > > several months ago, which led to the draft { > { > { > > { > http://www.watersprings.org/pub/id/draft-menth-pcn-emft- { > 00.txt { > { > > { > { > { > { > > { > { > This came out of the desire to achieve marked flow { { > { > > > { > termination. The original suggestion was to do this by { > { > > { > { > marking every Nth pkt. However, it was realised that { > { > > this { > { > could be achieved by marking every pkt, but then { > { > > altering the { > { > edge behaviour (every time it sees a { > { > > pkt, it terminates { > that { > flow with a probability of { > { > > 1/N). This was shown by { > simulation (see { > i-d) and { > { > > analysis (see email I sent to { > list) to achieve { > { > { > > exactly the same behaviour. { > { > > { > { > Hence marking every Nth pkt was shown to be an { > { > { > > unnecessary { > complication { > - it's clearly a good thing { > { > > { > to eliminate (all other things { > being equal) since it { > { > > adds { > complexity to the marking { > algorithm and is { > { > > another { > parameter to configure. { > { > > { > { > { > { > > { > { > I believe this gives you the system behaviour you want. { > { > > { > { > { > { > > { > { > Best wishes { > { > > { > { > phil { > { > > { > { > { > { > > { > { { > { > > { > { > { > > { { > { > > { > { > { > { > { > { > _______________________________________________ { > { > 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 Aug 26 05:46:26 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2022628C14B; Tue, 26 Aug 2008 05:46: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 876D028C0DD for ; Tue, 26 Aug 2008 05:46:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sh04R4B5hX7X for ; Tue, 26 Aug 2008 05:46:21 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id B601528C176 for ; Tue, 26 Aug 2008 05:46:21 -0700 (PDT) Received: from cpe-071-077-048-179.nc.res.rr.com ([71.77.48.179]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1KXxw9-0001DM-3X; Tue, 26 Aug 2008 08:46:17 -0400 From: Steven Blake To: Georgios Karagiannis In-Reply-To: <88M1zluY.1219751073.4526280.karagian@ewi.utwente.nl> References: <88M1zluY.1219751073.4526280.karagian@ewi.utwente.nl> Date: Tue, 26 Aug 2008 08:46:17 -0400 Message-Id: <1219754777.20944.8.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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-08-26 at 11:44 +0000, Georgios Karagiannis wrote: > Hi Phil, Hi all > > Here are some comments on the PCN architecture draft: > > 1) Thank you for clarifying the bullet in Setion 3.2 about flow > termination. > > 2) From what I understand the PCN architecture draft mentions that PCN > supports only the trunk (ingress-egress-aggregate) and not the HOSE > model. > Is the PCN architecture draft excluding solutions that support the HOSE > model? If not, please emphasize in the PCN architecture draft that > "solutions that are based on other types of flow aggregation than the > ingress-egress-aggregate method of flow aggregation, are not excluded > from the PCN WG activities." Actually they are, by our charter. Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Aug 26 07:12:31 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9101B3A6B7C; Tue, 26 Aug 2008 07: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 E39AB3A6803 for ; Tue, 26 Aug 2008 07:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.096 X-Spam-Level: ** X-Spam-Status: No, score=2.096 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhl+oOmxzQ-i for ; Tue, 26 Aug 2008 07: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 88ACD3A6B81 for ; Tue, 26 Aug 2008 07:12:27 -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 m7QEBt4r008784; Tue, 26 Aug 2008 16:11:59 +0200 (MEST) From: "Georgios Karagiannis" To: "'Steven Blake'" References: <88M1zluY.1219751073.4526280.karagian@ewi.utwente.nl> <1219754777.20944.8.camel@tachyon> Date: Tue, 26 Aug 2008 16:11:50 +0200 Message-ID: <001101c90785$b275a8f0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AckHfCvcsSYCbD5RSuG05giqQ02fQAACNMIg In-Reply-To: <1219754777.20944.8.camel@tachyon> 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, 26 Aug 2008 16:11:59 +0200 (MEST) Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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:slblake@petri-meat.com] > Sent: dinsdag 26 augustus 2008 14:46 > To: Georgios Karagiannis > Cc: pcn@ietf.org > Subject: Re: [PCN] PCN WG last call for > draft-ietf-pcn-architecture-05.txt > > On Tue, 2008-08-26 at 11:44 +0000, Georgios Karagiannis wrote: > > > Hi Phil, Hi all > > > > Here are some comments on the PCN architecture draft: > > > > 1) Thank you for clarifying the bullet in Setion 3.2 about flow > > termination. > > > > 2) From what I understand the PCN architecture draft > mentions that PCN > > supports only the trunk (ingress-egress-aggregate) and not the HOSE > > model. > > Is the PCN architecture draft excluding solutions that support the > > HOSE model? If not, please emphasize in the PCN architecture draft > > that "solutions that are based on other types of flow > aggregation than > > the ingress-egress-aggregate method of flow aggregation, are not > > excluded from the PCN WG activities." > > Actually they are, by our charter. I have not seen that the PCN charter excludes other types of aggregation. Please note that I am refering to the HOSE model where the traffic sent by one or more than one ingresses towards one egress is aggregated at the egress. In this way higgher traffic aggregation can be accomplished than in the situation that the pipe/trunk (ingress-egress-aggregate) is used, where the traffic sent by only one ingress in aggegated at the egress. Best regards, Georgios > > > Regards, > > // Steve > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Aug 26 07:16:51 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 293023A69E7; Tue, 26 Aug 2008 07:16: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 4C0193A69E7 for ; Tue, 26 Aug 2008 07:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.796 X-Spam-Level: X-Spam-Status: No, score=0.796 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMyjByOJDYFX for ; Tue, 26 Aug 2008 07:16:49 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 111283A693E for ; Tue, 26 Aug 2008 07:16:48 -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 m7QEFuK0009680; Tue, 26 Aug 2008 16:16:00 +0200 (MEST) From: "Georgios Karagiannis" To: , References: <88M1zluY.1219751073.4526280.karagian@ewi.utwente.nl> <4A916DBC72536E419A0BD955EDECEDEC03DAA1BB@E03MVB1-UKBR.domain1.systemhost.net> Date: Tue, 26 Aug 2008 16:15:51 +0200 Message-ID: <001301c90786$4261d650$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AckHcSXrCPrWnifWRSunfodLpR2oCgAACn6gAAUe9+A= In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA1BB@E03MVB1-UKBR.domain1.systemhost.net> 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, 26 Aug 2008 16:16:01 +0200 (MEST) Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 Please see in line! > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: dinsdag 26 augustus 2008 13:59 > To: karagian@cs.utwente.nl; pcn@ietf.org > Subject: RE: [PCN] PCN WG last call for > draft-ietf-pcn-architecture-05.txt > > > > { -----Original Message----- > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of { Georgios Karagiannis { Sent: 26 August 2008 12:45 > { To: pcn@ietf.org { Subject: Re: [PCN] PCN WG last call for > draft-ietf-pcn-architecture-05.txt > { > { Hi Phil, Hi all > { > { Here are some comments on the PCN architecture draft: > { > { 1) Thank you for clarifying the bullet in Setion 3.2 about > flow { termination. > { > { 2) From what I understand the PCN architecture draft > mentions that PCN { supports only the trunk > (ingress-egress-aggregate) and not the HOSE { model. > { Is the PCN architecture draft excluding solutions that > support the HOSE { model? If not, please emphasize in the PCN > architecture draft that { "solutions that are based on other > types of flow aggregation than the { ingress-egress-aggregate > method of flow aggregation, are not excluded { from the PCN > WG activities." > > Could you explain a bit more what you mean here please? Not > quite sure what your model is. > 2 geeneral points: > [1] I'm not sure we should raise possibilities that haven't > been analysed & had simulations behind them. > [2] this is an INFO architectural draft - people are can use > the STDS pieces in other ways. Georgios: I am refering to the HOSE model: Please note that I am refering to the HOSE model where the traffic sent by one or more than one ingresses towards one egress is aggregated at the (receiveing) egress. In this way higher traffic aggregation can be accomplished than in the situation that the pipe/trunk (ingress-egress-aggregate) is used, where the traffic sent by only one ingress is aggegated at the (receiving) egress. > > { > { > { 3) The architecture draft excludes the possibility of using > the { PCN-Affected marking encoding. From a previous email > driscussion I have { understood from you that { the PCN WG > does not exclude the possibility of extending the three { > encoding states (mentioned currently in the PCN architecture > draft) with { one additional encoding state. Therefore, > please emphasize in the PCN { architecture draft that a > fourth encoding state can be definedas an { extension, e.g., > PCN-Affected marking if the PCN WG decides to provide { > solutions tothe ECMP solution. > > Encoding states are little mentioned in the draft. I tried to > only assume what's in the baseline encoding, which involved > some changes in the -04 to -05 version. > > I'm not sure what part you think needs changing. Perhaps near > the end of > S1: > [I-D.moncaster-pcn-baseline-encoding], which standardises two > PCN encoding states (PCN-marked and not PCN-marked), whilst > (experimental) extensions to the baseline encoding can > provide three encoding states (threshold-marked, > excess-traffic-marked, not PCN-marked).> > > I could add to this sentence:- > "or perhaps further encoding states as suggested in [LC-PCN]" [Georgios] This is great! Best regards, Georgios > > > { > { > { 4) From what I understood the PCN architecture draft > emphasizes that the { selected encoding is implemented by a > combination of the DSCP and ECN { bits. Has this point been > decided by the PCN WG. > > Well the WG has decided on the baseline encoding, which does > indeed use a combination of dscp & ecn bits. Georgios: Was this during the IETF meeting? Best regards, Georgios > > Thanks for the comments > phil > > { > { > { Best regards, > { Georgios > { > { > { > { On 8/22/2008, "Steven Blake" wrote: > { > { >On Fri, 2008-08-08 at 20:03 -0400, Steven Blake wrote: > { > > { >> This message starts a 2+-week PCN working group last > call for advancing { >> > { >> Title : Pre-Congestion Notification > Architecture > { >> Author(s) : P. Eardley > { >> Filename : draft-ietf-pcn-architecture-05.txt > { >> Pages : 54 > { >> Date : 2008-08-07 > { >> > { >> as an Informational RFC. Substantive comments and > statements of { support { >> for this draft should be sent to > the pcn mailing list. Editorial { >> suggestions can be sent > directly to the document editor. > { >> The last call will end on Wednesday August 27. > { > > { >A reminder that this last call closes next Wednesday. > { > > { > > { >Regards, > { > > { >// Steve > { > > { >_______________________________________________ > { >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 Aug 26 07:29:00 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EC393A6B67; Tue, 26 Aug 2008 07:29: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 23C533A6A10 for ; Tue, 26 Aug 2008 07:28:59 -0700 (PDT) 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=0.833, 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 VqWC3wN23ovp for ; Tue, 26 Aug 2008 07:28:53 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 7526A3A6B67 for ; Tue, 26 Aug 2008 07:28:53 -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); Tue, 26 Aug 2008 15:28:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 26 Aug 2008 15:28:54 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA1C0@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <001301c90786$4261d650$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt Thread-Index: AckHcSXrCPrWnifWRSunfodLpR2oCgAACn6gAAUe9+AAAHzi4A== From: To: , X-OriginalArrivalTime: 26 Aug 2008 14:28:54.0220 (UTC) FILETIME=[1131E8C0:01C90788] Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 { > { 4) From what I understood the PCN architecture draft { > emphasizes that the { selected encoding is implemented by a { > combination of the DSCP and ECN { bits. Has this point been { > decided by the PCN WG. { > { > Well the WG has decided on the baseline encoding, which does { > indeed use a combination of dscp & ecn bits. { { Georgios: Was this during the IETF meeting? As far as I remember, the baseline encoding was agreed in Philadelphia, confirmed on the list, and re-confirmed in Dublin. { { Best regards, { Georgios { { > { > Thanks for the comments { > phil { > { > { { > { { > { Best regards, { > { Georgios { > { { > { { > { { > { On 8/22/2008, "Steven Blake" wrote: { > { { > { >On Fri, 2008-08-08 at 20:03 -0400, Steven Blake wrote: { > { > { > { >> This message starts a 2+-week PCN working group last { > call for advancing { >> { > { >> Title : Pre-Congestion Notification { > Architecture { > { >> Author(s) : P. Eardley { > { >> Filename : draft-ietf-pcn-architecture-05.txt { > { >> Pages : 54 { > { >> Date : 2008-08-07 { > { >> { > { >> as an Informational RFC. Substantive comments and { > statements of { support { >> for this draft should be sent to { > the pcn mailing list. Editorial { >> suggestions can be sent { > directly to the document editor. { > { >> The last call will end on Wednesday August 27. { > { > { > { >A reminder that this last call closes next Wednesday. { > { > { > { > { > { >Regards, { > { > { > { >// Steve { > { > { > { >_______________________________________________ { > { >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 Aug 26 07:39:06 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5957E28C0E6; Tue, 26 Aug 2008 07:39:06 -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 E732F28C0E6 for ; Tue, 26 Aug 2008 07:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.746 X-Spam-Level: X-Spam-Status: No, score=0.746 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_47=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AbiIVFuUz8L for ; Tue, 26 Aug 2008 07:39: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 31CBD3A685A for ; Tue, 26 Aug 2008 07:39: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 m7QEYYp6017738; Tue, 26 Aug 2008 16:34:37 +0200 (MEST) From: "Georgios Karagiannis" To: , , References: <004101c9076a$7d0ad700$77208500$@com> <4A916DBC72536E419A0BD955EDECEDEC03DAA1BD@E03MVB1-UKBR.domain1.systemhost.net> Date: Tue, 26 Aug 2008 16:34:29 +0200 Message-ID: <001401c90788$dc438910$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acj30xA3vhH+zhrERBS741ha0TCfJgABTgdgAljd/RAAAbLnQAAj5JMgAAGHpwAAAXORYAAB4WrgAAKNjLABN8nEEAAj22MAAAJ+etAAAs57UAAEswlQ In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA1BD@E03MVB1-UKBR.domain1.systemhost.net> 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, 26 Aug 2008 16:34:39 +0200 (MEST) Subject: Re: [PCN] regarding lc-pcn features and 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 Hi Phil Please note that the achieved consensus in IETF Dublin was not refering to the EMFT solution. Thus I do not understand what you mean here! As mentioned the LC-PCN solution is used in the experiments. N works in the following way. At the interior: The SM excess rate marking solution is used with the difference that: * the variable N is used: the marked excess rate is equal to (measured excess rate)/N In SM, N = 1. Note that if the excess rate is higher than the capacity of the link and N = 1 then the the marked excess rate that will be sent towards the egress cannot represent the measured excess rate, since in this case the measured excess rate is higher than the capacity of the link. A marked excess rate higher than the capacity of the link cannot travel up to the egress. This is the problem that has been shown in the simulatiuon experiments. This problem is solved by the using the equation: (marked excess rate) = (measured excess rate)/N * Affected Marking encoding is used to provide ECMP support At the egress: The LC-PCN solution is used, where the bandwidth to be terminated is calculated by: Bandidth to be terminated = marked rate * N. This is needed to balance the marked excess rate equation used at the interior node. When N is chosen properly then the total excess rate value can be propagated to the egress immediately, since (marked excess rate) = (measured excess rate)/N and the total value of the marked excess rate is not higher than the capacity of the link. Therefore, the recovery time in this case is faster than the situation where N = 1. Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of philip.eardley@bt.com > Sent: dinsdag 26 augustus 2008 14:12 > To: heinmekkes@gmail.com; pcn@ietf.org > Subject: Re: [PCN] regarding lc-pcn features and consensus > > Thanks Hein, > { > { We have not done a comparison with EMFT since this was not > the goal of the { experiments. > > This is unfortunate. The work to date (analysis & > simulations) has shown that the EMFT approach is just as good > as the 'marking every Nth pkt' > approach. So we need evidence that demonstrates to what > extent and in what circumstances this becomes untrue. Only if > this evidence shows a significant concern do I see any reason > to re-visit our consensus decision. > > Also, a side comment: Earlier discussion also seemed to show > that if speed of termination is your most important > criterion, then you should choose CL rather than EMFT /marked flow. > > { > { We tried to show that using different values than N = 1 is > useful, since { in { many cases it provides a decrease in > recovery time of up to 5 times. > { > { This is evidence that shows that a different > proportionality than N = > 1 on > { marking bytes and measured excess bytes is very useful. The > SM draft { supports only the N = 1 proportionality between > marking bytes and measured { excess bytes. > > Sorry, I don't understand. N=1 means every pkt is marked. And > the edge behaviour is to discard every marked pkt. So N=1 > maximises the speed of termination. Yet your results seem to > show the opposite. > > phil > { > { Hein > { > { > { > -----Original Message----- > { > From: philip.eardley@bt.com > [mailto:philip.eardley@bt.com] { > Sent: dinsdag 26 augustus > 2008 11:36 { > To: heinmekkes@gmail.com; pcn@ietf.org { > > Subject: RE: [PCN] regarding lc-pcn features and consensus { > > { > Hein { > { > Couple of quick questions { > { > - what > does N=1 mean? I thought it meant marking every Nth pkt & { > > terminating every flow. But this doesn't seem to make sense? > { > - have you done the comparison with the EMFT method? > { > > { > thanks > { > phil > { > > { > { -----Original Message----- > { > { From: pcn-bounces@ietf.org > [mailto:pcn-bounces@ietf.org] On Behalf Of { > Hein { > { > Mekkes { > { Sent: 25 August 2008 17:30 { > { To: > pcn@ietf.org { > { Subject: Re: [PCN] regarding lc-pcn > features and consensus { > { { > { Dear all { > { { > { We > had done some simulation experiments to emphasize the need of > { > using { > the { > { variable N in situations where the > overload is higher than 100% of { > the { > { capacity of a link. > { > { > { > { Two sets of experiments are used. > { > { > { > { In those experiments the single bottleneck topology > with 10 ingresses { > is { > { used, see the SM draft for > more details. The used RTT (on an unloaded { > { network) is > set to be 4 ms. The capcity of the botleneck link is > 45 > { > Mbs. > { > { The > { > { flows are generating CBR traffic, with a holding time > of 1 minute. > { > The > { > { used > { > { solution is LC-PCN trunk (using ingress-egress-aggregates). > { > { > { > { In the first set of experiments an overload of 180% is > simulated. > { > { > { > { Graphs 1 and 2 show the results of the first set of experiments. > { > { Graph 1 shows the situation where N = 1 is used and > Graph 2 shows the { > { situation where N = 2 is used. > { > { > { > { From these graphs can be seen that the recovery time > when N = 1 is { > equal { > { to { > { +/- 1500 ms, while > when N = 2 the recovery time is +/- 300 ms. > { > { > { > { In the second set of experiments an overload of 250% is > simulated. > { > { > { > { Graphs 3 and 4 show the results of the second set of > experiments. > { > { Graph 3 shows the situation where N = 1 is used and > Graph 4 shows the { > { situation where N = 3 is used. > { > { > { > { From this graph can be seen that the recovery time when > N = 1 is { > equal { > to { > { +/- 1500 ms, while when N = 3 > the recovery time is +/- 400 ms. > { > { > { > { From these graphs can be seen that by using the > required N value the { > { recovery time can be decreased > with a factor of up to 5 times. > { > { > { > { Kind regards, > { > { Hein > { > { > { > { > { > { > -----Original Message----- > { > { > From: pcn-bounces@ietf.org > [mailto:pcn-bounces@ietf.org] On Behalf { > Of { > { > > Georgios Karagiannis { > { > Sent: dinsdag 19 augustus 2008 > 13:42 { > { > To: philip.eardley@bt.com; > slblake@petri-meat.com; pcn@ietf.org { > { > Cc: > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > { > > Subject: Re: [PCN] regarding lc-pcn features and consensus { > > { > { > { > Hi Phil { > { > { > { > Specific simulation > results on the PCN context on the question that { > you { > { > had { > { > I do not have. > { > { > However, if you expect to see simulation results on > this matter I { > { > expect { > { > that these results { > { > should be shown by Michael since you are in favour of adopting > that { > { > solution. > { > { > Michael mentioned already that results associated > with the dicussed { > { > case { > { > were not presented yet. > { > { > > { > { > Best regards, > { > { > Georgios > { > { > > { > { > > { > { > > { > { > > -----Original Message----- > { > { > > From: philip.eardley@bt.com > [mailto:philip.eardley@bt.com] { > { > > Sent: dinsdag 19 > augustus 2008 12:25 { > { > > To: karagian@cs.utwente.nl; > slblake@petri-meat.com; pcn@ietf.org { > { > > Cc: > Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > { > > > Subject: RE: [PCN] regarding lc-pcn features and consensus > { > { > > { > { > > Georgios { > { > > { > { > > I notice you > avoided my question " Please can you point me to { > { > > > the earlier comparative { > { > > > analysis / simulations > that shows when it starts becoming { > { > important" > { > { > > so I assume you have haven't done comparative > analysis / { > simulations? > { > { > > Anyway, Michael's simulations seem to show that the > problem { > { > > is not big enough to worry about. > { > { > > > { > { > > Thanks > { > { > > phil > { > { > > > { > { > > { -----Original Message----- > { > { > > { From: Georgios Karagiannis > [mailto:karagian@cs.utwente.nl] { > { > > { Sent: 19 August > 2008 10:34 { To: Eardley,PL,Philip,CXR9 R; { > { > > > slblake@petri-meat.com; pcn@ietf.org { Cc: > { > { > > Lars.Westberg@ericsson.com; > Attila.Bader@ericsson.com { { > { > > Subject: RE: [PCN] > regarding lc-pcn features and consensus { { > { > > { Hi Phil > { { Yes I am refering to the situation that you are { > { > > > mentioning. > { > { > > { Please note that in severe congestion situations > the { > { > > overload can easily { and { most of the times { > go above 100% { > { > > of the capacity of the link. > { > { > > { > { > { > > { The mentioned issues were pointed out during > Michael { > { > > presentation (IETF { 71) { by Anna and by > me. I am not sure { > { > > if they were included in the PCN > minutes { of { IETF 71. > { > { > > { > { > { > > { Best regards, > { > { > > { Georgios > { > { > > { > { > { > > { > { > { > > { > { > { > > { > { > { > > { > -----Original Message----- { > { > > { > From: > philip.eardley@bt.com { > { > > > [mailto:philip.eardley@bt.com] { > Sent: dinsdag 19 augustus > { > { > > 2008 10:55 { > To: karagian@cs.utwente.nl; { > { > > > slblake@petri-meat.com; pcn@ietf.org { > Cc: > { > { > > Lars.Westberg@ericsson.com; > Attila.Bader@ericsson.com { > { > { > > Subject: RE: [PCN] > regarding lc-pcn features and consensus { { > { > > > { > Hi > Georgios { > { > i think what you're referring to { > { > > > (please correct) is that if { > the interior node is { > { > > > massively overloaded, then you're saying { > that the I-D's > { > { > > approach might terminate slower, essentially { > > because of a { > { > > saturation effect (you can't have more > than 100% { > marked { > { > > pkts) - whereas this > saturation effect doesn't appear { > { > { > > until (much) > higher loads with the 'marking every Nth pkt' > { > { > > algorithm. > { > { > > { > > { > { > > { > Sure, at first glance I can believe there's a > theoretical { > { > > { > saturation effect. Question is > whether it's important in { > { > > { > practice. Please can > you point me to the earlier { > { > > comparative { > > analysis / simulations that shows when it { > { > > starts > becoming { > important (eg link to the right mail - { > { > > > sorry my memory for { > old discussions is often bad!). > { > { > > { > > { > { > > { > Thanks > { > { > > { > Phil/ > { > { > > { > > { > { > > { > { -----Original Message----- { > { > > { > { > From: Georgios Karagiannis { > { > > > [mailto:karagian@cs.utwente.nl] { > { Sent: 19 August 2008 { > > { > > 09:11 { To: Eardley,PL,Philip,CXR9 R; { > { > { > > > slblake@petri-meat.com; pcn@ietf.org { Cc: > { > { > > { > Lars.Westberg@ericsson.com; > Attila.Bader@ericsson.com { { { > { > > Subject: RE: [PCN] > regarding lc-pcn features and consensus { > { { > > { > { { > > { > Hi { > { > Phil { { At the time I have checked this draft > and I { > { > > { > have also followed the { presentation > given by Michael { > { > > during { > the { IETF 71. From the > discussions that we have { > { > > had then, I { > did > realise that { the { algorithm provided { > { > > in { { > { > > { > > http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt > { > { > > { > { cannot achieve the same behaviour as the > algorithm { > { > > that is { > marking every { N-th packet { > when the percentage { > { > > of overload { > in an interior > node is higher than 100% of { { > { > > the capacity of the link. > { > { > > { > { > { > { > > { > { Best regards, > { > { > > { > { Georgios > { > { > > { > { > { > { > > { > { > { > { > > { > { > { > { > > { > { > { > { > > { > { > { > { > > { > { > -----Original Message----- { > { > > { > { > > From: philip.eardley@bt.com { > { > > { > > [mailto:philip.eardley@bt.com] { > Sent: maandag 18 { > { > > > augustus { > 2008 17:04 { > To: karagian@cs.utwente.nl; { > { > { > > slblake@petri-meat.com; pcn@ietf.org { > Cc: > { > { > > { > Lars.Westberg@ericsson.com; > Attila.Bader@ericsson.com { > { > { > > { > Subject: RE: > [PCN] regarding lc-pcn features and { > { > > consensus { { > > > { > { > - marking every Nth pkt is not { > supported. > { > { > > { > { > { Thus you mean that the option of marking > every Nth { > { > > pkt { > is precluded. > { > { > > { > { > { Without this option the LC-PCN algorithm > will { > { > > become { > very { > slow { in situations of > high overloads { > { > > that are { > above the { > capacity > of a link. > { > { > > { > { > { > { > { > > { > { > { Therefore, we would very much appreciate > if an { > { > { > > experimental { > extesion of { this { > feature will be allowed { > { > > { > { to support the { > > option that marked excess rate { > { > { > > represents { > high levels of { { > excess rate). This can be { { > { > > > implemented by marking every { { > N-th packet (or { { > > { > { > byte)instead { { > { > of marking each packet (or { > > byte). N is a { { > { > > > constant that is { equal or { > higher { than 1. > { > { > > { > { > > { > { > > { > { > Georgios > { > { > > { > { > > { > { > > { > { > We had quite some discussion between a > couple of { > { > > IETFs { { > > several months ago, which > led to the draft { > { > { > > { > > http://www.watersprings.org/pub/id/draft-menth-pcn-emft- > { > 00.txt > { > { > > { > { > > { > { > > { > { > This came out of the desire to achieve > marked flow { { > { > > > { > termination. The original > suggestion was to do this by { > { > > { > { > marking every > Nth pkt. However, it was realised that { > { > > this { > { > > could be achieved by marking every pkt, but then { > { > > > altering the { > { > edge behaviour (every time it sees a { > > { > > pkt, it terminates { > that { > flow with a probability > of { > { > > 1/N). This was shown by { > simulation (see { > > i-d) and { > { > > analysis (see email I sent to { > list) to > achieve { > { > { > > exactly the same behaviour. > { > { > > { > { > Hence marking every Nth pkt was shown to be > an { > { > { > > unnecessary { > complication { > - it's > clearly a good thing { > { > > { > to eliminate (all other > things { > being equal) since it { > { > > adds { > > complexity to the marking { > algorithm and is { > { > > > another { > parameter to configure. > { > { > > { > { > > { > { > > { > { > I believe this gives you the system > behaviour you want. > { > { > > { > { > > { > { > > { > { > Best wishes > { > { > > { > { > phil > { > { > > { > { > > { > { > > { > { > { > { > > { > > { > { > > { > { > { > > > { > { > > { > { > > { > { > _______________________________________________ > { > { > 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 Aug 26 07:54:27 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 457243A69D1; Tue, 26 Aug 2008 07:54: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 D04383A6960 for ; Tue, 26 Aug 2008 07:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.729 X-Spam-Level: X-Spam-Status: No, score=0.729 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_47=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDhXbqJ7Y6Ey for ; Tue, 26 Aug 2008 07:54: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 BE02328C1A1 for ; Tue, 26 Aug 2008 07:54: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 m7QEnRWt025259; Tue, 26 Aug 2008 16:49:30 +0200 (MEST) From: "Georgios Karagiannis" To: , "'Hein Mekkes'" References: <000601c906cf$dc165da0$944318e0$@com> <4A916DBC72536E419A0BD955EDECEDEC03DAA1B6@E03MVB1-UKBR.domain1.systemhost.net><004101c9076a$7d0ad700$77208500$@com> <48B3E7FA.8010405@informatik.uni-wuerzburg.de> Date: Tue, 26 Aug 2008 16:49:22 +0200 Message-ID: <001501c9078a$f0aa3e60$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AckHbpXuMUnK/CS/ToGKfN0EuVB2mQAGxepg In-Reply-To: <48B3E7FA.8010405@informatik.uni-wuerzburg.de> 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, 26 Aug 2008 16:49:32 +0200 (MEST) Cc: pcn@ietf.org Subject: Re: [PCN] regarding lc-pcn features and 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 Hi Michael Please see the slides that were presented by Hein during the IETF meeting in Dublin: http://www.ietf.org/proceedings/08jul/slides/pcn-10.pdf The excess marking works based on the admissible rate for admission control and on the configured termination rate for flow termination. Please also note that the used trigger to activate the flow termination at the egress is: IF {[PCN_marked rate/ total rate) > U -1] OR [at least one Affected_Marked packet arrived)} THEN egress goes to flow termination state. Note that when Affected marking is used then Total rate = PCN_marked rate + affected_marked rate Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Michael Menth > Sent: dinsdag 26 augustus 2008 13:25 > To: Hein Mekkes > Cc: pcn@ietf.org > Subject: Re: [PCN] regarding lc-pcn features and consensus > > Hi Hein, > > when I was looking at lc-pcn method, I found that it works > only when excess marking is used based on the supportable > rate. It does not work for excess marking based on the > admissible rate because then the egress node must determine > the edge-to-edge supportable rate per ingress-egress > aggregate using the rate of unmarked packets multiplied by u. > In case of packet loss (and no preferential dropping of > marked packets), this rate is underestimated which then leads > to overtermination. Thus, this method is only applicable in > case of excess marking based on the supportable rate. Is that true? > > Regards, > > Michael > > Hein Mekkes wrote: > > Hi Phil, > > > > We have not done a comparison with EMFT since this was not > the goal of > > the experiments. > > > > We tried to show that using different values than N = 1 is useful, > > since in many cases it provides a decrease in recovery time > of up to 5 times. > > > > This is evidence that shows that a different > proportionality than N = > > 1 on marking bytes and measured excess bytes is very useful. The SM > > draft supports only the N = 1 proportionality between marking bytes > > and measured excess bytes. > > > > Hein > > > > > > > >> -----Original Message----- > >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > >> Sent: dinsdag 26 augustus 2008 11:36 > >> To: heinmekkes@gmail.com; pcn@ietf.org > >> Subject: RE: [PCN] regarding lc-pcn features and consensus > >> > >> Hein > >> > >> Couple of quick questions > >> > >> - what does N=1 mean? I thought it meant marking every Nth pkt & > >> terminating every flow. But this doesn't seem to make sense? > >> - have you done the comparison with the EMFT method? > >> > >> thanks > >> phil > >> > >> { -----Original Message----- > >> { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > On Behalf > >> Of Hein { Mekkes { Sent: 25 August 2008 17:30 { To: pcn@ietf.org { > >> Subject: Re: [PCN] regarding lc-pcn features and consensus > { { Dear > >> all { { We had done some simulation experiments to > emphasize the need > >> of using the { variable N in situations where the overload > is higher > >> than 100% of the { capacity of a link. > >> { > >> { Two sets of experiments are used. > >> { > >> { In those experiments the single bottleneck topology with 10 > >> ingresses is { used, see the SM draft for more details. > The used RTT > >> (on an unloaded { network) is set to be 4 ms. The capcity of the > >> botleneck link is 45 Mbs. > >> { The > >> { flows are generating CBR traffic, with a holding time of > 1 minute. > >> The > >> { used > >> { solution is LC-PCN trunk (using ingress-egress-aggregates). > >> { > >> { In the first set of experiments an overload of 180% is simulated. > >> { > >> { Graphs 1 and 2 show the results of the first set of experiments. > >> { Graph 1 shows the situation where N = 1 is used and > Graph 2 shows > >> the { situation where N = 2 is used. > >> { > >> { From these graphs can be seen that the recovery time > when N = 1 is > >> equal { to { +/- 1500 ms, while when N = 2 the recovery > time is +/- > >> 300 ms. > >> { > >> { In the second set of experiments an overload of 250% is > simulated. > >> { > >> { Graphs 3 and 4 show the results of the second set of experiments. > >> { Graph 3 shows the situation where N = 1 is used and > Graph 4 shows > >> the { situation where N = 3 is used. > >> { > >> { From this graph can be seen that the recovery time when N = 1 is > >> equal to { +/- 1500 ms, while when N = 3 the recovery time > is +/- 400 > >> ms. > >> { > >> { From these graphs can be seen that by using the required N value > >> the { recovery time can be decreased with a factor of up > to 5 times. > >> { > >> { Kind regards, > >> { Hein > >> { > >> { > >> { > -----Original Message----- > >> { > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > >> Behalf Of { > Georgios Karagiannis { > Sent: dinsdag 19 > augustus 2008 > >> 13:42 { > To: philip.eardley@bt.com; slblake@petri-meat.com; > >> pcn@ietf.org { > Cc: Lars.Westberg@ericsson.com; > >> Attila.Bader@ericsson.com { > Subject: Re: [PCN] regarding lc-pcn > >> features and consensus { > { > Hi Phil { > { > Specific simulation > >> results on the PCN context on the question that you { > > had { > I do > >> not have. > >> { > However, if you expect to see simulation results on > this matter I > >> { > expect { > that these results { > should be shown by Michael > >> since you are in favour of adopting that { > solution. > >> { > Michael mentioned already that results associated with the > >> dicussed { > case { > were not presented yet. > >> { > > >> { > Best regards, > >> { > Georgios > >> { > > >> { > > >> { > > >> { > > -----Original Message----- > >> { > > From: philip.eardley@bt.com > [mailto:philip.eardley@bt.com] { > > >> > Sent: dinsdag 19 augustus 2008 12:25 { > > To: > >> karagian@cs.utwente.nl; slblake@petri-meat.com; pcn@ietf.org { > > > >> Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > > > >> Subject: RE: [PCN] regarding lc-pcn features and consensus > { > > { > > >> > Georgios { > > { > > I notice you avoided my question " > Please can > >> you point me to { > > the earlier comparative { > > > analysis / > >> simulations that shows when it starts becoming { > important" > >> { > > so I assume you have haven't done comparative analysis / > >> simulations? > >> { > > Anyway, Michael's simulations seem to show that the > problem { > > >> > is not big enough to worry about. > >> { > > > >> { > > Thanks > >> { > > phil > >> { > > > >> { > > { -----Original Message----- > >> { > > { From: Georgios Karagiannis > [mailto:karagian@cs.utwente.nl] { > >> > > { Sent: 19 August 2008 10:34 { To: > Eardley,PL,Philip,CXR9 R; { > > >> > slblake@petri-meat.com; pcn@ietf.org { Cc: > >> { > > Lars.Westberg@ericsson.com; > Attila.Bader@ericsson.com { { > > > >> Subject: RE: [PCN] regarding lc-pcn features and consensus > { { > > { > >> Hi Phil { { Yes I am refering to the situation that you are { > > > >> mentioning. > >> { > > { Please note that in severe congestion situations the { > > > >> overload can easily { and { most of the times { go above > 100% { > > > >> of the capacity of the link. > >> { > > { > >> { > > { The mentioned issues were pointed out during Michael { > > > >> presentation (IETF { 71) { by Anna and by me. I am not > sure { > > if > >> they were included in the PCN minutes { of { IETF 71. > >> { > > { > >> { > > { Best regards, > >> { > > { Georgios > >> { > > { > >> { > > { > >> { > > { > >> { > > { > >> { > > { > -----Original Message----- > >> { > > { > From: philip.eardley@bt.com { > > > >> [mailto:philip.eardley@bt.com] { > Sent: dinsdag 19 augustus { > > > >> 2008 10:55 { > To: karagian@cs.utwente.nl; { > > > >> slblake@petri-meat.com; pcn@ietf.org { > Cc: > >> { > > Lars.Westberg@ericsson.com; > Attila.Bader@ericsson.com { > { > > > >> Subject: RE: [PCN] regarding lc-pcn features and consensus > { { > > > > >> { > Hi Georgios { > { > i think what you're referring to { > > > >> (please correct) is that if { > the interior node is { > > > massively > >> overloaded, then you're saying { > that the I-D's { > > approach > >> might terminate slower, essentially { > because of a { > > > saturation > >> effect (you can't have more than 100% { > marked { > > pkts) - > >> whereas this saturation effect doesn't appear { > { > > > until (much) > >> higher loads with the 'marking every Nth pkt' > >> { > > algorithm. > >> { > > { > > >> { > > { > Sure, at first glance I can believe there's a > theoretical { > >> > > { > saturation effect. Question is whether it's > important in { > > >> > { > practice. Please can you point me to the earlier { > > > >> comparative { > analysis / simulations that shows when it { > > > >> starts becoming { > important (eg link to the right mail - { > > > >> sorry my memory for { > old discussions is often bad!). > >> { > > { > > >> { > > { > Thanks > >> { > > { > Phil/ > >> { > > { > > >> { > > { > { -----Original Message----- { > > { > { From: Georgios > >> Karagiannis { > > [mailto:karagian@cs.utwente.nl] { > { Sent: 19 > >> August 2008 { > > 09:11 { To: Eardley,PL,Philip,CXR9 R; { > { > > > >> slblake@petri-meat.com; pcn@ietf.org { Cc: > >> { > > { > Lars.Westberg@ericsson.com; > Attila.Bader@ericsson.com { { { > >> > > Subject: RE: [PCN] regarding lc-pcn features and > consensus { > { > >> > >> { > >> { > Hi > >> { > Phil { { At the time I have checked this draft and I { > > { > > >> have also followed the { presentation given by Michael { > > > during { > >> > the { IETF 71. From the discussions that we have { > > > had then, I > >> { > did realise that { the { algorithm provided { > > in { > { > { > > > >> http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt > >> { > > { > { cannot achieve the same behaviour as the > algorithm { > > > >> that is { > marking every { N-th packet { when the > percentage { > > > >> of overload { > in an interior node is higher than 100% of { { > > > >> the capacity of the link. > >> { > > { > { > >> { > > { > { Best regards, > >> { > > { > { Georgios > >> { > > { > { > >> { > > { > { > >> { > > { > { > >> { > > { > { > >> { > > { > { > >> { > > { > { > -----Original Message----- { > > { > { > From: > >> philip.eardley@bt.com { > > { > [mailto:philip.eardley@bt.com] { > > >> Sent: maandag 18 { > > augustus { > 2008 17:04 { > To: > >> karagian@cs.utwente.nl; { > { > > slblake@petri-meat.com; > >> pcn@ietf.org { > Cc: > >> { > > { > Lars.Westberg@ericsson.com; > Attila.Bader@ericsson.com { > { > >> > > { > Subject: RE: [PCN] regarding lc-pcn features and { > > > >> consensus { { > > { > { > - marking every Nth pkt is not supported. > >> { > > { > { > { Thus you mean that the option of marking > every Nth { > >> > > pkt { > is precluded. > >> { > > { > { > { Without this option the LC-PCN algorithm > will { > > > >> become { > very { > slow { in situations of high overloads > { > > that > >> are { > above the { > capacity of a link. > >> { > > { > { > { > >> { > > { > { > { Therefore, we would very much appreciate > if an { > { > >> > > experimental { > extesion of { this { feature will be > allowed { > > >> > { > { to support the { > option that marked excess rate > { > { > > > >> represents { high levels of { { > excess rate). This can > be { { > > > >> implemented by marking every { { > N-th packet (or { { > > { > > >> byte)instead { { > of marking each packet (or { > byte). N > is a { { > > >> > > constant that is { equal or { higher { than 1. > >> { > > { > { > > >> { > > { > { > Georgios > >> { > > { > { > > >> { > > { > { > We had quite some discussion between a > couple of { > > > >> IETFs { { > > several months ago, which led to the draft { > { > > { > >> > http://www.watersprings.org/pub/id/draft-menth-pcn-emft- > >> 00.txt > >> { > > { > { > > >> { > > { > { > This came out of the desire to achieve > marked flow { { > >> > > > { > termination. The original suggestion was to do > this by { > > >> > { > { > marking every Nth pkt. However, it was realised > that { > > > >> this { > { > could be achieved by marking every pkt, but > then { > > > >> altering the { > { > edge behaviour (every time it sees a > { > > pkt, > >> it terminates { > that { > flow with a probability of { > > 1/N). > >> This was shown by { > simulation (see { > i-d) and { > > analysis > >> (see email I sent to { > list) to achieve { > { > > > exactly the same > >> behaviour. > >> { > > { > { > Hence marking every Nth pkt was shown to be > an { > { > > >> > unnecessary { > complication { > - it's clearly a good > thing { > > > >> { > to eliminate (all other things { > being equal) since it { > > > >> adds { > complexity to the marking { > algorithm and is { > > > another > >> { > parameter to configure. > >> { > > { > { > > >> { > > { > { > I believe this gives you the system > behaviour you want. > >> { > > { > { > > >> { > > { > { > Best wishes > >> { > > { > { > phil > >> { > > { > { > > >> { > > { > { > >> { > > { > > >> { > > { > >> { > > > >> { > > >> { > > >> { > _______________________________________________ > >> { > 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 Aug 26 08:26:29 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C5C328C197; Tue, 26 Aug 2008 08:26: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 5FCD628C172 for ; Tue, 26 Aug 2008 08:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.721 X-Spam-Level: X-Spam-Status: No, score=0.721 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_47=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Z4pw8z4SbTe for ; Tue, 26 Aug 2008 08:26:22 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id DA52228C197 for ; Tue, 26 Aug 2008 08:26:21 -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 m7QFQC4X007924; Tue, 26 Aug 2008 17:26:17 +0200 (MEST) From: "Georgios Karagiannis" To: References: <000601c906cf$dc165da0$944318e0$@com> <4A916DBC72536E419A0BD955EDECEDEC03DAA1B6@E03MVB1-UKBR.domain1.systemhost.net><004101c9076a$7d0ad700$77208500$@com> <48B3E7FA.8010405@informatik.uni-wuerzburg.de> <001501c9078a$f0aa3e60$810c5982@dynamic.ewi.utwente.nl> <48B41E4A.60000@informatik.uni-wuerzburg.de> Date: Tue, 26 Aug 2008 17:26:07 +0200 Message-ID: <001e01c90790$1426c520$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AckHjuqhTrAvgd1VTvG9u9Lzf7ZZOAAAF/eg In-Reply-To: <48B41E4A.60000@informatik.uni-wuerzburg.de> 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, 26 Aug 2008 17:26:19 +0200 (MEST) Cc: pcn@ietf.org Subject: Re: [PCN] regarding lc-pcn features and 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 Hi Michael Regarding the total load: When affected marking encoding is used then: Total load = PCN_marked rate + Affected marked rate When affected marked is not used: Total load = PCN_marked rate + unmarked rate. Please also note that for the used experiments the standard random dropping of packets is used and not the preferential dropping of unmarked packets. Best regards, Georgios > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: dinsdag 26 augustus 2008 17:16 > To: Georgios Karagiannis > Cc: 'Hein Mekkes'; pcn@ietf.org > Subject: Re: [PCN] regarding lc-pcn features and consensus > > Hi Georgios, > > I am referring to page 3 of > http://www.ietf.org/proceedings/08jul/slides/pcn-10.pdf > What is "total_load"? The rate of marked and unmarked pcn > traffic received by the egress node? Or is it something else? > How much traffic is terminated if (u-1)*(unmarked rate - > ((N-1)*PCN_marked rate)) <= 0? This can happen in case of > packet loss and in particular if unmarked packets are > preferentially dropped as you propose. > > Regards, > > Michael > > > Georgios Karagiannis wrote: > > Hi Michael > > > > Please see the slides that were presented by Hein during the IETF > > meeting in > > Dublin: > > http://www.ietf.org/proceedings/08jul/slides/pcn-10.pdf > > > > The excess marking works based on the admissible rate for admission > > control and on the configured termination rate for flow termination. > > > > Please also note that the used trigger to activate the flow > > termination at the egress is: > > > > IF {[PCN_marked rate/ total rate) > U -1] OR [at least one > > Affected_Marked packet arrived)} THEN egress goes to flow > termination > > state. > > > > Note that when Affected marking is used then Total rate = > PCN_marked > > rate + affected_marked rate > > > > Best regards, > > Georgios > > > > > > > > > > > >> -----Original Message----- > >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > On Behalf Of > >> Michael Menth > >> Sent: dinsdag 26 augustus 2008 13:25 > >> To: Hein Mekkes > >> Cc: pcn@ietf.org > >> Subject: Re: [PCN] regarding lc-pcn features and consensus > >> > >> Hi Hein, > >> > >> when I was looking at lc-pcn method, I found that it works > only when > >> excess marking is used based on the supportable rate. It does not > >> work for excess marking based on the admissible rate > because then the > >> egress node must determine the edge-to-edge supportable rate per > >> ingress-egress aggregate using the rate of unmarked packets > >> multiplied by u. > >> In case of packet loss (and no preferential dropping of marked > >> packets), this rate is underestimated which then leads to > >> overtermination. Thus, this method is only applicable in case of > >> excess marking based on the supportable rate. Is that true? > >> > >> Regards, > >> > >> Michael > >> > >> Hein Mekkes wrote: > >> > >>> Hi Phil, > >>> > >>> We have not done a comparison with EMFT since this was not > >>> > >> the goal of > >> > >>> the experiments. > >>> > >>> We tried to show that using different values than N = 1 > is useful, > >>> since in many cases it provides a decrease in recovery time > >>> > >> of up to 5 times. > >> > >>> This is evidence that shows that a different > >>> > >> proportionality than N = > >> > >>> 1 on marking bytes and measured excess bytes is very > useful. The SM > >>> draft supports only the N = 1 proportionality between > marking bytes > >>> and measured excess bytes. > >>> > >>> Hein > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > >>>> Sent: dinsdag 26 augustus 2008 11:36 > >>>> To: heinmekkes@gmail.com; pcn@ietf.org > >>>> Subject: RE: [PCN] regarding lc-pcn features and consensus > >>>> > >>>> Hein > >>>> > >>>> Couple of quick questions > >>>> > >>>> - what does N=1 mean? I thought it meant marking every Nth pkt & > >>>> terminating every flow. But this doesn't seem to make sense? > >>>> - have you done the comparison with the EMFT method? > >>>> > >>>> thanks > >>>> phil > >>>> > >>>> { -----Original Message----- > >>>> { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > >>>> > >> On Behalf > >> > >>>> Of Hein { Mekkes { Sent: 25 August 2008 17:30 { To: > pcn@ietf.org { > >>>> Subject: Re: [PCN] regarding lc-pcn features and consensus > >>>> > >> { { Dear > >> > >>>> all { { We had done some simulation experiments to > >>>> > >> emphasize the need > >> > >>>> of using the { variable N in situations where the overload > >>>> > >> is higher > >> > >>>> than 100% of the { capacity of a link. > >>>> { > >>>> { Two sets of experiments are used. > >>>> { > >>>> { In those experiments the single bottleneck topology with 10 > >>>> ingresses is { used, see the SM draft for more details. > >>>> > >> The used RTT > >> > >>>> (on an unloaded { network) is set to be 4 ms. The capcity of the > >>>> botleneck link is 45 Mbs. > >>>> { The > >>>> { flows are generating CBR traffic, with a holding time of > >>>> > >> 1 minute. > >> > >>>> The > >>>> { used > >>>> { solution is LC-PCN trunk (using ingress-egress-aggregates). > >>>> { > >>>> { In the first set of experiments an overload of 180% is > simulated. > >>>> { > >>>> { Graphs 1 and 2 show the results of the first set of > experiments. > >>>> { Graph 1 shows the situation where N = 1 is used and > >>>> > >> Graph 2 shows > >> > >>>> the { situation where N = 2 is used. > >>>> { > >>>> { From these graphs can be seen that the recovery time > >>>> > >> when N = 1 is > >> > >>>> equal { to { +/- 1500 ms, while when N = 2 the recovery > >>>> > >> time is +/- > >> > >>>> 300 ms. > >>>> { > >>>> { In the second set of experiments an overload of 250% is > >>>> > >> simulated. > >> > >>>> { > >>>> { Graphs 3 and 4 show the results of the second set of > experiments. > >>>> { Graph 3 shows the situation where N = 1 is used and > >>>> > >> Graph 4 shows > >> > >>>> the { situation where N = 3 is used. > >>>> { > >>>> { From this graph can be seen that the recovery time > when N = 1 is > >>>> equal to { +/- 1500 ms, while when N = 3 the recovery time > >>>> > >> is +/- 400 > >> > >>>> ms. > >>>> { > >>>> { From these graphs can be seen that by using the > required N value > >>>> the { recovery time can be decreased with a factor of up > >>>> > >> to 5 times. > >> > >>>> { > >>>> { Kind regards, > >>>> { Hein > >>>> { > >>>> { > >>>> { > -----Original Message----- > >>>> { > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > >>>> Behalf Of { > Georgios Karagiannis { > Sent: dinsdag 19 > >>>> > >> augustus 2008 > >> > >>>> 13:42 { > To: philip.eardley@bt.com; slblake@petri-meat.com; > >>>> pcn@ietf.org { > Cc: Lars.Westberg@ericsson.com; > >>>> Attila.Bader@ericsson.com { > Subject: Re: [PCN] > regarding lc-pcn > >>>> features and consensus { > { > Hi Phil { > { > Specific > simulation > >>>> results on the PCN context on the question that you { > > >>>> > >> had { > I do > >> > >>>> not have. > >>>> { > However, if you expect to see simulation results on > >>>> > >> this matter I > >> > >>>> { > expect { > that these results { > should be shown by Michael > >>>> since you are in favour of adopting that { > solution. > >>>> { > Michael mentioned already that results associated with the > >>>> dicussed { > case { > were not presented yet. > >>>> { > > >>>> { > Best regards, > >>>> { > Georgios > >>>> { > > >>>> { > > >>>> { > > >>>> { > > -----Original Message----- > >>>> { > > From: philip.eardley@bt.com > >>>> > >> [mailto:philip.eardley@bt.com] { > > >> > >>>>> Sent: dinsdag 19 augustus 2008 12:25 { > > To: > >>>>> > >>>> karagian@cs.utwente.nl; slblake@petri-meat.com; > pcn@ietf.org { > > > >>>> Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > > > >>>> Subject: RE: [PCN] regarding lc-pcn features and consensus > >>>> > >> { > > { > > >> > >>>>> Georgios { > > { > > I notice you avoided my question " > >>>>> > >> Please can > >> > >>>> you point me to { > > the earlier comparative { > > > analysis / > >>>> simulations that shows when it starts becoming { > important" > >>>> { > > so I assume you have haven't done comparative analysis / > >>>> simulations? > >>>> { > > Anyway, Michael's simulations seem to show that the > >>>> > >> problem { > > >> > >>>>> is not big enough to worry about. > >>>>> > >>>> { > > > >>>> { > > Thanks > >>>> { > > phil > >>>> { > > > >>>> { > > { -----Original Message----- > >>>> { > > { From: Georgios Karagiannis > >>>> > >> [mailto:karagian@cs.utwente.nl] { > >> > >>>>>> { Sent: 19 August 2008 10:34 { To: > >>>>>> > >> Eardley,PL,Philip,CXR9 R; { > > >> > >>>>> slblake@petri-meat.com; pcn@ietf.org { Cc: > >>>>> > >>>> { > > Lars.Westberg@ericsson.com; > >>>> > >> Attila.Bader@ericsson.com { { > > > >> > >>>> Subject: RE: [PCN] regarding lc-pcn features and consensus > >>>> > >> { { > > { > >> > >>>> Hi Phil { { Yes I am refering to the situation that you > are { > > > >>>> mentioning. > >>>> { > > { Please note that in severe congestion situations > the { > > > >>>> overload can easily { and { most of the times { go above > >>>> > >> 100% { > > > >> > >>>> of the capacity of the link. > >>>> { > > { > >>>> { > > { The mentioned issues were pointed out during > Michael { > > > >>>> presentation (IETF { 71) { by Anna and by me. I am not > >>>> > >> sure { > > if > >> > >>>> they were included in the PCN minutes { of { IETF 71. > >>>> { > > { > >>>> { > > { Best regards, > >>>> { > > { Georgios > >>>> { > > { > >>>> { > > { > >>>> { > > { > >>>> { > > { > >>>> { > > { > -----Original Message----- { > > { > From: > >>>> philip.eardley@bt.com { > > [mailto:philip.eardley@bt.com] { > > >>>> Sent: dinsdag 19 augustus { > > > >>>> 2008 10:55 { > To: karagian@cs.utwente.nl; { > > > >>>> slblake@petri-meat.com; pcn@ietf.org { > Cc: > >>>> { > > Lars.Westberg@ericsson.com; > >>>> > >> Attila.Bader@ericsson.com { > { > > > >> > >>>> Subject: RE: [PCN] regarding lc-pcn features and consensus > >>>> > >> { { > > > > >> > >>>> { > Hi Georgios { > { > i think what you're referring to { > > > >>>> (please correct) is that if { > the interior node is { > > > >>>> > >> massively > >> > >>>> overloaded, then you're saying { > that the I-D's { > > approach > >>>> might terminate slower, essentially { > because of a { > > > >>>> > >> saturation > >> > >>>> effect (you can't have more than 100% { > marked { > > pkts) - > >>>> whereas this saturation effect doesn't appear { > { > > > >>>> > >> until (much) > >> > >>>> higher loads with the 'marking every Nth pkt' > >>>> { > > algorithm. > >>>> { > > { > > >>>> { > > { > Sure, at first glance I can believe there's a > >>>> > >> theoretical { > >> > >>>>>> { > saturation effect. Question is whether it's > >>>>>> > >> important in { > > >> > >>>>> { > practice. Please can you point me to the earlier { > > > >>>>> > >>>> comparative { > analysis / simulations that shows when it { > > > >>>> starts becoming { > important (eg link to the right mail - { > > > >>>> sorry my memory for { > old discussions is often bad!). > >>>> { > > { > > >>>> { > > { > Thanks > >>>> { > > { > Phil/ > >>>> { > > { > > >>>> { > > { > { -----Original Message----- { > > { > { From: > Georgios > >>>> Karagiannis { > > [mailto:karagian@cs.utwente.nl] { > { Sent: 19 > >>>> August 2008 { > > 09:11 { To: Eardley,PL,Philip,CXR9 R; > { > { > > > >>>> slblake@petri-meat.com; pcn@ietf.org { Cc: > >>>> { > > { > Lars.Westberg@ericsson.com; > >>>> > >> Attila.Bader@ericsson.com { { { > >> > >>>>>> Subject: RE: [PCN] regarding lc-pcn features and > >>>>>> > >> consensus { > { > >> > >>>> > >>>> { > >>>> { > Hi > >>>> { > Phil { { At the time I have checked this draft and I > { > > { > > >>>> have also followed the { presentation given by Michael { > > >>>> > >>> during { > >>> > >>>>> the { IETF 71. From the discussions that we have { > > > >>>>> > >> had then, I > >> > >>>> { > did realise that { the { algorithm provided { > > in { > >>>> > >> { > { > > > >> > >>>> http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt > >>>> { > > { > { cannot achieve the same behaviour as the > >>>> > >> algorithm { > > > >> > >>>> that is { > marking every { N-th packet { when the > >>>> > >> percentage { > > > >> > >>>> of overload { > in an interior node is higher than 100% > of { { > > > >>>> the capacity of the link. > >>>> { > > { > { > >>>> { > > { > { Best regards, > >>>> { > > { > { Georgios > >>>> { > > { > { > >>>> { > > { > { > >>>> { > > { > { > >>>> { > > { > { > >>>> { > > { > { > >>>> { > > { > { > -----Original Message----- { > > { > { > From: > >>>> philip.eardley@bt.com { > > { > > [mailto:philip.eardley@bt.com] { > > >>>> Sent: maandag 18 { > > augustus { > 2008 17:04 { > To: > >>>> karagian@cs.utwente.nl; { > { > > slblake@petri-meat.com; > >>>> pcn@ietf.org { > Cc: > >>>> { > > { > Lars.Westberg@ericsson.com; > >>>> > >> Attila.Bader@ericsson.com { > { > >> > >>>>>> { > Subject: RE: [PCN] regarding lc-pcn features and { > > > >>>>>> > >>>> consensus { { > > { > { > - marking every Nth pkt is not > supported. > >>>> { > > { > { > { Thus you mean that the option of marking > >>>> > >> every Nth { > >> > >>>>>> pkt { > is precluded. > >>>>>> > >>>> { > > { > { > { Without this option the LC-PCN algorithm > >>>> > >> will { > > > >> > >>>> become { > very { > slow { in situations of high overloads > >>>> > >> { > > that > >> > >>>> are { > above the { > capacity of a link. > >>>> { > > { > { > { > >>>> { > > { > { > { Therefore, we would very much appreciate > >>>> > >> if an { > { > >> > >>>>>> experimental { > extesion of { this { feature will be > >>>>>> > >> allowed { > > >> > >>>>> { > { to support the { > option that marked excess rate > >>>>> > >> { > { > > > >> > >>>> represents { high levels of { { > excess rate). This can > >>>> > >> be { { > > > >> > >>>> implemented by marking every { { > N-th packet (or { { > > { > > >>>> byte)instead { { > of marking each packet (or { > byte). N > >>>> > >> is a { { > > >> > >>>>>> constant that is { equal or { higher { than 1. > >>>>>> > >>>> { > > { > { > > >>>> { > > { > { > Georgios > >>>> { > > { > { > > >>>> { > > { > { > We had quite some discussion between a > >>>> > >> couple of { > > > >> > >>>> IETFs { { > > several months ago, which led to the draft { > >>>> > >> { > > { > >> > >>>>> http://www.watersprings.org/pub/id/draft-menth-pcn-emft- > >>>>> > >>>> 00.txt > >>>> { > > { > { > > >>>> { > > { > { > This came out of the desire to achieve > >>>> > >> marked flow { { > >> > >>>>>>> { > termination. The original suggestion was to do > >>>>>>> > >> this by { > > >> > >>>>> { > { > marking every Nth pkt. However, it was realised > >>>>> > >> that { > > > >> > >>>> this { > { > could be achieved by marking every pkt, but > >>>> > >> then { > > > >> > >>>> altering the { > { > edge behaviour (every time it sees a > >>>> > >> { > > pkt, > >> > >>>> it terminates { > that { > flow with a probability of { > > > 1/N). > >>>> This was shown by { > simulation (see { > i-d) and { > > > analysis > >>>> (see email I sent to { > list) to achieve { > { > > > >>>> > >> exactly the same > >> > >>>> behaviour. > >>>> { > > { > { > Hence marking every Nth pkt was shown to be > >>>> > >> an { > { > > >> > >>>>> unnecessary { > complication { > - it's clearly a good > >>>>> > >> thing { > > > >> > >>>> { > to eliminate (all other things { > being equal) > since it { > > > >>>> adds { > complexity to the marking { > algorithm and is > { another { > >>>> > parameter to configure. > >>>> { > > { > { > > >>>> { > > { > { > I believe this gives you the system > >>>> > >> behaviour you want. > >> > >>>> { > > { > { > > >>>> { > > { > { > Best wishes > >>>> { > > { > { > phil > >>>> { > > { > { > > >>>> { > > { > { > >>>> { > > { > > >>>> { > > { > >>>> { > > > >>>> { > > >>>> { > > >>>> { > _______________________________________________ > >>>> { > 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 From pcn-bounces@ietf.org Tue Aug 26 08:39:39 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A4713A6A53; Tue, 26 Aug 2008 08:39: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 7E9073A6A53 for ; Tue, 26 Aug 2008 08:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=0.600, 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 VYMNf1i6ZwUt for ; Tue, 26 Aug 2008 08:39:37 -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 9B3C03A67D6 for ; Tue, 26 Aug 2008 08:39:37 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 8CCDBA0618; Tue, 26 Aug 2008 17:39:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 7FABCA0617; Tue, 26 Aug 2008 17:39:38 +0200 (CEST) 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 6BF5CA05FE; Tue, 26 Aug 2008 17:39:38 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.12.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m7QFdc227973; Tue, 26 Aug 2008 17:39:38 +0200 Received: from [IPv6:::1] (nero.informatik.uni-wuerzburg.de [132.187.12.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 39BF3C7FD3; Tue, 26 Aug 2008 17:39:38 +0200 (CEST) Message-ID: <48B42364.2050603@informatik.uni-wuerzburg.de> Date: Tue, 26 Aug 2008 17:38:12 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Georgios Karagiannis References: <000601c906cf$dc165da0$944318e0$@com> <4A916DBC72536E419A0BD955EDECEDEC03DAA1B6@E03MVB1-UKBR.domain1.systemhost.net><004101c9076a$7d0ad700$77208500$@com> <48B3E7FA.8010405@informatik.uni-wuerzburg.de> <001501c9078a$f0aa3e60$810c5982@dynamic.ewi.utwente.nl> <48B41E4A.60000@informatik.uni-wuerzburg.de> <001e01c90790$1426c520$810c5982@dynamic.ewi.utwente.nl> In-Reply-To: <001e01c90790$1426c520$810c5982@dynamic.ewi.utwente.nl> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] regarding lc-pcn features and 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 Georgios, >> I am referring to page 3 of >> http://www.ietf.org/proceedings/08jul/slides/pcn-10.pdf >> How much traffic is terminated if (u-1)*(unmarked rate - >> ((N-1)*PCN_marked rate)) <= 0? This can happen in case of >> packet loss and in particular if unmarked packets are >> preferentially dropped as you propose. >> What's the answer to that question? 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 Aug 26 08:43:12 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 130C33A6AAF; Tue, 26 Aug 2008 08:43: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 3667B3A698F for ; Tue, 26 Aug 2008 08:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.86 X-Spam-Level: X-Spam-Status: No, score=0.86 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_05=-1.11, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OuJaSzM+p8jf for ; Tue, 26 Aug 2008 08:43:07 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id EDD703A69EA for ; Tue, 26 Aug 2008 08:43:06 -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 m7QFh1Yh012992; Tue, 26 Aug 2008 17:43:04 +0200 (MEST) From: "Georgios Karagiannis" To: References: <000601c906cf$dc165da0$944318e0$@com> <4A916DBC72536E419A0BD955EDECEDEC03DAA1B6@E03MVB1-UKBR.domain1.systemhost.net><004101c9076a$7d0ad700$77208500$@com> <48B3E7FA.8010405@informatik.uni-wuerzburg.de> <001501c9078a$f0aa3e60$810c5982@dynamic.ewi.utwente.nl> <48B41E4A.60000@informatik.uni-wuerzburg.de> <001e01c90790$1426c520$810c5982@dynamic.ewi.utwente.nl> <48B42364.2050603@informatik.uni-wuerzburg.de> Date: Tue, 26 Aug 2008 17:42:56 +0200 Message-ID: <002001c90792$6bf7ee80$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AckHkfNHb2tZ9yNWRbOagaReIom5dAAABlqA In-Reply-To: <48B42364.2050603@informatik.uni-wuerzburg.de> 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, 26 Aug 2008 17:43:04 +0200 (MEST) Cc: pcn@ietf.org Subject: Re: [PCN] regarding lc-pcn features and 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 Hi Michael The answer is: Traffic to be terminated = Received PCN_marked rate * N - configured_termination_rate_egress The configured_termination_rate_egress is calculated as is given below. Best regards, Georgios > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: dinsdag 26 augustus 2008 17:38 > To: Georgios Karagiannis > Cc: 'Hein Mekkes'; pcn@ietf.org > Subject: Re: [PCN] regarding lc-pcn features and consensus > > Hi Georgios, > > >> I am referring to page 3 of > >> http://www.ietf.org/proceedings/08jul/slides/pcn-10.pdf > >> How much traffic is terminated if (u-1)*(unmarked rate - > >> ((N-1)*PCN_marked rate)) <= 0? This can happen in case of > packet loss > >> and in particular if unmarked packets are preferentially > dropped as > >> you propose. > >> > What's the answer to that question? > > 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 Aug 26 08:46:26 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 876C53A698F; Tue, 26 Aug 2008 08:46: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 46B943A698F for ; Tue, 26 Aug 2008 08:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300, 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 IaU4+sWcOyLm for ; Tue, 26 Aug 2008 08:46:24 -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 1E9043A6903 for ; Tue, 26 Aug 2008 08:46:24 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 8DF1A198E29; Tue, 26 Aug 2008 17:46:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 809CA198E28; Tue, 26 Aug 2008 17:46:25 +0200 (CEST) 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 5EF3B198E24; Tue, 26 Aug 2008 17:46:25 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.12.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m7QFkP228491; Tue, 26 Aug 2008 17:46:25 +0200 Received: from [IPv6:::1] (nero.informatik.uni-wuerzburg.de [132.187.12.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 2B3AAC7FD3; Tue, 26 Aug 2008 17:46:25 +0200 (CEST) Message-ID: <48B424FB.2060102@informatik.uni-wuerzburg.de> Date: Tue, 26 Aug 2008 17:44:59 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Georgios Karagiannis References: <000601c906cf$dc165da0$944318e0$@com> <4A916DBC72536E419A0BD955EDECEDEC03DAA1B6@E03MVB1-UKBR.domain1.systemhost.net><004101c9076a$7d0ad700$77208500$@com> <48B3E7FA.8010405@informatik.uni-wuerzburg.de> <001501c9078a$f0aa3e60$810c5982@dynamic.ewi.utwente.nl> <48B41E4A.60000@informatik.uni-wuerzburg.de> <001e01c90790$1426c520$810c5982@dynamic.ewi.utwente.nl> <48B42364.2050603@informatik.uni-wuerzburg.de> <002001c90792$6bf7ee80$810c5982@dynamic.ewi.utwente.nl> In-Reply-To: <002001c90792$6bf7ee80$810c5982@dynamic.ewi.utwente.nl> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] regarding lc-pcn features and 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 Georgios, that means, overtermination can occur because the configured_termination_rate_egress is possibly underestimated if unmarked packets are preferentially dropped. True? You'll see that in simulations only if the overload starts at the beginning of the measurment interval. Regards, Michael Georgios Karagiannis wrote: > Hi Michael > > The answer is: > > Traffic to be terminated = > Received PCN_marked rate * N - configured_termination_rate_egress > > The configured_termination_rate_egress is calculated as is given below. > > Best regards, > Georgios > > > >> -----Original Message----- >> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >> Sent: dinsdag 26 augustus 2008 17:38 >> To: Georgios Karagiannis >> Cc: 'Hein Mekkes'; pcn@ietf.org >> Subject: Re: [PCN] regarding lc-pcn features and consensus >> >> Hi Georgios, >> >> >>>> I am referring to page 3 of >>>> http://www.ietf.org/proceedings/08jul/slides/pcn-10.pdf >>>> How much traffic is terminated if (u-1)*(unmarked rate - >>>> ((N-1)*PCN_marked rate)) <= 0? This can happen in case of >>>> >> packet loss >> >>>> and in particular if unmarked packets are preferentially >>>> >> dropped as >> >>>> you propose. >>>> >>>> >> What's the answer to that question? >> >> 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 >> >> -- 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 Aug 26 08:50:09 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64D3D3A6B87; Tue, 26 Aug 2008 08:50: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 C9B443A69E2 for ; Tue, 26 Aug 2008 08:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_47=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j9sq-r4uhmOW for ; Tue, 26 Aug 2008 08:49:58 -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 24D6B28C1A4 for ; Tue, 26 Aug 2008 08:49:58 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id A6A9F198DDC; Tue, 26 Aug 2008 17:17:53 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 98597198DDB; Tue, 26 Aug 2008 17:17:53 +0200 (CEST) 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 73D6D198DD8; Tue, 26 Aug 2008 17:17:53 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.12.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m7QFHq227088; Tue, 26 Aug 2008 17:17:52 +0200 Received: from [IPv6:::1] (nero.informatik.uni-wuerzburg.de [132.187.12.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 96136C7FDB; Tue, 26 Aug 2008 17:17:52 +0200 (CEST) Message-ID: <48B41E4A.60000@informatik.uni-wuerzburg.de> Date: Tue, 26 Aug 2008 17:16:26 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Georgios Karagiannis References: <000601c906cf$dc165da0$944318e0$@com> <4A916DBC72536E419A0BD955EDECEDEC03DAA1B6@E03MVB1-UKBR.domain1.systemhost.net><004101c9076a$7d0ad700$77208500$@com> <48B3E7FA.8010405@informatik.uni-wuerzburg.de> <001501c9078a$f0aa3e60$810c5982@dynamic.ewi.utwente.nl> In-Reply-To: <001501c9078a$f0aa3e60$810c5982@dynamic.ewi.utwente.nl> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] regarding lc-pcn features and 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 Georgios, I am referring to page 3 of http://www.ietf.org/proceedings/08jul/slides/pcn-10.pdf What is "total_load"? The rate of marked and unmarked pcn traffic received by the egress node? Or is it something else? How much traffic is terminated if (u-1)*(unmarked rate - ((N-1)*PCN_marked rate)) <= 0? This can happen in case of packet loss and in particular if unmarked packets are preferentially dropped as you propose. Regards, Michael Georgios Karagiannis wrote: > Hi Michael > > Please see the slides that were presented by Hein during the IETF meeting in > Dublin: > http://www.ietf.org/proceedings/08jul/slides/pcn-10.pdf > > The excess marking works based on the admissible rate for admission control > and on the > configured termination rate for flow termination. > > Please also note that the used trigger to activate the flow termination at > the egress is: > > IF {[PCN_marked rate/ total rate) > U -1] OR [at least one Affected_Marked > packet arrived)} > THEN egress goes to flow termination state. > > Note that when Affected marking is used then > Total rate = PCN_marked rate + affected_marked rate > > Best regards, > Georgios > > > > > >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On >> Behalf Of Michael Menth >> Sent: dinsdag 26 augustus 2008 13:25 >> To: Hein Mekkes >> Cc: pcn@ietf.org >> Subject: Re: [PCN] regarding lc-pcn features and consensus >> >> Hi Hein, >> >> when I was looking at lc-pcn method, I found that it works >> only when excess marking is used based on the supportable >> rate. It does not work for excess marking based on the >> admissible rate because then the egress node must determine >> the edge-to-edge supportable rate per ingress-egress >> aggregate using the rate of unmarked packets multiplied by u. >> In case of packet loss (and no preferential dropping of >> marked packets), this rate is underestimated which then leads >> to overtermination. Thus, this method is only applicable in >> case of excess marking based on the supportable rate. Is that true? >> >> Regards, >> >> Michael >> >> Hein Mekkes wrote: >> >>> Hi Phil, >>> >>> We have not done a comparison with EMFT since this was not >>> >> the goal of >> >>> the experiments. >>> >>> We tried to show that using different values than N = 1 is useful, >>> since in many cases it provides a decrease in recovery time >>> >> of up to 5 times. >> >>> This is evidence that shows that a different >>> >> proportionality than N = >> >>> 1 on marking bytes and measured excess bytes is very useful. The SM >>> draft supports only the N = 1 proportionality between marking bytes >>> and measured excess bytes. >>> >>> Hein >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >>>> Sent: dinsdag 26 augustus 2008 11:36 >>>> To: heinmekkes@gmail.com; pcn@ietf.org >>>> Subject: RE: [PCN] regarding lc-pcn features and consensus >>>> >>>> Hein >>>> >>>> Couple of quick questions >>>> >>>> - what does N=1 mean? I thought it meant marking every Nth pkt & >>>> terminating every flow. But this doesn't seem to make sense? >>>> - have you done the comparison with the EMFT method? >>>> >>>> thanks >>>> phil >>>> >>>> { -----Original Message----- >>>> { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] >>>> >> On Behalf >> >>>> Of Hein { Mekkes { Sent: 25 August 2008 17:30 { To: pcn@ietf.org { >>>> Subject: Re: [PCN] regarding lc-pcn features and consensus >>>> >> { { Dear >> >>>> all { { We had done some simulation experiments to >>>> >> emphasize the need >> >>>> of using the { variable N in situations where the overload >>>> >> is higher >> >>>> than 100% of the { capacity of a link. >>>> { >>>> { Two sets of experiments are used. >>>> { >>>> { In those experiments the single bottleneck topology with 10 >>>> ingresses is { used, see the SM draft for more details. >>>> >> The used RTT >> >>>> (on an unloaded { network) is set to be 4 ms. The capcity of the >>>> botleneck link is 45 Mbs. >>>> { The >>>> { flows are generating CBR traffic, with a holding time of >>>> >> 1 minute. >> >>>> The >>>> { used >>>> { solution is LC-PCN trunk (using ingress-egress-aggregates). >>>> { >>>> { In the first set of experiments an overload of 180% is simulated. >>>> { >>>> { Graphs 1 and 2 show the results of the first set of experiments. >>>> { Graph 1 shows the situation where N = 1 is used and >>>> >> Graph 2 shows >> >>>> the { situation where N = 2 is used. >>>> { >>>> { From these graphs can be seen that the recovery time >>>> >> when N = 1 is >> >>>> equal { to { +/- 1500 ms, while when N = 2 the recovery >>>> >> time is +/- >> >>>> 300 ms. >>>> { >>>> { In the second set of experiments an overload of 250% is >>>> >> simulated. >> >>>> { >>>> { Graphs 3 and 4 show the results of the second set of experiments. >>>> { Graph 3 shows the situation where N = 1 is used and >>>> >> Graph 4 shows >> >>>> the { situation where N = 3 is used. >>>> { >>>> { From this graph can be seen that the recovery time when N = 1 is >>>> equal to { +/- 1500 ms, while when N = 3 the recovery time >>>> >> is +/- 400 >> >>>> ms. >>>> { >>>> { From these graphs can be seen that by using the required N value >>>> the { recovery time can be decreased with a factor of up >>>> >> to 5 times. >> >>>> { >>>> { Kind regards, >>>> { Hein >>>> { >>>> { >>>> { > -----Original Message----- >>>> { > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On >>>> Behalf Of { > Georgios Karagiannis { > Sent: dinsdag 19 >>>> >> augustus 2008 >> >>>> 13:42 { > To: philip.eardley@bt.com; slblake@petri-meat.com; >>>> pcn@ietf.org { > Cc: Lars.Westberg@ericsson.com; >>>> Attila.Bader@ericsson.com { > Subject: Re: [PCN] regarding lc-pcn >>>> features and consensus { > { > Hi Phil { > { > Specific simulation >>>> results on the PCN context on the question that you { > >>>> >> had { > I do >> >>>> not have. >>>> { > However, if you expect to see simulation results on >>>> >> this matter I >> >>>> { > expect { > that these results { > should be shown by Michael >>>> since you are in favour of adopting that { > solution. >>>> { > Michael mentioned already that results associated with the >>>> dicussed { > case { > were not presented yet. >>>> { > >>>> { > Best regards, >>>> { > Georgios >>>> { > >>>> { > >>>> { > >>>> { > > -----Original Message----- >>>> { > > From: philip.eardley@bt.com >>>> >> [mailto:philip.eardley@bt.com] { > >> >>>>> Sent: dinsdag 19 augustus 2008 12:25 { > > To: >>>>> >>>> karagian@cs.utwente.nl; slblake@petri-meat.com; pcn@ietf.org { > > >>>> Cc: Lars.Westberg@ericsson.com; Attila.Bader@ericsson.com { > > >>>> Subject: RE: [PCN] regarding lc-pcn features and consensus >>>> >> { > > { > >> >>>>> Georgios { > > { > > I notice you avoided my question " >>>>> >> Please can >> >>>> you point me to { > > the earlier comparative { > > > analysis / >>>> simulations that shows when it starts becoming { > important" >>>> { > > so I assume you have haven't done comparative analysis / >>>> simulations? >>>> { > > Anyway, Michael's simulations seem to show that the >>>> >> problem { > >> >>>>> is not big enough to worry about. >>>>> >>>> { > > >>>> { > > Thanks >>>> { > > phil >>>> { > > >>>> { > > { -----Original Message----- >>>> { > > { From: Georgios Karagiannis >>>> >> [mailto:karagian@cs.utwente.nl] { >> >>>>>> { Sent: 19 August 2008 10:34 { To: >>>>>> >> Eardley,PL,Philip,CXR9 R; { > >> >>>>> slblake@petri-meat.com; pcn@ietf.org { Cc: >>>>> >>>> { > > Lars.Westberg@ericsson.com; >>>> >> Attila.Bader@ericsson.com { { > > >> >>>> Subject: RE: [PCN] regarding lc-pcn features and consensus >>>> >> { { > > { >> >>>> Hi Phil { { Yes I am refering to the situation that you are { > > >>>> mentioning. >>>> { > > { Please note that in severe congestion situations the { > > >>>> overload can easily { and { most of the times { go above >>>> >> 100% { > > >> >>>> of the capacity of the link. >>>> { > > { >>>> { > > { The mentioned issues were pointed out during Michael { > > >>>> presentation (IETF { 71) { by Anna and by me. I am not >>>> >> sure { > > if >> >>>> they were included in the PCN minutes { of { IETF 71. >>>> { > > { >>>> { > > { Best regards, >>>> { > > { Georgios >>>> { > > { >>>> { > > { >>>> { > > { >>>> { > > { >>>> { > > { > -----Original Message----- >>>> { > > { > From: philip.eardley@bt.com { > > >>>> [mailto:philip.eardley@bt.com] { > Sent: dinsdag 19 augustus { > > >>>> 2008 10:55 { > To: karagian@cs.utwente.nl; { > > >>>> slblake@petri-meat.com; pcn@ietf.org { > Cc: >>>> { > > Lars.Westberg@ericsson.com; >>>> >> Attila.Bader@ericsson.com { > { > > >> >>>> Subject: RE: [PCN] regarding lc-pcn features and consensus >>>> >> { { > > > >> >>>> { > Hi Georgios { > { > i think what you're referring to { > > >>>> (please correct) is that if { > the interior node is { > > >>>> >> massively >> >>>> overloaded, then you're saying { > that the I-D's { > > approach >>>> might terminate slower, essentially { > because of a { > > >>>> >> saturation >> >>>> effect (you can't have more than 100% { > marked { > > pkts) - >>>> whereas this saturation effect doesn't appear { > { > > >>>> >> until (much) >> >>>> higher loads with the 'marking every Nth pkt' >>>> { > > algorithm. >>>> { > > { > >>>> { > > { > Sure, at first glance I can believe there's a >>>> >> theoretical { >> >>>>>> { > saturation effect. Question is whether it's >>>>>> >> important in { > >> >>>>> { > practice. Please can you point me to the earlier { > > >>>>> >>>> comparative { > analysis / simulations that shows when it { > > >>>> starts becoming { > important (eg link to the right mail - { > > >>>> sorry my memory for { > old discussions is often bad!). >>>> { > > { > >>>> { > > { > Thanks >>>> { > > { > Phil/ >>>> { > > { > >>>> { > > { > { -----Original Message----- { > > { > { From: Georgios >>>> Karagiannis { > > [mailto:karagian@cs.utwente.nl] { > { Sent: 19 >>>> August 2008 { > > 09:11 { To: Eardley,PL,Philip,CXR9 R; { > { > > >>>> slblake@petri-meat.com; pcn@ietf.org { Cc: >>>> { > > { > Lars.Westberg@ericsson.com; >>>> >> Attila.Bader@ericsson.com { { { >> >>>>>> Subject: RE: [PCN] regarding lc-pcn features and >>>>>> >> consensus { > { >> >>>> >>>> { >>>> { > Hi >>>> { > Phil { { At the time I have checked this draft and I { > > { > >>>> have also followed the { presentation given by Michael { > >>>> >>> during { >>> >>>>> the { IETF 71. From the discussions that we have { > > >>>>> >> had then, I >> >>>> { > did realise that { the { algorithm provided { > > in { >>>> >> { > { > > >> >>>> http://www.watersprings.org/pub/id/draft-menth-pcn-emft-00.txt >>>> { > > { > { cannot achieve the same behaviour as the >>>> >> algorithm { > > >> >>>> that is { > marking every { N-th packet { when the >>>> >> percentage { > > >> >>>> of overload { > in an interior node is higher than 100% of { { > > >>>> the capacity of the link. >>>> { > > { > { >>>> { > > { > { Best regards, >>>> { > > { > { Georgios >>>> { > > { > { >>>> { > > { > { >>>> { > > { > { >>>> { > > { > { >>>> { > > { > { >>>> { > > { > { > -----Original Message----- { > > { > { > From: >>>> philip.eardley@bt.com { > > { > [mailto:philip.eardley@bt.com] { > >>>> Sent: maandag 18 { > > augustus { > 2008 17:04 { > To: >>>> karagian@cs.utwente.nl; { > { > > slblake@petri-meat.com; >>>> pcn@ietf.org { > Cc: >>>> { > > { > Lars.Westberg@ericsson.com; >>>> >> Attila.Bader@ericsson.com { > { >> >>>>>> { > Subject: RE: [PCN] regarding lc-pcn features and { > > >>>>>> >>>> consensus { { > > { > { > - marking every Nth pkt is not supported. >>>> { > > { > { > { Thus you mean that the option of marking >>>> >> every Nth { >> >>>>>> pkt { > is precluded. >>>>>> >>>> { > > { > { > { Without this option the LC-PCN algorithm >>>> >> will { > > >> >>>> become { > very { > slow { in situations of high overloads >>>> >> { > > that >> >>>> are { > above the { > capacity of a link. >>>> { > > { > { > { >>>> { > > { > { > { Therefore, we would very much appreciate >>>> >> if an { > { >> >>>>>> experimental { > extesion of { this { feature will be >>>>>> >> allowed { > >> >>>>> { > { to support the { > option that marked excess rate >>>>> >> { > { > > >> >>>> represents { high levels of { { > excess rate). This can >>>> >> be { { > > >> >>>> implemented by marking every { { > N-th packet (or { { > > { > >>>> byte)instead { { > of marking each packet (or { > byte). N >>>> >> is a { { > >> >>>>>> constant that is { equal or { higher { than 1. >>>>>> >>>> { > > { > { > >>>> { > > { > { > Georgios >>>> { > > { > { > >>>> { > > { > { > We had quite some discussion between a >>>> >> couple of { > > >> >>>> IETFs { { > > several months ago, which led to the draft { >>>> >> { > > { >> >>>>> http://www.watersprings.org/pub/id/draft-menth-pcn-emft- >>>>> >>>> 00.txt >>>> { > > { > { > >>>> { > > { > { > This came out of the desire to achieve >>>> >> marked flow { { >> >>>>>>> { > termination. The original suggestion was to do >>>>>>> >> this by { > >> >>>>> { > { > marking every Nth pkt. However, it was realised >>>>> >> that { > > >> >>>> this { > { > could be achieved by marking every pkt, but >>>> >> then { > > >> >>>> altering the { > { > edge behaviour (every time it sees a >>>> >> { > > pkt, >> >>>> it terminates { > that { > flow with a probability of { > > 1/N). >>>> This was shown by { > simulation (see { > i-d) and { > > analysis >>>> (see email I sent to { > list) to achieve { > { > > >>>> >> exactly the same >> >>>> behaviour. >>>> { > > { > { > Hence marking every Nth pkt was shown to be >>>> >> an { > { > >> >>>>> unnecessary { > complication { > - it's clearly a good >>>>> >> thing { > > >> >>>> { > to eliminate (all other things { > being equal) since it { > > >>>> adds { > complexity to the marking { > algorithm and is { >>>> another >>>> { > parameter to configure. >>>> { > > { > { > >>>> { > > { > { > I believe this gives you the system >>>> >> behaviour you want. >> >>>> { > > { > { > >>>> { > > { > { > Best wishes >>>> { > > { > { > phil >>>> { > > { > { > >>>> { > > { > { >>>> { > > { > >>>> { > > { >>>> { > > >>>> { > >>>> { > >>>> { > _______________________________________________ >>>> { > 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 From pcn-bounces@ietf.org Tue Aug 26 08:50:15 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE32528C1CD; Tue, 26 Aug 2008 08:50: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 4B77928C1CC for ; Tue, 26 Aug 2008 08:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.881 X-Spam-Level: X-Spam-Status: No, score=0.881 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_05=-1.11, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gqezxAIVb5Z for ; Tue, 26 Aug 2008 08:50:13 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 1DBDA28C1A4 for ; Tue, 26 Aug 2008 08:50:12 -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 m7QFo61p015451; Tue, 26 Aug 2008 17:50:11 +0200 (MEST) From: "Georgios Karagiannis" To: References: <000601c906cf$dc165da0$944318e0$@com> <4A916DBC72536E419A0BD955EDECEDEC03DAA1B6@E03MVB1-UKBR.domain1.systemhost.net><004101c9076a$7d0ad700$77208500$@com> <48B3E7FA.8010405@informatik.uni-wuerzburg.de> <001501c9078a$f0aa3e60$810c5982@dynamic.ewi.utwente.nl> <48B41E4A.60000@informatik.uni-wuerzburg.de> <001e01c90790$1426c520$810c5982@dynamic.ewi.utwente.nl> <48B42364.2050603@informatik.uni-wuerzburg.de> <002001c90792$6bf7ee80$810c5982@dynamic.ewi.utwente.nl> <48B424FB.2060102@informatik.uni-wuerzburg.de> Date: Tue, 26 Aug 2008 17:50:01 +0200 Message-ID: <002101c90793$6aa44ff0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AckHkuZ3b+aH1WCQR7Swo6IXRE9bxwAACMMw In-Reply-To: <48B424FB.2060102@informatik.uni-wuerzburg.de> 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, 26 Aug 2008 17:50:11 +0200 (MEST) Cc: pcn@ietf.org Subject: Re: [PCN] regarding lc-pcn features and 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 Hi Michael As I mentioned in the simulations experiments, random dropping was used. The situation of preferentially dropping unmarked packets was not tested, since random dropping works fine. Best regards, Georgios > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: dinsdag 26 augustus 2008 17:45 > To: Georgios Karagiannis > Cc: 'Hein Mekkes'; pcn@ietf.org > Subject: Re: [PCN] regarding lc-pcn features and consensus > > Hi Georgios, > > that means, overtermination can occur because the > configured_termination_rate_egress is possibly underestimated > if unmarked packets are preferentially dropped. True? You'll > see that in simulations only if the overload starts at the > beginning of the measurment interval. > > Regards, > > Michael > > Georgios Karagiannis wrote: > > Hi Michael > > > > The answer is: > > > > Traffic to be terminated = > > Received PCN_marked rate * N - configured_termination_rate_egress > > > > The configured_termination_rate_egress is calculated as is > given below. > > > > Best regards, > > Georgios > > > > > > > >> -----Original Message----- > >> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > >> Sent: dinsdag 26 augustus 2008 17:38 > >> To: Georgios Karagiannis > >> Cc: 'Hein Mekkes'; pcn@ietf.org > >> Subject: Re: [PCN] regarding lc-pcn features and consensus > >> > >> Hi Georgios, > >> > >> > >>>> I am referring to page 3 of > >>>> http://www.ietf.org/proceedings/08jul/slides/pcn-10.pdf > >>>> How much traffic is terminated if (u-1)*(unmarked rate - > >>>> ((N-1)*PCN_marked rate)) <= 0? This can happen in case of > >>>> > >> packet loss > >> > >>>> and in particular if unmarked packets are preferentially > >>>> > >> dropped as > >> > >>>> you propose. > >>>> > >>>> > >> What's the answer to that question? > >> > >> 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 > >> > >> > > -- > 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 Aug 26 08:57:00 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25D0928C1D0; Tue, 26 Aug 2008 08:57: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 C090B28C1C6 for ; Tue, 26 Aug 2008 08:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300, 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 7uIHO9QdzUdA for ; Tue, 26 Aug 2008 08:56: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 374A928C1D7 for ; Tue, 26 Aug 2008 08:56:57 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id A1924A064A; Tue, 26 Aug 2008 17:56:58 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 9253AA0645; Tue, 26 Aug 2008 17:56:58 +0200 (CEST) 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 67B75A061A; Tue, 26 Aug 2008 17:56:58 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.12.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id m7QFuw228845; Tue, 26 Aug 2008 17:56:58 +0200 Received: from [IPv6:::1] (nero.informatik.uni-wuerzburg.de [132.187.12.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 39D5CC7FDD; Tue, 26 Aug 2008 17:56:58 +0200 (CEST) Message-ID: <48B42774.5090009@informatik.uni-wuerzburg.de> Date: Tue, 26 Aug 2008 17:55:32 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Georgios Karagiannis References: <000601c906cf$dc165da0$944318e0$@com> <4A916DBC72536E419A0BD955EDECEDEC03DAA1B6@E03MVB1-UKBR.domain1.systemhost.net><004101c9076a$7d0ad700$77208500$@com> <48B3E7FA.8010405@informatik.uni-wuerzburg.de> <001501c9078a$f0aa3e60$810c5982@dynamic.ewi.utwente.nl> <48B41E4A.60000@informatik.uni-wuerzburg.de> <001e01c90790$1426c520$810c5982@dynamic.ewi.utwente.nl> <48B42364.2050603@informatik.uni-wuerzburg.de> <002001c90792$6bf7ee80$810c5982@dynamic.ewi.utwente.nl> <48B424FB.2060102@informatik.uni-wuerzburg.de> <002101c90793$6aa44ff0$810c5982@dynamic.ewi.utwente.nl> In-Reply-To: <002101c90793$6aa44ff0$810c5982@dynamic.ewi.utwente.nl> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] regarding lc-pcn features and 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 Georgios, ok, that's what I thought. From my point of view, your method requires preferential dropping of unmarked packets to be faster than other methods and in this case it is prone to overtermination. You should check that! BTW, that was the reason why we stopped working on this mechanism. Regards, Michael Georgios Karagiannis wrote: > Hi Michael > > As I mentioned in the simulations experiments, > random dropping was used. The situation of preferentially dropping unmarked > packets was not tested, > since random dropping works fine. > > Best regards, > Georgios > > >> -----Original Message----- >> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >> Sent: dinsdag 26 augustus 2008 17:45 >> To: Georgios Karagiannis >> Cc: 'Hein Mekkes'; pcn@ietf.org >> Subject: Re: [PCN] regarding lc-pcn features and consensus >> >> Hi Georgios, >> >> that means, overtermination can occur because the >> configured_termination_rate_egress is possibly underestimated >> if unmarked packets are preferentially dropped. True? You'll >> see that in simulations only if the overload starts at the >> beginning of the measurment interval. >> >> Regards, >> >> Michael >> >> Georgios Karagiannis wrote: >> >>> Hi Michael >>> >>> The answer is: >>> >>> Traffic to be terminated = >>> Received PCN_marked rate * N - configured_termination_rate_egress >>> >>> The configured_termination_rate_egress is calculated as is >>> >> given below. >> >>> Best regards, >>> Georgios >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >>>> Sent: dinsdag 26 augustus 2008 17:38 >>>> To: Georgios Karagiannis >>>> Cc: 'Hein Mekkes'; pcn@ietf.org >>>> Subject: Re: [PCN] regarding lc-pcn features and consensus >>>> >>>> Hi Georgios, >>>> >>>> >>>> >>>>>> I am referring to page 3 of >>>>>> http://www.ietf.org/proceedings/08jul/slides/pcn-10.pdf >>>>>> How much traffic is terminated if (u-1)*(unmarked rate - >>>>>> ((N-1)*PCN_marked rate)) <= 0? This can happen in case of >>>>>> >>>>>> >>>> packet loss >>>> >>>> >>>>>> and in particular if unmarked packets are preferentially >>>>>> >>>>>> >>>> dropped as >>>> >>>> >>>>>> you propose. >>>>>> >>>>>> >>>>>> >>>> What's the answer to that question? >>>> >>>> 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 >>>> >>>> >>>> >> -- >> 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 Tue Aug 26 21:18:29 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A323D3A6B24; Tue, 26 Aug 2008 21:18: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 C8FBF3A6B3E for ; Tue, 26 Aug 2008 21:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, 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 KPWsbezk1137 for ; Tue, 26 Aug 2008 21:18:27 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id CB5B43A6B24 for ; Tue, 26 Aug 2008 21:18:27 -0700 (PDT) Received: from cpe-071-077-048-179.nc.res.rr.com ([71.77.48.179]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1KYCU4-0003Cf-59; Wed, 27 Aug 2008 00:18:16 -0400 From: Steven Blake To: Georgios Karagiannis In-Reply-To: <001101c90785$b275a8f0$810c5982@dynamic.ewi.utwente.nl> References: <88M1zluY.1219751073.4526280.karagian@ewi.utwente.nl> <1219754777.20944.8.camel@tachyon> <001101c90785$b275a8f0$810c5982@dynamic.ewi.utwente.nl> Date: Wed, 27 Aug 2008 00:18:18 -0400 Message-Id: <1219810698.28648.8.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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-08-26 at 16:11 +0200, Georgios Karagiannis wrote: > Hi Steven > > > Please see in line! > > > > -----Original Message----- > > From: Steven Blake [mailto:slblake@petri-meat.com] > > Sent: dinsdag 26 augustus 2008 14:46 > > To: Georgios Karagiannis > > Cc: pcn@ietf.org > > Subject: Re: [PCN] PCN WG last call for > > draft-ietf-pcn-architecture-05.txt > > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios Karagiannis wrote: > > > > > Hi Phil, Hi all > > > > > > Here are some comments on the PCN architecture draft: > > > > > > 1) Thank you for clarifying the bullet in Setion 3.2 about flow > > > termination. > > > > > > 2) From what I understand the PCN architecture draft > > mentions that PCN > > > supports only the trunk (ingress-egress-aggregate) and not the HOSE > > > model. > > > Is the PCN architecture draft excluding solutions that support the > > > HOSE model? If not, please emphasize in the PCN architecture draft > > > that "solutions that are based on other types of flow > > aggregation than > > > the ingress-egress-aggregate method of flow aggregation, are not > > > excluded from the PCN WG activities." > > > > Actually they are, by our charter. > > I have not seen that the PCN charter excludes other types of aggregation. Well, I checked, and you are correct (mea culpa). > Please note > that I am refering to the HOSE model where the traffic sent by one or more > than one ingresses towards one egress > is aggregated at the egress. In this way higgher traffic aggregation can be > accomplished than in the situation > that the pipe/trunk (ingress-egress-aggregate) is used, where the traffic > sent by only one ingress in aggegated at the egress. Typically the "hose" model refers to point-to-multipoint traffic flow, not multipoint-to-point. Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Aug 27 00:47:52 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBD5E3A68BD; Wed, 27 Aug 2008 00:47: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 091913A689C for ; Wed, 27 Aug 2008 00:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.452 X-Spam-Level: * X-Spam-Status: No, score=1.452 tagged_above=-999 required=5 tests=[AWL=-0.644, BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxzSt4bRoCOe for ; Wed, 27 Aug 2008 00:47: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 AD5943A68BD for ; Wed, 27 Aug 2008 00:47:49 -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 m7R7liWS015702; Wed, 27 Aug 2008 09:47:48 +0200 (MEST) From: "Georgios Karagiannis" To: References: <000601c906cf$dc165da0$944318e0$@com> <4A916DBC72536E419A0BD955EDECEDEC03DAA1B6@E03MVB1-UKBR.domain1.systemhost.net><004101c9076a$7d0ad700$77208500$@com> <48B3E7FA.8010405@informatik.uni-wuerzburg.de> <001501c9078a$f0aa3e60$810c5982@dynamic.ewi.utwente.nl> <48B41E4A.60000@informatik.uni-wuerzburg.de> <001e01c90790$1426c520$810c5982@dynamic.ewi.utwente.nl> <48B42364.2050603@informatik.uni-wuerzburg.de> <002001c90792$6bf7ee80$810c5982@dynamic.ewi.utwente.nl> <48B424FB.2060102@informatik.uni-wuerzburg.de> <002101c90793$6aa44ff0$810c5982@dynamic.ewi.utwente.nl> <48B42774.5090009@informatik.uni-wuerzburg.de> Date: Wed, 27 Aug 2008 09:47:40 +0200 Message-ID: <000101c90819$325bc750$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <48B42774.5090009@informatik.uni-wuerzburg.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AckHlF8raRlNBRMTSpOvrLiTI/WFngAhFXSw 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, 27 Aug 2008 09:47:49 +0200 (MEST) Cc: pcn@ietf.org Subject: Re: [PCN] regarding lc-pcn features and 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 Hi Michael It is not true what you are saying. The LC-PCN algorithm is at the moment optimized to work for random dropping and it works for all situations of overprovisioning., as it has been shown very fast. Best regards, Georgios > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: dinsdag 26 augustus 2008 17:56 > To: Georgios Karagiannis > Cc: 'Hein Mekkes'; pcn@ietf.org > Subject: Re: [PCN] regarding lc-pcn features and consensus > > Hi Georgios, > > ok, that's what I thought. From my point of view, your method > requires preferential dropping of unmarked packets to be > faster than other methods and in this case it is prone to > overtermination. You should check that! BTW, that was the > reason why we stopped working on this mechanism. > > Regards, > > Michael > > Georgios Karagiannis wrote: > > Hi Michael > > > > As I mentioned in the simulations experiments, random dropping was > > used. The situation of preferentially dropping unmarked packets was > > not tested, since random dropping works fine. > > > > Best regards, > > Georgios > > > > > >> -----Original Message----- > >> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > >> Sent: dinsdag 26 augustus 2008 17:45 > >> To: Georgios Karagiannis > >> Cc: 'Hein Mekkes'; pcn@ietf.org > >> Subject: Re: [PCN] regarding lc-pcn features and consensus > >> > >> Hi Georgios, > >> > >> that means, overtermination can occur because the > >> configured_termination_rate_egress is possibly underestimated if > >> unmarked packets are preferentially dropped. True? You'll > see that in > >> simulations only if the overload starts at the beginning of the > >> measurment interval. > >> > >> Regards, > >> > >> Michael > >> > >> Georgios Karagiannis wrote: > >> > >>> Hi Michael > >>> > >>> The answer is: > >>> > >>> Traffic to be terminated = > >>> Received PCN_marked rate * N - configured_termination_rate_egress > >>> > >>> The configured_termination_rate_egress is calculated as is > >>> > >> given below. > >> > >>> Best regards, > >>> Georgios > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > >>>> Sent: dinsdag 26 augustus 2008 17:38 > >>>> To: Georgios Karagiannis > >>>> Cc: 'Hein Mekkes'; pcn@ietf.org > >>>> Subject: Re: [PCN] regarding lc-pcn features and consensus > >>>> > >>>> Hi Georgios, > >>>> > >>>> > >>>> > >>>>>> I am referring to page 3 of > >>>>>> http://www.ietf.org/proceedings/08jul/slides/pcn-10.pdf > >>>>>> How much traffic is terminated if (u-1)*(unmarked rate - > >>>>>> ((N-1)*PCN_marked rate)) <= 0? This can happen in case of > >>>>>> > >>>>>> > >>>> packet loss > >>>> > >>>> > >>>>>> and in particular if unmarked packets are preferentially > >>>>>> > >>>>>> > >>>> dropped as > >>>> > >>>> > >>>>>> you propose. > >>>>>> > >>>>>> > >>>>>> > >>>> What's the answer to that question? > >>>> > >>>> 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 > >>>> > >>>> > >>>> > >> -- > >> 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 Aug 27 00:54:40 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 882473A67A3; Wed, 27 Aug 2008 00:54: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 7146D3A67A3 for ; Wed, 27 Aug 2008 00:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.439 X-Spam-Level: * X-Spam-Status: No, score=1.439 tagged_above=-999 required=5 tests=[AWL=-0.471, BAYES_40=-0.185, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ui0p+vjZf2+Y for ; Wed, 27 Aug 2008 00:54: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 67BFC3A679C for ; Wed, 27 Aug 2008 00:54: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 m7R7sSLW017229; Wed, 27 Aug 2008 09:54:31 +0200 (MEST) From: "Georgios Karagiannis" To: "'Steven Blake'" References: <88M1zluY.1219751073.4526280.karagian@ewi.utwente.nl> <1219754777.20944.8.camel@tachyon> <001101c90785$b275a8f0$810c5982@dynamic.ewi.utwente.nl> <1219810698.28648.8.camel@tachyon> Date: Wed, 27 Aug 2008 09:54:23 +0200 Message-ID: <000201c9081a$220dc730$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1219810698.28648.8.camel@tachyon> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AckH+/QV3Y45tt6jSHmIy28ziDldOAAHfAOA 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, 27 Aug 2008 09:54:31 +0200 (MEST) Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 > -----Original Message----- > From: Steven Blake [mailto:slblake@petri-meat.com] > Sent: woensdag 27 augustus 2008 6:18 > To: Georgios Karagiannis > Cc: pcn@ietf.org > Subject: RE: [PCN] PCN WG last call for > draft-ietf-pcn-architecture-05.txt > > On Tue, 2008-08-26 at 16:11 +0200, Georgios Karagiannis wrote: > > > Hi Steven > > > > > > Please see in line! > > > > > > > -----Original Message----- > > > From: Steven Blake [mailto:slblake@petri-meat.com] > > > Sent: dinsdag 26 augustus 2008 14:46 > > > To: Georgios Karagiannis > > > Cc: pcn@ietf.org > > > Subject: Re: [PCN] PCN WG last call for > > > draft-ietf-pcn-architecture-05.txt > > > > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios Karagiannis wrote: > > > > > > > Hi Phil, Hi all > > > > > > > > Here are some comments on the PCN architecture draft: > > > > > > > > 1) Thank you for clarifying the bullet in Setion 3.2 about flow > > > > termination. > > > > > > > > 2) From what I understand the PCN architecture draft > > > mentions that PCN > > > > supports only the trunk (ingress-egress-aggregate) and not the > > > > HOSE model. > > > > Is the PCN architecture draft excluding solutions that > support the > > > > HOSE model? If not, please emphasize in the PCN > architecture draft > > > > that "solutions that are based on other types of flow > > > aggregation than > > > > the ingress-egress-aggregate method of flow > aggregation, are not > > > > excluded from the PCN WG activities." > > > > > > Actually they are, by our charter. > > > > I have not seen that the PCN charter excludes other types > of aggregation. > > Well, I checked, and you are correct (mea culpa). Georgios: No problem > > > Please note > > that I am refering to the HOSE model where the traffic sent > by one or > > more than one ingresses towards one egress is aggregated at the > > egress. In this way higgher traffic aggregation can be accomplished > > than in the situation that the pipe/trunk > (ingress-egress-aggregate) > > is used, where the traffic sent by only one ingress in aggegated at > > the egress. > > Typically the "hose" model refers to point-to-multipoint > traffic flow, not multipoint-to-point. Georgios: Typically yes, but in this case we refer to bandwidth allocation in a multipoint-to-point fashion. > > > Regards, > > // Steve > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Aug 27 00:56:15 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E157F3A67A3; Wed, 27 Aug 2008 00:56: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 62B653A67A3 for ; Wed, 27 Aug 2008 00:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.284 X-Spam-Level: X-Spam-Status: No, score=0.284 tagged_above=-999 required=5 tests=[AWL=0.788, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: 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-5o72dUXAvO for ; Wed, 27 Aug 2008 00:56:13 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 328C53A691F for ; Wed, 27 Aug 2008 00:56:13 -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 m7R7uATv018368; Wed, 27 Aug 2008 09:56:13 +0200 (MEST) From: "Georgios Karagiannis" To: References: <000601c906cf$dc165da0$944318e0$@com> <4A916DBC72536E419A0BD955EDECEDEC03DAA1B6@E03MVB1-UKBR.domain1.systemhost.net><004101c9076a$7d0ad700$77208500$@com><48B3E7FA.8010405@informatik.uni-wuerzburg.de><001501c9078a$f0aa3e60$810c5982@dynamic.ewi.utwente.nl><48B41E4A.60000@informatik.uni-wuerzburg.de><001e01c90790$1426c520$810c5982@dynamic.ewi.utwente.nl><48B42364.2050603@informatik.uni-wuerzburg.de><002001c90792$6bf7ee80$810c5982@dynamic.ewi.utwente.nl><48B424FB.2060102@informatik.uni-wuerzburg.de><002101c90793$6aa44ff0$810c5982@dynamic.ewi.utwente.nl><48B42774.5090009@informatik.uni-wuerzburg.de> <000101c90819$325bc750$810c5982@dynamic.ewi.utwente.nl> Date: Wed, 27 Aug 2008 09:56:06 +0200 Message-ID: <000301c9081a$5f0e14a0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <000101c90819$325bc750$810c5982@dynamic.ewi.utwente.nl> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AckHlF8raRlNBRMTSpOvrLiTI/WFngAhFXSwAABes5A= 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, 27 Aug 2008 09:56:14 +0200 (MEST) Cc: pcn@ietf.org Subject: Re: [PCN] regarding lc-pcn features and 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 Hi Micahel I meant in all situations of overload: > It is not true what you are saying. The LC-PCN algorithm is > at the moment optimized to work for random dropping and it > > works for all situations of overload, as it has been > shown very fast. > > Best regards, > Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Georgios Karagiannis > Sent: woensdag 27 augustus 2008 9:48 > To: menth@informatik.uni-wuerzburg.de > Cc: pcn@ietf.org > Subject: Re: [PCN] regarding lc-pcn features and consensus > > Hi Michael > > It is not true what you are saying. The LC-PCN algorithm is > at the moment optimized to work for random dropping and it > works for all situations of overprovisioning., as it has been > shown very fast. > > Best regards, > Georgios > > > > > > > -----Original Message----- > > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > > Sent: dinsdag 26 augustus 2008 17:56 > > To: Georgios Karagiannis > > Cc: 'Hein Mekkes'; pcn@ietf.org > > Subject: Re: [PCN] regarding lc-pcn features and consensus > > > > Hi Georgios, > > > > ok, that's what I thought. From my point of view, your > method requires > > preferential dropping of unmarked packets to be faster than other > > methods and in this case it is prone to overtermination. You should > > check that! BTW, that was the reason why we stopped working on this > > mechanism. > > > > Regards, > > > > Michael > > > > Georgios Karagiannis wrote: > > > Hi Michael > > > > > > As I mentioned in the simulations experiments, random > dropping was > > > used. The situation of preferentially dropping unmarked > packets was > > > not tested, since random dropping works fine. > > > > > > Best regards, > > > Georgios > > > > > > > > >> -----Original Message----- > > >> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > > >> Sent: dinsdag 26 augustus 2008 17:45 > > >> To: Georgios Karagiannis > > >> Cc: 'Hein Mekkes'; pcn@ietf.org > > >> Subject: Re: [PCN] regarding lc-pcn features and consensus > > >> > > >> Hi Georgios, > > >> > > >> that means, overtermination can occur because the > > >> configured_termination_rate_egress is possibly underestimated if > > >> unmarked packets are preferentially dropped. True? You'll > > see that in > > >> simulations only if the overload starts at the beginning of the > > >> measurment interval. > > >> > > >> Regards, > > >> > > >> Michael > > >> > > >> Georgios Karagiannis wrote: > > >> > > >>> Hi Michael > > >>> > > >>> The answer is: > > >>> > > >>> Traffic to be terminated = > > >>> Received PCN_marked rate * N - > configured_termination_rate_egress > > >>> > > >>> The configured_termination_rate_egress is calculated as is > > >>> > > >> given below. > > >> > > >>> Best regards, > > >>> Georgios > > >>> > > >>> > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > > >>>> Sent: dinsdag 26 augustus 2008 17:38 > > >>>> To: Georgios Karagiannis > > >>>> Cc: 'Hein Mekkes'; pcn@ietf.org > > >>>> Subject: Re: [PCN] regarding lc-pcn features and consensus > > >>>> > > >>>> Hi Georgios, > > >>>> > > >>>> > > >>>> > > >>>>>> I am referring to page 3 of > > >>>>>> http://www.ietf.org/proceedings/08jul/slides/pcn-10.pdf > > >>>>>> How much traffic is terminated if (u-1)*(unmarked rate - > > >>>>>> ((N-1)*PCN_marked rate)) <= 0? This can happen in case of > > >>>>>> > > >>>>>> > > >>>> packet loss > > >>>> > > >>>> > > >>>>>> and in particular if unmarked packets are preferentially > > >>>>>> > > >>>>>> > > >>>> dropped as > > >>>> > > >>>> > > >>>>>> you propose. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>> What's the answer to that question? > > >>>> > > >>>> 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 > > >>>> > > >>>> > > >>>> > > >> -- > > >> 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 > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Aug 27 01:01:35 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96BF73A691F; Wed, 27 Aug 2008 01:01: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 0B8193A68CE for ; Wed, 27 Aug 2008 01:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.923 X-Spam-Level: X-Spam-Status: No, score=-0.923 tagged_above=-999 required=5 tests=[AWL=-1.425, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_ASCII0=1.5, 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 ci6xb+0759NL for ; Wed, 27 Aug 2008 01:01:28 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 76DD53A691F for ; Wed, 27 Aug 2008 01:01:27 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Aug 2008 09:01:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Aug 2008 09:01:27 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA1C4@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <713A7C5347A4344A8671770DFE2B2EA7017CC2CE@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Request for clarification of Other and priority traffic - seedraft-eardley-pcn-marking-behaviour-01 Thread-Index: AckHVfNfByaoB9vRTiaa/aj4wzcElgAxGMVw From: To: , X-OriginalArrivalTime: 27 Aug 2008 08:01:27.0668 (UTC) FILETIME=[1B955340:01C9081B] Subject: Re: [PCN] Request for clarification of Other and priority traffic - seedraft-eardley-pcn-marking-behaviour-01 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="===============1760875829==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1760875829== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9081B.1B742B25" This is a multi-part message in MIME format. ------_=_NextPart_001_01C9081B.1B742B25 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Chris, Indeed this section is unclear and will be improved in the next version. =20 However, it should be better in the most recent verson of the architecture draft, section 6.5 "PCN-traffic" http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-05.txt=20 =20 I think this answers your questions, but would appreciate it if you could have a look and see if it makes sense or leaves something unclear. =20 The sense of this S6.5 text will appear in the next version of the marking draft =20 Thanks phil =20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of HUBLET Christian Sent: 26 August 2008 09:30 To: pcn@ietf.org Subject: [PCN] Request for clarification of Other and priority traffic - seedraft-eardley-pcn-marking-behaviour-01 =20 =20 Hello,=20 >From draft-eardley-pcn-marking-behaviour-01, I understand that the to be metered traffic is :=20 - PCN traffic + Other traffic + Priority traffic.=20 >From the draft it is not clear to me what priority traffic basically means:=20 - In the definitions of section 1.1, priority traffic shares the same capacity.=20 - I wonder what the meaning is of capacity:=20 1. sharing the same physical interface (read capacity) or=20 2. the bandwidth (read capacity) is configured for the 2 (or 3) types of traffic. (no separate capacity (bandwidth) is specified per traffic type) I suppose that for the "other traffic" also both definitions can be applicable.=20 In the first definition, I see an issue for admittance control. If not all other and priority traffic is actually present in the network,=20 there could be an overadmittance of the PCN traffic. A practical example could be coexistance of business traffic and residential traffic in the same diffserv network.=20 The residential traffic is controlled via PCN, the business traffic is controlled via a policer at the edge of the network. If not all sessions for the business traffic are active, the PCN traffic could take capacity which was meant to be used for business traffic. =20 In the second definition, I do not understand why lower priority traffic should not be taken into account if the same capacity (read bandwidth) is shared with PCN traffic. I have the impression that there is a strict requirement to take into account other traffic and priority traffic if present (metered packet (see section 2.4) is part of meter traffic (see section 1.1)). If the first definition is applied, this strict requirement can have a huge impact on the number of applications that can be supported in the diffserv domain and the accuracy with which the PCN bandwidth is controlled. In the second definition, it is the wish of the operator to share the bandwidth for a number of applications which is basically a normal policy. But in this last case, it is not clear why lower priority traffic can't share the same bandwidth. Thanks for clarifying.=20 Kr,=20 Chris=20 =20 _________________________________=20 Christian hublet=20 Bell Labs - Fixed Access=20 Copernicuslaan 50=20 B2018 Antwerp=20 Belgium=20 Tel. +32 3 2408789;=20 Email : Christian.Hublet@alcatel-lucent.be=20 =20 =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 Alcatel-Lucent Bell NV=20 Fortis 220-0002334-42=20 VAT BE 0404 621 642 Register of Legal Entities Antwerp=20 DISCLAIMER: This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited without the prior consent of its author. =20 ------_=_NextPart_001_01C9081B.1B742B25 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Request for clarification of Other and priority traffic - see draft-eardley-pcn-marking-behaviour-01

Thanks Chris,

Indeed this section is unclear and = will be improved in the next version.

 

However, it should be better in the = most recent verson of the architecture draft, section 6.5 = “PCN-traffic” http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-05= .txt

 

I think this answers your = questions, but would appreciate it if you could have a look and see if it makes sense = or leaves something unclear.

 

The sense of this S6.5 text will = appear in the next version of the marking draft

 

Thanks

phil

 

-----Original Message-----
From: = pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On = Behalf Of HUBLET Christian
Sent: 26 August 2008 = 09:30
To: pcn@ietf.org
Subject: [PCN] Request = for clarification of Other and priority traffic - seedraft-eardley-pcn-marking-behaviour-01

 

 

Hello,

From draft-eardley-pcn-marking-behaviour-01, I understand that the to be = metered traffic is :
        - PCN traffic + Other = traffic + Priority traffic.

From the draft it is not clear to me what priority traffic basically = means:
        - In the definitions of = section 1.1, priority traffic shares the same capacity.
        - I wonder what the meaning = is of capacity:
                1. sharing the same = physical interface (read capacity) or
                2. the bandwidth (read = capacity) is configured for the 2 (or 3) types of traffic. (no separate capacity = (bandwidth) is specified per traffic type)

I suppose that for the "other traffic" also both definitions can = be applicable.

In the first definition, I see an issue for admittance control. If not all = other and priority traffic is actually present in the network, =

there could be an overadmittance of the PCN traffic. A practical example could = be coexistance of business traffic and residential traffic in the same = diffserv network.

The residential traffic is controlled via PCN, the business traffic is = controlled via a policer at the edge of the network. If not all sessions for the = business traffic are active, the PCN traffic could take capacity which was meant = to be used for business traffic.

 
In the second definition, I do not understand why lower priority traffic should = not be taken into account if the same capacity (read bandwidth) is shared with = PCN traffic.

I have the impression that there is a strict requirement to take into = account other traffic and priority traffic if present (metered packet (see = section 2.4) is part of meter traffic (see section 1.1)). If the first definition is applied, this strict requirement can have a huge impact on the number of applications that can be  supported  in the diffserv domain = and the accuracy with which the PCN bandwidth is controlled. In the second = definition, it is the wish of the operator to share the bandwidth for a number of applications which is basically a normal policy. But in this last case, = it is not clear why lower priority traffic can't share the same = bandwidth.

Thanks for clarifying.

Kr,

Chris

 

_________________________________
Christian hublet
Bell Labs - Fixed Access
Copernicuslaan 50
B2018 Antwerp
Belgium
Tel. +32 3 2408789;
Email : Christian.Hublet@alcatel-lucent.be

 

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =

Alcatel-Lucent Bell = NV
Fortis = 220-0002334-42
VAT BE 0404 621 642 Register of = Legal Entities Antwerp

DISCLAIMER: This message = (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the = intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, = is strictly prohibited without the prior consent of its = author.

 

=00 ------_=_NextPart_001_01C9081B.1B742B25-- --===============1760875829== 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 --===============1760875829==-- From pcn-bounces@ietf.org Wed Aug 27 01:19:34 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 140E83A6BC4; Wed, 27 Aug 2008 01: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 0BDE73A693D for ; Wed, 27 Aug 2008 01:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[AWL=0.910, 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 mjajlYw4s4BP for ; Wed, 27 Aug 2008 01:19:32 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id CE4BF3A6A46 for ; Wed, 27 Aug 2008 01:19:31 -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, 27 Aug 2008 09:19:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Aug 2008 09:19:30 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA1C5@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <000201c9081a$220dc730$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt Thread-Index: AckH+/QV3Y45tt6jSHmIy28ziDldOAAHfAOAAACCC8A= From: To: , X-OriginalArrivalTime: 27 Aug 2008 08:19:30.0416 (UTC) FILETIME=[A0F38F00:01C9081D] Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 the question is about adding to the draft: A model where the egress measures marks coming from all the ingresses, and makes admission decision based on that. Before adding anything about this to the draft, I'd like to understand if this is a genuine practical, understood option (if so, OK), or if it's a theoretical possibility or one not well understood. (there are many things in the latter category that aren't mentioned in the draft.) Questions are why this is interesting, why is it better than the models already well-known, are there comparative analysis /simulations? I suppose I've got 2 general issues: [1] every time something is added, overall the document becomes harder to understand, more daunting to read & it looks less like the WG has consensus. [2] this is an INFO doc. People are free to invent ways of using the standards pieces other than the architecture draft says, and indeed in ways not yet dreamt of. Phil. { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { Georgios Karagiannis { Sent: 27 August 2008 08:54 { To: 'Steven Blake' { Cc: pcn@ietf.org { Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt { { Hi Steven { { > -----Original Message----- { > From: Steven Blake [mailto:slblake@petri-meat.com] { > Sent: woensdag 27 augustus 2008 6:18 { > To: Georgios Karagiannis { > Cc: pcn@ietf.org { > Subject: RE: [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt { > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios Karagiannis wrote: { > { > > Hi Steven { > > { > > { > > Please see in line! { > > { > > { > > > -----Original Message----- { > > > From: Steven Blake [mailto:slblake@petri-meat.com] { > > > Sent: dinsdag 26 augustus 2008 14:46 { > > > To: Georgios Karagiannis { > > > Cc: pcn@ietf.org { > > > Subject: Re: [PCN] PCN WG last call for { > > > draft-ietf-pcn-architecture-05.txt { > > > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios Karagiannis wrote: { > > > { > > > > Hi Phil, Hi all { > > > > { > > > > Here are some comments on the PCN architecture draft: { > > > > { > > > > 1) Thank you for clarifying the bullet in Setion 3.2 about flow { > > > > termination. { > > > > { > > > > 2) From what I understand the PCN architecture draft { > > > mentions that PCN { > > > > supports only the trunk (ingress-egress-aggregate) and not the { > > > > HOSE model. { > > > > Is the PCN architecture draft excluding solutions that { > support the { > > > > HOSE model? If not, please emphasize in the PCN { > architecture draft { > > > > that "solutions that are based on other types of flow { > > > aggregation than { > > > > the ingress-egress-aggregate method of flow { > aggregation, are not { > > > > excluded from the PCN WG activities." { > > > { > > > Actually they are, by our charter. { > > { > > I have not seen that the PCN charter excludes other types { > of aggregation. { > { > Well, I checked, and you are correct (mea culpa). { Georgios: No problem { { > { > > Please note { > > that I am refering to the HOSE model where the traffic sent { > by one or { > > more than one ingresses towards one egress is aggregated at the { > > egress. In this way higgher traffic aggregation can be accomplished { > > than in the situation that the pipe/trunk { > (ingress-egress-aggregate) { > > is used, where the traffic sent by only one ingress in aggegated at { > > the egress. { > { > Typically the "hose" model refers to point-to-multipoint { > traffic flow, not multipoint-to-point. { Georgios: Typically yes, but in this case we refer to bandwidth allocation { in a multipoint-to-point fashion. { { > { > { > Regards, { > { > // Steve { > { { { _______________________________________________ { 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 Aug 27 01:46:07 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB2823A6C38; Wed, 27 Aug 2008 01:46: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 2BE073A6C38 for ; Wed, 27 Aug 2008 01:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.135 X-Spam-Level: * X-Spam-Status: No, score=1.135 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_20=-0.74, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6PRXYo-CILE for ; Wed, 27 Aug 2008 01:46: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 7E2FB3A6BFB for ; Wed, 27 Aug 2008 01:46:04 -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 m7R8fR15027567; Wed, 27 Aug 2008 10:41:30 +0200 (MEST) From: "Georgios Karagiannis" To: , References: <000201c9081a$220dc730$810c5982@dynamic.ewi.utwente.nl> <4A916DBC72536E419A0BD955EDECEDEC03DAA1C5@E03MVB1-UKBR.domain1.systemhost.net> Date: Wed, 27 Aug 2008 10:41:22 +0200 Message-ID: <000501c90820$b1efaca0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA1C5@E03MVB1-UKBR.domain1.systemhost.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AckH+/QV3Y45tt6jSHmIy28ziDldOAAHfAOAAACCC8AAAQ+VQA== 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, 27 Aug 2008 10:41:30 +0200 (MEST) Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 What I explained is the well know HOSE bandwidth management model. During the IETF in Dublin, Hein also shown also some results that were obtrained using the HOSE model. Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: woensdag 27 augustus 2008 10:20 > To: karagian@cs.utwente.nl; slblake@petri-meat.com > Cc: pcn@ietf.org > Subject: RE: [PCN] PCN WG last call for > draft-ietf-pcn-architecture-05.txt > > So the question is about adding to the draft: > A model where the egress measures marks coming from all the > ingresses, and makes admission decision based on that. > > Before adding anything about this to the draft, I'd like to > understand if this is a genuine practical, understood option > (if so, OK), or if it's a theoretical possibility or one not > well understood. > (there are many things in the latter category that aren't > mentioned in the draft.) > > Questions are why this is interesting, why is it better than > the models already well-known, are there comparative analysis > /simulations? > > I suppose I've got 2 general issues: > [1] every time something is added, overall the document > becomes harder to understand, more daunting to read & it > looks less like the WG has consensus. > [2] this is an INFO doc. People are free to invent ways of > using the standards pieces other than the architecture draft > says, and indeed in ways not yet dreamt of. > > Phil. > > { -----Original Message----- > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of { Georgios Karagiannis { Sent: 27 August 2008 08:54 > { To: 'Steven Blake' > { Cc: pcn@ietf.org > { Subject: Re: [PCN] PCN WG last call for > draft-ietf-pcn-architecture-05.txt > { > { Hi Steven > { > { > -----Original Message----- > { > From: Steven Blake [mailto:slblake@petri-meat.com] { > > Sent: woensdag 27 augustus 2008 6:18 { > To: Georgios > Karagiannis { > Cc: pcn@ietf.org { > Subject: RE: [PCN] PCN > WG last call for { > draft-ietf-pcn-architecture-05.txt > { > > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios Karagiannis wrote: > { > > { > > Hi Steven > { > > > { > > > { > > Please see in line! > { > > > { > > > { > > > -----Original Message----- > { > > > From: Steven Blake [mailto:slblake@petri-meat.com] { > > > > Sent: dinsdag 26 augustus 2008 14:46 { > > > To: > Georgios Karagiannis { > > > Cc: pcn@ietf.org { > > > > Subject: Re: [PCN] PCN WG last call for { > > > > draft-ietf-pcn-architecture-05.txt > { > > > > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios Karagiannis wrote: > { > > > > { > > > > Hi Phil, Hi all > { > > > > > { > > > > Here are some comments on the PCN architecture draft: > { > > > > > { > > > > 1) Thank you for clarifying the bullet in Setion > 3.2 about flow { > > > > termination. > { > > > > > { > > > > 2) From what I understand the PCN architecture > draft { > > > mentions that PCN { > > > > supports only the > trunk (ingress-egress-aggregate) and not the { > > > > HOSE model. > { > > > > Is the PCN architecture draft excluding solutions > that { > support the { > > > > HOSE model? If not, please > emphasize in the PCN { > architecture draft { > > > > that > "solutions that are based on other types of flow { > > > > aggregation than { > > > > the ingress-egress-aggregate > method of flow { > aggregation, are not { > > > > excluded > from the PCN WG activities." > { > > > > { > > > Actually they are, by our charter. > { > > > { > > I have not seen that the PCN charter excludes other > types { > of aggregation. > { > > { > Well, I checked, and you are correct (mea culpa). > { Georgios: No problem > { > { > > { > > Please note > { > > that I am refering to the HOSE model where the traffic > sent { > by one or { > > more than one ingresses towards one > egress is aggregated at the { > > egress. In this way higgher > traffic aggregation can be accomplished { > > than in the > situation that the pipe/trunk { > (ingress-egress-aggregate) > { > > is used, where the traffic sent by only one ingress in > aggegated at { > > the egress. > { > > { > Typically the "hose" model refers to point-to-multipoint > { > traffic flow, not multipoint-to-point. > { Georgios: Typically yes, but in this case we refer to > bandwidth allocation { in a multipoint-to-point fashion. > { > { > > { > > { > Regards, > { > > { > // Steve > { > > { > { > { _______________________________________________ > { 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 Aug 27 01:52:36 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60F303A6BE6; Wed, 27 Aug 2008 01:52: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 8D6783A6C0B for ; Wed, 27 Aug 2008 01:52:34 -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 zyT6nIPLkj7W for ; Wed, 27 Aug 2008 01:52:33 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id DBD423A6842 for ; Wed, 27 Aug 2008 01:52:32 -0700 (PDT) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.64]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Aug 2008 09:52:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Aug 2008 09:52:31 +0100 Message-ID: In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA1C5@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt Thread-Index: AckH+/QV3Y45tt6jSHmIy28ziDldOAAHfAOAAACCC8AAAS46IA== From: To: , , X-OriginalArrivalTime: 27 Aug 2008 08:52:28.0567 (UTC) FILETIME=[3C057270:01C90822] Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 don't recall having read anything before suggesting using the hose model "backwards" as Georgios suggests but I will admit that I am no expert in that particular field. Whilst the charter doesn't exclude the hose model explicitly it does seem to be written in such a way as to suggest it is excluded: "encoding and transport of (pre-)congestion information between the egress and the controlling domain ingress" suggests there is a singular ingress for each decision made at the egress. Other parts of the charter also seem to indicate this too... I don't feel we understand the hose model at all well. It seems to have only been mentioned relatively recently. I think given the maturity of the rest of the architecture document I don't want to see it held up by this. I would however be (reasonably) happy to see a sentence along the following lines: "This document assumes that all flow admission and termination decisions are based on the trunk (IEA) model. A future revision to this document might provide support for the hose model in the configuration where one egress makes decisions based on information received from many ingresses. 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 philip.eardley@bt.com > Sent: 27 August 2008 09:20 > To: karagian@cs.utwente.nl; slblake@petri-meat.com > Cc: pcn@ietf.org > Subject: Re: [PCN] PCN WG last call for > draft-ietf-pcn-architecture-05.txt > > So the question is about adding to the draft: > A model where the egress measures marks coming from all the ingresses, > and makes admission decision based on that. > > Before adding anything about this to the draft, I'd like to understand > if this is a genuine practical, understood option (if so, OK), or if > it's a theoretical possibility or one not well understood. > (there are many things in the latter category that aren't mentioned in > the draft.) > > Questions are why this is interesting, why is it better than > the models > already well-known, are there comparative analysis /simulations? > > I suppose I've got 2 general issues: > [1] every time something is added, overall the document becomes harder > to understand, more daunting to read & it looks less like the WG has > consensus. > [2] this is an INFO doc. People are free to invent ways of using the > standards pieces other than the architecture draft says, and indeed in > ways not yet dreamt of. > > Phil. > > { -----Original Message----- > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of > { Georgios Karagiannis > { Sent: 27 August 2008 08:54 > { To: 'Steven Blake' > { Cc: pcn@ietf.org > { Subject: Re: [PCN] PCN WG last call for > draft-ietf-pcn-architecture-05.txt > { > { Hi Steven > { > { > -----Original Message----- > { > From: Steven Blake [mailto:slblake@petri-meat.com] > { > Sent: woensdag 27 augustus 2008 6:18 > { > To: Georgios Karagiannis > { > Cc: pcn@ietf.org > { > Subject: RE: [PCN] PCN WG last call for > { > draft-ietf-pcn-architecture-05.txt > { > > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios Karagiannis wrote: > { > > { > > Hi Steven > { > > > { > > > { > > Please see in line! > { > > > { > > > { > > > -----Original Message----- > { > > > From: Steven Blake [mailto:slblake@petri-meat.com] > { > > > Sent: dinsdag 26 augustus 2008 14:46 > { > > > To: Georgios Karagiannis > { > > > Cc: pcn@ietf.org > { > > > Subject: Re: [PCN] PCN WG last call for > { > > > draft-ietf-pcn-architecture-05.txt > { > > > > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios Karagiannis wrote: > { > > > > { > > > > Hi Phil, Hi all > { > > > > > { > > > > Here are some comments on the PCN architecture draft: > { > > > > > { > > > > 1) Thank you for clarifying the bullet in Setion 3.2 about > flow > { > > > > termination. > { > > > > > { > > > > 2) From what I understand the PCN architecture draft > { > > > mentions that PCN > { > > > > supports only the trunk (ingress-egress-aggregate) > and not the > { > > > > HOSE model. > { > > > > Is the PCN architecture draft excluding solutions that > { > support the > { > > > > HOSE model? If not, please emphasize in the PCN > { > architecture draft > { > > > > that "solutions that are based on other types of flow > { > > > aggregation than > { > > > > the ingress-egress-aggregate method of flow > { > aggregation, are not > { > > > > excluded from the PCN WG activities." > { > > > > { > > > Actually they are, by our charter. > { > > > { > > I have not seen that the PCN charter excludes other types > { > of aggregation. > { > > { > Well, I checked, and you are correct (mea culpa). > { Georgios: No problem > { > { > > { > > Please note > { > > that I am refering to the HOSE model where the traffic sent > { > by one or > { > > more than one ingresses towards one egress is aggregated at the > { > > egress. In this way higgher traffic aggregation can be > accomplished > { > > than in the situation that the pipe/trunk > { > (ingress-egress-aggregate) > { > > is used, where the traffic sent by only one ingress in aggegated > at > { > > the egress. > { > > { > Typically the "hose" model refers to point-to-multipoint > { > traffic flow, not multipoint-to-point. > { Georgios: Typically yes, but in this case we refer to bandwidth > allocation > { in a multipoint-to-point fashion. > { > { > > { > > { > Regards, > { > > { > // Steve > { > > { > { > { _______________________________________________ > { 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 Aug 27 02:31:44 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D17373A6C62; Wed, 27 Aug 2008 02:31: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 71F6A3A6BFB for ; Wed, 27 Aug 2008 02:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.458, 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 hlA9H5U+--EG for ; Wed, 27 Aug 2008 02:31:42 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 15E573A691F for ; Wed, 27 Aug 2008 02:31:41 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Aug 2008 10:31:27 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Aug 2008 10:31:26 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA1C6@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <000501c90820$b1efaca0$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt Thread-Index: AckH+/QV3Y45tt6jSHmIy28ziDldOAAHfAOAAACCC8AAAQ+VQAABwDwQ From: To: , X-OriginalArrivalTime: 27 Aug 2008 09:31:27.0145 (UTC) FILETIME=[ADEC2190:01C90827] Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 thought your emails with steve had revealed that your model was the exact opposite of the well known hose model? { -----Original Message----- { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] { Sent: 27 August 2008 09:41 { To: Eardley,PL,Philip,CXR9 R; slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt { { Hi Phil { { What I explained is the well know HOSE bandwidth management model. { During the IETF in Dublin, Hein also shown also some results { that were obtrained using the HOSE model. { { { Best regards, { Georgios { { { > -----Original Message----- { > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 augustus 2008 10:20 { > To: karagian@cs.utwente.nl; slblake@petri-meat.com { > Cc: pcn@ietf.org { > Subject: RE: [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt { > { > So the question is about adding to the draft: { > A model where the egress measures marks coming from all the { > ingresses, and makes admission decision based on that. { > { > Before adding anything about this to the draft, I'd like to { > understand if this is a genuine practical, understood option { > (if so, OK), or if it's a theoretical possibility or one not { > well understood. { > (there are many things in the latter category that aren't { > mentioned in the draft.) { > { > Questions are why this is interesting, why is it better than { > the models already well-known, are there comparative analysis { > /simulations? { > { > I suppose I've got 2 general issues: { > [1] every time something is added, overall the document { > becomes harder to understand, more daunting to read & it { > looks less like the WG has consensus. { > [2] this is an INFO doc. People are free to invent ways of { > using the standards pieces other than the architecture draft { > says, and indeed in ways not yet dreamt of. { > { > Phil. { > { > { -----Original Message----- { > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On { > Behalf Of { Georgios Karagiannis { Sent: 27 August 2008 08:54 { > { To: 'Steven Blake' { > { Cc: pcn@ietf.org { > { Subject: Re: [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt { > { { > { Hi Steven { > { { > { > -----Original Message----- { > { > From: Steven Blake [mailto:slblake@petri-meat.com] { > { > Sent: woensdag 27 augustus 2008 6:18 { > To: Georgios { > Karagiannis { > Cc: pcn@ietf.org { > Subject: RE: [PCN] PCN { > WG last call for { > draft-ietf-pcn-architecture-05.txt { > { > { > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios Karagiannis wrote: { > { > { > { > > Hi Steven { > { > > { > { > > { > { > > Please see in line! { > { > > { > { > > { > { > > > -----Original Message----- { > { > > > From: Steven Blake [mailto:slblake@petri-meat.com] { { > > > > Sent: dinsdag 26 augustus 2008 14:46 { > > > To: { > Georgios Karagiannis { > > > Cc: pcn@ietf.org { > > > { > Subject: Re: [PCN] PCN WG last call for { > > > { > draft-ietf-pcn-architecture-05.txt { > { > > > { > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios Karagiannis wrote: { > { > > > { > { > > > > Hi Phil, Hi all { > { > > > > { > { > > > > Here are some comments on the PCN architecture draft: { > { > > > > { > { > > > > 1) Thank you for clarifying the bullet in Setion { > 3.2 about flow { > > > > termination. { > { > > > > { > { > > > > 2) From what I understand the PCN architecture { > draft { > > > mentions that PCN { > > > > supports only the { > trunk (ingress-egress-aggregate) and not the { > > > > HOSE model. { > { > > > > Is the PCN architecture draft excluding solutions { > that { > support the { > > > > HOSE model? If not, please { > emphasize in the PCN { > architecture draft { > > > > that { > "solutions that are based on other types of flow { > > > { > aggregation than { > > > > the ingress-egress-aggregate { > method of flow { > aggregation, are not { > > > > excluded { > from the PCN WG activities." { > { > > > { > { > > > Actually they are, by our charter. { > { > > { > { > > I have not seen that the PCN charter excludes other { > types { > of aggregation. { > { > { > { > Well, I checked, and you are correct (mea culpa). { > { Georgios: No problem { > { { > { > { > { > > Please note { > { > > that I am refering to the HOSE model where the traffic { > sent { > by one or { > > more than one ingresses towards one { > egress is aggregated at the { > > egress. In this way higgher { > traffic aggregation can be accomplished { > > than in the { > situation that the pipe/trunk { > (ingress-egress-aggregate) { > { > > is used, where the traffic sent by only one ingress in { > aggegated at { > > the egress. { > { > { > { > Typically the "hose" model refers to point-to-multipoint { > { > traffic flow, not multipoint-to-point. { > { Georgios: Typically yes, but in this case we refer to { > bandwidth allocation { in a multipoint-to-point fashion. { > { { > { > { > { > { > { > Regards, { > { > { > { > // Steve { > { > { > { { > { { > { _______________________________________________ { > { 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 Aug 27 02:38:23 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDE483A6C77; Wed, 27 Aug 2008 02:38: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 B2A5A3A6C77 for ; Wed, 27 Aug 2008 02:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.226 X-Spam-Level: X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[AWL=0.730, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TLBieIY1A1a for ; Wed, 27 Aug 2008 02:38:21 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 64DD43A6BFB for ; Wed, 27 Aug 2008 02:38:21 -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 m7R9bgSx008951; Wed, 27 Aug 2008 11:37:48 +0200 (MEST) From: "Georgios Karagiannis" To: , , References: <4A916DBC72536E419A0BD955EDECEDEC03DAA1C5@E03MVB1-UKBR.domain1.systemhost.net> Date: Wed, 27 Aug 2008 11:37:37 +0200 Message-ID: <001801c90828$8fa2b950$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AckH+/QV3Y45tt6jSHmIy28ziDldOAAHfAOAAACCC8AAAS46IAAB1GOQ 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, 27 Aug 2008 11:37:49 +0200 (MEST) Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 Toby What about the following two sentences: "This document assumes that all flow admission and termination decisions are based on the trunk (IEA) model. However, this document does not exclude a possible extension to the IEA model, denoted as hose model, where one egress makes decisions based on information received from many ingresses." Best regards, Georgios > -----Original Message----- > From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] > Sent: woensdag 27 augustus 2008 10:53 > To: philip.eardley@bt.com; karagian@cs.utwente.nl; > slblake@petri-meat.com > Cc: pcn@ietf.org > Subject: RE: [PCN] PCN WG last call for > draft-ietf-pcn-architecture-05.txt > > I don't recall having read anything before suggesting using > the hose model "backwards" as Georgios suggests but I will > admit that I am no expert in that particular field. > > Whilst the charter doesn't exclude the hose model explicitly > it does seem to be written in such a way as to suggest it is > excluded: > "encoding and transport of (pre-)congestion information > between the egress and the controlling domain ingress" > suggests there is a singular ingress for each decision made > at the egress. Other parts of the charter also seem to > indicate this too... > > I don't feel we understand the hose model at all well. It > seems to have only been mentioned relatively recently. I > think given the maturity of the rest of the architecture > document I don't want to see it held up by this. I would > however be (reasonably) happy to see a sentence along the > following lines: > "This document assumes that all flow admission and > termination decisions are based on the trunk (IEA) model. A > future revision to this document might provide support for > the hose model in the configuration where one egress makes > decisions based on information received from many ingresses. > > 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 > > philip.eardley@bt.com > > Sent: 27 August 2008 09:20 > > To: karagian@cs.utwente.nl; slblake@petri-meat.com > > Cc: pcn@ietf.org > > Subject: Re: [PCN] PCN WG last call for > > draft-ietf-pcn-architecture-05.txt > > > > So the question is about adding to the draft: > > A model where the egress measures marks coming from all the > ingresses, > > and makes admission decision based on that. > > > > Before adding anything about this to the draft, I'd like to > understand > > if this is a genuine practical, understood option (if so, > OK), or if > > it's a theoretical possibility or one not well understood. > > (there are many things in the latter category that aren't > mentioned in > > the draft.) > > > > Questions are why this is interesting, why is it better than the > > models already well-known, are there comparative analysis > > /simulations? > > > > I suppose I've got 2 general issues: > > [1] every time something is added, overall the document > becomes harder > > to understand, more daunting to read & it looks less like > the WG has > > consensus. > > [2] this is an INFO doc. People are free to invent ways of > using the > > standards pieces other than the architecture draft says, > and indeed in > > ways not yet dreamt of. > > > > Phil. > > > > { -----Original Message----- > > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > On Behalf > > Of { Georgios Karagiannis { Sent: 27 August 2008 08:54 { > To: 'Steven > > Blake' > > { Cc: pcn@ietf.org > > { Subject: Re: [PCN] PCN WG last call for > > draft-ietf-pcn-architecture-05.txt > > { > > { Hi Steven > > { > > { > -----Original Message----- > > { > From: Steven Blake [mailto:slblake@petri-meat.com] { > Sent: > > woensdag 27 augustus 2008 6:18 { > To: Georgios Karagiannis { > Cc: > > pcn@ietf.org { > Subject: RE: [PCN] PCN WG last call for { > > > draft-ietf-pcn-architecture-05.txt > > { > > > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios Karagiannis wrote: > > { > > > { > > Hi Steven > > { > > > > { > > > > { > > Please see in line! > > { > > > > { > > > > { > > > -----Original Message----- > > { > > > From: Steven Blake [mailto:slblake@petri-meat.com] { > > > > > Sent: dinsdag 26 augustus 2008 14:46 { > > > To: Georgios > Karagiannis > > { > > > Cc: pcn@ietf.org { > > > Subject: Re: [PCN] PCN WG > last call > > for { > > > draft-ietf-pcn-architecture-05.txt > > { > > > > > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios > Karagiannis wrote: > > { > > > > > { > > > > Hi Phil, Hi all > > { > > > > > > { > > > > Here are some comments on the PCN architecture draft: > > { > > > > > > { > > > > 1) Thank you for clarifying the bullet in Setion > 3.2 about > > flow { > > > > termination. > > { > > > > > > { > > > > 2) From what I understand the PCN architecture > draft { > > > > > mentions that PCN { > > > > supports only the trunk > > (ingress-egress-aggregate) and not the { > > > > HOSE model. > > { > > > > Is the PCN architecture draft excluding solutions > that { > > > support the { > > > > HOSE model? If not, please emphasize > in the PCN > > { > architecture draft { > > > > that "solutions that are based on > > other types of flow { > > > aggregation than { > > > > the > > ingress-egress-aggregate method of flow { > aggregation, > are not { > > > > > > excluded from the PCN WG activities." > > { > > > > > { > > > Actually they are, by our charter. > > { > > > > { > > I have not seen that the PCN charter excludes other > types { > of > > aggregation. > > { > > > { > Well, I checked, and you are correct (mea culpa). > > { Georgios: No problem > > { > > { > > > { > > Please note > > { > > that I am refering to the HOSE model where the > traffic sent { > > > by one or { > > more than one ingresses towards one egress is > > aggregated at the { > > egress. In this way higgher traffic > > aggregation can be accomplished { > > than in the situation > that the > > pipe/trunk { > (ingress-egress-aggregate) { > > is used, where the > > traffic sent by only one ingress in aggegated at { > > the egress. > > { > > > { > Typically the "hose" model refers to point-to-multipoint { > > > traffic flow, not multipoint-to-point. > > { Georgios: Typically yes, but in this case we refer to bandwidth > > allocation { in a multipoint-to-point fashion. > > { > > { > > > { > > > { > Regards, > > { > > > { > // Steve > > { > > > { > > { > > { _______________________________________________ > > { 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 Aug 27 02:51:35 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8B2A3A684F; Wed, 27 Aug 2008 02: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 5D2A33A6977 for ; Wed, 27 Aug 2008 02:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.306 X-Spam-Level: X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=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 d+SS+AdOMNj1 for ; Wed, 27 Aug 2008 02:51:33 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 5C8CD3A684F for ; Wed, 27 Aug 2008 02:51:33 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Aug 2008 10:49:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Aug 2008 10:49:43 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA1C7@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <001801c90828$8fa2b950$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt Thread-Index: AckH+/QV3Y45tt6jSHmIy28ziDldOAAHfAOAAACCC8AAAS46IAAB1GOQAACEHCA= From: To: , , X-OriginalArrivalTime: 27 Aug 2008 09:49:43.0985 (UTC) FILETIME=[3BB0A210:01C9082A] Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 at the moment I'm against adding any such text. Please see earlier email for the reasons & how to convince me to change my mind. { -----Original Message----- { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] { Sent: 27 August 2008 10:38 { To: Moncaster,T,Toby,CXR9 R; Eardley,PL,Philip,CXR9 R; slblake@petri- { meat.com { Cc: pcn@ietf.org { Subject: RE: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt { { Hi Toby { { What about the following two sentences: { { "This document assumes that all flow admission and { termination decisions are based on the trunk (IEA) model. However, this { document { does not exclude a possible extension to the IEA model, denoted as hose { model, { where one egress makes decisions based on information received from many { ingresses." { { { Best regards, { Georgios { { { > -----Original Message----- { > From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] { > Sent: woensdag 27 augustus 2008 10:53 { > To: philip.eardley@bt.com; karagian@cs.utwente.nl; { > slblake@petri-meat.com { > Cc: pcn@ietf.org { > Subject: RE: [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt { > { > I don't recall having read anything before suggesting using { > the hose model "backwards" as Georgios suggests but I will { > admit that I am no expert in that particular field. { > { > Whilst the charter doesn't exclude the hose model explicitly { > it does seem to be written in such a way as to suggest it is { > excluded: { > "encoding and transport of (pre-)congestion information { > between the egress and the controlling domain ingress" { > suggests there is a singular ingress for each decision made { > at the egress. Other parts of the charter also seem to { > indicate this too... { > { > I don't feel we understand the hose model at all well. It { > seems to have only been mentioned relatively recently. I { > think given the maturity of the rest of the architecture { > document I don't want to see it held up by this. I would { > however be (reasonably) happy to see a sentence along the { > following lines: { > "This document assumes that all flow admission and { > termination decisions are based on the trunk (IEA) model. A { > future revision to this document might provide support for { > the hose model in the configuration where one egress makes { > decisions based on information received from many ingresses. { > { > 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 { > > philip.eardley@bt.com { > > Sent: 27 August 2008 09:20 { > > To: karagian@cs.utwente.nl; slblake@petri-meat.com { > > Cc: pcn@ietf.org { > > Subject: Re: [PCN] PCN WG last call for { > > draft-ietf-pcn-architecture-05.txt { > > { > > So the question is about adding to the draft: { > > A model where the egress measures marks coming from all the { > ingresses, { > > and makes admission decision based on that. { > > { > > Before adding anything about this to the draft, I'd like to { > understand { > > if this is a genuine practical, understood option (if so, { > OK), or if { > > it's a theoretical possibility or one not well understood. { > > (there are many things in the latter category that aren't { > mentioned in { > > the draft.) { > > { > > Questions are why this is interesting, why is it better than the { > > models already well-known, are there comparative analysis { > > /simulations? { > > { > > I suppose I've got 2 general issues: { > > [1] every time something is added, overall the document { > becomes harder { > > to understand, more daunting to read & it looks less like { > the WG has { > > consensus. { > > [2] this is an INFO doc. People are free to invent ways of { > using the { > > standards pieces other than the architecture draft says, { > and indeed in { > > ways not yet dreamt of. { > > { > > Phil. { > > { > > { -----Original Message----- { > > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] { > On Behalf { > > Of { Georgios Karagiannis { Sent: 27 August 2008 08:54 { { > To: 'Steven { > > Blake' { > > { Cc: pcn@ietf.org { > > { Subject: Re: [PCN] PCN WG last call for { > > draft-ietf-pcn-architecture-05.txt { > > { { > > { Hi Steven { > > { { > > { > -----Original Message----- { > > { > From: Steven Blake [mailto:slblake@petri-meat.com] { > Sent: { > > woensdag 27 augustus 2008 6:18 { > To: Georgios Karagiannis { > Cc: { > > pcn@ietf.org { > Subject: RE: [PCN] PCN WG last call for { > { > > draft-ietf-pcn-architecture-05.txt { > > { > { > > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios Karagiannis wrote: { > > { > { > > { > > Hi Steven { > > { > > { > > { > > { > > { > > Please see in line! { > > { > > { > > { > > { > > { > > > -----Original Message----- { > > { > > > From: Steven Blake [mailto:slblake@petri-meat.com] { > > > { > > Sent: dinsdag 26 augustus 2008 14:46 { > > > To: Georgios { > Karagiannis { > > { > > > Cc: pcn@ietf.org { > > > Subject: Re: [PCN] PCN WG { > last call { > > for { > > > draft-ietf-pcn-architecture-05.txt { > > { > > > { > > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios { > Karagiannis wrote: { > > { > > > { > > { > > > > Hi Phil, Hi all { > > { > > > > { > > { > > > > Here are some comments on the PCN architecture draft: { > > { > > > > { > > { > > > > 1) Thank you for clarifying the bullet in Setion { > 3.2 about { > > flow { > > > > termination. { > > { > > > > { > > { > > > > 2) From what I understand the PCN architecture { > draft { > > > { > > mentions that PCN { > > > > supports only the trunk { > > (ingress-egress-aggregate) and not the { > > > > HOSE model. { > > { > > > > Is the PCN architecture draft excluding solutions { > that { > { > > support the { > > > > HOSE model? If not, please emphasize { > in the PCN { > > { > architecture draft { > > > > that "solutions that are based on { > > other types of flow { > > > aggregation than { > > > > the { > > ingress-egress-aggregate method of flow { > aggregation, { > are not { > > { > > > > excluded from the PCN WG activities." { > > { > > > { > > { > > > Actually they are, by our charter. { > > { > > { > > { > > I have not seen that the PCN charter excludes other { > types { > of { > > aggregation. { > > { > { > > { > Well, I checked, and you are correct (mea culpa). { > > { Georgios: No problem { > > { { > > { > { > > { > > Please note { > > { > > that I am refering to the HOSE model where the { > traffic sent { > { > > by one or { > > more than one ingresses towards one egress is { > > aggregated at the { > > egress. In this way higgher traffic { > > aggregation can be accomplished { > > than in the situation { > that the { > > pipe/trunk { > (ingress-egress-aggregate) { > > is used, where the { > > traffic sent by only one ingress in aggegated at { > > the egress. { > > { > { > > { > Typically the "hose" model refers to point-to-multipoint { > { > > traffic flow, not multipoint-to-point. { > > { Georgios: Typically yes, but in this case we refer to bandwidth { > > allocation { in a multipoint-to-point fashion. { > > { { > > { > { > > { > { > > { > Regards, { > > { > { > > { > // Steve { > > { > { > > { { > > { { > > { _______________________________________________ { > > { 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 Aug 27 03:37:48 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C8DA3A6BFB; Wed, 27 Aug 2008 03:37: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 554283A6BFB for ; Wed, 27 Aug 2008 03:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.465 X-Spam-Level: X-Spam-Status: No, score=0.465 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzID9vzR1wPz for ; Wed, 27 Aug 2008 03:37: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 BF8173A6AC1 for ; Wed, 27 Aug 2008 03:37:42 -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 m7RAb8QQ022352; Wed, 27 Aug 2008 12:37:12 +0200 (MEST) From: "Georgios Karagiannis" To: , References: <000501c90820$b1efaca0$810c5982@dynamic.ewi.utwente.nl> <4A916DBC72536E419A0BD955EDECEDEC03DAA1C6@E03MVB1-UKBR.domain1.systemhost.net> Date: Wed, 27 Aug 2008 12:37:04 +0200 Message-ID: <001c01c90830$dc8f96e0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA1C6@E03MVB1-UKBR.domain1.systemhost.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AckH+/QV3Y45tt6jSHmIy28ziDldOAAHfAOAAACCC8AAAQ+VQAABwDwQAAIzkmA= 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, 27 Aug 2008 12:37:13 +0200 (MEST) Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 HOSE model is defined some 20 years ago, please see e.g the following article: N. G. Duffield, P. Goyal and A. Greenberg, "A Flexible Model for Resource Management in Virtual Private Networks", in: Proc. of ACM SIGCOMM, 1999. In the above article I found the following definition: "A hose is characterized by the aggregate traffic to and from one endpoint in the VPN to the set of other endpoints in the VPN" Thus the definition refers to aggregated traffic to and from one edge to and from all other endpoints. In our case we refer only to the aggregated traffic from other endpoints to one endpoint. Thus what we use is in line with the definition of the HOSE model. Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: woensdag 27 augustus 2008 11:31 > To: karagian@cs.utwente.nl; slblake@petri-meat.com > Cc: pcn@ietf.org > Subject: RE: [PCN] PCN WG last call for > draft-ietf-pcn-architecture-05.txt > > I thought your emails with steve had revealed that your model > was the exact opposite of the well known hose model? > > > { -----Original Message----- > { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > { Sent: 27 August 2008 09:41 { To: Eardley,PL,Philip,CXR9 R; > slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt > { > { Hi Phil > { > { What I explained is the well know HOSE bandwidth management model. > { During the IETF in Dublin, Hein also shown also some > results { that were obtrained using the HOSE model. > { > { > { Best regards, > { Georgios > { > { > { > -----Original Message----- > { > From: philip.eardley@bt.com > [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 augustus > 2008 10:20 { > To: karagian@cs.utwente.nl; > slblake@petri-meat.com { > Cc: pcn@ietf.org { > Subject: RE: > [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt > { > > { > So the question is about adding to the draft: > { > A model where the egress measures marks coming from all > the { > ingresses, and makes admission decision based on that. > { > > { > Before adding anything about this to the draft, I'd like > to { > understand if this is a genuine practical, understood > option { > (if so, OK), or if it's a theoretical possibility > or one not { > well understood. > { > (there are many things in the latter category that aren't > { > mentioned in the draft.) { > { > Questions are why this > is interesting, why is it better than { > the models already > well-known, are there comparative analysis { > /simulations? > { > > { > I suppose I've got 2 general issues: > { > [1] every time something is added, overall the document { > becomes harder to understand, more daunting to read & it { > > looks less like the WG has consensus. > { > [2] this is an INFO doc. People are free to invent ways > of { > using the standards pieces other than the architecture > draft { > says, and indeed in ways not yet dreamt of. > { > > { > Phil. > { > > { > { -----Original Message----- > { > { From: pcn-bounces@ietf.org > [mailto:pcn-bounces@ietf.org] On { > Behalf Of { Georgios > Karagiannis { Sent: 27 August 2008 08:54 { > { To: 'Steven Blake' > { > { Cc: pcn@ietf.org > { > { Subject: Re: [PCN] PCN WG last call for { > > draft-ietf-pcn-architecture-05.txt > { > { > { > { Hi Steven > { > { > { > { > -----Original Message----- > { > { > From: Steven Blake [mailto:slblake@petri-meat.com] { > > { > Sent: woensdag 27 augustus 2008 6:18 { > To: Georgios { > Karagiannis { > Cc: pcn@ietf.org { > Subject: RE: [PCN] PCN > { > WG last call for { > draft-ietf-pcn-architecture-05.txt > { > { > > { > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios Karagiannis wrote: > { > { > > { > { > > Hi Steven > { > { > > > { > { > > > { > { > > Please see in line! > { > { > > > { > { > > > { > { > > > -----Original Message----- > { > { > > > From: Steven Blake > [mailto:slblake@petri-meat.com] { { > > > > Sent: dinsdag 26 > augustus 2008 14:46 { > > > To: > { > Georgios Karagiannis { > > > Cc: pcn@ietf.org { > > > { > > Subject: Re: [PCN] PCN WG last call for { > > > { > > draft-ietf-pcn-architecture-05.txt > { > { > > > > { > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios Karagiannis > wrote: > { > { > > > > { > { > > > > Hi Phil, Hi all > { > { > > > > > { > { > > > > Here are some comments on the PCN architecture draft: > { > { > > > > > { > { > > > > 1) Thank you for clarifying the bullet in > Setion { > 3.2 about flow { > > > > termination. > { > { > > > > > { > { > > > > 2) From what I understand the PCN architecture > { > draft { > > > mentions that PCN { > > > > supports only > the { > trunk (ingress-egress-aggregate) and not the { > > > > > HOSE model. > { > { > > > > Is the PCN architecture draft excluding > solutions { > that { > support the { > > > > HOSE model? If > not, please { > emphasize in the PCN { > architecture draft { > > > > that { > "solutions that are based on other types of > flow { > > > { > aggregation than { > > > > the > ingress-egress-aggregate { > method of flow { > aggregation, > are not { > > > > excluded { > from the PCN WG activities." > { > { > > > > { > { > > > Actually they are, by our charter. > { > { > > > { > { > > I have not seen that the PCN charter excludes other > { > types { > of aggregation. > { > { > > { > { > Well, I checked, and you are correct (mea culpa). > { > { Georgios: No problem > { > { > { > { > > { > { > > Please note > { > { > > that I am refering to the HOSE model where the > traffic { > sent { > by one or { > > more than one ingresses > towards one { > egress is aggregated at the { > > egress. In > this way higgher { > traffic aggregation can be accomplished > { > > than in the { > situation that the pipe/trunk { > > (ingress-egress-aggregate) { > { > > is used, where the > traffic sent by only one ingress in { > aggegated at { > > the egress. > { > { > > { > { > Typically the "hose" model refers to > point-to-multipoint { > { > traffic flow, not multipoint-to-point. > { > { Georgios: Typically yes, but in this case we refer to { > bandwidth allocation { in a multipoint-to-point fashion. > { > { > { > { > > { > { > > { > { > Regards, > { > { > > { > { > // Steve > { > { > > { > { > { > { > { > { _______________________________________________ > { > { 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 Aug 27 04:35:03 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C6FE3A6B18; Wed, 27 Aug 2008 04:35: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 0C3D23A6ACD for ; Wed, 27 Aug 2008 04:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[AWL=0.381, 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 MGE512QuQRP3 for ; Wed, 27 Aug 2008 04:34: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 6229A3A6B18 for ; Wed, 27 Aug 2008 04:34:51 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Aug 2008 12:34:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Aug 2008 12:34:52 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA1CA@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <001c01c90830$dc8f96e0$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt Thread-Index: AckH+/QV3Y45tt6jSHmIy28ziDldOAAHfAOAAACCC8AAAQ+VQAABwDwQAAIzkmAAAgYjcA== From: To: , X-OriginalArrivalTime: 27 Aug 2008 11:34:53.0310 (UTC) FILETIME=[EC5739E0:01C90838] Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 note that the Duffield et al definition below is different from what your talking about, since their definition includes traffic in both directions, whilst yours is a one way definition. I think other people, with a DiffServ architecture background, would interpret it as traffic from one ingress going to any egress. So that's 3 possibilities. In any case, this is really a side issue, compared with my main points /questions in earlier email. { -----Original Message----- { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] { Sent: 27 August 2008 11:37 { To: Eardley,PL,Philip,CXR9 R; slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt { { Hi Phil { { HOSE model is defined some 20 years ago, please see e.g the following { article: { { N. G. Duffield, P. Goyal and A. Greenberg, "A Flexible Model { for Resource Management in Virtual Private Networks", in: { Proc. of ACM SIGCOMM, 1999. { { In the above article I found the following definition: { { "A hose is characterized by the aggregate traffic { to and from one endpoint in the VPN to the set of other { endpoints in the VPN" { { Thus the definition refers to aggregated traffic to and from one edge to { and { from all other endpoints. { { { In our case we refer only to the aggregated traffic from other endpoints { to { one endpoint. { { Thus what we use is in line with the definition of the HOSE model. { { Best regards, { Georgios { { { { { > -----Original Message----- { > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 augustus 2008 11:31 { > To: karagian@cs.utwente.nl; slblake@petri-meat.com { > Cc: pcn@ietf.org { > Subject: RE: [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt { > { > I thought your emails with steve had revealed that your model { > was the exact opposite of the well known hose model? { > { > { > { -----Original Message----- { > { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] { > { Sent: 27 August 2008 09:41 { To: Eardley,PL,Philip,CXR9 R; { > slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: { > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt { > { { > { Hi Phil { > { { > { What I explained is the well know HOSE bandwidth management model. { > { During the IETF in Dublin, Hein also shown also some { > results { that were obtrained using the HOSE model. { > { { > { { > { Best regards, { > { Georgios { > { { > { { > { > -----Original Message----- { > { > From: philip.eardley@bt.com { > [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 augustus { > 2008 10:20 { > To: karagian@cs.utwente.nl; { > slblake@petri-meat.com { > Cc: pcn@ietf.org { > Subject: RE: { > [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt { > { > { > { > So the question is about adding to the draft: { > { > A model where the egress measures marks coming from all { > the { > ingresses, and makes admission decision based on that. { > { > { > { > Before adding anything about this to the draft, I'd like { > to { > understand if this is a genuine practical, understood { > option { > (if so, OK), or if it's a theoretical possibility { > or one not { > well understood. { > { > (there are many things in the latter category that aren't { > { > mentioned in the draft.) { > { > Questions are why this { > is interesting, why is it better than { > the models already { > well-known, are there comparative analysis { > /simulations? { > { > { > { > I suppose I've got 2 general issues: { > { > [1] every time something is added, overall the document { { > becomes harder to understand, more daunting to read & it { > > looks { less { like the WG has consensus. { > { > [2] this is an INFO doc. People are free to invent ways { > of { > using the standards pieces other than the architecture { > draft { > says, and indeed in ways not yet dreamt of. { > { > { > { > Phil. { > { > { > { > { -----Original Message----- { > { > { From: pcn-bounces@ietf.org { > [mailto:pcn-bounces@ietf.org] On { > Behalf Of { Georgios { > Karagiannis { Sent: 27 August 2008 08:54 { > { To: 'Steven Blake' { > { > { Cc: pcn@ietf.org { > { > { Subject: Re: [PCN] PCN WG last call for { > { > draft-ietf-pcn-architecture-05.txt { > { > { { > { > { Hi Steven { > { > { { > { > { > -----Original Message----- { > { > { > From: Steven Blake [mailto:slblake@petri-meat.com] { { > > { > Sent: woensdag 27 augustus 2008 6:18 { > To: Georgios { { > Karagiannis { > Cc: pcn@ietf.org { > Subject: RE: [PCN] PCN > { > WG { last { call for { > draft-ietf-pcn-architecture-05.txt { > { > { > { > { > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios Karagiannis wrote: { > { > { > { > { > { > > Hi Steven { > { > { > > { > { > { > > { > { > { > > Please see in line! { > { > { > > { > { > { > > { > { > { > > > -----Original Message----- { > { > { > > > From: Steven Blake { > [mailto:slblake@petri-meat.com] { { > > > > Sent: dinsdag 26 { > augustus 2008 14:46 { > > > To: { > { > Georgios Karagiannis { > > > Cc: pcn@ietf.org { > > > { > { > Subject: Re: [PCN] PCN WG last call for { > > > { > { > draft-ietf-pcn-architecture-05.txt { > { > { > > > { > { > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios Karagiannis { > wrote: { > { > { > > > { > { > { > > > > Hi Phil, Hi all { > { > { > > > > { > { > { > > > > Here are some comments on the PCN architecture draft: { > { > { > > > > { > { > { > > > > 1) Thank you for clarifying the bullet in { > Setion { > 3.2 about flow { > > > > termination. { > { > { > > > > { > { > { > > > > 2) From what I understand the PCN architecture { > { > draft { > > > mentions that PCN { > > > > supports only { > the { > trunk (ingress-egress-aggregate) and not the { > > > { > > HOSE model. { > { > { > > > > Is the PCN architecture draft excluding { > solutions { > that { > support the { > > > > HOSE model? If { > not, please { > emphasize in the PCN { > architecture draft { { > > > > that { > "solutions that are based on other types of > flow { > > { > { { > aggregation than { > > > > the { > ingress-egress-aggregate { > method of flow { > aggregation, { > are not { > > > > excluded { > from the PCN WG activities." { > { > { > > > { > { > { > > > Actually they are, by our charter. { > { > { > > { > { > { > > I have not seen that the PCN charter excludes other { > { > types { > of aggregation. { > { > { > { > { > { > Well, I checked, and you are correct (mea culpa). { > { > { Georgios: No problem { > { > { { > { > { > { > { > { > > Please note { > { > { > > that I am refering to the HOSE model where the { > traffic { > sent { > by one or { > > more than one ingresses { > towards one { > egress is aggregated at the { > > egress. In { > this way higgher { > traffic aggregation can be accomplished { > { > > than in the { > situation that the pipe/trunk { > { > (ingress-egress-aggregate) { > { > > is used, where the { > traffic sent by only one ingress in { > aggegated at { > > the egress. { > { > { > { > { > { > Typically the "hose" model refers to { > point-to-multipoint { > { > traffic flow, not multipoint-to-point. { > { > { Georgios: Typically yes, but in this case we refer to { { > bandwidth allocation { in a multipoint-to-point fashion. { > { > { { > { > { > { > { > { > { > { > { > Regards, { > { > { > { > { > { > // Steve { > { > { > { > { > { { > { > { { > { > { _______________________________________________ { > { > { 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 Aug 27 04:57:02 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE3AE28C0EA; Wed, 27 Aug 2008 04:57: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 DE5D828C0EA for ; Wed, 27 Aug 2008 04:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.436 X-Spam-Level: X-Spam-Status: No, score=0.436 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ha8aEfWLKoO for ; Wed, 27 Aug 2008 04:56: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 6C0D43A6884 for ; Wed, 27 Aug 2008 04:56: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 m7RBtvhF009713; Wed, 27 Aug 2008 13:56:01 +0200 (MEST) From: "Georgios Karagiannis" To: , References: <001c01c90830$dc8f96e0$810c5982@dynamic.ewi.utwente.nl> <4A916DBC72536E419A0BD955EDECEDEC03DAA1CA@E03MVB1-UKBR.domain1.systemhost.net> Date: Wed, 27 Aug 2008 13:55:52 +0200 Message-ID: <002101c9083b$de8d88c0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA1CA@E03MVB1-UKBR.domain1.systemhost.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AckH+/QV3Y45tt6jSHmIy28ziDldOAAHfAOAAACCC8AAAQ+VQAABwDwQAAIzkmAAAgYjcAAAgQIA 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, 27 Aug 2008 13:56:02 +0200 (MEST) Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 Assuming that ingresses can only send data traffic and egresses can receive data traffic, a HOSE model that is used in the PCN domain between ingress nodes and egress edge nodes, is refering to aggregates between ingress and egress edge nodes, where ingresses are sending traffic and egresses are receiving data traffic. Thus the HOSE aggregation model used in PCN is a HOSE aggregation model used between ingress and egress nodes. Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: woensdag 27 augustus 2008 13:35 > To: karagian@cs.utwente.nl; slblake@petri-meat.com > Cc: pcn@ietf.org > Subject: RE: [PCN] PCN WG last call for > draft-ietf-pcn-architecture-05.txt > > I note that the Duffield et al definition below is different > from what your talking about, since their definition includes > traffic in both directions, whilst yours is a one way > definition. I think other people, with a DiffServ > architecture background, would interpret it as traffic from > one ingress going to any egress. So that's 3 possibilities. > > In any case, this is really a side issue, compared with my > main points /questions in earlier email. > > { -----Original Message----- > { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > { Sent: 27 August 2008 11:37 { To: Eardley,PL,Philip,CXR9 R; > slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt > { > { Hi Phil > { > { HOSE model is defined some 20 years ago, please see e.g the > following { article: > { > { N. G. Duffield, P. Goyal and A. Greenberg, "A Flexible > Model { for Resource Management in Virtual Private Networks", in: > { Proc. of ACM SIGCOMM, 1999. > { > { In the above article I found the following definition: > { > { "A hose is characterized by the aggregate traffic { to and > from one endpoint in the VPN to the set of other { endpoints > in the VPN" > { > { Thus the definition refers to aggregated traffic to and > from one edge to { and { from all other endpoints. > { > { > { In our case we refer only to the aggregated traffic from > other endpoints { to { one endpoint. > { > { Thus what we use is in line with the definition of the HOSE model. > { > { Best regards, > { Georgios > { > { > { > { > { > -----Original Message----- > { > From: philip.eardley@bt.com > [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 augustus > 2008 11:31 { > To: karagian@cs.utwente.nl; > slblake@petri-meat.com { > Cc: pcn@ietf.org { > Subject: RE: > [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt > { > > { > I thought your emails with steve had revealed that your > model { > was the exact opposite of the well known hose model? > { > > { > > { > { -----Original Message----- > { > { From: Georgios Karagiannis > [mailto:karagian@cs.utwente.nl] { > { Sent: 27 August 2008 > 09:41 { To: Eardley,PL,Philip,CXR9 R; { > > slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: > { > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt > { > { > { > { Hi Phil > { > { > { > { What I explained is the well know HOSE bandwidth > management model. > { > { During the IETF in Dublin, Hein also shown also some { > > results { that were obtrained using the HOSE model. > { > { > { > { > { > { Best regards, > { > { Georgios > { > { > { > { > { > { > -----Original Message----- > { > { > From: philip.eardley@bt.com > { > [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 > augustus { > 2008 10:20 { > To: karagian@cs.utwente.nl; { > > slblake@petri-meat.com { > Cc: pcn@ietf.org { > Subject: RE: > { > [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt > { > { > > { > { > So the question is about adding to the draft: > { > { > A model where the egress measures marks coming from > all { > the { > ingresses, and makes admission decision based on that. > { > { > > { > { > Before adding anything about this to the draft, I'd > like { > to { > understand if this is a genuine practical, > understood { > option { > (if so, OK), or if it's a > theoretical possibility { > or one not { > well understood. > { > { > (there are many things in the latter category that > aren't { > { > mentioned in the draft.) { > { > Questions are > why this { > is interesting, why is it better than { > the > models already { > well-known, are there comparative analysis > { > /simulations? > { > { > > { > { > I suppose I've got 2 general issues: > { > { > [1] every time something is added, overall the > document { { > becomes harder to understand, more daunting to > read & it { > > looks { less { like the WG has consensus. > { > { > [2] this is an INFO doc. People are free to invent > ways { > of { > using the standards pieces other than the > architecture { > draft { > says, and indeed in ways not yet dreamt of. > { > { > > { > { > Phil. > { > { > > { > { > { -----Original Message----- > { > { > { From: pcn-bounces@ietf.org > { > [mailto:pcn-bounces@ietf.org] On { > Behalf Of { Georgios > { > Karagiannis { Sent: 27 August 2008 08:54 { > { To: 'Steven Blake' > { > { > { Cc: pcn@ietf.org > { > { > { Subject: Re: [PCN] PCN WG last call for { > { > > draft-ietf-pcn-architecture-05.txt > { > { > { > { > { > { Hi Steven > { > { > { > { > { > { > -----Original Message----- > { > { > { > From: Steven Blake > [mailto:slblake@petri-meat.com] { { > > { > Sent: woensdag 27 > augustus 2008 6:18 { > To: Georgios { { > Karagiannis { > Cc: > pcn@ietf.org { > Subject: RE: [PCN] PCN > { > WG { last { > call for { > draft-ietf-pcn-architecture-05.txt > { > { > { > > { > { > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios Karagiannis > wrote: > { > { > { > > { > { > { > > Hi Steven > { > { > { > > > { > { > { > > > { > { > { > > Please see in line! > { > { > { > > > { > { > { > > > { > { > { > > > -----Original Message----- { > { > { > > > > From: Steven Blake { > [mailto:slblake@petri-meat.com] { { > > > > > Sent: dinsdag 26 { > augustus 2008 14:46 { > > > To: > { > { > Georgios Karagiannis { > > > Cc: pcn@ietf.org { > > > > { > { > Subject: Re: [PCN] PCN WG last call for { > > > { > { > draft-ietf-pcn-architecture-05.txt > { > { > { > > > > { > { > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios > Karagiannis { > wrote: > { > { > { > > > > { > { > { > > > > Hi Phil, Hi all > { > { > { > > > > > { > { > { > > > > Here are some comments on the PCN > architecture draft: > { > { > { > > > > > { > { > { > > > > 1) Thank you for clarifying the bullet in { > Setion { > 3.2 about flow { > > > > termination. > { > { > { > > > > > { > { > { > > > > 2) From what I understand the PCN > architecture { > { > draft { > > > mentions that PCN { > > > > > supports only { > the { > trunk (ingress-egress-aggregate) > and not the { > > > { > > HOSE model. > { > { > { > > > > Is the PCN architecture draft excluding { > > solutions { > that { > support the { > > > > HOSE model? If { > not, please { > emphasize in the PCN { > architecture draft { > { > > > > that { > "solutions that are based on other types > of > flow { > > > > { > > { { > aggregation than { > > > > the > { > ingress-egress-aggregate { > method of flow { > > aggregation, { > are not { > > > > excluded { > from the PCN > WG activities." > { > { > { > > > > { > { > { > > > Actually they are, by our charter. > { > { > { > > > { > { > { > > I have not seen that the PCN charter excludes > other { > { > types { > of aggregation. > { > { > { > > { > { > { > Well, I checked, and you are correct (mea culpa). > { > { > { Georgios: No problem > { > { > { > { > { > { > > { > { > { > > Please note > { > { > { > > that I am refering to the HOSE model where the > { > traffic { > sent { > by one or { > > more than one > ingresses { > towards one { > egress is aggregated at the { > > > egress. In { > this way higgher { > traffic aggregation can > be accomplished { > { > > than in the { > situation that the > pipe/trunk { > { > (ingress-egress-aggregate) { > { > > is > used, where the { > traffic sent by only one ingress in { > > aggegated at { > > the egress. > { > { > { > > { > { > { > Typically the "hose" model refers to { > > point-to-multipoint { > { > traffic flow, not multipoint-to-point. > { > { > { Georgios: Typically yes, but in this case we refer > to { { > bandwidth allocation { in a multipoint-to-point fashion. > { > { > { > { > { > { > > { > { > { > > { > { > { > Regards, > { > { > { > > { > { > { > // Steve > { > { > { > > { > { > { > { > { > { > { > { > { _______________________________________________ > { > { > { 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 Aug 27 05:04:29 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83DE83A6884; Wed, 27 Aug 2008 05:04: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 F161A3A6826 for ; Wed, 27 Aug 2008 05:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.66 X-Spam-Level: X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[AWL=0.339, 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 tSJWhHr0wZTR for ; Wed, 27 Aug 2008 05:04:26 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 31A693A6884 for ; Wed, 27 Aug 2008 05:04:26 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Aug 2008 13:03:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Aug 2008 13:03:02 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA1CB@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <002101c9083b$de8d88c0$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt Thread-Index: AckH+/QV3Y45tt6jSHmIy28ziDldOAAHfAOAAACCC8AAAQ+VQAABwDwQAAIzkmAAAgYjcAAAgQIAAACUl0A= From: To: , X-OriginalArrivalTime: 27 Aug 2008 12:03:03.0673 (UTC) FILETIME=[DBE02690:01C9083C] Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 You appear to be saying all 3 definitions are the same. I think they're all different. Let's call the gateway nodes A, B, C, D ,E and F. Duffield: hose at A is all traffic to b,c,d,e,f and all traffic from b,c,d,e,f DiffServ: hose at A is all traffic to b,c,d,e,f Georgios: hose at A is all traffic from b,c,d,e,f { -----Original Message----- { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] { Sent: 27 August 2008 12:56 { To: Eardley,PL,Philip,CXR9 R; slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt { { Hi Phil { { Assuming that ingresses can only send data traffic and egresses can { receive { data traffic, { a HOSE model that is used in the PCN domain between ingress nodes and { egress { edge nodes, { is refering to aggregates between ingress and egress edge nodes, where { ingresses are { sending traffic and egresses are receiving data traffic. { { Thus the HOSE aggregation model used in PCN is a HOSE aggregation model { used between ingress and egress nodes. { { { Best regards, { Georgios { { > -----Original Message----- { > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 augustus 2008 13:35 { > To: karagian@cs.utwente.nl; slblake@petri-meat.com { > Cc: pcn@ietf.org { > Subject: RE: [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt { > { > I note that the Duffield et al definition below is different { > from what your talking about, since their definition includes { > traffic in both directions, whilst yours is a one way { > definition. I think other people, with a DiffServ { > architecture background, would interpret it as traffic from { > one ingress going to any egress. So that's 3 possibilities. { > { > In any case, this is really a side issue, compared with my { > main points /questions in earlier email. { > { > { -----Original Message----- { > { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] { > { Sent: 27 August 2008 11:37 { To: Eardley,PL,Philip,CXR9 R; { > slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: { > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt { > { { > { Hi Phil { > { { > { HOSE model is defined some 20 years ago, please see e.g the { > following { article: { > { { > { N. G. Duffield, P. Goyal and A. Greenberg, "A Flexible { > Model { for Resource Management in Virtual Private Networks", in: { > { Proc. of ACM SIGCOMM, 1999. { > { { > { In the above article I found the following definition: { > { { > { "A hose is characterized by the aggregate traffic { to and { > from one endpoint in the VPN to the set of other { endpoints { > in the VPN" { > { { > { Thus the definition refers to aggregated traffic to and { > from one edge to { and { from all other endpoints. { > { { > { { > { In our case we refer only to the aggregated traffic from { > other endpoints { to { one endpoint. { > { { > { Thus what we use is in line with the definition of the HOSE model. { > { { > { Best regards, { > { Georgios { > { { > { { > { { > { { > { > -----Original Message----- { > { > From: philip.eardley@bt.com { > [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 augustus { > 2008 11:31 { > To: karagian@cs.utwente.nl; { > slblake@petri-meat.com { > Cc: pcn@ietf.org { > Subject: RE: { > [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt { > { > { > { > I thought your emails with steve had revealed that your { > model { > was the exact opposite of the well known hose model? { > { > { > { > { > { > { -----Original Message----- { > { > { From: Georgios Karagiannis { > [mailto:karagian@cs.utwente.nl] { > { Sent: 27 August 2008 { > 09:41 { To: Eardley,PL,Philip,CXR9 R; { > { > slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: { > { > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt { > { > { { > { > { Hi Phil { > { > { { > { > { What I explained is the well know HOSE bandwidth { > management model. { > { > { During the IETF in Dublin, Hein also shown also some { { > > results { that were obtrained using the HOSE model. { > { > { { > { > { { > { > { Best regards, { > { > { Georgios { > { > { { > { > { { > { > { > -----Original Message----- { > { > { > From: philip.eardley@bt.com { > { > [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 { > augustus { > 2008 10:20 { > To: karagian@cs.utwente.nl; { > { > slblake@petri-meat.com { > Cc: pcn@ietf.org { > Subject: RE: { > { > [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt { > { > { > { > { > { > So the question is about adding to the draft: { > { > { > A model where the egress measures marks coming from { > all { > the { > ingresses, and makes admission decision based on that. { > { > { > { > { > { > Before adding anything about this to the draft, I'd { > like { > to { > understand if this is a genuine practical, { > understood { > option { > (if so, OK), or if it's a { > theoretical possibility { > or one not { > well understood. { > { > { > (there are many things in the latter category that { > aren't { > { > mentioned in the draft.) { > { > Questions are { > why this { > is interesting, why is it better than { > the { > models already { > well-known, are there comparative analysis { > { > /simulations? { > { > { > { > { > { > I suppose I've got 2 general issues: { > { > { > [1] every time something is added, overall the { > document { { > becomes harder to understand, more daunting to { > read & it { > > looks { less { like the WG has consensus. { > { > { > [2] this is an INFO doc. People are free to invent { > ways { > of { > using the standards pieces other than the { > architecture { > draft { > says, and indeed in ways not yet dreamt of. { > { > { > { > { > { > Phil. { > { > { > { > { > { > { -----Original Message----- { > { > { > { From: pcn-bounces@ietf.org { > { > [mailto:pcn-bounces@ietf.org] On { > Behalf Of { Georgios { > { > Karagiannis { Sent: 27 August 2008 08:54 { > { To: 'Steven Blake' { > { > { > { Cc: pcn@ietf.org { > { > { > { Subject: Re: [PCN] PCN WG last call for { > { > { > draft-ietf-pcn-architecture-05.txt { > { > { > { { > { > { > { Hi Steven { > { > { > { { > { > { > { > -----Original Message----- { > { > { > { > From: Steven Blake { > [mailto:slblake@petri-meat.com] { { > > { > Sent: woensdag 27 { > augustus 2008 6:18 { > To: Georgios { { > Karagiannis { > Cc: { > pcn@ietf.org { > Subject: RE: [PCN] PCN > { > WG { last { { > call for { > draft-ietf-pcn-architecture-05.txt { > { > { > { > { > { > { > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios Karagiannis { > wrote: { > { > { > { > { > { > { > { > > Hi Steven { > { > { > { > > { > { > { > { > > { > { > { > { > > Please see in line! { > { > { > { > > { > { > { > { > > { > { > { > { > > > -----Original Message----- { > { > { > > > { > From: Steven Blake { > [mailto:slblake@petri-meat.com] { { > { > > > > Sent: dinsdag 26 { > augustus 2008 14:46 { > > > To: { > { > { > Georgios Karagiannis { > > > Cc: pcn@ietf.org { > > > { > { > { > Subject: Re: [PCN] PCN WG last call for { > > > { > { { > draft-ietf-pcn-architecture-05.txt { > { > { > { > > > { > { > { > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios { > Karagiannis { > wrote: { > { > { > { > > > { > { > { > { > > > > Hi Phil, Hi all { > { > { > { > > > > { > { > { > { > > > > Here are some comments on the PCN { > architecture draft: { > { > { > { > > > > { > { > { > { > > > > 1) Thank you for clarifying the bullet in { { > Setion { > 3.2 about flow { > > > > termination. { > { > { > { > > > > { > { > { > { > > > > 2) From what I understand the PCN { > architecture { > { > draft { > > > mentions that PCN { > > > { > > supports only { > the { > trunk (ingress-egress-aggregate) { > and not the { > > > { > > HOSE model. { > { > { > { > > > > Is the PCN architecture draft excluding { > { > solutions { > that { > support the { > > > > HOSE model? If { { > not, please { > emphasize in the PCN { > architecture draft { > { > > > { > { that { > "solutions that are based on other types { > of > flow { { > > > { > { > { > { { > aggregation than { > > > > the { > { > ingress-egress-aggregate { > method of flow { > { > aggregation, { > are not { > > > > excluded { > from the PCN { > WG activities." { > { > { > { > > > { > { > { > { > > > Actually they are, by our charter. { > { > { > { > > { > { > { > { > > I have not seen that the PCN charter excludes { > other { > { > types { > of aggregation. { > { > { > { > { > { > { > { > Well, I checked, and you are correct (mea culpa). { > { > { > { Georgios: No problem { > { > { > { { > { > { > { > { > { > { > { > > Please note { > { > { > { > > that I am refering to the HOSE model where the { > { > traffic { > sent { > by one or { > > more than one { > ingresses { > towards one { > egress is aggregated at the { > { > > egress. In { > this way higgher { > traffic aggregation can { > be accomplished { > { > > than in the { > situation that the { > pipe/trunk { > { > (ingress-egress-aggregate) { > { > > is { > used, where the { > traffic sent by only one ingress in { > { > aggegated at { > > the egress. { > { > { > { > { > { > { > { > Typically the "hose" model refers to { > { > point-to-multipoint { > { > traffic flow, not multipoint-to-point. { > { > { > { Georgios: Typically yes, but in this case we refer { > to { { > bandwidth allocation { in a multipoint-to-point fashion. { > { > { > { { > { > { > { > { > { > { > { > { > { > { > { > Regards, { > { > { > { > { > { > { > { > // Steve { > { > { > { > { > { > { > { { > { > { > { { > { > { > { _______________________________________________ { > { > { > { 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 Aug 27 05:40:17 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ECFE28C235; Wed, 27 Aug 2008 05:40: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 7B6EE3A6A77 for ; Wed, 27 Aug 2008 05:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.412 X-Spam-Level: X-Spam-Status: No, score=0.412 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LUMG-VNI6VA for ; Wed, 27 Aug 2008 05:40: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 E6E253A699D for ; Wed, 27 Aug 2008 05:40:13 -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 m7RCdvZ1021171; Wed, 27 Aug 2008 14:40:01 +0200 (MEST) From: "Georgios Karagiannis" To: , References: <002101c9083b$de8d88c0$810c5982@dynamic.ewi.utwente.nl> <4A916DBC72536E419A0BD955EDECEDEC03DAA1CB@E03MVB1-UKBR.domain1.systemhost.net> Date: Wed, 27 Aug 2008 14:39:51 +0200 Message-ID: <002901c90842$03af3e90$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA1CB@E03MVB1-UKBR.domain1.systemhost.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AckH+/QV3Y45tt6jSHmIy28ziDldOAAHfAOAAACCC8AAAQ+VQAABwDwQAAIzkmAAAgYjcAAAgQIAAACUl0AAAPKMUA== 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, 27 Aug 2008 14:40:02 +0200 (MEST) Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 Your explanations are right, but regarding the explanation over Diffserv, please note that this is only one of the possible views. In a HOSE model two aggregated bandwidth specifications per node could be used: Incomning aggregated bandwdith: associated with the incoming traffic from all other nodes This is the HOSE model view that I was refereing to. Outgoing aggregated bandwdith: the amount of the aggregated traffic that the node can send towards all other nodes. This is the version that you were referring as Diffserv hose model. The Duffield Hose model specification uses both aggregated bandwidth specifications listed above. Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: woensdag 27 augustus 2008 14:03 > To: karagian@cs.utwente.nl; slblake@petri-meat.com > Cc: pcn@ietf.org > Subject: RE: [PCN] PCN WG last call for > draft-ietf-pcn-architecture-05.txt > > You appear to be saying all 3 definitions are the same. I > think they're all different. > > Let's call the gateway nodes A, B, C, D ,E and F. > > Duffield: hose at A is all traffic to b,c,d,e,f and all > traffic from b,c,d,e,f > > DiffServ: hose at A is all traffic to b,c,d,e,f > > Georgios: hose at A is all traffic from b,c,d,e,f > > { -----Original Message----- > { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > { Sent: 27 August 2008 12:56 { To: Eardley,PL,Philip,CXR9 R; > slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt > { > { Hi Phil > { > { Assuming that ingresses can only send data traffic and > egresses can { receive { data traffic, { a HOSE model that is > used in the PCN domain between ingress nodes and { egress { > edge nodes, { is refering to aggregates between ingress and > egress edge nodes, where { ingresses are { sending traffic > and egresses are receiving data traffic. > { > { Thus the HOSE aggregation model used in PCN is a HOSE > aggregation model { used between ingress and egress nodes. > { > { > { Best regards, > { Georgios > { > { > -----Original Message----- > { > From: philip.eardley@bt.com > [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 augustus > 2008 13:35 { > To: karagian@cs.utwente.nl; > slblake@petri-meat.com { > Cc: pcn@ietf.org { > Subject: RE: > [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt > { > > { > I note that the Duffield et al definition below is > different { > from what your talking about, since their > definition includes { > traffic in both directions, whilst > yours is a one way { > definition. I think other people, with > a DiffServ { > architecture background, would interpret it as > traffic from { > one ingress going to any egress. So that's 3 > possibilities. > { > > { > In any case, this is really a side issue, compared with > my { > main points /questions in earlier email. > { > > { > { -----Original Message----- > { > { From: Georgios Karagiannis > [mailto:karagian@cs.utwente.nl] { > { Sent: 27 August 2008 > 11:37 { To: Eardley,PL,Philip,CXR9 R; { > > slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: > { > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt > { > { > { > { Hi Phil > { > { > { > { HOSE model is defined some 20 years ago, please see e.g > the { > following { article: > { > { > { > { N. G. Duffield, P. Goyal and A. Greenberg, "A Flexible > { > Model { for Resource Management in Virtual Private Networks", in: > { > { Proc. of ACM SIGCOMM, 1999. > { > { > { > { In the above article I found the following definition: > { > { > { > { "A hose is characterized by the aggregate traffic { to > and { > from one endpoint in the VPN to the set of other { > endpoints { > in the VPN" > { > { > { > { Thus the definition refers to aggregated traffic to and > { > from one edge to { and { from all other endpoints. > { > { > { > { > { > { In our case we refer only to the aggregated traffic > from { > other endpoints { to { one endpoint. > { > { > { > { Thus what we use is in line with the definition of the > HOSE model. > { > { > { > { Best regards, > { > { Georgios > { > { > { > { > { > { > { > { > { > { > -----Original Message----- > { > { > From: philip.eardley@bt.com > { > [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 > augustus { > 2008 11:31 { > To: karagian@cs.utwente.nl; { > > slblake@petri-meat.com { > Cc: pcn@ietf.org { > Subject: RE: > { > [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt > { > { > > { > { > I thought your emails with steve had revealed that > your { > model { > was the exact opposite of the well known > hose model? > { > { > > { > { > > { > { > { -----Original Message----- > { > { > { From: Georgios Karagiannis > { > [mailto:karagian@cs.utwente.nl] { > { Sent: 27 August > 2008 { > 09:41 { To: Eardley,PL,Philip,CXR9 R; { > { > > slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: > { > { > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt > { > { > { > { > { > { Hi Phil > { > { > { > { > { > { What I explained is the well know HOSE bandwidth { > > management model. > { > { > { During the IETF in Dublin, Hein also shown also > some { { > > results { that were obtrained using the HOSE model. > { > { > { > { > { > { > { > { > { Best regards, > { > { > { Georgios > { > { > { > { > { > { > { > { > { > -----Original Message----- > { > { > { > From: philip.eardley@bt.com > { > { > [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 > { > augustus { > 2008 10:20 { > To: karagian@cs.utwente.nl; { > { > slblake@petri-meat.com { > Cc: pcn@ietf.org { > Subject: > RE: > { > { > [PCN] PCN WG last call for { > > draft-ietf-pcn-architecture-05.txt > { > { > { > > { > { > { > So the question is about adding to the draft: > { > { > { > A model where the egress measures marks coming > from { > all { > the { > ingresses, and makes admission > decision based on that. > { > { > { > > { > { > { > Before adding anything about this to the draft, > I'd { > like { > to { > understand if this is a genuine > practical, { > understood { > option { > (if so, OK), or if > it's a { > theoretical possibility { > or one not { > well understood. > { > { > { > (there are many things in the latter category > that { > aren't { > { > mentioned in the draft.) { > { > > Questions are { > why this { > is interesting, why is it > better than { > the { > models already { > well-known, are > there comparative analysis { > { > /simulations? > { > { > { > > { > { > { > I suppose I've got 2 general issues: > { > { > { > [1] every time something is added, overall the { > > document { { > becomes harder to understand, more daunting > to { > read & it { > > looks { less { like the WG has consensus. > { > { > { > [2] this is an INFO doc. People are free to > invent { > ways { > of { > using the standards pieces other > than the { > architecture { > draft { > says, and indeed in > ways not yet dreamt of. > { > { > { > > { > { > { > Phil. > { > { > { > > { > { > { > { -----Original Message----- { > { > { > { From: > pcn-bounces@ietf.org { > { > [mailto:pcn-bounces@ietf.org] On > { > Behalf Of { Georgios { > { > Karagiannis { Sent: 27 > August 2008 08:54 { > { To: 'Steven Blake' > { > { > { > { Cc: pcn@ietf.org > { > { > { > { Subject: Re: [PCN] PCN WG last call for { > { > > { > draft-ietf-pcn-architecture-05.txt > { > { > { > { > { > { > { > { Hi Steven > { > { > { > { > { > { > { > { > -----Original Message----- { > { > { > { > > From: Steven Blake { > [mailto:slblake@petri-meat.com] { { > > > { > Sent: woensdag 27 { > augustus 2008 6:18 { > To: > Georgios { { > Karagiannis { > Cc: > { > pcn@ietf.org { > Subject: RE: [PCN] PCN > { > WG { last { > { > call for { > draft-ietf-pcn-architecture-05.txt > { > { > { > { > > { > { > { > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios > Karagiannis { > wrote: > { > { > { > { > > { > { > { > { > > Hi Steven > { > { > { > { > > > { > { > { > { > > > { > { > { > { > > Please see in line! > { > { > { > { > > > { > { > { > { > > > { > { > { > { > > > -----Original Message----- { > { > { > > > > { > From: Steven Blake { > [mailto:slblake@petri-meat.com] > { { > { > > > > Sent: dinsdag 26 { > augustus 2008 14:46 { > > > To: > { > { > { > Georgios Karagiannis { > > > Cc: pcn@ietf.org { > > > > { > { > { > Subject: Re: [PCN] PCN WG last call for { > > > > { > { { > draft-ietf-pcn-architecture-05.txt > { > { > { > { > > > > { > { > { > { > > > On Tue, 2008-08-26 at 11:44 +0000, > Georgios { > Karagiannis { > wrote: > { > { > { > { > > > > { > { > { > { > > > > Hi Phil, Hi all > { > { > { > { > > > > > { > { > { > { > > > > Here are some comments on the PCN { > > architecture draft: > { > { > { > { > > > > > { > { > { > { > > > > 1) Thank you for clarifying the bullet > in { { > Setion { > 3.2 about flow { > > > > termination. > { > { > { > { > > > > > { > { > { > { > > > > 2) From what I understand the PCN { > > architecture { > { > draft { > > > mentions that PCN { > > > > { > > supports only { > the { > trunk > (ingress-egress-aggregate) { > and not the { > > > { > > HOSE model. > { > { > { > { > > > > Is the PCN architecture draft excluding > { > { > solutions { > that { > support the { > > > > HOSE > model? If { { > not, please { > emphasize in the PCN { > > architecture draft { > { > > > > > { > > { that { > "solutions that are based on other types { > of > > flow { { > > > { > { > { > { { > aggregation than { > > > > > the { > { > ingress-egress-aggregate { > method of flow { > { > aggregation, { > are not { > > > > excluded { > from the PCN > { > WG activities." > { > { > { > { > > > > { > { > { > { > > > Actually they are, by our charter. > { > { > { > { > > > { > { > { > { > > I have not seen that the PCN charter > excludes { > other { > { > types { > of aggregation. > { > { > { > { > > { > { > { > { > Well, I checked, and you are correct (mea culpa). > { > { > { > { Georgios: No problem > { > { > { > { > { > { > { > { > > { > { > { > { > > Please note > { > { > { > { > > that I am refering to the HOSE model where > the { > { > traffic { > sent { > by one or { > > more than > one { > ingresses { > towards one { > egress is aggregated at > the { > { > > egress. In { > this way higgher { > traffic > aggregation can { > be accomplished { > { > > than in the { > > situation that the { > pipe/trunk { > { > > (ingress-egress-aggregate) { > { > > is { > used, where the { > traffic sent by only one ingress in { > { > aggegated at { > > > the egress. > { > { > { > { > > { > { > { > { > Typically the "hose" model refers to { > { > > point-to-multipoint { > { > traffic flow, not multipoint-to-point. > { > { > { > { Georgios: Typically yes, but in this case we > refer { > to { { > bandwidth allocation { in a > multipoint-to-point fashion. > { > { > { > { > { > { > { > { > > { > { > { > { > > { > { > { > { > Regards, > { > { > { > { > > { > { > { > { > // Steve > { > { > { > { > > { > { > { > { > { > { > { > { > { > { > { > { _______________________________________________ > { > { > { > { 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 Aug 27 05:48:54 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 325F73A680C; Wed, 27 Aug 2008 05:48: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 BD5E93A67A6 for ; Wed, 27 Aug 2008 05:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.694 X-Spam-Level: X-Spam-Status: No, score=-2.694 tagged_above=-999 required=5 tests=[AWL=0.305, 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 DgTC4gWg9Lw0 for ; Wed, 27 Aug 2008 05:48: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 2EF7E3A680C for ; Wed, 27 Aug 2008 05:48:51 -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, 27 Aug 2008 13:48:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Aug 2008 13:48:49 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA1CD@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <002901c90842$03af3e90$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt Thread-Index: AckH+/QV3Y45tt6jSHmIy28ziDldOAAHfAOAAACCC8AAAQ+VQAABwDwQAAIzkmAAAgYjcAAAgQIAAACUl0AAAPKMUAAAp0dg From: To: , X-OriginalArrivalTime: 27 Aug 2008 12:48:50.0427 (UTC) FILETIME=[41118CB0:01C90843] Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 2475: 2. Differentiated Services Architectural Model The differentiated services architecture is based on a simple model where traffic entering a network is classified and possibly conditioned at the boundaries of the network, and assigned to different behavior aggregates. Note "entering". Anyway, this sub-thread has gone on too long already. We're arguing about irrelevant detail. Looking forward to answers on the earlier points raised. Best wishes Phil. { -----Original Message----- { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] { Sent: 27 August 2008 13:40 { To: Eardley,PL,Philip,CXR9 R; slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt { { Hi Phil { { Your explanations are right, but regarding the explanation over { Diffserv, please note that this is only one of the possible views. { { In a HOSE model two aggregated bandwidth specifications per node could be { used: { { Incomning aggregated bandwdith: associated with the incoming traffic from { all other nodes { This is the HOSE model view that I was refereing to. { { Outgoing aggregated bandwdith: the amount of the aggregated traffic that { the { node can send towards all other nodes. { This is the version that you were referring as Diffserv hose model. { { The Duffield Hose model specification uses both aggregated bandwidth { specifications listed above. { { { { Best regards, { Georgios { { { { > -----Original Message----- { > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 augustus 2008 14:03 { > To: karagian@cs.utwente.nl; slblake@petri-meat.com { > Cc: pcn@ietf.org { > Subject: RE: [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt { > { > You appear to be saying all 3 definitions are the same. I { > think they're all different. { > { > Let's call the gateway nodes A, B, C, D ,E and F. { > { > Duffield: hose at A is all traffic to b,c,d,e,f and all { > traffic from b,c,d,e,f { > { > DiffServ: hose at A is all traffic to b,c,d,e,f { > { > Georgios: hose at A is all traffic from b,c,d,e,f { > { > { -----Original Message----- { > { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] { > { Sent: 27 August 2008 12:56 { To: Eardley,PL,Philip,CXR9 R; { > slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: { > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt { > { { > { Hi Phil { > { { > { Assuming that ingresses can only send data traffic and { > egresses can { receive { data traffic, { a HOSE model that is { > used in the PCN domain between ingress nodes and { egress { { > edge nodes, { is refering to aggregates between ingress and { > egress edge nodes, where { ingresses are { sending traffic { > and egresses are receiving data traffic. { > { { > { Thus the HOSE aggregation model used in PCN is a HOSE { > aggregation model { used between ingress and egress nodes. { > { { > { { > { Best regards, { > { Georgios { > { { > { > -----Original Message----- { > { > From: philip.eardley@bt.com { > [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 augustus { > 2008 13:35 { > To: karagian@cs.utwente.nl; { > slblake@petri-meat.com { > Cc: pcn@ietf.org { > Subject: RE: { > [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt { > { > { > { > I note that the Duffield et al definition below is { > different { > from what your talking about, since their { > definition includes { > traffic in both directions, whilst { > yours is a one way { > definition. I think other people, with { > a DiffServ { > architecture background, would interpret it as { > traffic from { > one ingress going to any egress. So that's 3 { > possibilities. { > { > { > { > In any case, this is really a side issue, compared with { > my { > main points /questions in earlier email. { > { > { > { > { -----Original Message----- { > { > { From: Georgios Karagiannis { > [mailto:karagian@cs.utwente.nl] { > { Sent: 27 August 2008 { > 11:37 { To: Eardley,PL,Philip,CXR9 R; { > { > slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: { > { > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt { > { > { { > { > { Hi Phil { > { > { { > { > { HOSE model is defined some 20 years ago, please see e.g { > the { > following { article: { > { > { { > { > { N. G. Duffield, P. Goyal and A. Greenberg, "A Flexible { > { > Model { for Resource Management in Virtual Private Networks", in: { > { > { Proc. of ACM SIGCOMM, 1999. { > { > { { > { > { In the above article I found the following definition: { > { > { { > { > { "A hose is characterized by the aggregate traffic { to { > and { > from one endpoint in the VPN to the set of other { { > endpoints { > in the VPN" { > { > { { > { > { Thus the definition refers to aggregated traffic to and { > { > from one edge to { and { from all other endpoints. { > { > { { > { > { { > { > { In our case we refer only to the aggregated traffic { > from { > other endpoints { to { one endpoint. { > { > { { > { > { Thus what we use is in line with the definition of the { > HOSE model. { > { > { { > { > { Best regards, { > { > { Georgios { > { > { { > { > { { > { > { { > { > { { > { > { > -----Original Message----- { > { > { > From: philip.eardley@bt.com { > { > [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 { > augustus { > 2008 11:31 { > To: karagian@cs.utwente.nl; { > { > slblake@petri-meat.com { > Cc: pcn@ietf.org { > Subject: RE: { > { > [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt { > { > { > { > { > { > I thought your emails with steve had revealed that { > your { > model { > was the exact opposite of the well known { > hose model? { > { > { > { > { > { > { > { > { > { -----Original Message----- { > { > { > { From: Georgios Karagiannis { > { > [mailto:karagian@cs.utwente.nl] { > { Sent: 27 August { > 2008 { > 09:41 { To: Eardley,PL,Philip,CXR9 R; { > { > { > slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: { > { > { > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt { > { > { > { { > { > { > { Hi Phil { > { > { > { { > { > { > { What I explained is the well know HOSE bandwidth { { > > management model. { > { > { > { During the IETF in Dublin, Hein also shown also { > some { { > > results { that were obtrained using the HOSE model. { > { > { > { { > { > { > { { > { > { > { Best regards, { > { > { > { Georgios { > { > { > { { > { > { > { { > { > { > { > -----Original Message----- { > { > { > { > From: philip.eardley@bt.com { > { > { > [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 { > { > augustus { > 2008 10:20 { > To: karagian@cs.utwente.nl; { { > { > slblake@petri-meat.com { > Cc: pcn@ietf.org { > Subject: > RE: { > { > { > [PCN] PCN WG last call for { > { > draft-ietf-pcn-architecture-05.txt { > { > { > { > { > { > { > { > So the question is about adding to the draft: { > { > { > { > A model where the egress measures marks coming { > from { > all { > the { > ingresses, and makes admission { > decision based on that. { > { > { > { > { > { > { > { > Before adding anything about this to the draft, { > I'd { > like { > to { > understand if this is a genuine { > practical, { > understood { > option { > (if so, OK), or if { > it's a { > theoretical possibility { > or one not { > well understood. { > { > { > { > (there are many things in the latter category { > that { > aren't { > { > mentioned in the draft.) { > { > { > Questions are { > why this { > is interesting, why is it { > better than { > the { > models already { > well-known, are { > there comparative analysis { > { > /simulations? { > { > { > { > { > { > { > { > I suppose I've got 2 general issues: { > { > { > { > [1] every time something is added, overall the { { > > document { { > becomes harder to understand, more daunting { > to { > read & it { > > looks { less { like the WG has consensus. { > { > { > { > [2] this is an INFO doc. People are free to { > invent { > ways { > of { > using the standards pieces other { > than the { > architecture { > draft { > says, and indeed in { > ways not yet dreamt of. { > { > { > { > { > { > { > { > Phil. { > { > { > { > { > { > { > { > { -----Original Message----- { > { > { > { From: { > pcn-bounces@ietf.org { > { > [mailto:pcn-bounces@ietf.org] On { > { > Behalf Of { Georgios { > { > Karagiannis { Sent: 27 { > August 2008 08:54 { > { To: 'Steven Blake' { > { > { > { > { Cc: pcn@ietf.org { > { > { > { > { Subject: Re: [PCN] PCN WG last call for { > { > { > { > draft-ietf-pcn-architecture-05.txt { > { > { > { > { { > { > { > { > { Hi Steven { > { > { > { > { { > { > { > { > { > -----Original Message----- { > { > { > { > { > From: Steven Blake { > [mailto:slblake@petri-meat.com] { { > { > > { > Sent: woensdag 27 { > augustus 2008 6:18 { > To: { > Georgios { { > Karagiannis { > Cc: { > { > pcn@ietf.org { > Subject: RE: [PCN] PCN > { > WG { last { { > { > call for { > draft-ietf-pcn-architecture-05.txt { > { > { > { > { > { > { > { > { > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios { > Karagiannis { > wrote: { > { > { > { > { > { > { > { > { > { > > Hi Steven { > { > { > { > { > > { > { > { > { > { > > { > { > { > { > { > > Please see in line! { > { > { > { > { > > { > { > { > { > { > > { > { > { > { > { > > > -----Original Message----- { > { > { > > { > > { > From: Steven Blake { > [mailto:slblake@petri-meat.com] { > { { > { > > > > Sent: dinsdag 26 { > augustus 2008 14:46 { > > > To: { > { > { > { > Georgios Karagiannis { > > > Cc: pcn@ietf.org { > { > > > { > { > { > Subject: Re: [PCN] PCN WG last call for { > > { > > { > { { > draft-ietf-pcn-architecture-05.txt { > { > { > { > { > > > { > { > { > { > { > > > On Tue, 2008-08-26 at 11:44 +0000, { > Georgios { > Karagiannis { > wrote: { > { > { > { > { > > > { > { > { > { > { > > > > Hi Phil, Hi all { > { > { > { > { > > > > { > { > { > { > { > > > > Here are some comments on the PCN { > { > architecture draft: { > { > { > { > { > > > > { > { > { > { > { > > > > 1) Thank you for clarifying the bullet { > in { { > Setion { > 3.2 about flow { > > > > termination. { > { > { > { > { > > > > { > { > { > { > { > > > > 2) From what I understand the PCN { > { > architecture { > { > draft { > > > mentions that PCN { > > > { > { > > supports only { > the { > trunk { > (ingress-egress-aggregate) { > and not the { > > > { > > HOSE model. { > { > { > { > { > > > > Is the PCN architecture draft excluding { > { > { > solutions { > that { > support the { > > > > HOSE { > model? If { { > not, please { > emphasize in the PCN { > { > architecture draft { > { > { > > > { > { > { > { that { > "solutions that are based on other types { > of > { > flow { { > > > { > { > { > { { > aggregation than { > > > > { > the { > { > ingress-egress-aggregate { > method of flow { > { { > aggregation, { > are not { > > > > excluded { > from the PCN > { > WG { activities." { > { > { > { > { > > > { > { > { > { > { > > > Actually they are, by our charter. { > { > { > { > { > > { > { > { > { > { > > I have not seen that the PCN charter { > excludes { > other { > { > types { > of aggregation. { > { > { > { > { > { > { > { > { > { > Well, I checked, and you are correct (mea culpa). { > { > { > { > { Georgios: No problem { > { > { > { > { { > { > { > { > { > { > { > { > { > { > > Please note { > { > { > { > { > > that I am refering to the HOSE model where { > the { > { > traffic { > sent { > by one or { > > more than { > one { > ingresses { > towards one { > egress is aggregated at { > the { > { > > egress. In { > this way higgher { > traffic { > aggregation can { > be accomplished { > { > > than in the { > { > situation that the { > pipe/trunk { > { > { > (ingress-egress-aggregate) { > { > > is { > used, where the { { > traffic sent by only one ingress in { > { > aggegated at { > > > the { egress. { > { > { > { > { > { > { > { > { > { > Typically the "hose" model refers to { > { > { > point-to-multipoint { > { > traffic flow, not multipoint-to-point. { > { > { > { > { Georgios: Typically yes, but in this case we { > refer { > to { { > bandwidth allocation { in a { > multipoint-to-point fashion. { > { > { > { > { { > { > { > { > { > { > { > { > { > { > { > { > { > { > { > Regards, { > { > { > { > { > { > { > { > { > { > // Steve { > { > { > { > { > { > { > { > { > { { > { > { > { > { { > { > { > { > { _______________________________________________ { > { > { > { > { 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 Aug 27 06:15:33 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 939BB3A693A; Wed, 27 Aug 2008 06:15: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 65F5D3A693A for ; Wed, 27 Aug 2008 06:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.091 X-Spam-Level: X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[AWL=0.595, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ds+OaqQ+xOOv for ; Wed, 27 Aug 2008 06:15:28 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 288C73A68EF for ; Wed, 27 Aug 2008 06:15:28 -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 m7RDFNhD000822; Wed, 27 Aug 2008 15:15:28 +0200 (MEST) From: "Georgios Karagiannis" To: , References: <000201c9081a$220dc730$810c5982@dynamic.ewi.utwente.nl> <4A916DBC72536E419A0BD955EDECEDEC03DAA1C5@E03MVB1-UKBR.domain1.systemhost.net> Date: Wed, 27 Aug 2008 15:15:18 +0200 Message-ID: <002b01c90846$f77b84d0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA1C5@E03MVB1-UKBR.domain1.systemhost.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AckH+/QV3Y45tt6jSHmIy28ziDldOAAHfAOAAACCC8AACiaIMA== 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, 27 Aug 2008 15:15:28 +0200 (MEST) Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 What I was trying to say in the previous emails is that the definition of the HOSE aggregation model covers a wide area, and its interpretation varies depending on the context that it is used. The answers to your questions can be found below: > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: woensdag 27 augustus 2008 10:20 > To: karagian@cs.utwente.nl; slblake@petri-meat.com > Cc: pcn@ietf.org > Subject: RE: [PCN] PCN WG last call for > draft-ietf-pcn-architecture-05.txt > > So the question is about adding to the draft: > A model where the egress measures marks coming from all the > ingresses, and makes admission decision based on that. > > Before adding anything about this to the draft, I'd like to > understand if this is a genuine practical, understood option > (if so, OK), or if it's a theoretical possibility or one not > well understood. > (there are many things in the latter category that aren't > mentioned in the draft.) > > Questions are why this is interesting, why is it better than > the models already well-known, are there comparative analysis > /simulations? Georgios: It is interesting because is more scalable than the ingress-egress-aggregation model and because the level of flow aggregation (and thus the level of statistical aggregation) that can be achieved is higher than in the IEA case. > > I suppose I've got 2 general issues: > [1] every time something is added, overall the document > becomes harder to understand, more daunting to read & it > looks less like the WG has consensus. Georgios: I think that the sentence proposed by you, see below (with an addition from my side) is clear enough: "An aggregation model where the egress measures marks coming from all the ingresses, and makes admission decision based on that." > [2] this is an INFO doc. People are free to invent ways of > using the standards pieces other than the architecture draft > says, and indeed in ways not yet dreamt of. Georgios: I am not sure if this is always true, that is why I would like to see somethink like the sentence given above. Best regards, Georgios > > Phil. > > { -----Original Message----- > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of { Georgios Karagiannis { Sent: 27 August 2008 08:54 > { To: 'Steven Blake' > { Cc: pcn@ietf.org > { Subject: Re: [PCN] PCN WG last call for > draft-ietf-pcn-architecture-05.txt > { > { Hi Steven > { > { > -----Original Message----- > { > From: Steven Blake [mailto:slblake@petri-meat.com] { > > Sent: woensdag 27 augustus 2008 6:18 { > To: Georgios > Karagiannis { > Cc: pcn@ietf.org { > Subject: RE: [PCN] PCN > WG last call for { > draft-ietf-pcn-architecture-05.txt > { > > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios Karagiannis wrote: > { > > { > > Hi Steven > { > > > { > > > { > > Please see in line! > { > > > { > > > { > > > -----Original Message----- > { > > > From: Steven Blake [mailto:slblake@petri-meat.com] { > > > > Sent: dinsdag 26 augustus 2008 14:46 { > > > To: > Georgios Karagiannis { > > > Cc: pcn@ietf.org { > > > > Subject: Re: [PCN] PCN WG last call for { > > > > draft-ietf-pcn-architecture-05.txt > { > > > > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios Karagiannis wrote: > { > > > > { > > > > Hi Phil, Hi all > { > > > > > { > > > > Here are some comments on the PCN architecture draft: > { > > > > > { > > > > 1) Thank you for clarifying the bullet in Setion > 3.2 about flow { > > > > termination. > { > > > > > { > > > > 2) From what I understand the PCN architecture > draft { > > > mentions that PCN { > > > > supports only the > trunk (ingress-egress-aggregate) and not the { > > > > HOSE model. > { > > > > Is the PCN architecture draft excluding solutions > that { > support the { > > > > HOSE model? If not, please > emphasize in the PCN { > architecture draft { > > > > that > "solutions that are based on other types of flow { > > > > aggregation than { > > > > the ingress-egress-aggregate > method of flow { > aggregation, are not { > > > > excluded > from the PCN WG activities." > { > > > > { > > > Actually they are, by our charter. > { > > > { > > I have not seen that the PCN charter excludes other > types { > of aggregation. > { > > { > Well, I checked, and you are correct (mea culpa). > { Georgios: No problem > { > { > > { > > Please note > { > > that I am refering to the HOSE model where the traffic > sent { > by one or { > > more than one ingresses towards one > egress is aggregated at the { > > egress. In this way higgher > traffic aggregation can be accomplished { > > than in the > situation that the pipe/trunk { > (ingress-egress-aggregate) > { > > is used, where the traffic sent by only one ingress in > aggegated at { > > the egress. > { > > { > Typically the "hose" model refers to point-to-multipoint > { > traffic flow, not multipoint-to-point. > { Georgios: Typically yes, but in this case we refer to > bandwidth allocation { in a multipoint-to-point fashion. > { > { > > { > > { > Regards, > { > > { > // Steve > { > > { > { > { _______________________________________________ > { 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 Aug 27 08:32:43 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA91728B56A; Wed, 27 Aug 2008 08:32:43 -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 BECAC3A6C7E for ; Wed, 27 Aug 2008 08:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.022 X-Spam-Level: X-Spam-Status: No, score=-3.022 tagged_above=-999 required=5 tests=[AWL=0.577, 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 0nSVGonZVaYQ for ; Wed, 27 Aug 2008 08:32:37 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 99A503A6B3D for ; Wed, 27 Aug 2008 08:32:36 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Aug 2008 16:32:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Aug 2008 16:32:30 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA1D0@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <002b01c90846$f77b84d0$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt Thread-Index: AckH+/QV3Y45tt6jSHmIy28ziDldOAAHfAOAAACCC8AACiaIMAAEvatw From: To: , X-OriginalArrivalTime: 27 Aug 2008 15:32:31.0301 (UTC) FILETIME=[1EC3FF50:01C9085A] Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 the question is about adding to the draft: { > A model where the egress measures marks coming from all the { > ingresses, and makes admission decision based on that. { > { > Before adding anything about this to the draft, I'd like to { > understand if this is a genuine practical, understood option { > (if so, OK), or if it's a theoretical possibility or one not { > well understood. { > (there are many things in the latter category that aren't { > mentioned in the draft.) { > { > Questions are why this is interesting, why is it better than { > the models already well-known, are there comparative analysis { > /simulations? { { Georgios: It is interesting because is more scalable than the { ingress-egress-aggregation model and { because the level of flow aggregation (and thus the level of statistical { aggregation) { that can be achieved is higher than in the IEA case. I don't really believe either of these claims. On scalability, what's the scenario? Eg imagine a core network with 100 or so gateway pcn-nodes. Whether an egress node is recording marking info per ingress node (100 pieces of info) or recording it whatever the ingress (1 piece of info) - is this really a significant scaling difference? Especially when you remember that the PCN-ingress-nodes keep per flow state for policing purposes. On aggregation, I actually think the opposite is true. In your case, you can get a focused overload: many flows happen to focus on a particular link and then all flows through the congested link fail catastrophically. With PCN (ie ingress-egress-aggregates) the finer grained info should prevent this happening. So your scheme has to be more cautious about how much traffic it admits (eg by setting the PCN-threshold-rate lower). { { { > { > I suppose I've got 2 general issues: { > [1] every time something is added, overall the document { > becomes harder to understand, more daunting to read & it { > looks less like the WG has consensus. { { Georgios: I think that the sentence proposed by you, it most certainly wasn't proposed by me see below (with an { addition from my side) { is clear enough: { "An aggregation model where the egress measures marks coming from all the { ingresses, and makes admission decision based on that." my point was different. It wasn't about the clarity or not of the sentence. { { { > [2] this is an INFO doc. People are free to invent ways of { > using the standards pieces other than the architecture draft { > says, and indeed in ways not yet dreamt of. { { Georgios: I am not sure if this is always true, that is why I would { like to see somethink like the sentence given above. What I wrote seems true. Indeed, in general if subsequent experience shows that Info docs haven't captured important ways in which Stds docs are being used in practice, then docs get revised. { { Best regards, { Georgios { { { > { > Phil. { > { > { -----Original Message----- { > { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On { > Behalf Of { Georgios Karagiannis { Sent: 27 August 2008 08:54 { > { To: 'Steven Blake' { > { Cc: pcn@ietf.org { > { Subject: Re: [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt { > { { > { Hi Steven { > { { > { > -----Original Message----- { > { > From: Steven Blake [mailto:slblake@petri-meat.com] { > { > Sent: woensdag 27 augustus 2008 6:18 { > To: Georgios { > Karagiannis { > Cc: pcn@ietf.org { > Subject: RE: [PCN] PCN { > WG last call for { > draft-ietf-pcn-architecture-05.txt { > { > { > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios Karagiannis wrote: { > { > { > { > > Hi Steven { > { > > { > { > > { > { > > Please see in line! { > { > > { > { > > { > { > > > -----Original Message----- { > { > > > From: Steven Blake [mailto:slblake@petri-meat.com] { { > > > > Sent: dinsdag 26 augustus 2008 14:46 { > > > To: { > Georgios Karagiannis { > > > Cc: pcn@ietf.org { > > > { > Subject: Re: [PCN] PCN WG last call for { > > > { > draft-ietf-pcn-architecture-05.txt { > { > > > { > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios Karagiannis wrote: { > { > > > { > { > > > > Hi Phil, Hi all { > { > > > > { > { > > > > Here are some comments on the PCN architecture draft: { > { > > > > { > { > > > > 1) Thank you for clarifying the bullet in Setion { > 3.2 about flow { > > > > termination. { > { > > > > { > { > > > > 2) From what I understand the PCN architecture { > draft { > > > mentions that PCN { > > > > supports only the { > trunk (ingress-egress-aggregate) and not the { > > > > HOSE model. { > { > > > > Is the PCN architecture draft excluding solutions { > that { > support the { > > > > HOSE model? If not, please { > emphasize in the PCN { > architecture draft { > > > > that { > "solutions that are based on other types of flow { > > > { > aggregation than { > > > > the ingress-egress-aggregate { > method of flow { > aggregation, are not { > > > > excluded { > from the PCN WG activities." { > { > > > { > { > > > Actually they are, by our charter. { > { > > { > { > > I have not seen that the PCN charter excludes other { > types { > of aggregation. { > { > { > { > Well, I checked, and you are correct (mea culpa). { > { Georgios: No problem { > { { > { > { > { > > Please note { > { > > that I am refering to the HOSE model where the traffic { > sent { > by one or { > > more than one ingresses towards one { > egress is aggregated at the { > > egress. In this way higgher { > traffic aggregation can be accomplished { > > than in the { > situation that the pipe/trunk { > (ingress-egress-aggregate) { > { > > is used, where the traffic sent by only one ingress in { > aggegated at { > > the egress. { > { > { > { > Typically the "hose" model refers to point-to-multipoint { > { > traffic flow, not multipoint-to-point. { > { Georgios: Typically yes, but in this case we refer to { > bandwidth allocation { in a multipoint-to-point fashion. { > { { > { > { > { > { > { > Regards, { > { > { > { > // Steve { > { > { > { { > { { > { _______________________________________________ { > { 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 Aug 27 09:00:48 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5983E3A68F4; Wed, 27 Aug 2008 09:00: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 3DA1C3A681F for ; Wed, 27 Aug 2008 09:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaouy9Z3C8Vy for ; Wed, 27 Aug 2008 09:00:35 -0700 (PDT) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id C7A8C3A68F4 for ; Wed, 27 Aug 2008 09:00:34 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.ad2.ad.alcatel.com [155.132.6.76]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m7RFxdHF023197; Wed, 27 Aug 2008 17:59:39 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.54]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 27 Aug 2008 17:59:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Aug 2008 17:59:38 +0200 Message-ID: <713A7C5347A4344A8671770DFE2B2EA7017CCC1C@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA1C4@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Request for clarification of Other and priority traffic - seedraft-eardley-pcn-marking-behaviour-01 Thread-Index: AckHVfNfByaoB9vRTiaa/aj4wzcElgAxGMVwAA/2iEA= References: <713A7C5347A4344A8671770DFE2B2EA7017CC2CE@FRVELSMBS22.ad2.ad.alcatel.com> <4A916DBC72536E419A0BD955EDECEDEC03DAA1C4@E03MVB1-UKBR.domain1.systemhost.net> From: "HUBLET Christian" To: , X-OriginalArrivalTime: 27 Aug 2008 15:59:39.0104 (UTC) FILETIME=[E9030600:01C9085D] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [PCN] Request for clarification of Other and priority traffic - seedraft-eardley-pcn-marking-behaviour-01 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="===============0117933470==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0117933470== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9085D.E909847F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C9085D.E909847F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Phil, =20 Thanks for the reply. =20 Unfortunately the message in section 6.5 is not clear to me: =20 First bullet point : no remarks. =20 Second bullet point : single metering for all the identified DSCP values, or metering per DSCP value, or a mix of the two mechanisms =20 Third bullet point : I understand that BW of priority scheduled traffic on the same link should be taking into account by the PCN token bucket. --> so capacity in the marking draft means link=20 The strange point is that a PCN node dedicates capacity to NON PCN traffic. what does this mean? =20 Fourth bullet point : "uses same capacity on a link as PCN traffic" --> capacity is probably bandwidth that is shared. PCN traffic and non PCN but same codepoint.=20 share the same capacity since scheduling ... --> capacity is a queue with a certain servicing rate which is common for PCN and non PCN ? =20 Fifth bullet point : "it is not advised to have non PCN traffic that shares the same capacity on a link as PCN traffic" --> Capacity is bandwidth that is shared between PCN and non PCN traffic=20 =20 So my view is that capacity is used in different meaning in section 6.5. =20 I suppose a discussion is held in the past that discusses the value of taking into account other and priority traffic. Could some one point me to a doc or email discussion that provides a view on the problem. Thanks. =20 kr, =20 Chris Hublet ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: woensdag 27 augustus 2008 10:01 To: HUBLET Christian; pcn@ietf.org Subject: RE: [PCN] Request for clarification of Other and priority traffic - seedraft-eardley-pcn-marking-behaviour-01 Thanks Chris, Indeed this section is unclear and will be improved in the next version. =20 However, it should be better in the most recent verson of the architecture draft, section 6.5 "PCN-traffic" http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-05.txt=20 =20 I think this answers your questions, but would appreciate it if you could have a look and see if it makes sense or leaves something unclear. =20 The sense of this S6.5 text will appear in the next version of the marking draft =20 Thanks phil =20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of HUBLET Christian Sent: 26 August 2008 09:30 To: pcn@ietf.org Subject: [PCN] Request for clarification of Other and priority traffic - seedraft-eardley-pcn-marking-behaviour-01 =20 =20 Hello,=20 >From draft-eardley-pcn-marking-behaviour-01, I understand that the to be metered traffic is :=20 - PCN traffic + Other traffic + Priority traffic.=20 >From the draft it is not clear to me what priority traffic basically means:=20 - In the definitions of section 1.1, priority traffic shares the same capacity.=20 - I wonder what the meaning is of capacity:=20 1. sharing the same physical interface (read capacity) or=20 2. the bandwidth (read capacity) is configured for the 2 (or 3) types of traffic. (no separate capacity (bandwidth) is specified per traffic type) I suppose that for the "other traffic" also both definitions can be applicable.=20 In the first definition, I see an issue for admittance control. If not all other and priority traffic is actually present in the network,=20 there could be an overadmittance of the PCN traffic. A practical example could be coexistance of business traffic and residential traffic in the same diffserv network.=20 The residential traffic is controlled via PCN, the business traffic is controlled via a policer at the edge of the network. If not all sessions for the business traffic are active, the PCN traffic could take capacity which was meant to be used for business traffic. =20 In the second definition, I do not understand why lower priority traffic should not be taken into account if the same capacity (read bandwidth) is shared with PCN traffic. I have the impression that there is a strict requirement to take into account other traffic and priority traffic if present (metered packet (see section 2.4) is part of meter traffic (see section 1.1)). If the first definition is applied, this strict requirement can have a huge impact on the number of applications that can be supported in the diffserv domain and the accuracy with which the PCN bandwidth is controlled. In the second definition, it is the wish of the operator to share the bandwidth for a number of applications which is basically a normal policy. But in this last case, it is not clear why lower priority traffic can't share the same bandwidth. Thanks for clarifying.=20 Kr,=20 Chris=20 =20 _________________________________=20 Christian hublet=20 Bell Labs - Fixed Access=20 Copernicuslaan 50=20 B2018 Antwerp=20 Belgium=20 Tel. +32 3 2408789;=20 Email : Christian.Hublet@alcatel-lucent.be=20 =20 =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 Alcatel-Lucent Bell NV=20 Fortis 220-0002334-42=20 VAT BE 0404 621 642 Register of Legal Entities Antwerp=20 DISCLAIMER: This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited without the prior consent of its author. =20 ------_=_NextPart_001_01C9085D.E909847F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Request for clarification of Other and priority = traffic - see draft-eardley-pcn-marking-behaviour-01
Phil,
 
Thanks for the reply.
 
Unfortunately the message in section 6.5 is = not clear=20 to me:
 
First bullet point : no = remarks.
 
Second bullet point : single = metering for all=20 the identified DSCP values, or metering per DSCP value, or a mix of = the two=20 mechanisms
 
Third bullet point : I understand that = BW of=20 priority scheduled traffic on the same link should be taking into = account=20 by the PCN token bucket.
       &nbs= p;-->=20 so capacity in the marking draft means = link 
    The strange point is that = a PCN node=20 dedicates capacity to NON PCN traffic. what does this = mean?
 
Fourth bullet point : "uses = same capacity=20 on a link as PCN traffic"
       &nbs= p;-->=20 capacity is probably bandwidth that is shared. PCN traffic and = non PCN=20 but same codepoint. 
    share the same capacity = since=20 scheduling ...
        = -->=20 capacity is a queue with a certain servicing rate which is common for = PCN and=20 non PCN ?
 
Fifth=20 bullet point : "it is not advised to have non PCN traffic = that shares=20 the same capacity on a link as PCN traffic"
       =20 --> Capacity is bandwidth that is shared between PCN and non PCN = traffic 
 
So my=20 view is that capacity is used in different meaning in section=20 6.5.
 
I=20 suppose a discussion is held in the past that discusses the value of = taking into=20 account other and priority traffic.
Could=20 some one point me to a doc or email discussion that provides a view on = the=20 problem. Thanks.
 
kr,
 
Chris = Hublet

From: philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: woensdag 27 augustus = 2008=20 10:01
To: HUBLET Christian; pcn@ietf.org
Subject: = RE: [PCN]=20 Request for clarification of Other and priority traffic -=20 seedraft-eardley-pcn-marking-behaviour-01

Thanks=20 Chris,

Indeed this = section is=20 unclear and will be improved in the next version.

 

However, it = should be=20 better in the most recent verson of the architecture draft, section 6.5=20 “PCN-traffic” http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-05= .txt=20

 

I think this = answers=20 your questions, but would appreciate it if you could have a look and see = if it=20 makes sense or leaves something unclear.

 

The sense of = this S6.5=20 text will appear in the next version of the marking = draft

 

Thanks

phil

 

-----Original=20 Message-----
From:=20 pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of HUBLET = Christian
Sent: 26 August 2008 = 09:30
To: pcn@ietf.org
Subject: [PCN] Request for = clarification of=20 Other and priority traffic -=20 seedraft-eardley-pcn-marking-behaviour-01

 

 

Hello,

From=20 draft-eardley-pcn-marking-behaviour-01, I understand that the to be = metered=20 traffic is : =
        - PCN=20 traffic + Other traffic + Priority traffic.

From the draft it is not = clear to me=20 what priority traffic basically means:=20
        - In the definitions of = section 1.1,=20 priority traffic shares the same capacity.=20
        - I wonder what the = meaning is of=20 capacity:
       =20         1. sharing the same = physical=20 interface (read capacity) or=20
       =20         2. the bandwidth (read = capacity) is=20 configured for the 2 (or 3) types of traffic. (no separate capacity = (bandwidth)=20 is specified per traffic type)

I=20 suppose that for the "other traffic" also both definitions can be=20 applicable.

In=20 the first definition, I see an issue for admittance control. If not all = other=20 and priority traffic is actually present in the network, =

there could be an = overadmittance of=20 the PCN traffic. A practical example could be coexistance of business = traffic=20 and residential traffic in the same diffserv network.

The=20 residential traffic is controlled via PCN, the business traffic is = controlled=20 via a policer at the edge of the network. If not all sessions for the = business=20 traffic are active, the PCN traffic could take capacity which was meant = to be=20 used for business traffic.

  =
In the=20 second definition, I do not understand why lower priority traffic should = not be=20 taken into account if the same capacity (read bandwidth) is shared with = PCN=20 traffic.

I=20 have the impression that there is a strict requirement to take into = account=20 other traffic and priority traffic if present (metered packet (see = section 2.4)=20 is part of meter traffic (see section 1.1)). If the first definition is = applied,=20 this strict requirement can have a huge impact on the number of = applications=20 that can be  supported  in the diffserv domain and the = accuracy with=20 which the PCN bandwidth is controlled. In the second definition, it is = the wish=20 of the operator to share the bandwidth for a number of applications = which is=20 basically a normal policy. But in this last case, it is not clear why = lower=20 priority traffic can't share the same bandwidth.

Thanks for = clarifying.=20

Kr,

Chris

 

_________________________________=20
Christian=20 hublet
Bell Labs - Fixed=20 Access
Copernicuslaan=20 50
B2018 = Antwerp=20
Belgium=20
Tel. +32 3 = 2408789;=20
Email :=20 Christian.Hublet@alcatel-lucent.be

 

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20

Alcatel-Lucent=20 Bell NV
Fortis=20 220-0002334-42
VAT = BE 0404=20 621 642 Register of Legal Entities Antwerp

DISCLAIMER:=20 This message (including any attachments) contains confidential = information=20 intended for a specific individual and purpose, and is protected by law. = If you=20 are not the intended recipient, you should delete this message. Any = disclosure,=20 copying, or distribution of this message, or the taking of any action = based on=20 it, is strictly prohibited without the prior consent of its=20 author.

 

------_=_NextPart_001_01C9085D.E909847F-- --===============0117933470== 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 --===============0117933470==-- From pcn-bounces@ietf.org Wed Aug 27 09:40:26 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7484F3A694C; Wed, 27 Aug 2008 09: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 6445B3A694C for ; Wed, 27 Aug 2008 09:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_FR=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 SEpr47MyKSse for ; Wed, 27 Aug 2008 09:40:24 -0700 (PDT) Received: from smail6.alcatel.fr (gc-na5.alcatel.fr [64.208.49.5]) by core3.amsl.com (Postfix) with ESMTP id 5ADA13A67E9 for ; Wed, 27 Aug 2008 09:40:23 -0700 (PDT) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.ad2.ad.alcatel.com [155.132.6.75]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m7RGdorp031396; Wed, 27 Aug 2008 18:39:50 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.54]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 27 Aug 2008 18:39:50 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Aug 2008 18:39:49 +0200 Message-ID: <713A7C5347A4344A8671770DFE2B2EA7017CCC38@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <1219408519.32328.6.camel@tachyon> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt Thread-Index: AckEWwwd/lJWR+mvSBCa3Vjevsx4kgEA5HZw References: <1218240220.16668.6.camel@tachyon> <1219408519.32328.6.camel@tachyon> From: "HUBLET Christian" To: "Steven Blake" , "pcn" X-OriginalArrivalTime: 27 Aug 2008 16:39:50.0412 (UTC) FILETIME=[86436CC0:01C90863] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 Two small remarks on the draft which has improved a lot over time compared to previous versions of the document: - section 6.2: second bullet if excess marked traffic is measured and excess marked packets are dropped, I would assume that this will result in undertermination and a slower termination process i.s.o. of the mentioned overtermination. - section 6.3: figure 2 does not line up with 2 state marking. excess marking and threshold marking is mentioned, I would assume only threshold marking is used (even for admittance). rest of the figure looks OK. Kr, Chris -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Steven Blake Sent: vrijdag 22 augustus 2008 14:35 To: pcn Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt On Fri, 2008-08-08 at 20:03 -0400, Steven Blake wrote: > This message starts a 2+-week PCN working group last call for > advancing > > Title : Pre-Congestion Notification Architecture > Author(s) : P. Eardley > Filename : draft-ietf-pcn-architecture-05.txt > Pages : 54 > Date : 2008-08-07 > > as an Informational RFC. Substantive comments and statements of > support for this draft should be sent to the pcn mailing list. > Editorial suggestions can be sent directly to the document editor. > The last call will end on Wednesday August 27. A reminder that this last call closes next Wednesday. Regards, // Steve _______________________________________________ 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 Aug 28 01:28:30 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 737D83A687A; Thu, 28 Aug 2008 01:28: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 D61433A687A for ; Thu, 28 Aug 2008 01:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=-0.678, BAYES_40=-0.185, 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 ady1ZPZFI3ky for ; Thu, 28 Aug 2008 01:28:29 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id CBB393A6851 for ; Thu, 28 Aug 2008 01:28:28 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Aug 2008 09:27:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Aug 2008 09:27:31 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA1D8@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <713A7C5347A4344A8671770DFE2B2EA7017CCC38@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt Thread-Index: AckEWwwd/lJWR+mvSBCa3Vjevsx4kgEA5HZwACIVB1A= From: To: , , X-OriginalArrivalTime: 28 Aug 2008 08:27:32.0420 (UTC) FILETIME=[EAA94840:01C908E7] Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 Thanks for your supportive remarks, and spotting these 2 errors phil { - section 6.3: figure 2 does not line up with 2 state marking. { excess marking and threshold marking is { mentioned, { I would assume only threshold marking is used { (even for admittance). { rest of the figure looks OK. Thanks. in fact only excess marking is used. Above PCN-excess-rate, it should read "Some pkts excess-traffic-marked" Above U*PCN-excess-rate, it should read "Further pkts excess-traffic-marked" (sorry, I don't know what happened here. I remember copying Figure 1 and making the appropriate changes, but somehow I must have managed to undo the changes!!) _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Aug 28 02:25:16 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AECD728C172; Thu, 28 Aug 2008 02:25: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 E04F23A6910 for ; Thu, 28 Aug 2008 02:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.667 X-Spam-Level: X-Spam-Status: No, score=-0.667 tagged_above=-999 required=5 tests=[AWL=-1.769, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, MIME_ASCII0=1.5, 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 DVSdS41C6Cuk for ; Thu, 28 Aug 2008 02:25:04 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id D6F6E3A6819 for ; Thu, 28 Aug 2008 02:25:03 -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); Thu, 28 Aug 2008 10:24:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Aug 2008 10:24:30 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA1D9@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <713A7C5347A4344A8671770DFE2B2EA7017CCC1C@FRVELSMBS22.ad2.ad.alcatel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Request for clarification of Other and priority traffic - seedraft-eardley-pcn-marking-behaviour-01 Thread-Index: AckHVfNfByaoB9vRTiaa/aj4wzcElgAxGMVwAA/2iEAAJCYYQA== From: To: , X-OriginalArrivalTime: 28 Aug 2008 09:24:30.0690 (UTC) FILETIME=[E01BE420:01C908EF] Subject: Re: [PCN] Request for clarification of Other and priority traffic - seedraft-eardley-pcn-marking-behaviour-01 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="===============2038701954==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============2038701954== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C908EF.DFD23889" This is a multi-part message in MIME format. ------_=_NextPart_001_01C908EF.DFD23889 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks chris, in-line phil =20 -----Original Message----- From: HUBLET Christian [mailto:Christian.Hublet@alcatel-lucent.be]=20 Sent: 27 August 2008 17:00 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] Request for clarification of Other and priority traffic - seedraft-eardley-pcn-marking-behaviour-01 =20 Phil, =20 Thanks for the reply. =20 Unfortunately the message in section 6.5 is not clear to me: =20 First bullet point : no remarks. =20 Second bullet point : single metering for all the identified DSCP values, or metering per DSCP value, or a mix of the two mechanisms =20 [phil] this bullet reflects old discussions where we talked about PCn running separately for several classes - so your 2nd sense ie "metering per DSCP value".=20 However, the first sense would also be possible. I'm not actually sure in retrospect that this bullet adds much, so I propose deleting it.=20 please shout if you object & would prefer to keep it (if so, please suggest a re-phrasing) =20 Third bullet point : I understand that BW of priority scheduled traffic on the same link should be taking into account by the PCN token bucket. --> so capacity in the marking draft means link=20 The strange point is that a PCN node dedicates capacity to NON PCN traffic. what does this mean? =20 [phil] i think this is just that I could make the sentence construction clearer. It means that there are 2 possibilities [1] the router has some capacity set aside dedicated for the "important" traffic (eg operator's control msgs). This means that pcn isnt allowed to use this capacity, even if "important traffic" isnt currently using it. In this case there's nothing for PCn to worry about [2] the router shares capacity between the "important" traffic & pcn traffic. But it's assumed that the "important" traffic is always priority scheduled ahead of pcn-traffic. It would be possible in a worst case for pcn to get no capacity. Clearly the "important" traffic needs to contribute to pcn's meters.=20 =20 Fourth bullet point : "uses same capacity on a link as PCN traffic" --> capacity is probably bandwidth that is shared. PCN traffic and non PCN but same codepoint.=20 share the same capacity since scheduling ... --> capacity is a queue with a certain servicing rate which is common for PCN and non PCN ? =20 Fifth bullet point : "it is not advised to have non PCN traffic that shares the same capacity on a link as PCN traffic" --> Capacity is bandwidth that is shared between PCN and non PCN traffic=20 =20 So my view is that capacity is used in different meaning in section 6.5. =20 "Capacity" - I meant the capacity as in the forwarding bandwidth on the link. But I think in practice this is equivalent to same queue. =20 if there are different types of traffic "sharing capacity", then possibilities are: 1. all the types of traffic go in the same queue. Clearly then the router's capacity is shared. 2. each type of traffic goes in a separate queue and the queues are scheduled with equal priority. =20 However, assuming that both types of traffic have same dscp (this is the example mentioned in the 4th bullet), then in practice both types of traffic go in the same queue. (In theory it would be possible to go in different queues (by the router classification looking at ECN field), but in practice it seems that nodes only look at dscp when determining what queue to put traffic in. But in any case, even if separate queues were used, this is really just an implementation detail that we shouldn't worry about.) =20 Chris, do you think it makes it clear if I re-phrase it from: There may be other traffic that uses the same capacity (on a link) as PCN-traffic. =20 To: There may be other traffic that uses the same capacity as PCN-traffic. "Capacity" means forwarding bandwidth on a link. =20 And in: they will share the same capacity since scheduling behaviour is coupled with the DSCP only. - add the phrase "in practice" (next to "scheduling behaviour") =20 Please suggest some alternative words if you think they'd help. I guess I've read this stuff too many times - find it hard to view it from perspective of someone coming to it fresh! =20 Thanks phil =20 I suppose a discussion is held in the past that discusses the value of taking into account other and priority traffic. Could some one point me to a doc or email discussion that provides a view on the problem. Thanks. =20 kr, =20 Chris Hublet =20 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: woensdag 27 augustus 2008 10:01 To: HUBLET Christian; pcn@ietf.org Subject: RE: [PCN] Request for clarification of Other and priority traffic - seedraft-eardley-pcn-marking-behaviour-01 Thanks Chris, Indeed this section is unclear and will be improved in the next version. =20 However, it should be better in the most recent verson of the architecture draft, section 6.5 "PCN-traffic" http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-05.txt=20 =20 I think this answers your questions, but would appreciate it if you could have a look and see if it makes sense or leaves something unclear. =20 The sense of this S6.5 text will appear in the next version of the marking draft =20 Thanks phil =20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of HUBLET Christian Sent: 26 August 2008 09:30 To: pcn@ietf.org Subject: [PCN] Request for clarification of Other and priority traffic - seedraft-eardley-pcn-marking-behaviour-01 =20 =20 Hello,=20 >From draft-eardley-pcn-marking-behaviour-01, I understand that the to be metered traffic is :=20 - PCN traffic + Other traffic + Priority traffic.=20 >From the draft it is not clear to me what priority traffic basically means:=20 - In the definitions of section 1.1, priority traffic shares the same capacity.=20 - I wonder what the meaning is of capacity:=20 1. sharing the same physical interface (read capacity) or=20 2. the bandwidth (read capacity) is configured for the 2 (or 3) types of traffic. (no separate capacity (bandwidth) is specified per traffic type) I suppose that for the "other traffic" also both definitions can be applicable.=20 In the first definition, I see an issue for admittance control. If not all other and priority traffic is actually present in the network,=20 there could be an overadmittance of the PCN traffic. A practical example could be coexistance of business traffic and residential traffic in the same diffserv network.=20 The residential traffic is controlled via PCN, the business traffic is controlled via a policer at the edge of the network. If not all sessions for the business traffic are active, the PCN traffic could take capacity which was meant to be used for business traffic. =20 In the second definition, I do not understand why lower priority traffic should not be taken into account if the same capacity (read bandwidth) is shared with PCN traffic. I have the impression that there is a strict requirement to take into account other traffic and priority traffic if present (metered packet (see section 2.4) is part of meter traffic (see section 1.1)). If the first definition is applied, this strict requirement can have a huge impact on the number of applications that can be supported in the diffserv domain and the accuracy with which the PCN bandwidth is controlled. In the second definition, it is the wish of the operator to share the bandwidth for a number of applications which is basically a normal policy. But in this last case, it is not clear why lower priority traffic can't share the same bandwidth. Thanks for clarifying.=20 Kr,=20 Chris=20 =20 _________________________________=20 Christian hublet=20 Bell Labs - Fixed Access=20 Copernicuslaan 50=20 B2018 Antwerp=20 Belgium=20 Tel. +32 3 2408789;=20 Email : Christian.Hublet@alcatel-lucent.be=20 =20 =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 Alcatel-Lucent Bell NV=20 Fortis 220-0002334-42=20 VAT BE 0404 621 642 Register of Legal Entities Antwerp=20 DISCLAIMER: This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited without the prior consent of its author. =20 ------_=_NextPart_001_01C908EF.DFD23889 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Request for clarification of Other and priority traffic - see draft-eardley-pcn-marking-behaviour-01

Thanks chris, = in-line

phil

 

-----Original Message-----
From: HUBLET Christian [mailto:Christian.Hublet@alcatel-lucent.be]
Sent: 27 August 2008 = 17:00
To: = Eardley,PL,Philip,CXR9 R; pcn@ietf.org
Subject: RE: [PCN] = Request for clarification of Other and priority traffic - seedraft-eardley-pcn-marking-behaviour-01

 

Phil,

 

Thanks for the = reply.

 

Unfortunately the message in = section 6.5 is not clear to me:

 

First bullet point : no = remarks.

 

Second bullet point : single metering for all the identified DSCP values, or metering per DSCP = value, or a mix of the two mechanisms

 

[phil] this bullet reflects old discussions where we talked about PCn running separately for several = classes – so your 2nd sense ie “metering per = DSCP value”.

However, the first sense would also = be possible.

I’m not actually sure in = retrospect that this bullet adds much, so I propose deleting it.

please shout if you object & = would prefer to keep it (if so, please suggest a re-phrasing)

 

Third bullet point : I = understand that BW of priority scheduled traffic on the same link should = be taking into account by the PCN token bucket.

      =   --> so capacity in the marking draft means = link 

    The strange = point is that a PCN node dedicates capacity to NON PCN traffic. what does this = mean?

 

[phil] i think this is just that I = could make the sentence construction clearer. It means that there are 2 = possibilities

[1] the router has some capacity = set aside dedicated for the “important” traffic (eg operator’s = control msgs). This means that pcn isnt allowed to use this capacity, even if = “important traffic” isnt currently using it. In this case there’s = nothing for PCn to worry about

[2] the router shares capacity = between the “important” traffic & pcn traffic. But it’s = assumed that the “important” traffic is always priority scheduled ahead of pcn-traffic. It would be possible in a worst case for pcn to get no = capacity. Clearly the “important” traffic needs to contribute to pcn’s = meters.

 

Fourth bullet point : = "uses same capacity on a link as PCN traffic"

      =   --> capacity is probably bandwidth that is shared. PCN traffic and = non PCN but same codepoint. 

    share the same = capacity since scheduling ...

      =   --> capacity is a queue with a certain servicing rate which is common = for PCN and non PCN ?

 

Fifth bullet point : "it is = not advised to have non PCN traffic that shares the same capacity on a link = as PCN traffic"

      =   --> Capacity is bandwidth that is shared between PCN and non PCN traffic 

 

So my view is that capacity is used = in different meaning in section 6.5.

 

“Capacity” – I = meant the capacity as in the forwarding bandwidth on the link. But I think in = practice this is equivalent to same queue.

 

if there are different types of = traffic “sharing capacity”, then possibilities are:

1. all the types of traffic go in = the same queue. Clearly then the router’s capacity is = shared.

2. each type of traffic goes in a = separate queue and the queues are scheduled with equal = priority.

 

However, assuming that both types = of traffic have same dscp (this is the example mentioned in the = 4th bullet), then in practice both types of traffic go in the same queue. (In theory = it would be possible to go in different queues (by the router = classification looking at ECN field), but in practice it seems that nodes only look at = dscp when determining what queue to put traffic in. But in any case, even if separate queues were used, this is really just an implementation detail = that we shouldn’t worry about.)

 

Chris, do you think it makes it = clear if I re-phrase it from:

There may be other traffic that uses the same =
capacity (on a link)
      as =
PCN-traffic. 

To:

There may be other traffic that uses the same =
capacity as PCN-traffic. “Capacity” means forwarding =
bandwidth on a link.
 
And =
in:
they will =
share the
      same capacity =
since scheduling behaviour is coupled with the =
DSCP
      =
only.
- add the =
phrase “in practice” (next to “scheduling =
behaviour”)

 

Please suggest some alternative = words if you think they’d help. I guess I’ve read this stuff too many = times  - find it hard to view it from perspective of someone coming to it = fresh!

 

Thanks

phil

 

I suppose a discussion is held in = the past that discusses the value of taking into account other and priority = traffic.

Could some one point me to a doc or = email discussion that provides a view on the problem. = Thanks.

 

kr,

 

Chris Hublet

 

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
Sent: woensdag 27 = augustus 2008 10:01
To: HUBLET Christian; = pcn@ietf.org
Subject: RE: [PCN] = Request for clarification of Other and priority traffic - seedraft-eardley-pcn-marking-behaviour-01

Thanks Chris,

Indeed this section is unclear and = will be improved in the next version.

 

However, it should be better in the = most recent verson of the architecture draft, section 6.5 = “PCN-traffic” http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-05= .txt

 

I think this answers your = questions, but would appreciate it if you could have a look and see if it makes sense = or leaves something unclear.

 

The sense of this S6.5 text will = appear in the next version of the marking draft

 

Thanks

phil

 

-----Original Message-----
From: = pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On = Behalf Of HUBLET Christian
Sent: 26 August 2008 = 09:30
To: pcn@ietf.org
Subject: [PCN] Request = for clarification of Other and priority traffic - seedraft-eardley-pcn-marking-behaviour-01

 

 

Hello,

From draft-eardley-pcn-marking-behaviour-01, I understand that the to be = metered traffic is :
        - PCN traffic + Other = traffic + Priority traffic.

From the draft it is not clear to me what priority traffic basically = means:
        - In the definitions of = section 1.1, priority traffic shares the same capacity.
        - I wonder what the meaning = is of capacity:
                1. sharing the same = physical interface (read capacity) or
                2. the bandwidth (read = capacity) is configured for the 2 (or 3) types of traffic. (no separate capacity = (bandwidth) is specified per traffic type)

I suppose that for the "other traffic" also both definitions can = be applicable.

In the first definition, I see an issue for admittance control. If not all = other and priority traffic is actually present in the network, =

there could be an overadmittance of the PCN traffic. A practical example could = be coexistance of business traffic and residential traffic in the same = diffserv network.

The residential traffic is controlled via PCN, the business traffic is = controlled via a policer at the edge of the network. If not all sessions for the = business traffic are active, the PCN traffic could take capacity which was meant = to be used for business traffic.

 
In the second definition, I do not understand why lower priority traffic should = not be taken into account if the same capacity (read bandwidth) is shared with = PCN traffic.

I have the impression that there is a strict requirement to take into = account other traffic and priority traffic if present (metered packet (see section = 2.4) is part of meter traffic (see section 1.1)). If the first definition is = applied, this strict requirement can have a huge impact on the number of = applications that can be  supported  in the diffserv domain and the = accuracy with which the PCN bandwidth is controlled. In the second definition, it is = the wish of the operator to share the bandwidth for a number of applications = which is basically a normal policy. But in this last case, it is not clear why = lower priority traffic can't share the same bandwidth.

Thanks for clarifying.

Kr,

Chris

 

_________________________________
Christian hublet
Bell Labs - Fixed Access
Copernicuslaan 50
B2018 Antwerp
Belgium
Tel. +32 3 2408789;
Email : Christian.Hublet@alcatel-lucent.be

 

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =

Alcatel-Lucent Bell = NV
Fortis = 220-0002334-42
VAT BE 0404 621 642 Register of = Legal Entities Antwerp

DISCLAIMER: This message = (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the = intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, = is strictly prohibited without the prior consent of its = author.

 

=00 ------_=_NextPart_001_01C908EF.DFD23889-- --===============2038701954== 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 --===============2038701954==-- From pcn-bounces@ietf.org Thu Aug 28 02:44:57 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFF743A6912; Thu, 28 Aug 2008 02:44: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 805D13A6912 for ; Thu, 28 Aug 2008 02:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 mpYDpshXYPZl for ; Thu, 28 Aug 2008 02:44:54 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 6C0793A686B for ; Thu, 28 Aug 2008 02:44:53 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail21.telekom.de with ESMTP; Thu, 28 Aug 2008 11:44:24 +0200 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, 28 Aug 2008 11:44:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Aug 2008 11:44:22 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C01B11310@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <001c01c90830$dc8f96e0$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt thread-index: AckH+/QV3Y45tt6jSHmIy28ziDldOAAHfAOAAACCC8AAAQ+VQAABwDwQAAIzkmAAMG5/AA== References: <000501c90820$b1efaca0$810c5982@dynamic.ewi.utwente.nl><4A916DBC72536E419A0BD955EDECEDEC03DAA1C6@E03MVB1-UKBR.domain1.systemhost.net> <001c01c90830$dc8f96e0$810c5982@dynamic.ewi.utwente.nl> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 28 Aug 2008 09:44:23.0839 (UTC) FILETIME=[A747FAF0:01C908F2] Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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, the hose model on an ingress node requires functionalities treating packets irrespective disregarding the destination address and the hose model applied to an egress node there require functionalities working on all packets disregarding their origin address. I've copied in two sections of draft westberg. The mechanisms mentioned there with regard to the hose model: - are obviously not related to the hose model. - are out of scope of the PCN WG. I think the WG can go on now. Regards, Ruediger Quotes from draft-westberg-pcn-load-control-04 3.1.2.2. PCN-egress-node features [snip] Note that if an edge-to-edge pair aggregated state is not available at the PCN-egress-node, e.g., when the HOSE model is used then the PCN-egress-node cannot determine whether a PCN-egress-node associated with the edge-to-edge pair PCN aggregate operates in Normal state, Admission Control state or Flow Termination state. However, even in this case, when a probe packet arrives at the PCN-egress-node, then this request should be rejected if the probe packet is PCN_marking encoded. Otherwise, i.e., if the probe packet is not PCN_marking encoded, it should be accepted. 3.2.2. PCN-egress-node [snip] Note that in the ingress-egress-aggregate model the excess rate and the flows to be terminated are associated with the same edge-to-edge (i.e., ingress-egress) pair PCN aggregate and with the same traffic class, i.e., PHB. In the HOSE model the excess rate and the flows to be terminated are associated with the same traffic class, i.e., PHB. The PCN-egress-node needs to store for each flow the address, e.g., IP address and port number, of the PCN-ingress-node from where the particular flow passed before arriving to the PCN-egress-node. This can be for example done by using information that is carried by the external protocols used in combination with the LC-PCN solution. For the flows that should be terminated the PCN-egress-node informs the associated PCN-ingress-node to terminate them. If the PCN domain uses thet ingress-egress-aggregate model and if the PCN-egress-node receives any admission flow request, belonging to a ingress-egress- aggregate state operating in flow termination state then the request must be rejected. -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Georgios Karagiannis Sent: Wednesday, August 27, 2008 12:37 PM To: philip.eardley@bt.com; slblake@petri-meat.com Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt Hi Phil HOSE model is defined some 20 years ago, please see e.g the following article: N. G. Duffield, P. Goyal and A. Greenberg, "A Flexible Model for Resource Management in Virtual Private Networks", in: Proc. of ACM SIGCOMM, 1999. In the above article I found the following definition: "A hose is characterized by the aggregate traffic to and from one endpoint in the VPN to the set of other endpoints in the VPN" Thus the definition refers to aggregated traffic to and from one edge to and from all other endpoints. In our case we refer only to the aggregated traffic from other endpoints to one endpoint. Thus what we use is in line with the definition of the HOSE model. Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: woensdag 27 augustus 2008 11:31 > To: karagian@cs.utwente.nl; slblake@petri-meat.com > Cc: pcn@ietf.org > Subject: RE: [PCN] PCN WG last call for > draft-ietf-pcn-architecture-05.txt > > I thought your emails with steve had revealed that your model > was the exact opposite of the well known hose model? > > > { -----Original Message----- > { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > { Sent: 27 August 2008 09:41 { To: Eardley,PL,Philip,CXR9 R; > slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt > { > { Hi Phil > { > { What I explained is the well know HOSE bandwidth management model. > { During the IETF in Dublin, Hein also shown also some > results { that were obtrained using the HOSE model. > { > { > { Best regards, > { Georgios > { > { > { > -----Original Message----- > { > From: philip.eardley@bt.com > [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 augustus > 2008 10:20 { > To: karagian@cs.utwente.nl; > slblake@petri-meat.com { > Cc: pcn@ietf.org { > Subject: RE: > [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt > { > > { > So the question is about adding to the draft: > { > A model where the egress measures marks coming from all > the { > ingresses, and makes admission decision based on that. > { > > { > Before adding anything about this to the draft, I'd like > to { > understand if this is a genuine practical, understood > option { > (if so, OK), or if it's a theoretical possibility > or one not { > well understood. > { > (there are many things in the latter category that aren't > { > mentioned in the draft.) { > { > Questions are why this > is interesting, why is it better than { > the models already > well-known, are there comparative analysis { > /simulations? > { > > { > I suppose I've got 2 general issues: > { > [1] every time something is added, overall the document { > becomes harder to understand, more daunting to read & it { > > looks less like the WG has consensus. > { > [2] this is an INFO doc. People are free to invent ways > of { > using the standards pieces other than the architecture > draft { > says, and indeed in ways not yet dreamt of. > { > > { > Phil. > { > > { > { -----Original Message----- > { > { From: pcn-bounces@ietf.org > [mailto:pcn-bounces@ietf.org] On { > Behalf Of { Georgios > Karagiannis { Sent: 27 August 2008 08:54 { > { To: 'Steven Blake' > { > { Cc: pcn@ietf.org > { > { Subject: Re: [PCN] PCN WG last call for { > > draft-ietf-pcn-architecture-05.txt > { > { > { > { Hi Steven > { > { > { > { > -----Original Message----- > { > { > From: Steven Blake [mailto:slblake@petri-meat.com] { > > { > Sent: woensdag 27 augustus 2008 6:18 { > To: Georgios { > Karagiannis { > Cc: pcn@ietf.org { > Subject: RE: [PCN] PCN > { > WG last call for { > draft-ietf-pcn-architecture-05.txt > { > { > > { > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios Karagiannis wrote: > { > { > > { > { > > Hi Steven > { > { > > > { > { > > > { > { > > Please see in line! > { > { > > > { > { > > > { > { > > > -----Original Message----- > { > { > > > From: Steven Blake > [mailto:slblake@petri-meat.com] { { > > > > Sent: dinsdag 26 > augustus 2008 14:46 { > > > To: > { > Georgios Karagiannis { > > > Cc: pcn@ietf.org { > > > { > > Subject: Re: [PCN] PCN WG last call for { > > > { > > draft-ietf-pcn-architecture-05.txt > { > { > > > > { > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios Karagiannis > wrote: > { > { > > > > { > { > > > > Hi Phil, Hi all > { > { > > > > > { > { > > > > Here are some comments on the PCN architecture draft: > { > { > > > > > { > { > > > > 1) Thank you for clarifying the bullet in > Setion { > 3.2 about flow { > > > > termination. > { > { > > > > > { > { > > > > 2) From what I understand the PCN architecture > { > draft { > > > mentions that PCN { > > > > supports only > the { > trunk (ingress-egress-aggregate) and not the { > > > > > HOSE model. > { > { > > > > Is the PCN architecture draft excluding > solutions { > that { > support the { > > > > HOSE model? If > not, please { > emphasize in the PCN { > architecture draft { > > > > that { > "solutions that are based on other types of > flow { > > > { > aggregation than { > > > > the > ingress-egress-aggregate { > method of flow { > aggregation, > are not { > > > > excluded { > from the PCN WG activities." > { > { > > > > { > { > > > Actually they are, by our charter. > { > { > > > { > { > > I have not seen that the PCN charter excludes other > { > types { > of aggregation. > { > { > > { > { > Well, I checked, and you are correct (mea culpa). > { > { Georgios: No problem > { > { > { > { > > { > { > > Please note > { > { > > that I am refering to the HOSE model where the > traffic { > sent { > by one or { > > more than one ingresses > towards one { > egress is aggregated at the { > > egress. In > this way higgher { > traffic aggregation can be accomplished > { > > than in the { > situation that the pipe/trunk { > > (ingress-egress-aggregate) { > { > > is used, where the > traffic sent by only one ingress in { > aggegated at { > > the egress. > { > { > > { > { > Typically the "hose" model refers to > point-to-multipoint { > { > traffic flow, not multipoint-to-point. > { > { Georgios: Typically yes, but in this case we refer to { > bandwidth allocation { in a multipoint-to-point fashion. > { > { > { > { > > { > { > > { > { > Regards, > { > { > > { > { > // Steve > { > { > > { > { > { > { > { > { _______________________________________________ > { > { 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 Aug 28 03:45:21 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D0133A6B03; Thu, 28 Aug 2008 03:45: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 668893A69C9 for ; Thu, 28 Aug 2008 03:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.354 X-Spam-Level: X-Spam-Status: No, score=0.354 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id armcsKXEj3Su for ; Thu, 28 Aug 2008 03:45: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 C970D3A687A for ; Thu, 28 Aug 2008 03:45:03 -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 m7SAidlj018673; Thu, 28 Aug 2008 12:44:44 +0200 (MEST) From: "Georgios Karagiannis" To: "'Geib, Ruediger'" References: <000501c90820$b1efaca0$810c5982@dynamic.ewi.utwente.nl><4A916DBC72536E419A0BD955EDECEDEC03DAA1C6@E03MVB1-UKBR.domain1.systemhost.net> <001c01c90830$dc8f96e0$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1C01B11310@S4DE8PSAANK.mitte.t-com.de> Date: Thu, 28 Aug 2008 12:44:34 +0200 Message-ID: <001301c908fb$13807910$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <1B6169C658325341A3B8066E23919E1C01B11310@S4DE8PSAANK.mitte.t-com.de> Thread-Index: AckH+/QV3Y45tt6jSHmIy28ziDldOAAHfAOAAACCC8AAAQ+VQAABwDwQAAIzkmAAMG5/AAACOGNQ 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, 28 Aug 2008 12:44:45 +0200 (MEST) Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 As I shown in previous emails, the definition of the HOSE model covers an wide area and its interpretation depends on the context. Thus the mentioned model can be seen as a HOSE model in the PCN context. As you could follow the discussion with Steven, this model is not out of the PCN WG scope. Best regards, Georgios > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: donderdag 28 augustus 2008 11:44 > To: karagian@cs.utwente.nl > Cc: pcn@ietf.org > Subject: RE: [PCN] PCN WG last call for > draft-ietf-pcn-architecture-05.txt > > Georgios, > > the hose model on an ingress node requires functionalities > treating packets irrespective disregarding the destination > address and the hose model applied to an egress node there > require functionalities working on all packets disregarding > their origin address. > > I've copied in two sections of draft westberg. The mechanisms > mentioned there with regard to the hose model: > - are obviously not related to the hose model. > - are out of scope of the PCN WG. > > I think the WG can go on now. > > Regards, > > Ruediger > > > > Quotes from draft-westberg-pcn-load-control-04 > > 3.1.2.2. PCN-egress-node features > > [snip] > > Note that if an edge-to-edge pair aggregated state is not available > at the PCN-egress-node, e.g., when the HOSE model is used then the > PCN-egress-node cannot determine whether a PCN-egress-node > associated > with the edge-to-edge pair PCN aggregate operates in Normal state, > Admission Control state or Flow Termination state. > However, even in > this case, when a probe packet arrives at the PCN-egress-node, then > this request should be rejected if the probe packet is PCN_marking > encoded. Otherwise, i.e., if the probe packet is not PCN_marking > encoded, it should be accepted. > > 3.2.2. PCN-egress-node > > [snip] > > Note that in the ingress-egress-aggregate model the excess rate and > the flows to be terminated are associated with the same > edge-to-edge > (i.e., ingress-egress) pair PCN aggregate and with the same traffic > class, i.e., PHB. In the HOSE model the excess rate and > the flows to > be terminated are associated with the same traffic class, > i.e., PHB. > The PCN-egress-node needs to store for each flow the address, e.g., > IP address and port number, of the PCN-ingress-node from where the > particular flow passed before arriving to the > PCN-egress-node. This > can be for example done by using information that is carried by the > external protocols used in combination with the LC-PCN > solution. For > the flows that should be terminated the PCN-egress-node informs the > associated PCN-ingress-node to terminate them. If the PCN domain > uses thet ingress-egress-aggregate model and if the PCN-egress-node > receives any admission flow request, belonging to a ingress-egress- > aggregate state operating in flow termination state then > the request > must be rejected. > > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Georgios Karagiannis > Sent: Wednesday, August 27, 2008 12:37 PM > To: philip.eardley@bt.com; slblake@petri-meat.com > Cc: pcn@ietf.org > Subject: Re: [PCN] PCN WG last call for > draft-ietf-pcn-architecture-05.txt > > Hi Phil > > HOSE model is defined some 20 years ago, please see e.g the following > article: > > N. G. Duffield, P. Goyal and A. Greenberg, "A Flexible Model > for Resource Management in Virtual Private Networks", in: > Proc. of ACM SIGCOMM, 1999. > > In the above article I found the following definition: > > "A hose is characterized by the aggregate traffic to and from > one endpoint in the VPN to the set of other endpoints in the VPN" > > Thus the definition refers to aggregated traffic to and from > one edge to and from all other endpoints. > > > In our case we refer only to the aggregated traffic from > other endpoints to one endpoint. > > Thus what we use is in line with the definition of the HOSE model. > > Best regards, > Georgios > > > > > > -----Original Message----- > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > Sent: woensdag 27 augustus 2008 11:31 > > To: karagian@cs.utwente.nl; slblake@petri-meat.com > > Cc: pcn@ietf.org > > Subject: RE: [PCN] PCN WG last call for > > draft-ietf-pcn-architecture-05.txt > > > > I thought your emails with steve had revealed that your > model was the > > exact opposite of the well known hose model? > > > > > > { -----Original Message----- > > { From: Georgios Karagiannis > [mailto:karagian@cs.utwente.nl] { Sent: > > 27 August 2008 09:41 { To: Eardley,PL,Philip,CXR9 R; > > slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: > > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt > > { > > { Hi Phil > > { > > { What I explained is the well know HOSE bandwidth management model. > > { During the IETF in Dublin, Hein also shown also some > results { that > > were obtrained using the HOSE model. > > { > > { > > { Best regards, > > { Georgios > > { > > { > > { > -----Original Message----- > > { > From: philip.eardley@bt.com > > [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 augustus > > 2008 10:20 { > To: karagian@cs.utwente.nl; > slblake@petri-meat.com { > > > Cc: pcn@ietf.org { > Subject: RE: > > [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt > > { > > > { > So the question is about adding to the draft: > > { > A model where the egress measures marks coming from all the { > > > ingresses, and makes admission decision based on that. > > { > > > { > Before adding anything about this to the draft, I'd like to { > > > understand if this is a genuine practical, understood > option { > (if > > so, OK), or if it's a theoretical possibility or one not { > well > > understood. > > { > (there are many things in the latter category that aren't { > > > mentioned in the draft.) { > { > Questions are why this is > > interesting, why is it better than { > the models already > well-known, > > are there comparative analysis { > /simulations? > > { > > > { > I suppose I've got 2 general issues: > > { > [1] every time something is added, overall the document > { becomes > > harder to understand, more daunting to read & it { > > looks less > like the WG has consensus. > > { > [2] this is an INFO doc. People are free to invent ways of { > > > using the standards pieces other than the architecture > draft { > says, > > and indeed in ways not yet dreamt of. > > { > > > { > Phil. > > { > > > { > { -----Original Message----- > > { > { From: pcn-bounces@ietf.org > > [mailto:pcn-bounces@ietf.org] On { > Behalf Of { Georgios > Karagiannis > > { Sent: 27 August 2008 08:54 { > { To: 'Steven Blake' > > { > { Cc: pcn@ietf.org > > { > { Subject: Re: [PCN] PCN WG last call for { > > > draft-ietf-pcn-architecture-05.txt > > { > { > > { > { Hi Steven > > { > { > > { > { > -----Original Message----- > > { > { > From: Steven Blake [mailto:slblake@petri-meat.com] { > > > { > Sent: woensdag 27 augustus 2008 6:18 { > To: Georgios { > > Karagiannis { > Cc: pcn@ietf.org { > Subject: RE: [PCN] PCN > > { > WG > > last > call for { > draft-ietf-pcn-architecture-05.txt > > { > { > > > { > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios > Karagiannis wrote: > > { > { > > > { > { > > Hi Steven > > { > { > > > > { > { > > > > { > { > > Please see in line! > > { > { > > > > { > { > > > > { > { > > > -----Original Message----- { > { > > > From: > Steven Blake > > [mailto:slblake@petri-meat.com] { { > > > > Sent: dinsdag > 26 augustus > > 2008 14:46 { > > > To: > > { > Georgios Karagiannis { > > > Cc: pcn@ietf.org { > > > { > > > Subject: Re: [PCN] PCN WG last call for { > > > { > > > draft-ietf-pcn-architecture-05.txt > > { > { > > > > > { > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios Karagiannis > > wrote: > > { > { > > > > > { > { > > > > Hi Phil, Hi all > > { > { > > > > > > { > { > > > > Here are some comments on the PCN architecture draft: > > { > { > > > > > > { > { > > > > 1) Thank you for clarifying the bullet in > Setion { > 3.2 > > about flow { > > > > termination. > > { > { > > > > > > { > { > > > > 2) From what I understand the PCN > architecture { > draft > > { > > > mentions that PCN { > > > > supports only the { > trunk > > (ingress-egress-aggregate) and not the { > > > > > > HOSE model. > > { > { > > > > Is the PCN architecture draft excluding solutions { > > > that { > support the { > > > > HOSE model? If not, please { > > > emphasize in the PCN { > architecture draft { > > > > > that { > "solutions that are based on other types of > > flow { > > > > > > > > > { > aggregation than { > > > > the > > ingress-egress-aggregate { > method of flow { > > aggregation, are not { > > > > > > excluded { > from the PCN WG activities." > > { > { > > > > > { > { > > > Actually they are, by our charter. > > { > { > > > > { > { > > I have not seen that the PCN charter excludes other { > > > types { > of aggregation. > > { > { > > > { > { > Well, I checked, and you are correct (mea culpa). > > { > { Georgios: No problem > > { > { > > { > { > > > { > { > > Please note > > { > { > > that I am refering to the HOSE model where the > traffic { > > > sent { > by one or { > > more than one ingresses towards one { > > > egress is aggregated at the { > > egress. In this way higgher { > > > traffic aggregation can be accomplished { > > than in the { > > > situation that the pipe/trunk { > > > (ingress-egress-aggregate) { > { > > is used, where the > traffic sent > > by only one ingress in { > aggegated at { > > the egress. > > { > { > > > { > { > Typically the "hose" model refers to > point-to-multipoint { > { > > > traffic flow, not multipoint-to-point. > > { > { Georgios: Typically yes, but in this case we refer to { > > bandwidth allocation { in a multipoint-to-point fashion. > > { > { > > { > { > > > { > { > > > { > { > Regards, > > { > { > > > { > { > // Steve > > { > { > > > { > { > > { > { > > { > { _______________________________________________ > > { > { 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 Aug 28 03:52:36 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2077C3A6AAD; Thu, 28 Aug 2008 03:52: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 244763A6AAD for ; Thu, 28 Aug 2008 03:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 H9hbYIE5gguY for ; Thu, 28 Aug 2008 03:52:30 -0700 (PDT) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 3092A3A6912 for ; Thu, 28 Aug 2008 03:52:30 -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, 28 Aug 2008 12:52:28 +0200 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, 28 Aug 2008 12:52:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Aug 2008 12:52:25 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C01B11378@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <001301c908fb$13807910$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt thread-index: AckH+/QV3Y45tt6jSHmIy28ziDldOAAHfAOAAACCC8AAAQ+VQAABwDwQAAIzkmAAMG5/AAACOGNQAABYCEA= References: <000501c90820$b1efaca0$810c5982@dynamic.ewi.utwente.nl><4A916DBC72536E419A0BD955EDECEDEC03DAA1C6@E03MVB1-UKBR.domain1.systemhost.net> <001c01c90830$dc8f96e0$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1C01B11310@S4DE8PSAANK.mitte.t-com.de> <001301c908fb$13807910$810c5982@dynamic.ewi.utwente.nl> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 28 Aug 2008 10:52:27.0258 (UTC) FILETIME=[293045A0:01C908FC] Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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, please argue like a sales representative with managers. But not with me on this list. Regards, Ruediger = -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] = Sent: Thursday, August 28, 2008 12:45 PM To: Geib, R=FCdiger Cc: pcn@ietf.org Subject: RE: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt Hi Ruediger As I shown in previous emails, the definition of the HOSE model covers an wide area = and its interpretation depends on the context. Thus the mentioned model can be seen as a HOSE model in the PCN context. As you could follow the discussion with Steven, this model is = not out of the PCN WG scope. Best regards, Georgios > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] = > Sent: donderdag 28 augustus 2008 11:44 > To: karagian@cs.utwente.nl > Cc: pcn@ietf.org > Subject: RE: [PCN] PCN WG last call for = > draft-ietf-pcn-architecture-05.txt > = > Georgios, > = > the hose model on an ingress node requires functionalities = > treating packets irrespective disregarding the destination = > address and the hose model applied to an egress node there = > require functionalities working on all packets disregarding = > their origin address. = > = > I've copied in two sections of draft westberg. The mechanisms = > mentioned there with regard to the hose model: > - are obviously not related to the hose model. > - are out of scope of the PCN WG. > = > I think the WG can go on now. > = > Regards, > = > Ruediger > = > = > = > Quotes from draft-westberg-pcn-load-control-04 > = > 3.1.2.2. PCN-egress-node features > = > [snip] > = > Note that if an edge-to-edge pair aggregated state is not available > at the PCN-egress-node, e.g., when the HOSE model is used then the > PCN-egress-node cannot determine whether a PCN-egress-node = > associated > with the edge-to-edge pair PCN aggregate operates in Normal state, > Admission Control state or Flow Termination state. = > However, even in > this case, when a probe packet arrives at the PCN-egress-node, then > this request should be rejected if the probe packet is PCN_marking > encoded. Otherwise, i.e., if the probe packet is not PCN_marking > encoded, it should be accepted. = > = > 3.2.2. PCN-egress-node > = > [snip] > = > Note that in the ingress-egress-aggregate model the excess rate and > the flows to be terminated are associated with the same = > edge-to-edge > (i.e., ingress-egress) pair PCN aggregate and with the same traffic > class, i.e., PHB. In the HOSE model the excess rate and = > the flows to > be terminated are associated with the same traffic class, = > i.e., PHB. > The PCN-egress-node needs to store for each flow the address, e.g., > IP address and port number, of the PCN-ingress-node from where the > particular flow passed before arriving to the = > PCN-egress-node. This > can be for example done by using information that is carried by the > external protocols used in combination with the LC-PCN = > solution. For > the flows that should be terminated the PCN-egress-node informs the > associated PCN-ingress-node to terminate them. If the PCN domain > uses thet ingress-egress-aggregate model and if the PCN-egress-node > receives any admission flow request, belonging to a ingress-egress- > aggregate state operating in flow termination state then = > the request > must be rejected. = > = > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On = > Behalf Of Georgios Karagiannis > Sent: Wednesday, August 27, 2008 12:37 PM > To: philip.eardley@bt.com; slblake@petri-meat.com > Cc: pcn@ietf.org > Subject: Re: [PCN] PCN WG last call for = > draft-ietf-pcn-architecture-05.txt > = > Hi Phil > = > HOSE model is defined some 20 years ago, please see e.g the following > article: > = > N. G. Duffield, P. Goyal and A. Greenberg, "A Flexible Model = > for Resource Management in Virtual Private Networks", in: > Proc. of ACM SIGCOMM, 1999. > = > In the above article I found the following definition: > = > "A hose is characterized by the aggregate traffic to and from = > one endpoint in the VPN to the set of other endpoints in the VPN" > = > Thus the definition refers to aggregated traffic to and from = > one edge to and from all other endpoints. > = > = > In our case we refer only to the aggregated traffic from = > other endpoints to one endpoint. > = > Thus what we use is in line with the definition of the HOSE model. > = > Best regards, > Georgios > = > = > = > = > > -----Original Message----- > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > Sent: woensdag 27 augustus 2008 11:31 > > To: karagian@cs.utwente.nl; slblake@petri-meat.com > > Cc: pcn@ietf.org > > Subject: RE: [PCN] PCN WG last call for = > > draft-ietf-pcn-architecture-05.txt > > = > > I thought your emails with steve had revealed that your = > model was the = > > exact opposite of the well known hose model? > > = > > = > > { -----Original Message----- > > { From: Georgios Karagiannis = > [mailto:karagian@cs.utwente.nl] { Sent: = > > 27 August 2008 09:41 { To: Eardley,PL,Philip,CXR9 R; = > > slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: > > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt > > { > > { Hi Phil > > { > > { What I explained is the well know HOSE bandwidth management model. > > { During the IETF in Dublin, Hein also shown also some = > results { that = > > were obtrained using the HOSE model. > > { > > { > > { Best regards, > > { Georgios > > { > > { > > { > -----Original Message----- > > { > From: philip.eardley@bt.com > > [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 augustus > > 2008 10:20 { > To: karagian@cs.utwente.nl; = > slblake@petri-meat.com { > = > > Cc: pcn@ietf.org { > Subject: RE: > > [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt > > { > > > { > So the question is about adding to the draft: > > { > A model where the egress measures marks coming from all the { > = > > ingresses, and makes admission decision based on that. > > { > > > { > Before adding anything about this to the draft, I'd like to { > = > > understand if this is a genuine practical, understood = > option { > (if = > > so, OK), or if it's a theoretical possibility or one not { > well = > > understood. > > { > (there are many things in the latter category that aren't { > = > > mentioned in the draft.) { > { > Questions are why this is = > > interesting, why is it better than { > the models already = > well-known, = > > are there comparative analysis { > /simulations? > > { > > > { > I suppose I've got 2 general issues: > > { > [1] every time something is added, overall the document = > { becomes = > > harder to understand, more daunting to read & it { > > looks less > like the WG has consensus. > > { > [2] this is an INFO doc. People are free to invent ways of { > = > > using the standards pieces other than the architecture = > draft { > says, = > > and indeed in ways not yet dreamt of. > > { > > > { > Phil. > > { > > > { > { -----Original Message----- > > { > { From: pcn-bounces@ietf.org > > [mailto:pcn-bounces@ietf.org] On { > Behalf Of { Georgios = > Karagiannis = > > { Sent: 27 August 2008 08:54 { > { To: 'Steven Blake' > > { > { Cc: pcn@ietf.org > > { > { Subject: Re: [PCN] PCN WG last call for { > = > > draft-ietf-pcn-architecture-05.txt > > { > { > > { > { Hi Steven > > { > { > > { > { > -----Original Message----- > > { > { > From: Steven Blake [mailto:slblake@petri-meat.com] { > > > { > Sent: woensdag 27 augustus 2008 6:18 { > To: Georgios { > > Karagiannis { > Cc: pcn@ietf.org { > Subject: RE: [PCN] PCN = > > { > WG = > > last > call for { > draft-ietf-pcn-architecture-05.txt > > { > { > > > { > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios = > Karagiannis wrote: > > { > { > > > { > { > > Hi Steven > > { > { > > > > { > { > > > > { > { > > Please see in line! > > { > { > > > > { > { > > > > { > { > > > -----Original Message----- { > { > > > From: = > Steven Blake = > > [mailto:slblake@petri-meat.com] { { > > > > Sent: dinsdag = > 26 augustus = > > 2008 14:46 { > > > To: > > { > Georgios Karagiannis { > > > Cc: pcn@ietf.org { > > > { > > > Subject: Re: [PCN] PCN WG last call for { > > > { > = > > draft-ietf-pcn-architecture-05.txt > > { > { > > > > > { > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios Karagiannis > > wrote: > > { > { > > > > > { > { > > > > Hi Phil, Hi all > > { > { > > > > > > { > { > > > > Here are some comments on the PCN architecture draft: > > { > { > > > > > > { > { > > > > 1) Thank you for clarifying the bullet in = > Setion { > 3.2 = > > about flow { > > > > termination. > > { > { > > > > > > { > { > > > > 2) From what I understand the PCN = > architecture { > draft = > > { > > > mentions that PCN { > > > > supports only the { > trunk = > > (ingress-egress-aggregate) and not the { > > > > > > HOSE model. > > { > { > > > > Is the PCN architecture draft excluding solutions { > = > > that { > support the { > > > > HOSE model? If not, please { > = > > emphasize in the PCN { > architecture draft { > > > > > that { > "solutions that are based on other types of = > > flow { > = > > > > > > > > { > aggregation than { > > > > the = > > ingress-egress-aggregate { > method of flow { > = > aggregation, are not { = > > > > > > excluded { > from the PCN WG activities." > > { > { > > > > > { > { > > > Actually they are, by our charter. > > { > { > > > > { > { > > I have not seen that the PCN charter excludes other { > = > > types { > of aggregation. > > { > { > > > { > { > Well, I checked, and you are correct (mea culpa). > > { > { Georgios: No problem > > { > { > > { > { > > > { > { > > Please note > > { > { > > that I am refering to the HOSE model where the = > traffic { > = > > sent { > by one or { > > more than one ingresses towards one { > = > > egress is aggregated at the { > > egress. In this way higgher { > = > > traffic aggregation can be accomplished { > > than in the { > = > > situation that the pipe/trunk { > > > (ingress-egress-aggregate) { > { > > is used, where the = > traffic sent = > > by only one ingress in { > aggegated at { > > the egress. > > { > { > > > { > { > Typically the "hose" model refers to = > point-to-multipoint { > { = > > > traffic flow, not multipoint-to-point. > > { > { Georgios: Typically yes, but in this case we refer to { = > > bandwidth allocation { in a multipoint-to-point fashion. > > { > { > > { > { > > > { > { > > > { > { > Regards, > > { > { > > > { > { > // Steve > > { > { > > > { > { > > { > { > > { > { _______________________________________________ > > { > { 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 Aug 28 04:21:16 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBFA03A6B30; Thu, 28 Aug 2008 04:21: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 34C393A6A71 for ; Thu, 28 Aug 2008 04:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mmGZ5U7o07t for ; Thu, 28 Aug 2008 04:21:14 -0700 (PDT) Received: from portland.eukhost.com (portland.eukhost.com [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 541533A6B30 for ; Thu, 28 Aug 2008 04:21:14 -0700 (PDT) Received: from c-69-255-67-45.hsd1.md.comcast.net ([69.255.67.45]:61232 helo=[192.168.1.120]) by portland.eukhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1KYfYu-0003EG-7U; Thu, 28 Aug 2008 11:21:12 +0000 Message-Id: <9D6855DD-2DAE-4BAA-A078-DC514D41B6C0@g11.org.uk> From: ken carlberg To: "Geib, Ruediger" In-Reply-To: <1B6169C658325341A3B8066E23919E1C01B11378@S4DE8PSAANK.mitte.t-com.de> Mime-Version: 1.0 (Apple Message framework v926) Date: Thu, 28 Aug 2008 07:21:10 -0400 References: <000501c90820$b1efaca0$810c5982@dynamic.ewi.utwente.nl><4A916DBC72536E419A0BD955EDECEDEC03DAA1C6@E03MVB1-UKBR.domain1.systemhost.net> <001c01c90830$dc8f96e0$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1C01B11310@S4DE8PSAANK.mitte.t-com.de> <001301c908fb$13807910$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1C01B11378@S4DE8PSAANK.mitte.t-com.de> X-Mailer: Apple Mail (2.926) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - portland.eukhost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - g11.org.uk Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 whoa. let's take a timeout and catch our breadths for a moment before = this starts to turn ugly. there has been a lengthy exchange on the = list and some of it appears to have now reached a point where folks = are talking past each other. with respect to the Hose model, I don't have a strong conviction abut = it one way or the other. Elements of what Georgios says grab my = attention, but the points being made seem to resemble a moving target, = so I don't become convinced about its inclusion into the Architecture = document as it stands right now. Perhaps a way to get beyond this = impasse is to tweak the Architecture document a bit so that it = acknowledges that other models (without mentioning the Hose model per = se) may be put forth and agreed upon in the future and leave it at = that. (Phil, if this tweaking already exists or has been done, then = great, sorry I missed it, and let's move on) -ken ps, its probably helpful to get some additional stronger guidance from = the Chairs and/or ADs at this point as well. On Aug 28, 2008, at 6:52 AM, Geib, Ruediger wrote: > Georgios, > > please argue like a sales representative with managers. > > But not with me on this list. > > Regards, > > Ruediger > > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: Thursday, August 28, 2008 12:45 PM > To: Geib, R=FCdiger > Cc: pcn@ietf.org > Subject: RE: [PCN] PCN WG last call for draft-ietf-pcn- = > architecture-05.txt > > Hi Ruediger > > As I shown in previous emails, the definition of the HOSE model = > covers an > wide area > and its interpretation depends on the context. > Thus the mentioned model can be seen as a HOSE model in the PCN = > context. > > As you could follow the discussion with Steven, this model is > not out of the PCN WG scope. > > Best regards, > Georgios > > > > >> -----Original Message----- >> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] >> Sent: donderdag 28 augustus 2008 11:44 >> To: karagian@cs.utwente.nl >> Cc: pcn@ietf.org >> Subject: RE: [PCN] PCN WG last call for >> draft-ietf-pcn-architecture-05.txt >> >> Georgios, >> >> the hose model on an ingress node requires functionalities >> treating packets irrespective disregarding the destination >> address and the hose model applied to an egress node there >> require functionalities working on all packets disregarding >> their origin address. >> >> I've copied in two sections of draft westberg. The mechanisms >> mentioned there with regard to the hose model: >> - are obviously not related to the hose model. >> - are out of scope of the PCN WG. >> >> I think the WG can go on now. >> >> Regards, >> >> Ruediger >> >> >> >> Quotes from draft-westberg-pcn-load-control-04 >> >> 3.1.2.2. PCN-egress-node features >> >> [snip] >> >> Note that if an edge-to-edge pair aggregated state is not available >> at the PCN-egress-node, e.g., when the HOSE model is used then the >> PCN-egress-node cannot determine whether a PCN-egress-node >> associated >> with the edge-to-edge pair PCN aggregate operates in Normal state, >> Admission Control state or Flow Termination state. >> However, even in >> this case, when a probe packet arrives at the PCN-egress-node, then >> this request should be rejected if the probe packet is PCN_marking >> encoded. Otherwise, i.e., if the probe packet is not PCN_marking >> encoded, it should be accepted. >> >> 3.2.2. PCN-egress-node >> >> [snip] >> >> Note that in the ingress-egress-aggregate model the excess rate and >> the flows to be terminated are associated with the same >> edge-to-edge >> (i.e., ingress-egress) pair PCN aggregate and with the same traffic >> class, i.e., PHB. In the HOSE model the excess rate and >> the flows to >> be terminated are associated with the same traffic class, >> i.e., PHB. >> The PCN-egress-node needs to store for each flow the address, e.g., >> IP address and port number, of the PCN-ingress-node from where the >> particular flow passed before arriving to the >> PCN-egress-node. This >> can be for example done by using information that is carried by the >> external protocols used in combination with the LC-PCN >> solution. For >> the flows that should be terminated the PCN-egress-node informs the >> associated PCN-ingress-node to terminate them. If the PCN domain >> uses thet ingress-egress-aggregate model and if the PCN-egress-node >> receives any admission flow request, belonging to a ingress-egress- >> aggregate state operating in flow termination state then >> the request >> must be rejected. >> >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On >> Behalf Of Georgios Karagiannis >> Sent: Wednesday, August 27, 2008 12:37 PM >> To: philip.eardley@bt.com; slblake@petri-meat.com >> Cc: pcn@ietf.org >> Subject: Re: [PCN] PCN WG last call for >> draft-ietf-pcn-architecture-05.txt >> >> Hi Phil >> >> HOSE model is defined some 20 years ago, please see e.g the following >> article: >> >> N. G. Duffield, P. Goyal and A. Greenberg, "A Flexible Model >> for Resource Management in Virtual Private Networks", in: >> Proc. of ACM SIGCOMM, 1999. >> >> In the above article I found the following definition: >> >> "A hose is characterized by the aggregate traffic to and from >> one endpoint in the VPN to the set of other endpoints in the VPN" >> >> Thus the definition refers to aggregated traffic to and from >> one edge to and from all other endpoints. >> >> >> In our case we refer only to the aggregated traffic from >> other endpoints to one endpoint. >> >> Thus what we use is in line with the definition of the HOSE model. >> >> Best regards, >> Georgios >> >> >> >> >>> -----Original Message----- >>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >>> Sent: woensdag 27 augustus 2008 11:31 >>> To: karagian@cs.utwente.nl; slblake@petri-meat.com >>> Cc: pcn@ietf.org >>> Subject: RE: [PCN] PCN WG last call for >>> draft-ietf-pcn-architecture-05.txt >>> >>> I thought your emails with steve had revealed that your >> model was the >>> exact opposite of the well known hose model? >>> >>> >>> { -----Original Message----- >>> { From: Georgios Karagiannis >> [mailto:karagian@cs.utwente.nl] { Sent: >>> 27 August 2008 09:41 { To: Eardley,PL,Philip,CXR9 R; >>> slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: >>> [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt >>> { >>> { Hi Phil >>> { >>> { What I explained is the well know HOSE bandwidth management model. >>> { During the IETF in Dublin, Hein also shown also some >> results { that >>> were obtrained using the HOSE model. >>> { >>> { >>> { Best regards, >>> { Georgios >>> { >>> { >>> { > -----Original Message----- >>> { > From: philip.eardley@bt.com >>> [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 augustus >>> 2008 10:20 { > To: karagian@cs.utwente.nl; >> slblake@petri-meat.com { > >>> Cc: pcn@ietf.org { > Subject: RE: >>> [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt >>> { > >>> { > So the question is about adding to the draft: >>> { > A model where the egress measures marks coming from all the { > >>> ingresses, and makes admission decision based on that. >>> { > >>> { > Before adding anything about this to the draft, I'd like to { > >>> understand if this is a genuine practical, understood >> option { > (if >>> so, OK), or if it's a theoretical possibility or one not { > well >>> understood. >>> { > (there are many things in the latter category that aren't { > >>> mentioned in the draft.) { > { > Questions are why this is >>> interesting, why is it better than { > the models already >> well-known, >>> are there comparative analysis { > /simulations? >>> { > >>> { > I suppose I've got 2 general issues: >>> { > [1] every time something is added, overall the document >> { becomes >>> harder to understand, more daunting to read & it { > > looks less >> like the WG has consensus. >>> { > [2] this is an INFO doc. People are free to invent ways of { > >>> using the standards pieces other than the architecture >> draft { > says, >>> and indeed in ways not yet dreamt of. >>> { > >>> { > Phil. >>> { > >>> { > { -----Original Message----- >>> { > { From: pcn-bounces@ietf.org >>> [mailto:pcn-bounces@ietf.org] On { > Behalf Of { Georgios >> Karagiannis >>> { Sent: 27 August 2008 08:54 { > { To: 'Steven Blake' >>> { > { Cc: pcn@ietf.org >>> { > { Subject: Re: [PCN] PCN WG last call for { > >>> draft-ietf-pcn-architecture-05.txt >>> { > { >>> { > { Hi Steven >>> { > { >>> { > { > -----Original Message----- >>> { > { > From: Steven Blake [mailto:slblake@petri-meat.com] { >>>> { > Sent: woensdag 27 augustus 2008 6:18 { > To: Georgios { >>> Karagiannis { > Cc: pcn@ietf.org { > Subject: RE: [PCN] PCN >>> { > WG >>> last >> call for { > draft-ietf-pcn-architecture-05.txt >>> { > { > >>> { > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios >> Karagiannis wrote: >>> { > { > >>> { > { > > Hi Steven >>> { > { > > >>> { > { > > >>> { > { > > Please see in line! >>> { > { > > >>> { > { > > >>> { > { > > > -----Original Message----- { > { > > > From: >> Steven Blake >>> [mailto:slblake@petri-meat.com] { { > > > > Sent: dinsdag >> 26 augustus >>> 2008 14:46 { > > > To: >>> { > Georgios Karagiannis { > > > Cc: pcn@ietf.org { > > > { > >>> Subject: Re: [PCN] PCN WG last call for { > > > { > >>> draft-ietf-pcn-architecture-05.txt >>> { > { > > > >>> { > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios Karagiannis >>> wrote: >>> { > { > > > >>> { > { > > > > Hi Phil, Hi all >>> { > { > > > > >>> { > { > > > > Here are some comments on the PCN architecture draft: >>> { > { > > > > >>> { > { > > > > 1) Thank you for clarifying the bullet in >> Setion { > 3.2 >>> about flow { > > > > termination. >>> { > { > > > > >>> { > { > > > > 2) From what I understand the PCN >> architecture { > draft >>> { > > > mentions that PCN { > > > > supports only the { > trunk >>> (ingress-egress-aggregate) and not the { > > > >>>> HOSE model. >>> { > { > > > > Is the PCN architecture draft excluding solutions { > >>> that { > support the { > > > > HOSE model? If not, please { > >>> emphasize in the PCN { > architecture draft { >>>>>> that { > "solutions that are based on other types of >>> flow { > >>>>>>>> >> { > aggregation than { > > > > the >>> ingress-egress-aggregate { > method of flow { > >> aggregation, are not { >>>>>>> excluded { > from the PCN WG activities." >>> { > { > > > >>> { > { > > > Actually they are, by our charter. >>> { > { > > >>> { > { > > I have not seen that the PCN charter excludes other { > >>> types { > of aggregation. >>> { > { > >>> { > { > Well, I checked, and you are correct (mea culpa). >>> { > { Georgios: No problem >>> { > { >>> { > { > >>> { > { > > Please note >>> { > { > > that I am refering to the HOSE model where the >> traffic { > >>> sent { > by one or { > > more than one ingresses towards one { > >>> egress is aggregated at the { > > egress. In this way higgher { > >>> traffic aggregation can be accomplished { > > than in the { > >>> situation that the pipe/trunk { > >>> (ingress-egress-aggregate) { > { > > is used, where the >> traffic sent >>> by only one ingress in { > aggegated at { > > the egress. >>> { > { > >>> { > { > Typically the "hose" model refers to >> point-to-multipoint { > { >>>> traffic flow, not multipoint-to-point. >>> { > { Georgios: Typically yes, but in this case we refer to { >>> bandwidth allocation { in a multipoint-to-point fashion. >>> { > { >>> { > { > >>> { > { > >>> { > { > Regards, >>> { > { > >>> { > { > // Steve >>> { > { > >>> { > { >>> { > { >>> { > { _______________________________________________ >>> { > { 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 Aug 28 04:30:32 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E334C3A6B90; Thu, 28 Aug 2008 04:30: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 7B27C3A6B90 for ; Thu, 28 Aug 2008 04:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.917 X-Spam-Level: X-Spam-Status: No, score=-0.917 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_57=0.6, 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 el02RFitQNm3 for ; Thu, 28 Aug 2008 04:30:24 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 748523A6975 for ; Thu, 28 Aug 2008 04:30:23 -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); Thu, 28 Aug 2008 12:30:24 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Aug 2008 12:30:23 +0100 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 121992302861; Thu, 28 Aug 2008 12:30:28 +0100 Received: from mut.jungle.bt.co.uk ([10.73.69.128]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m7SBULJA004422; Thu, 28 Aug 2008 12:30:21 +0100 Message-Id: <200808281130.m7SBULJA004422@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Aug 2008 12:30:20 +0100 To: From: Bob Briscoe In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA1CB@E03MVB1-UKBR.doma in1.systemhost.net> References: <002101c9083b$de8d88c0$810c5982@dynamic.ewi.utwente.nl> <4A916DBC72536E419A0BD955EDECEDEC03DAA1CB@E03MVB1-UKBR.domain1.systemhost.net> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 28 Aug 2008 11:30:23.0978 (UTC) FILETIME=[76382CA0:01C90901] Cc: pcn@ietf.org Subject: Re: [PCN] MP2P aggregates (was: PCN WG last call for draft-ietf-pcn-architecture-05.txt) 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've started a different thread on this, because I think there is general consensus that it is not relevant to the last call on the current PCN architecture. Bringing in a completely different architecture at the last minute requires another informational doc about that architecture, not holding up the current one. Here's why I say it's a completely different architecture... Using your multipoint-to-point (MP2P) (so-called 'hose') scenario and Phil's notation from earlier in the thread below, with traffic from b,c,d,e,f to A. b___X__________ c___________ \ \ \ d------------+---+--> A e___________/ / f______________/ - if there's high pre-congestion on link X just after traffic leaves b (say) - but traffic from c,d,e,f to A doesn't go through this pre-congested link - you claim A can average all the markings from b,c,d,e,f together, - giving an average for the MP2P aggregate lower than pre-congestion on b-A - then A could continue to tell any of b,c,d,e,f to accept new flows - then flows will still be added to a highly pre-congested path b-A If you have invented a way to solve this problem, it will involve discriminating between each of the ingress-egress paths within the MP2P aggregate (perhaps using affected marking). So you will need to store state for each path and you're no longer storing just a single state for the MP2P aggregate any more. In MPLS fora, the implications of allowing MP2P aggregates have caused years of arguments. We didn't include MP2P in the PCN architecture for a very good reason: you cannot create the assurances we're trying to create with MP2P aggregates. If you want an assured MP2P aggregate, you have to build it using a set of P2P (point-to-point) aggregates. We're doing other work on MP2P aggregates, but we're not bringing it to the PCN w-g. Please respect that the IETF has to limit the scope of each work item in order to achieve anything. Finally, if you've ever watered your garden with a hose that sucks the water off the grass back into the hose, then I will allow you to use the term hose for an MP2P aggregate. Until you can demonstrate this feat experimentally in your garden, please use words that mean what they say. Video footage running backwards will not be acceptable evidence. Bob At 13:03 27/08/2008, philip.eardley@bt.com wrote: >You appear to be saying all 3 definitions are the same. I think they're >all different. > >Let's call the gateway nodes A, B, C, D ,E and F. > >Duffield: hose at A is all traffic to b,c,d,e,f and all traffic from >b,c,d,e,f > >DiffServ: hose at A is all traffic to b,c,d,e,f > >Georgios: hose at A is all traffic from b,c,d,e,f > >{ -----Original Message----- >{ From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >{ Sent: 27 August 2008 12:56 >{ To: Eardley,PL,Philip,CXR9 R; slblake@petri-meat.com >{ Cc: pcn@ietf.org >{ Subject: RE: [PCN] PCN WG last call for >draft-ietf-pcn-architecture-05.txt >{ >{ Hi Phil >{ >{ Assuming that ingresses can only send data traffic and egresses can >{ receive >{ data traffic, >{ a HOSE model that is used in the PCN domain between ingress nodes and >{ egress >{ edge nodes, >{ is refering to aggregates between ingress and egress edge nodes, where >{ ingresses are >{ sending traffic and egresses are receiving data traffic. >{ >{ Thus the HOSE aggregation model used in PCN is a HOSE aggregation >model >{ used between ingress and egress nodes. >{ >{ >{ Best regards, >{ Georgios >{ >{ > -----Original Message----- >{ > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >{ > Sent: woensdag 27 augustus 2008 13:35 >{ > To: karagian@cs.utwente.nl; slblake@petri-meat.com >{ > Cc: pcn@ietf.org >{ > Subject: RE: [PCN] PCN WG last call for >{ > draft-ietf-pcn-architecture-05.txt >{ > >{ > I note that the Duffield et al definition below is different >{ > from what your talking about, since their definition includes >{ > traffic in both directions, whilst yours is a one way >{ > definition. I think other people, with a DiffServ >{ > architecture background, would interpret it as traffic from >{ > one ingress going to any egress. So that's 3 possibilities. >{ > >{ > In any case, this is really a side issue, compared with my >{ > main points /questions in earlier email. >{ > >{ > { -----Original Message----- >{ > { From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] >{ > { Sent: 27 August 2008 11:37 { To: Eardley,PL,Philip,CXR9 R; >{ > slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: >{ > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt >{ > { >{ > { Hi Phil >{ > { >{ > { HOSE model is defined some 20 years ago, please see e.g the >{ > following { article: >{ > { >{ > { N. G. Duffield, P. Goyal and A. Greenberg, "A Flexible >{ > Model { for Resource Management in Virtual Private Networks", in: >{ > { Proc. of ACM SIGCOMM, 1999. >{ > { >{ > { In the above article I found the following definition: >{ > { >{ > { "A hose is characterized by the aggregate traffic { to and >{ > from one endpoint in the VPN to the set of other { endpoints >{ > in the VPN" >{ > { >{ > { Thus the definition refers to aggregated traffic to and >{ > from one edge to { and { from all other endpoints. >{ > { >{ > { >{ > { In our case we refer only to the aggregated traffic from >{ > other endpoints { to { one endpoint. >{ > { >{ > { Thus what we use is in line with the definition of the HOSE model. >{ > { >{ > { Best regards, >{ > { Georgios >{ > { >{ > { >{ > { >{ > { >{ > { > -----Original Message----- >{ > { > From: philip.eardley@bt.com >{ > [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 augustus >{ > 2008 11:31 { > To: karagian@cs.utwente.nl; >{ > slblake@petri-meat.com { > Cc: pcn@ietf.org { > Subject: RE: >{ > [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt >{ > { > >{ > { > I thought your emails with steve had revealed that your >{ > model { > was the exact opposite of the well known hose model? >{ > { > >{ > { > >{ > { > { -----Original Message----- >{ > { > { From: Georgios Karagiannis >{ > [mailto:karagian@cs.utwente.nl] { > { Sent: 27 August 2008 >{ > 09:41 { To: Eardley,PL,Philip,CXR9 R; { > >{ > slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: >{ > { > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt >{ > { > { >{ > { > { Hi Phil >{ > { > { >{ > { > { What I explained is the well know HOSE bandwidth >{ > management model. >{ > { > { During the IETF in Dublin, Hein also shown also some { >{ > > results { that were obtrained using the HOSE model. >{ > { > { >{ > { > { >{ > { > { Best regards, >{ > { > { Georgios >{ > { > { >{ > { > { >{ > { > { > -----Original Message----- >{ > { > { > From: philip.eardley@bt.com >{ > { > [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 >{ > augustus { > 2008 10:20 { > To: karagian@cs.utwente.nl; { > >{ > slblake@petri-meat.com { > Cc: pcn@ietf.org { > Subject: RE: >{ > { > [PCN] PCN WG last call for { > >draft-ietf-pcn-architecture-05.txt >{ > { > { > >{ > { > { > So the question is about adding to the draft: >{ > { > { > A model where the egress measures marks coming from >{ > all { > the { > ingresses, and makes admission decision based on >that. >{ > { > { > >{ > { > { > Before adding anything about this to the draft, I'd >{ > like { > to { > understand if this is a genuine practical, >{ > understood { > option { > (if so, OK), or if it's a >{ > theoretical possibility { > or one not { > well understood. >{ > { > { > (there are many things in the latter category that >{ > aren't { > { > mentioned in the draft.) { > { > Questions are >{ > why this { > is interesting, why is it better than { > the >{ > models already { > well-known, are there comparative analysis >{ > { > /simulations? >{ > { > { > >{ > { > { > I suppose I've got 2 general issues: >{ > { > { > [1] every time something is added, overall the >{ > document { { > becomes harder to understand, more daunting to >{ > read & it { > > looks { less { like the WG has consensus. >{ > { > { > [2] this is an INFO doc. People are free to invent >{ > ways { > of { > using the standards pieces other than the >{ > architecture { > draft { > says, and indeed in ways not yet dreamt >of. >{ > { > { > >{ > { > { > Phil. >{ > { > { > >{ > { > { > { -----Original Message----- >{ > { > { > { From: pcn-bounces@ietf.org >{ > { > [mailto:pcn-bounces@ietf.org] On { > Behalf Of { Georgios >{ > { > Karagiannis { Sent: 27 August 2008 08:54 { > { To: 'Steven >Blake' >{ > { > { > { Cc: pcn@ietf.org >{ > { > { > { Subject: Re: [PCN] PCN WG last call for { > { > >{ > draft-ietf-pcn-architecture-05.txt >{ > { > { > { >{ > { > { > { Hi Steven >{ > { > { > { >{ > { > { > { > -----Original Message----- >{ > { > { > { > From: Steven Blake >{ > [mailto:slblake@petri-meat.com] { { > > { > Sent: woensdag 27 >{ > augustus 2008 6:18 { > To: Georgios { { > Karagiannis { > Cc: >{ > pcn@ietf.org { > Subject: RE: [PCN] PCN > { > WG { last { >{ > call for { > draft-ietf-pcn-architecture-05.txt >{ > { > { > { > >{ > { > { > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios Karagiannis >{ > wrote: >{ > { > { > { > >{ > { > { > { > > Hi Steven >{ > { > { > { > > >{ > { > { > { > > >{ > { > { > { > > Please see in line! >{ > { > { > { > > >{ > { > { > { > > >{ > { > { > { > > > -----Original Message----- { > { > { > > > >{ > From: Steven Blake { > [mailto:slblake@petri-meat.com] { { > >{ > > > > Sent: dinsdag 26 { > augustus 2008 14:46 { > > > To: >{ > { > { > Georgios Karagiannis { > > > Cc: pcn@ietf.org { > > > >{ > { > { > Subject: Re: [PCN] PCN WG last call for { > > > { > { >{ > draft-ietf-pcn-architecture-05.txt >{ > { > { > { > > > >{ > { > { > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios >{ > Karagiannis { > wrote: >{ > { > { > { > > > >{ > { > { > { > > > > Hi Phil, Hi all >{ > { > { > { > > > > >{ > { > { > { > > > > Here are some comments on the PCN >{ > architecture draft: >{ > { > { > { > > > > >{ > { > { > { > > > > 1) Thank you for clarifying the bullet in { >{ > Setion { > 3.2 about flow { > > > > termination. >{ > { > { > { > > > > >{ > { > { > { > > > > 2) From what I understand the PCN >{ > architecture { > { > draft { > > > mentions that PCN { > > > >{ > > supports only { > the { > trunk (ingress-egress-aggregate) >{ > and not the { > > > { > > HOSE model. >{ > { > { > { > > > > Is the PCN architecture draft excluding { > >{ > solutions { > that { > support the { > > > > HOSE model? If { >{ > not, please { > emphasize in the PCN { > architecture draft { > { > > > > >{ > >{ that { > "solutions that are based on other types >{ > of > flow { >{ > > > >{ > { > >{ > { { > aggregation than { > > > > the >{ > { > ingress-egress-aggregate { > method of flow { > >{ > aggregation, { > are not { > > > > excluded { > from the PCN >{ > WG activities." >{ > { > { > { > > > >{ > { > { > { > > > Actually they are, by our charter. >{ > { > { > { > > >{ > { > { > { > > I have not seen that the PCN charter excludes >{ > other { > { > types { > of aggregation. >{ > { > { > { > >{ > { > { > { > Well, I checked, and you are correct (mea culpa). >{ > { > { > { Georgios: No problem >{ > { > { > { >{ > { > { > { > >{ > { > { > { > > Please note >{ > { > { > { > > that I am refering to the HOSE model where the >{ > { > traffic { > sent { > by one or { > > more than one >{ > ingresses { > towards one { > egress is aggregated at the { > >{ > > egress. In { > this way higgher { > traffic aggregation can >{ > be accomplished { > { > > than in the { > situation that the >{ > pipe/trunk { > { > (ingress-egress-aggregate) { > { > > is >{ > used, where the { > traffic sent by only one ingress in { > >{ > aggegated at { > > the egress. >{ > { > { > { > >{ > { > { > { > Typically the "hose" model refers to { > >{ > point-to-multipoint { > { > traffic flow, not multipoint-to-point. >{ > { > { > { Georgios: Typically yes, but in this case we refer >{ > to { { > bandwidth allocation { in a multipoint-to-point fashion. >{ > { > { > { >{ > { > { > { > >{ > { > { > { > >{ > { > { > { > Regards, >{ > { > { > { > >{ > { > { > { > // Steve >{ > { > { > { > >{ > { > { > { >{ > { > { > { >{ > { > { > { _______________________________________________ >{ > { > { > { 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 ____________________________________________________________________________ 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 Aug 28 04:46:47 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14EC53A6975; Thu, 28 Aug 2008 04:46: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 AF4B93A6B1E for ; Thu, 28 Aug 2008 04:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.339 X-Spam-Level: X-Spam-Status: No, score=0.339 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZp6PgbOkgl3 for ; Thu, 28 Aug 2008 04:46: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 675413A6975 for ; Thu, 28 Aug 2008 04:46: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 m7SBkASm001808; Thu, 28 Aug 2008 13:46:14 +0200 (MEST) From: "Georgios Karagiannis" To: "'ken carlberg'" , "'Geib, Ruediger'" References: <000501c90820$b1efaca0$810c5982@dynamic.ewi.utwente.nl><4A916DBC72536E419A0BD955EDECEDEC03DAA1C6@E03MVB1-UKBR.domain1.systemhost.net> <001c01c90830$dc8f96e0$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1C01B11310@S4DE8PSAANK.mitte.t-com.de> <001301c908fb$13807910$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1C01B11378@S4DE8PSAANK.mitte.t-com.de> <9D6855DD-2DAE-4BAA-A078-DC514D41B6C0@g11.org.uk> Date: Thu, 28 Aug 2008 13:46:06 +0200 Message-ID: <001c01c90903$aad2e6b0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <9D6855DD-2DAE-4BAA-A078-DC514D41B6C0@g11.org.uk> Thread-Index: AckJADMsmFe74QwwQ3KkX/oH11/AcgAA0hmw 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, 28 Aug 2008 13:46:15 +0200 (MEST) Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 Ken I agree with your proposal! = > Perhaps a way to get beyond this impasse = > is to tweak the Architecture document a bit so that it = > acknowledges that other models (without mentioning the Hose model per > se) may be put forth and agreed upon in the future and leave = > it at that. Best regards, Georgios > -----Original Message----- > From: ken carlberg [mailto:carlberg@g11.org.uk] = > Sent: donderdag 28 augustus 2008 13:21 > To: Geib, Ruediger > Cc: karagian@cs.utwente.nl; pcn@ietf.org > Subject: Re: [PCN] PCN WG last call for = > draft-ietf-pcn-architecture-05.txt > = > whoa. let's take a timeout and catch our breadths for a = > moment before this starts to turn ugly. there has been a = > lengthy exchange on the list and some of it appears to have = > now reached a point where folks are talking past each other. > = > with respect to the Hose model, I don't have a strong = > conviction abut it one way or the other. Elements of what = > Georgios says grab my attention, but the points being made = > seem to resemble a moving target, so I don't become convinced = > about its inclusion into the Architecture document as it = > stands right now. Perhaps a way to get beyond this impasse = > is to tweak the Architecture document a bit so that it = > acknowledges that other models (without mentioning the Hose model per > se) may be put forth and agreed upon in the future and leave = > it at that. (Phil, if this tweaking already exists or has = > been done, then great, sorry I missed it, and let's move on) > = > -ken > = > ps, its probably helpful to get some additional stronger = > guidance from the Chairs and/or ADs at this point as well. > = > = > On Aug 28, 2008, at 6:52 AM, Geib, Ruediger wrote: > = > > Georgios, > > > > please argue like a sales representative with managers. > > > > But not with me on this list. > > > > Regards, > > > > Ruediger > > > > -----Original Message----- > > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > Sent: Thursday, August 28, 2008 12:45 PM > > To: Geib, R=FCdiger > > Cc: pcn@ietf.org > > Subject: RE: [PCN] PCN WG last call for draft-ietf-pcn- = > > architecture-05.txt > > > > Hi Ruediger > > > > As I shown in previous emails, the definition of the HOSE = > model covers = > > an wide area and its interpretation depends on the context. > > Thus the mentioned model can be seen as a HOSE model in the PCN = > > context. > > > > As you could follow the discussion with Steven, this model = > is not out = > > of the PCN WG scope. > > > > Best regards, > > Georgios > > > > > > > > > >> -----Original Message----- > >> From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > >> Sent: donderdag 28 augustus 2008 11:44 > >> To: karagian@cs.utwente.nl > >> Cc: pcn@ietf.org > >> Subject: RE: [PCN] PCN WG last call for = > >> draft-ietf-pcn-architecture-05.txt > >> > >> Georgios, > >> > >> the hose model on an ingress node requires functionalities = > treating = > >> packets irrespective disregarding the destination address and the = > >> hose model applied to an egress node there require functionalities = > >> working on all packets disregarding their origin address. > >> > >> I've copied in two sections of draft westberg. The mechanisms = > >> mentioned there with regard to the hose model: > >> - are obviously not related to the hose model. > >> - are out of scope of the PCN WG. > >> > >> I think the WG can go on now. > >> > >> Regards, > >> > >> Ruediger > >> > >> > >> > >> Quotes from draft-westberg-pcn-load-control-04 > >> > >> 3.1.2.2. PCN-egress-node features > >> > >> [snip] > >> > >> Note that if an edge-to-edge pair aggregated state is = > not available > >> at the PCN-egress-node, e.g., when the HOSE model is = > used then the > >> PCN-egress-node cannot determine whether a PCN-egress-node = > >> associated > >> with the edge-to-edge pair PCN aggregate operates in = > Normal state, > >> Admission Control state or Flow Termination state. > >> However, even in > >> this case, when a probe packet arrives at the = > PCN-egress-node, then > >> this request should be rejected if the probe packet is = > PCN_marking > >> encoded. Otherwise, i.e., if the probe packet is not PCN_marking > >> encoded, it should be accepted. > >> > >> 3.2.2. PCN-egress-node > >> > >> [snip] > >> > >> Note that in the ingress-egress-aggregate model the = > excess rate and > >> the flows to be terminated are associated with the same = > >> edge-to-edge > >> (i.e., ingress-egress) pair PCN aggregate and with the = > same traffic > >> class, i.e., PHB. In the HOSE model the excess rate and = > the flows = > >> to > >> be terminated are associated with the same traffic class, i.e., = > >> PHB. > >> The PCN-egress-node needs to store for each flow the = > address, e.g., > >> IP address and port number, of the PCN-ingress-node from = > where the > >> particular flow passed before arriving to the PCN-egress-node. = > >> This > >> can be for example done by using information that is = > carried by the > >> external protocols used in combination with the LC-PCN = > solution. = > >> For > >> the flows that should be terminated the PCN-egress-node = > informs the > >> associated PCN-ingress-node to terminate them. If the PCN domain > >> uses thet ingress-egress-aggregate model and if the = > PCN-egress-node > >> receives any admission flow request, belonging to a = > ingress-egress- > >> aggregate state operating in flow termination state then the = > >> request > >> must be rejected. > >> > >> -----Original Message----- > >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] = > On Behalf Of = > >> Georgios Karagiannis > >> Sent: Wednesday, August 27, 2008 12:37 PM > >> To: philip.eardley@bt.com; slblake@petri-meat.com > >> Cc: pcn@ietf.org > >> Subject: Re: [PCN] PCN WG last call for = > >> draft-ietf-pcn-architecture-05.txt > >> > >> Hi Phil > >> > >> HOSE model is defined some 20 years ago, please see e.g = > the following > >> article: > >> > >> N. G. Duffield, P. Goyal and A. Greenberg, "A Flexible Model for = > >> Resource Management in Virtual Private Networks", in: > >> Proc. of ACM SIGCOMM, 1999. > >> > >> In the above article I found the following definition: > >> > >> "A hose is characterized by the aggregate traffic to and from one = > >> endpoint in the VPN to the set of other endpoints in the VPN" > >> > >> Thus the definition refers to aggregated traffic to and = > from one edge = > >> to and from all other endpoints. > >> > >> > >> In our case we refer only to the aggregated traffic from other = > >> endpoints to one endpoint. > >> > >> Thus what we use is in line with the definition of the HOSE model. > >> > >> Best regards, > >> Georgios > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > >>> Sent: woensdag 27 augustus 2008 11:31 > >>> To: karagian@cs.utwente.nl; slblake@petri-meat.com > >>> Cc: pcn@ietf.org > >>> Subject: RE: [PCN] PCN WG last call for = > >>> draft-ietf-pcn-architecture-05.txt > >>> > >>> I thought your emails with steve had revealed that your > >> model was the > >>> exact opposite of the well known hose model? > >>> > >>> > >>> { -----Original Message----- > >>> { From: Georgios Karagiannis > >> [mailto:karagian@cs.utwente.nl] { Sent: > >>> 27 August 2008 09:41 { To: Eardley,PL,Philip,CXR9 R; = > >>> slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: > >>> [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt > >>> { > >>> { Hi Phil > >>> { > >>> { What I explained is the well know HOSE bandwidth = > management model. > >>> { During the IETF in Dublin, Hein also shown also some > >> results { that > >>> were obtrained using the HOSE model. > >>> { > >>> { > >>> { Best regards, > >>> { Georgios > >>> { > >>> { > >>> { > -----Original Message----- > >>> { > From: philip.eardley@bt.com > >>> [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 augustus > >>> 2008 10:20 { > To: karagian@cs.utwente.nl; > >> slblake@petri-meat.com { > > >>> Cc: pcn@ietf.org { > Subject: RE: > >>> [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt > >>> { > > >>> { > So the question is about adding to the draft: > >>> { > A model where the egress measures marks coming from = > all the { > = > >>> ingresses, and makes admission decision based on that. > >>> { > > >>> { > Before adding anything about this to the draft, I'd = > like to { > = > >>> understand if this is a genuine practical, understood > >> option { > (if > >>> so, OK), or if it's a theoretical possibility or one not { > well = > >>> understood. > >>> { > (there are many things in the latter category that aren't { > = > >>> mentioned in the draft.) { > { > Questions are why this is = > >>> interesting, why is it better than { > the models already > >> well-known, > >>> are there comparative analysis { > /simulations? > >>> { > > >>> { > I suppose I've got 2 general issues: > >>> { > [1] every time something is added, overall the document > >> { becomes > >>> harder to understand, more daunting to read & it { > > looks less > >> like the WG has consensus. > >>> { > [2] this is an INFO doc. People are free to invent = > ways of { > = > >>> using the standards pieces other than the architecture > >> draft { > says, > >>> and indeed in ways not yet dreamt of. > >>> { > > >>> { > Phil. > >>> { > > >>> { > { -----Original Message----- > >>> { > { From: pcn-bounces@ietf.org > >>> [mailto:pcn-bounces@ietf.org] On { > Behalf Of { Georgios > >> Karagiannis > >>> { Sent: 27 August 2008 08:54 { > { To: 'Steven Blake' > >>> { > { Cc: pcn@ietf.org > >>> { > { Subject: Re: [PCN] PCN WG last call for { > = > >>> draft-ietf-pcn-architecture-05.txt > >>> { > { > >>> { > { Hi Steven > >>> { > { > >>> { > { > -----Original Message----- > >>> { > { > From: Steven Blake [mailto:slblake@petri-meat.com] { > >>>> { > Sent: woensdag 27 augustus 2008 6:18 { > To: Georgios { > >>> Karagiannis { > Cc: pcn@ietf.org { > Subject: RE: [PCN] = > PCN { > WG = > >>> last > >> call for { > draft-ietf-pcn-architecture-05.txt > >>> { > { > > >>> { > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios > >> Karagiannis wrote: > >>> { > { > > >>> { > { > > Hi Steven > >>> { > { > > > >>> { > { > > > >>> { > { > > Please see in line! > >>> { > { > > > >>> { > { > > > >>> { > { > > > -----Original Message----- { > { > > > From: > >> Steven Blake > >>> [mailto:slblake@petri-meat.com] { { > > > > Sent: dinsdag > >> 26 augustus > >>> 2008 14:46 { > > > To: > >>> { > Georgios Karagiannis { > > > Cc: pcn@ietf.org { > > > { > > >>> Subject: Re: [PCN] PCN WG last call for { > > > { > = > >>> draft-ietf-pcn-architecture-05.txt > >>> { > { > > > > >>> { > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios = > Karagiannis > >>> wrote: > >>> { > { > > > > >>> { > { > > > > Hi Phil, Hi all > >>> { > { > > > > > >>> { > { > > > > Here are some comments on the PCN = > architecture draft: > >>> { > { > > > > > >>> { > { > > > > 1) Thank you for clarifying the bullet in > >> Setion { > 3.2 > >>> about flow { > > > > termination. > >>> { > { > > > > > >>> { > { > > > > 2) From what I understand the PCN > >> architecture { > draft > >>> { > > > mentions that PCN { > > > > supports only the { > trunk > >>> (ingress-egress-aggregate) and not the { > > > > >>>> HOSE model. > >>> { > { > > > > Is the PCN architecture draft excluding = > solutions { > = > >>> that { > support the { > > > > HOSE model? If not, please { > = > >>> emphasize in the PCN { > architecture draft { > >>>>>> that { > "solutions that are based on other types of > >>> flow { > > >>>>>>>> > >> { > aggregation than { > > > > the > >>> ingress-egress-aggregate { > method of flow { > > >> aggregation, are not { > >>>>>>> excluded { > from the PCN WG activities." > >>> { > { > > > > >>> { > { > > > Actually they are, by our charter. > >>> { > { > > > >>> { > { > > I have not seen that the PCN charter excludes other { > = > >>> types { > of aggregation. > >>> { > { > > >>> { > { > Well, I checked, and you are correct (mea culpa). > >>> { > { Georgios: No problem > >>> { > { > >>> { > { > > >>> { > { > > Please note > >>> { > { > > that I am refering to the HOSE model where the > >> traffic { > > >>> sent { > by one or { > > more than one ingresses towards one { > = > >>> egress is aggregated at the { > > egress. In this way higgher { > = > >>> traffic aggregation can be accomplished { > > than in the { > = > >>> situation that the pipe/trunk { > > >>> (ingress-egress-aggregate) { > { > > is used, where the > >> traffic sent > >>> by only one ingress in { > aggegated at { > > the egress. > >>> { > { > > >>> { > { > Typically the "hose" model refers to > >> point-to-multipoint { > { > >>>> traffic flow, not multipoint-to-point. > >>> { > { Georgios: Typically yes, but in this case we refer to { = > >>> bandwidth allocation { in a multipoint-to-point fashion. > >>> { > { > >>> { > { > > >>> { > { > > >>> { > { > Regards, > >>> { > { > > >>> { > { > // Steve > >>> { > { > > >>> { > { > >>> { > { > >>> { > { _______________________________________________ > >>> { > { 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 Aug 28 05:15:33 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA04D3A6B2E; Thu, 28 Aug 2008 05:15: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 3D9243A6975 for ; Thu, 28 Aug 2008 05:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.37 X-Spam-Level: * X-Spam-Status: No, score=1.37 tagged_above=-999 required=5 tests=[AWL=-0.815, BAYES_05=-1.11, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_57=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iZHUVvpgdnz for ; Thu, 28 Aug 2008 05:15: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 AEF3D3A69C9 for ; Thu, 28 Aug 2008 05:15: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 m7SCEiFc007358; Thu, 28 Aug 2008 14:14:49 +0200 (MEST) From: "Georgios Karagiannis" To: "'Bob Briscoe'" References: <002101c9083b$de8d88c0$810c5982@dynamic.ewi.utwente.nl> <4A916DBC72536E419A0BD955EDECEDEC03DAA1CB@E03MVB1-UKBR.domain1.systemhost.net> <200808281130.m7SBULJA004422@bagheera.jungle.bt.co.uk> Date: Thu, 28 Aug 2008 14:14:39 +0200 Message-ID: <001d01c90907$a91beb10$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <200808281130.m7SBULJA004422@bagheera.jungle.bt.co.uk> Thread-Index: AckJBjbDMZhvGXSuTV+S92tyVhisuQAAFqyQ 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, 28 Aug 2008 14:14:51 +0200 (MEST) Cc: pcn@ietf.org Subject: Re: [PCN] MP2P aggregates (was: PCN WG last call for draft-ietf-pcn-architecture-05.txt) 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 I do not want to hold the publication of the architecture draft. I will be happy if, related to this issue, the sentence proposed by Ken in the previous email is used. Regarding one of your comments: > If you want an assured MP2P aggregate, you have to build it > using a set of P2P > (point-to-point) aggregates. Georgios: using a set of P2P aggregates to achieve this is not required. The MP2P aggregation is solved by using affected marking and just using one state. Please also note that at the same time this solution solves the ecmp problem. Best regards, Georgios > -----Original Message----- > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > Sent: donderdag 28 augustus 2008 13:30 > To: karagian@cs.utwente.nl > Cc: philip.eardley@bt.com; slblake@petri-meat.com; pcn@ietf.org > Subject: Re: MP2P aggregates (was: [PCN] PCN WG last call for > draft-ietf-pcn-architecture-05.txt) > > Georgios, > > I've started a different thread on this, because I think > there is general consensus that it is not relevant to the > last call on the current PCN architecture. > > Bringing in a completely different architecture at the last > minute requires another informational doc about that > architecture, not holding up the current one. Here's why I > say it's a completely different architecture... > > Using your multipoint-to-point (MP2P) (so-called 'hose') > scenario and Phil's notation from earlier in the thread > below, with traffic from b,c,d,e,f to A. > > b___X__________ > c___________ \ > \ \ > d------------+---+--> A > e___________/ / > f______________/ > > - if there's high pre-congestion on link X just after traffic > leaves b (say) > - but traffic from c,d,e,f to A doesn't go through this > pre-congested link > - you claim A can average all the markings from b,c,d,e,f together, > - giving an average for the MP2P aggregate lower than > pre-congestion on b-A > - then A could continue to tell any of b,c,d,e,f to accept new flows > - then flows will still be added to a highly pre-congested path b-A > > If you have invented a way to solve this problem, it will > involve discriminating between each of the ingress-egress > paths within the MP2P aggregate (perhaps using affected > marking). So you will need to store state for each path and > you're no longer storing just a single state for the MP2P > aggregate any more. > > In MPLS fora, the implications of allowing MP2P aggregates > have caused years of arguments. We didn't include MP2P in the > PCN architecture for a very good reason: you cannot create > the assurances we're trying to create with MP2P aggregates. > If you want an assured MP2P aggregate, you have to build it > using a set of P2P > (point-to-point) aggregates. > > We're doing other work on MP2P aggregates, but we're not > bringing it to the PCN w-g. Please respect that the IETF has > to limit the scope of each work item in order to achieve anything. > > Finally, if you've ever watered your garden with a hose that > sucks the water off the grass back into the hose, then I will > allow you to use the term hose for an MP2P aggregate. Until > you can demonstrate this feat experimentally in your garden, > please use words that mean what they say. Video footage > running backwards will not be acceptable evidence. > > > Bob > > At 13:03 27/08/2008, philip.eardley@bt.com wrote: > >You appear to be saying all 3 definitions are the same. I > think they're > >all different. > > > >Let's call the gateway nodes A, B, C, D ,E and F. > > > >Duffield: hose at A is all traffic to b,c,d,e,f and all traffic from > >b,c,d,e,f > > > >DiffServ: hose at A is all traffic to b,c,d,e,f > > > >Georgios: hose at A is all traffic from b,c,d,e,f > > > >{ -----Original Message----- > >{ From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > { Sent: 27 > >August 2008 12:56 { To: Eardley,PL,Philip,CXR9 R; > >slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: > [PCN] PCN WG > >last call for draft-ietf-pcn-architecture-05.txt > >{ > >{ Hi Phil > >{ > >{ Assuming that ingresses can only send data traffic and > egresses can { > >receive { data traffic, { a HOSE model that is used in the > PCN domain > >between ingress nodes and { egress { edge nodes, { is refering to > >aggregates between ingress and egress edge nodes, where { > ingresses are > >{ sending traffic and egresses are receiving data traffic. > >{ > >{ Thus the HOSE aggregation model used in PCN is a HOSE aggregation > >model { used between ingress and egress nodes. > >{ > >{ > >{ Best regards, > >{ Georgios > >{ > >{ > -----Original Message----- > >{ > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] { > > >Sent: woensdag 27 augustus 2008 13:35 { > To: > karagian@cs.utwente.nl; > >slblake@petri-meat.com { > Cc: pcn@ietf.org { > Subject: RE: > [PCN] PCN > >WG last call for { > draft-ietf-pcn-architecture-05.txt > >{ > > >{ > I note that the Duffield et al definition below is different { > > >from what your talking about, since their definition includes { > > >traffic in both directions, whilst yours is a one way { > > definition. I > >think other people, with a DiffServ { > architecture > background, would > >interpret it as traffic from { > one ingress going to any egress. So > >that's 3 possibilities. > >{ > > >{ > In any case, this is really a side issue, compared with > my { > main > >points /questions in earlier email. > >{ > > >{ > { -----Original Message----- > >{ > { From: Georgios Karagiannis > [mailto:karagian@cs.utwente.nl] { > { > >Sent: 27 August 2008 11:37 { To: Eardley,PL,Philip,CXR9 R; { > > >slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: > >{ > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt > >{ > { > >{ > { Hi Phil > >{ > { > >{ > { HOSE model is defined some 20 years ago, please see > e.g the { > > >following { article: > >{ > { > >{ > { N. G. Duffield, P. Goyal and A. Greenberg, "A Flexible > { > Model > >{ for Resource Management in Virtual Private Networks", in: > >{ > { Proc. of ACM SIGCOMM, 1999. > >{ > { > >{ > { In the above article I found the following definition: > >{ > { > >{ > { "A hose is characterized by the aggregate traffic { to and { > > >from one endpoint in the VPN to the set of other { endpoints > { > in the > >VPN" > >{ > { > >{ > { Thus the definition refers to aggregated traffic to > and { > from > >one edge to { and { from all other endpoints. > >{ > { > >{ > { > >{ > { In our case we refer only to the aggregated traffic from { > > >other endpoints { to { one endpoint. > >{ > { > >{ > { Thus what we use is in line with the definition of the > HOSE model. > >{ > { > >{ > { Best regards, > >{ > { Georgios > >{ > { > >{ > { > >{ > { > >{ > { > >{ > { > -----Original Message----- > >{ > { > From: philip.eardley@bt.com > >{ > [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 > augustus { > > >2008 11:31 { > To: karagian@cs.utwente.nl; { > > slblake@petri-meat.com { > >> Cc: pcn@ietf.org { > Subject: RE: > >{ > [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt > >{ > { > > >{ > { > I thought your emails with steve had revealed that your { > > >model { > was the exact opposite of the well known hose model? > >{ > { > > >{ > { > > >{ > { > { -----Original Message----- > >{ > { > { From: Georgios Karagiannis > >{ > [mailto:karagian@cs.utwente.nl] { > { Sent: 27 August 2008 { > > >09:41 { To: Eardley,PL,Philip,CXR9 R; { > { > > slblake@petri-meat.com { > >Cc: pcn@ietf.org { Subject: RE: > >{ > { > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt > >{ > { > { > >{ > { > { Hi Phil > >{ > { > { > >{ > { > { What I explained is the well know HOSE bandwidth { > > >management model. > >{ > { > { During the IETF in Dublin, Hein also shown also > some { { > > > >results { that were obtrained using the HOSE model. > >{ > { > { > >{ > { > { > >{ > { > { Best regards, > >{ > { > { Georgios > >{ > { > { > >{ > { > { > >{ > { > { > -----Original Message----- > >{ > { > { > From: philip.eardley@bt.com { > { > > >[mailto:philip.eardley@bt.com] { > Sent: woensdag 27 { > > augustus { > > >2008 10:20 { > To: karagian@cs.utwente.nl; { > { > > >slblake@petri-meat.com { > Cc: pcn@ietf.org { > Subject: RE: > >{ > { > [PCN] PCN WG last call for { > > >draft-ietf-pcn-architecture-05.txt > >{ > { > { > > >{ > { > { > So the question is about adding to the draft: > >{ > { > { > A model where the egress measures marks coming > from { > all > >{ > the { > ingresses, and makes admission decision based on that. > >{ > { > { > > >{ > { > { > Before adding anything about this to the draft, I'd { > > >like { > to { > understand if this is a genuine practical, { > > >understood { > option { > (if so, OK), or if it's a { > theoretical > >possibility { > or one not { > well understood. > >{ > { > { > (there are many things in the latter category that { > > >aren't { > { > mentioned in the draft.) { > { > Questions > are { > why > >this { > is interesting, why is it better than { > the { > models > >already { > well-known, are there comparative analysis { > { > > >/simulations? > >{ > { > { > > >{ > { > { > I suppose I've got 2 general issues: > >{ > { > { > [1] every time something is added, overall the { > document > >{ { > becomes harder to understand, more daunting to { > > read & it { > > >> looks { less { like the WG has consensus. > >{ > { > { > [2] this is an INFO doc. People are free to > invent { > ways > >{ > of { > using the standards pieces other than the { > > architecture { > >> draft { > says, and indeed in ways not yet dreamt of. > >{ > { > { > > >{ > { > { > Phil. > >{ > { > { > > >{ > { > { > { -----Original Message----- { > { > { > { From: > >pcn-bounces@ietf.org { > { > [mailto:pcn-bounces@ietf.org] On { > > >Behalf Of { Georgios { > { > Karagiannis { Sent: 27 August > 2008 08:54 { > >> { To: 'Steven Blake' > >{ > { > { > { Cc: pcn@ietf.org > >{ > { > { > { Subject: Re: [PCN] PCN WG last call for { > { > { > > >draft-ietf-pcn-architecture-05.txt > >{ > { > { > { > >{ > { > { > { Hi Steven > >{ > { > { > { > >{ > { > { > { > -----Original Message----- { > { > { > { > > From: Steven > >Blake { > [mailto:slblake@petri-meat.com] { { > > { > Sent: > woensdag 27 > >{ > augustus 2008 6:18 { > To: Georgios { { > Karagiannis { > Cc: > >{ > pcn@ietf.org { > Subject: RE: [PCN] PCN > { > WG { last > { { > call > >for { > draft-ietf-pcn-architecture-05.txt > >{ > { > { > { > > >{ > { > { > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios > Karagiannis > >{ > wrote: > >{ > { > { > { > > >{ > { > { > { > > Hi Steven > >{ > { > { > { > > > >{ > { > { > { > > > >{ > { > { > { > > Please see in line! > >{ > { > { > { > > > >{ > { > { > { > > > >{ > { > { > { > > > -----Original Message----- { > { > { > > > { > > >From: Steven Blake { > [mailto:slblake@petri-meat.com] { { > > { > > > > > >Sent: dinsdag 26 { > augustus 2008 14:46 { > > > To: > >{ > { > { > Georgios Karagiannis { > > > Cc: pcn@ietf.org { > > > > { > { > >> { > Subject: Re: [PCN] PCN WG last call for { > > > { > { { > > >draft-ietf-pcn-architecture-05.txt > >{ > { > { > { > > > > >{ > { > { > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios { > > >Karagiannis { > wrote: > >{ > { > { > { > > > > >{ > { > { > { > > > > Hi Phil, Hi all > >{ > { > { > { > > > > > >{ > { > { > { > > > > Here are some comments on the PCN { > > >architecture draft: > >{ > { > { > { > > > > > >{ > { > { > { > > > > 1) Thank you for clarifying the bullet > in { { > > >Setion { > 3.2 about flow { > > > > termination. > >{ > { > { > { > > > > > >{ > { > { > { > > > > 2) From what I understand the PCN { > > >architecture { > { > draft { > > > mentions that PCN { > > > { > > > >supports only { > the { > trunk (ingress-egress-aggregate) { > and not > >the { > > > { > > HOSE model. > >{ > { > { > { > > > > Is the PCN architecture draft > excluding { > { > > >solutions { > that { > support the { > > > > HOSE model? If > { { > not, > >please { > emphasize in the PCN { > architecture draft { > { > > > > > > >{ > > >{ that { > "solutions that are based on other types { > of > > flow { { > > >> > { > { > { > { { > aggregation than { > > > > the { > { > > >ingress-egress-aggregate { > method of flow { > { > aggregation, { > > >are not { > > > > excluded { > from the PCN { > WG activities." > >{ > { > { > { > > > > >{ > { > { > { > > > Actually they are, by our charter. > >{ > { > { > { > > > >{ > { > { > { > > I have not seen that the PCN charter excludes { > > >other { > { > types { > of aggregation. > >{ > { > { > { > > >{ > { > { > { > Well, I checked, and you are correct (mea culpa). > >{ > { > { > { Georgios: No problem > >{ > { > { > { > >{ > { > { > { > > >{ > { > { > { > > Please note > >{ > { > { > { > > that I am refering to the HOSE model where > the { > { > >> traffic { > sent { > by one or { > > more than one { > > ingresses { > > >towards one { > egress is aggregated at the { > { > > egress. In { > > >this way higgher { > traffic aggregation can { > be > accomplished { > { > >> > than in the { > situation that the { > pipe/trunk { > { > > >(ingress-egress-aggregate) { > { > > is { > used, where the > { > traffic > >sent by only one ingress in { > { > aggegated at { > > the egress. > >{ > { > { > { > > >{ > { > { > { > Typically the "hose" model refers to { > { > > >point-to-multipoint { > { > traffic flow, not multipoint-to-point. > >{ > { > { > { Georgios: Typically yes, but in this case we > refer { > to > >{ { > bandwidth allocation { in a multipoint-to-point fashion. > >{ > { > { > { > >{ > { > { > { > > >{ > { > { > { > > >{ > { > { > { > Regards, > >{ > { > { > { > > >{ > { > { > { > // Steve > >{ > { > { > { > > >{ > { > { > { > >{ > { > { > { > >{ > { > { > { _______________________________________________ > >{ > { > { > { 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 > > ______________________________________________________________ > ______________ > 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 Aug 28 05:18:06 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17B223A6945; Thu, 28 Aug 2008 05:18:06 -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 7C7E83A6BBE for ; Thu, 28 Aug 2008 05:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.217 X-Spam-Level: X-Spam-Status: No, score=-1.217 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_57=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 V8Mn-lSBnwFQ for ; Thu, 28 Aug 2008 05:17:57 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id AC7AE3A6B30 for ; Thu, 28 Aug 2008 05:17:54 -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, 28 Aug 2008 13:17:29 +0100 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, 28 Aug 2008 13:17:29 +0100 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 12199258488; Thu, 28 Aug 2008 13:17:28 +0100 Received: from mut.jungle.bt.co.uk ([10.73.69.128]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m7SCHPQc008585; Thu, 28 Aug 2008 13:17:26 +0100 Message-Id: <200808281217.m7SCHPQc008585@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Aug 2008 13:16:24 +0100 To: "EARDLEY, Phil" From: Bob Briscoe In-Reply-To: <1219408519.32328.6.camel@tachyon> References: <1218240220.16668.6.camel@tachyon> <1219408519.32328.6.camel@tachyon> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 28 Aug 2008 12:17:29.0366 (UTC) FILETIME=[0A482B60:01C90908] Cc: pcn Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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, I know the last call ended yesterday, but as I think you agreed to make some tweaks to the text, you might want to consider this addition to "Sec 7.7 Tunnelling" as well. Current text: o any PCN-marking is copied into the outer header Suggested new text o any PCN-marking is copied into the outer header Note that a tunnel will not provide this behaviour if it complies with [RFC3168] tunnelling in either mode, but it will if it complies with [RFC4301] IPSec tunnelling. ----------------------------------------------------------------------- Current text: Similarly, in line with the "uniform conceptual model" of [RFC2983] and the "full-functionality option" of [RFC3168], the following rule is applied if decapsulation is done within the PCN-domain: Suggested new text Similarly, in line with the "uniform conceptual model" of [RFC2983], with [RFC4301] and with the "full-functionality mode" of [RFC3168], the following rule is applied if decapsulation is done within the PCN- domain: ----------------------------------------------------------------------- Bob At 13:35 22/08/2008, Steven Blake wrote: >On Fri, 2008-08-08 at 20:03 -0400, Steven Blake wrote: > > > This message starts a 2+-week PCN working group last call for advancing > > > > Title : Pre-Congestion Notification Architecture > > Author(s) : P. Eardley > > Filename : draft-ietf-pcn-architecture-05.txt > > Pages : 54 > > Date : 2008-08-07 > > > > as an Informational RFC. Substantive comments and statements of support > > for this draft should be sent to the pcn mailing list. Editorial > > suggestions can be sent directly to the document editor. > > The last call will end on Wednesday August 27. > >A reminder that this last call closes next Wednesday. > > >Regards, > >// Steve > >_______________________________________________ >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 Aug 28 06:16:54 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB8BE28C2A0; Thu, 28 Aug 2008 06:16: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 06F0728C2A0 for ; Thu, 28 Aug 2008 06:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, 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 G1aD7HOZ2wL4 for ; Thu, 28 Aug 2008 06:16:53 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id EB9C928C29C for ; Thu, 28 Aug 2008 06:16:52 -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); Thu, 28 Aug 2008 14:16:54 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Aug 2008 14:16:54 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA1E6@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <200808281217.m7SCHPQc008585@bagheera.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt Thread-Index: AckJCApv02iGigbRRLGVcVOvI1DwpwACEEgw From: To: X-OriginalArrivalTime: 28 Aug 2008 13:16:54.0921 (UTC) FILETIME=[5784AF90:01C90910] Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 Sounds good clarification to me, thanks bob phil { -----Original Message----- { From: Briscoe,RJ,Bob,XVR9 BRISCORJ R { Sent: 28 August 2008 13:16 { To: Eardley,PL,Philip,CXR9 R { Cc: pcn; Steven Blake { Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt { { Phil, { { I know the last call ended yesterday, but as I think you agreed to { make some tweaks to the text, you might want to consider this { addition to "Sec 7.7 Tunnelling" as well. { { Current text: { o any PCN-marking is copied into the outer header { { Suggested new text { o any PCN-marking is copied into the outer header { { Note that a tunnel will not provide this behaviour if it complies { with [RFC3168] tunnelling in either mode, but it will if it complies { with [RFC4301] IPSec tunnelling. { ----------------------------------------------------------------------- { { Current text: { Similarly, in line with the "uniform conceptual model" of [RFC2983] { and the "full-functionality option" of [RFC3168], the following rule { is applied if decapsulation is done within the PCN-domain: { { Suggested new text { Similarly, in line with the "uniform conceptual model" of [RFC2983], { with [RFC4301] and with the "full-functionality mode" of [RFC3168], { the following rule is applied if decapsulation is done within the PCN- { domain: { ----------------------------------------------------------------------- { { { Bob { { At 13:35 22/08/2008, Steven Blake wrote: { >On Fri, 2008-08-08 at 20:03 -0400, Steven Blake wrote: { > { > > This message starts a 2+-week PCN working group last call for { advancing { > > { > > Title : Pre-Congestion Notification Architecture { > > Author(s) : P. Eardley { > > Filename : draft-ietf-pcn-architecture-05.txt { > > Pages : 54 { > > Date : 2008-08-07 { > > { > > as an Informational RFC. Substantive comments and statements of { support { > > for this draft should be sent to the pcn mailing list. Editorial { > > suggestions can be sent directly to the document editor. { > > The last call will end on Wednesday August 27. { > { >A reminder that this last call closes next Wednesday. { > { > { >Regards, { > { >// Steve { > { >_______________________________________________ { >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 Aug 28 07:27:46 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1B233A6CA7; Thu, 28 Aug 2008 07:27: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 E6BD33A6C9E for ; Thu, 28 Aug 2008 07:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.218 X-Spam-Level: X-Spam-Status: No, score=0.218 tagged_above=-999 required=5 tests=[AWL=-0.734, BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2vGrZH7RrYt for ; Thu, 28 Aug 2008 07:27:25 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 6C40C3A6CA7 for ; Thu, 28 Aug 2008 07:27:24 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m7SERMwq002638; Thu, 28 Aug 2008 16:27:22 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.54]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Thu, 28 Aug 2008 16:27:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 28 Aug 2008 16:27:20 +0200 Message-ID: <713A7C5347A4344A8671770DFE2B2EA7018108E0@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA1D9@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Request for clarification of Other and priority traffic - seedraft-eardley-pcn-marking-behaviour-01 Thread-Index: AckHVfNfByaoB9vRTiaa/aj4wzcElgAxGMVwAA/2iEAAJCYYQAAEJ4ug References: <713A7C5347A4344A8671770DFE2B2EA7017CCC1C@FRVELSMBS22.ad2.ad.alcatel.com> <4A916DBC72536E419A0BD955EDECEDEC03DAA1D9@E03MVB1-UKBR.domain1.systemhost.net> From: "HUBLET Christian" To: , X-OriginalArrivalTime: 28 Aug 2008 14:27:22.0696 (UTC) FILETIME=[2F77F480:01C9091A] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 Subject: Re: [PCN] Request for clarification of Other and priority traffic - seedraft-eardley-pcn-marking-behaviour-01 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="===============1990710162==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1990710162== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9091A.2F1D7A73" This is a multi-part message in MIME format. ------_=_NextPart_001_01C9091A.2F1D7A73 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Phil,=20 =20 We are making progress. Bullet point 3 is clear, bullet point 4 is still an issue for me. =20 I have the impression that capacity means bandwidth or allowed share of the available resources configured by the operator: - If an amount of bandwidth is assigned for the aggregate of PCN and some identified non PCN service, PCN and the identified non PCN traffic must be metered together.=20 - In other cases, the traffic must not be metered together. This is in line with the message in bullet point 3 covering PCN traffic and priority traffic.=20 =20 Bullet point 4 is covering PCN traffic and other traffic being traffic scheduled at the same priority (with implementation options 2 queues scheduled at the same priority or single queue handling both types of traffic). Since PCN is based on virtual queue (token bucket), PCN traffic can be metered separately. One could even say that there is no relation between the virtual queue and the real queue behavior if both are correctly configured. So I do not see why sharing the same queue or scheduling at the same priority is the key element to suddenly take into account the non PCN traffic for metering. If of course the operator configures a bandwidth capacity for the aggregate of PCN and non PCN traffic, both types of traffic must be metered together. If this interpretation is correct, this bullet point brings the same message to the table as the message in bullet point 3 covering priority traffic and PCN traffic. =20 Bullet point 6 is covering lower priority traffic. If in bullet point 3, higher priority traffic is taken into account when capacity is shared, why should the document exclude the situation that lower priority traffic and PCN traffic are sharing the same capacity. It also suggest a link between scheduling and PCN which is as indicated above is not clear to me.=20 =20 If this is true, my view on a message that you are bringing in the paragraph 6.5 could be: The PCN architecture is capable of covering situations where PCN and Non PCN traffic share the same network. It might be needed that non PCN traffic is taken into account in the metering. This is illustrated in the examples in the different bullet points that illustrate when non PCN traffic should be metered together with PCN traffic. But it is not advised that PCN traffic and non PCN traffic share the same capacity (assigned bandwidth) because it reduces the capability of PCN to protect admitted flows. Correct? =20 Some proposals/remarks related to the document =20 =20 Second bullet point: I believe this is an important bullet. the bullet could be rephrased as follows. The PCN architecture targets to handle admittance and termination for multiple services co-existing in the same PCN domain. Those services will be distinguished via a DSCP value. The PCN mechanisms could protect each service individually. Services could also be grouped. The aggregated traffic level of the group of services could be protected via a PCN mechanism. =20 Third bullet point: The message is clear know. But not yet reflected in the text. First proposal. ... or priority schedule it over PCN. In the latter case PCN and priority scheduled traffic are sharing the same bandwidth. In this case.... Other proposal: restructure as you propose and use your text below to clarify the message. =20 Fourth bullet point: As indicated before, I do not understand the relation between sharing the same queue and metering both types of traffic with a single token bucket for PCN control. I can imagine that in some cases this is required but in some cases it is not. I hope this brings us a step forward in understanding other and priority traffic. =20 Sixth bullet point:=20 =20 kr, =20 Chris ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: donderdag 28 augustus 2008 11:25 To: HUBLET Christian; pcn@ietf.org Subject: RE: [PCN] Request for clarification of Other and priority traffic - seedraft-eardley-pcn-marking-behaviour-01 Thanks chris, in-line phil =20 -----Original Message----- From: HUBLET Christian [mailto:Christian.Hublet@alcatel-lucent.be]=20 Sent: 27 August 2008 17:00 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] Request for clarification of Other and priority traffic - seedraft-eardley-pcn-marking-behaviour-01 =20 Phil, =20 Thanks for the reply. =20 Unfortunately the message in section 6.5 is not clear to me: =20 First bullet point : no remarks. =20 Second bullet point : single metering for all the identified DSCP values, or metering per DSCP value, or a mix of the two mechanisms =20 [phil] this bullet reflects old discussions where we talked about PCn running separately for several classes - so your 2nd sense ie "metering per DSCP value".=20 However, the first sense would also be possible. I'm not actually sure in retrospect that this bullet adds much, so I propose deleting it.=20 please shout if you object & would prefer to keep it (if so, please suggest a re-phrasing) =20 Third bullet point : I understand that BW of priority scheduled traffic on the same link should be taking into account by the PCN token bucket. --> so capacity in the marking draft means link=20 The strange point is that a PCN node dedicates capacity to NON PCN traffic. what does this mean? =20 [phil] i think this is just that I could make the sentence construction clearer. It means that there are 2 possibilities [1] the router has some capacity set aside dedicated for the "important" traffic (eg operator's control msgs). This means that pcn isnt allowed to use this capacity, even if "important traffic" isnt currently using it. In this case there's nothing for PCn to worry about [2] the router shares capacity between the "important" traffic & pcn traffic. But it's assumed that the "important" traffic is always priority scheduled ahead of pcn-traffic. It would be possible in a worst case for pcn to get no capacity. Clearly the "important" traffic needs to contribute to pcn's meters.=20 =20 Fourth bullet point : "uses same capacity on a link as PCN traffic" --> capacity is probably bandwidth that is shared. PCN traffic and non PCN but same codepoint.=20 share the same capacity since scheduling ... --> capacity is a queue with a certain servicing rate which is common for PCN and non PCN ? =20 Fifth bullet point : "it is not advised to have non PCN traffic that shares the same capacity on a link as PCN traffic" --> Capacity is bandwidth that is shared between PCN and non PCN traffic=20 =20 So my view is that capacity is used in different meaning in section 6.5. =20 "Capacity" - I meant the capacity as in the forwarding bandwidth on the link. But I think in practice this is equivalent to same queue. =20 if there are different types of traffic "sharing capacity", then possibilities are: 1. all the types of traffic go in the same queue. Clearly then the router's capacity is shared. 2. each type of traffic goes in a separate queue and the queues are scheduled with equal priority. =20 However, assuming that both types of traffic have same dscp (this is the example mentioned in the 4th bullet), then in practice both types of traffic go in the same queue. (In theory it would be possible to go in different queues (by the router classification looking at ECN field), but in practice it seems that nodes only look at dscp when determining what queue to put traffic in. But in any case, even if separate queues were used, this is really just an implementation detail that we shouldn't worry about.) =20 Chris, do you think it makes it clear if I re-phrase it from: There may be other traffic that uses the same capacity (on a link) as PCN-traffic. =20 To: There may be other traffic that uses the same capacity as PCN-traffic. "Capacity" means forwarding bandwidth on a link. =20 And in: they will share the same capacity since scheduling behaviour is coupled with the DSCP only. - add the phrase "in practice" (next to "scheduling behaviour") =20 Please suggest some alternative words if you think they'd help. I guess I've read this stuff too many times - find it hard to view it from perspective of someone coming to it fresh! =20 Thanks phil =20 I suppose a discussion is held in the past that discusses the value of taking into account other and priority traffic. Could some one point me to a doc or email discussion that provides a view on the problem. Thanks. =20 kr, =20 Chris Hublet =20 ________________________________ From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: woensdag 27 augustus 2008 10:01 To: HUBLET Christian; pcn@ietf.org Subject: RE: [PCN] Request for clarification of Other and priority traffic - seedraft-eardley-pcn-marking-behaviour-01 Thanks Chris, Indeed this section is unclear and will be improved in the next version. =20 However, it should be better in the most recent verson of the architecture draft, section 6.5 "PCN-traffic" http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-05.txt=20 =20 I think this answers your questions, but would appreciate it if you could have a look and see if it makes sense or leaves something unclear. =20 The sense of this S6.5 text will appear in the next version of the marking draft =20 Thanks phil =20 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of HUBLET Christian Sent: 26 August 2008 09:30 To: pcn@ietf.org Subject: [PCN] Request for clarification of Other and priority traffic - seedraft-eardley-pcn-marking-behaviour-01 =20 =20 Hello,=20 >From draft-eardley-pcn-marking-behaviour-01, I understand that the to be metered traffic is :=20 - PCN traffic + Other traffic + Priority traffic.=20 >From the draft it is not clear to me what priority traffic basically means:=20 - In the definitions of section 1.1, priority traffic shares the same capacity.=20 - I wonder what the meaning is of capacity:=20 1. sharing the same physical interface (read capacity) or=20 2. the bandwidth (read capacity) is configured for the 2 (or 3) types of traffic. (no separate capacity (bandwidth) is specified per traffic type) I suppose that for the "other traffic" also both definitions can be applicable.=20 In the first definition, I see an issue for admittance control. If not all other and priority traffic is actually present in the network,=20 there could be an overadmittance of the PCN traffic. A practical example could be coexistance of business traffic and residential traffic in the same diffserv network.=20 The residential traffic is controlled via PCN, the business traffic is controlled via a policer at the edge of the network. If not all sessions for the business traffic are active, the PCN traffic could take capacity which was meant to be used for business traffic. =20 In the second definition, I do not understand why lower priority traffic should not be taken into account if the same capacity (read bandwidth) is shared with PCN traffic. I have the impression that there is a strict requirement to take into account other traffic and priority traffic if present (metered packet (see section 2.4) is part of meter traffic (see section 1.1)). If the first definition is applied, this strict requirement can have a huge impact on the number of applications that can be supported in the diffserv domain and the accuracy with which the PCN bandwidth is controlled. In the second definition, it is the wish of the operator to share the bandwidth for a number of applications which is basically a normal policy. But in this last case, it is not clear why lower priority traffic can't share the same bandwidth. Thanks for clarifying.=20 Kr,=20 Chris=20 =20 _________________________________=20 Christian hublet=20 Bell Labs - Fixed Access=20 Copernicuslaan 50=20 B2018 Antwerp=20 Belgium=20 Tel. +32 3 2408789;=20 Email : Christian.Hublet@alcatel-lucent.be=20 =20 =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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 Alcatel-Lucent Bell NV=20 Fortis 220-0002334-42=20 VAT BE 0404 621 642 Register of Legal Entities Antwerp=20 DISCLAIMER: This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited without the prior consent of its author. =20 ------_=_NextPart_001_01C9091A.2F1D7A73 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Request for clarification of Other and priority = traffic - see draft-eardley-pcn-marking-behaviour-01
Hi Phil,
 
We are making progress. Bullet point 3 is = clear, bullet=20 point 4 is still an issue for me.
 
I have the impression that capacity means = bandwidth or=20 allowed share of the available resources configured by the=20 operator:
   - If an amount of = bandwidth is=20 assigned for the aggregate of PCN and some identified non = PCN=20 service, PCN and the identified non PCN traffic must be metered=20 together. 
    - In other cases, the = traffic must=20 not be metered together.
This is in line with the message in bullet = point 3=20 covering PCN traffic and priority = traffic. 
 
Bullet point 4 is covering PCN traffic and = other=20 traffic being traffic scheduled at the same priority (with = implementation=20 options 2 queues scheduled at the same priority or single queue handling = both=20 types of traffic). Since PCN is based on virtual queue (token bucket), = PCN=20 traffic can be metered separately. One could even say that there is = no=20 relation between the virtual queue and the real queue behavior = if both=20 are correctly configured. So I do not see why sharing the same = queue or=20 scheduling at the same priority is the key element to suddenly take = into=20 account the non PCN traffic for metering. If of course the=20 operator configures a bandwidth capacity for the aggregate of = PCN and=20 non PCN traffic, both types of traffic must be metered = together. If=20 this interpretation is correct, this bullet point brings the same = message=20 to the table as the message in bullet point 3 covering priority = traffic and=20 PCN traffic.
 
Bullet point 6 is covering lower priority = traffic. If=20 in bullet point 3, higher priority traffic is taken into account when = capacity=20 is shared, why should the document  exclude the situation that = lower=20 priority traffic and PCN traffic are sharing the same capacity. It = also=20 suggest a link between scheduling and PCN which is as indicated above is = not=20 clear to me. 
 
If this is true, my view on a message = that you are=20 bringing in the paragraph 6.5 could be:
The PCN architecture is capable of covering = situations=20 where PCN and Non PCN traffic share the same network. It might be needed = that=20 non PCN traffic is taken into account in the metering. = This is=20 illustrated in the examples in the different bullet points that = illustrate when=20 non PCN traffic should be metered together with PCN traffic. But it is = not=20 advised that PCN traffic and non PCN traffic share the same capacity = (assigned=20 bandwidth) because it reduces the capability of PCN to protect admitted = flows.=20 Correct?
 
Some proposals/remarks related to the=20 document  
 
Second bullet point: I believe this is an = important=20 bullet. the bullet could be rephrased as follows.
The PCN architecture targets to handle = admittance and=20 termination for multiple services co-existing in the same PCN domain. = Those=20 services will be distinguished via a DSCP=20 value. The PCN mechanisms could protect = each service=20 individually. Services could also be grouped. The aggregated = traffic level=20 of the group of services could be protected via a PCN=20 mechanism.
 
Third bullet point: The message is clear = know. But not=20 yet reflected in the text.
First proposal.
... or priority schedule it over PCN. = In the=20 latter case PCN and priority scheduled traffic are sharing the same=20 bandwidth. In this case....
Other proposal: restructure as you propose = and=20 use your text below to clarify the message.
 
Fourth = bullet point:=20 As indicated before, I do not understand the relation between sharing = the same=20 queue and metering both types of traffic with a single token bucket for = PCN=20 control. I can imagine that in some cases this is required but in some = cases it=20 is not.
I hope=20 this brings us a step forward in understanding other and priority=20 traffic.
 
Sixth=20 bullet point:
 
kr,
 
Chris

From: philip.eardley@bt.com = [mailto:philip.eardley@bt.com]=20
Sent: donderdag 28 augustus 2008 11:25
To: HUBLET=20 Christian; pcn@ietf.org
Subject: RE: [PCN] Request for = clarification=20 of Other and priority traffic -=20 seedraft-eardley-pcn-marking-behaviour-01

Thanks chris, = in-line

phil

 

-----Original=20 Message-----
From: = HUBLET=20 Christian [mailto:Christian.Hublet@alcatel-lucent.be]
Sent: 27 August 2008 = 17:00
To: Eardley,PL,Philip,CXR9 R;=20 pcn@ietf.org
Subject: = RE: [PCN]=20 Request for clarification of Other and priority traffic -=20 seedraft-eardley-pcn-marking-behaviour-01

 

Phil,

 

Thanks for = the=20 reply.

 

Unfortunately = the=20 message in section 6.5 is not clear to me:

 

First bullet = point : no=20 remarks.

 

Second bullet=20 point : single metering for all the identified DSCP values, or = metering per=20 DSCP value, or a mix of the two mechanisms

 

[phil] this = bullet=20 reflects old discussions where we talked about PCn running separately = for=20 several classes – so your 2nd sense ie “metering per = DSCP=20 value”.

However, the = first=20 sense would also be possible.

I’m not = actually sure=20 in retrospect that this bullet adds much, so I propose deleting it.=20

please shout = if you=20 object & would prefer to keep it (if so, please suggest a=20 re-phrasing)

 

Third bullet point=20 : I understand that BW of priority scheduled traffic on the = same link=20 should be taking into account by the PCN token = bucket.

        -->=20 so capacity in the marking draft means = link 

    The=20 strange point is that a PCN node dedicates capacity to NON PCN traffic. = what=20 does this mean?

 

[phil] i = think this is=20 just that I could make the sentence construction clearer. It means that = there=20 are 2 possibilities

[1] the = router has some=20 capacity set aside dedicated for the “important” traffic (eg = operator’s control=20 msgs). This means that pcn isnt allowed to use this capacity, even if = “important=20 traffic” isnt currently using it. In this case there’s = nothing for PCn to worry=20 about

[2] the = router shares=20 capacity between the “important” traffic & pcn traffic. = But it’s assumed=20 that the “important” traffic is always priority scheduled = ahead of pcn-traffic.=20 It would be possible in a worst case for pcn to get no capacity. Clearly = the=20 “important” traffic needs to contribute to pcn’s = meters.

 

Fourth bullet = point : "uses same capacity on a link as PCN = traffic"

        -->=20 capacity is probably bandwidth that is shared. PCN traffic and = non PCN=20 but same codepoint. 

   =20 share the same capacity since scheduling ...

       =20 --> capacity is a queue with a certain servicing rate which is common = for PCN=20 and non PCN ?

 

Fifth bullet = point :=20 "it is not advised to have non PCN traffic that shares the same capacity = on a=20 link as PCN traffic"

       =20 --> Capacity is bandwidth that is shared between PCN and non PCN = traffic 

 

So my view is = that=20 capacity is used in different meaning in section 6.5.

 

“Capacity” – I meant=20 the capacity as in the forwarding bandwidth on the link. But I think in = practice=20 this is equivalent to same queue.

 

if there are = different=20 types of traffic “sharing capacity”, then possibilities = are:

1. all the = types of=20 traffic go in the same queue. Clearly then the router’s capacity = is=20 shared.

2. each type = of traffic=20 goes in a separate queue and the queues are scheduled with equal=20 priority.

 

However, = assuming that=20 both types of traffic have same dscp (this is the example mentioned in = the=20 4th bullet), then in practice both types of traffic go in the = same=20 queue. (In theory it would be possible to go in different queues (by the = router=20 classification looking at ECN field), but in practice it seems that = nodes only=20 look at dscp when determining what queue to put traffic in. But in any = case,=20 even if separate queues were used, this is really just an implementation = detail=20 that we shouldn’t worry about.)

 

Chris, do you = think it=20 makes it clear if I re-phrase it from:

There may =
be other traffic that uses the same capacity (on a =
link)
      as =
PCN-traffic. 

To:

There may be other traffic that =
uses the same capacity as PCN-traffic. “Capacity” means =
forwarding bandwidth on a link.
 
And =
in:
they will share =
the
      same capacity =
since scheduling behaviour is coupled with the =
DSCP
      =
only.
- add the phrase “in practice” =
(next to “scheduling behaviour”)

 

Please suggest some alternative = words if=20 you think they’d help. I guess I’ve read this stuff too many = times  - find=20 it hard to view it from perspective of someone coming to it=20 fresh!

 

Thanks

phil

 

I suppose a = discussion=20 is held in the past that discusses the value of taking into account = other and=20 priority traffic.

Could some = one point me=20 to a doc or email discussion that provides a view on the problem.=20 Thanks.

 

kr,

 

Chris=20 Hublet

 

From: philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: woensdag 27 augustus 2008=20 10:01
To: HUBLET = Christian;=20 pcn@ietf.org
Subject: = RE: [PCN]=20 Request for clarification of Other and priority traffic -=20 seedraft-eardley-pcn-marking-behaviour-01

Thanks=20 Chris,

Indeed this = section is=20 unclear and will be improved in the next version.

 

However, it = should be=20 better in the most recent verson of the architecture draft, section 6.5=20 “PCN-traffic” http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-05= .txt=20

 

I think this = answers=20 your questions, but would appreciate it if you could have a look and see = if it=20 makes sense or leaves something unclear.

 

The sense of = this S6.5=20 text will appear in the next version of the marking = draft

 

Thanks

phil

 

-----Original=20 Message-----
From:=20 pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of HUBLET = Christian
Sent: 26 August 2008 = 09:30
To: pcn@ietf.org
Subject: [PCN] Request for = clarification of=20 Other and priority traffic -=20 seedraft-eardley-pcn-marking-behaviour-01

 

 

Hello,

From=20 draft-eardley-pcn-marking-behaviour-01, I understand that the to be = metered=20 traffic is : =
        - PCN=20 traffic + Other traffic + Priority traffic.

From the draft it is not = clear to me=20 what priority traffic basically means:=20
        - In the definitions of = section 1.1,=20 priority traffic shares the same capacity.=20
        - I wonder what the = meaning is of=20 capacity:
       =20         1. sharing the same = physical=20 interface (read capacity) or=20
       =20         2. the bandwidth (read = capacity) is=20 configured for the 2 (or 3) types of traffic. (no separate capacity = (bandwidth)=20 is specified per traffic type)

I=20 suppose that for the "other traffic" also both definitions can be=20 applicable.

In=20 the first definition, I see an issue for admittance control. If not all = other=20 and priority traffic is actually present in the network, =

there could be an = overadmittance of=20 the PCN traffic. A practical example could be coexistance of business = traffic=20 and residential traffic in the same diffserv network.

The=20 residential traffic is controlled via PCN, the business traffic is = controlled=20 via a policer at the edge of the network. If not all sessions for the = business=20 traffic are active, the PCN traffic could take capacity which was meant = to be=20 used for business traffic.

  =
In the=20 second definition, I do not understand why lower priority traffic should = not be=20 taken into account if the same capacity (read bandwidth) is shared with = PCN=20 traffic.

I=20 have the impression that there is a strict requirement to take into = account=20 other traffic and priority traffic if present (metered packet (see = section 2.4)=20 is part of meter traffic (see section 1.1)). If the first definition is = applied,=20 this strict requirement can have a huge impact on the number of = applications=20 that can be  supported  in the diffserv domain and the = accuracy with=20 which the PCN bandwidth is controlled. In the second definition, it is = the wish=20 of the operator to share the bandwidth for a number of applications = which is=20 basically a normal policy. But in this last case, it is not clear why = lower=20 priority traffic can't share the same bandwidth.

Thanks for = clarifying.=20

Kr,

Chris

 

_________________________________=20
Christian=20 hublet
Bell Labs - Fixed=20 Access
Copernicuslaan=20 50
B2018 = Antwerp=20
Belgium=20
Tel. +32 3 = 2408789;=20
Email :=20 Christian.Hublet@alcatel-lucent.be

 

=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=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20

Alcatel-Lucent=20 Bell NV
Fortis=20 220-0002334-42
VAT = BE 0404=20 621 642 Register of Legal Entities Antwerp

DISCLAIMER:=20 This message (including any attachments) contains confidential = information=20 intended for a specific individual and purpose, and is protected by law. = If you=20 are not the intended recipient, you should delete this message. Any = disclosure,=20 copying, or distribution of this message, or the taking of any action = based on=20 it, is strictly prohibited without the prior consent of its=20 author.

 

------_=_NextPart_001_01C9091A.2F1D7A73-- --===============1990710162== 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 --===============1990710162==-- From pcn-bounces@ietf.org Thu Aug 28 08:07:31 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4764E28C1DB; Thu, 28 Aug 2008 08:07: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 C7BB228C0F5 for ; Thu, 28 Aug 2008 08:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.067 X-Spam-Level: X-Spam-Status: No, score=-1.067 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_57=0.6, 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 nVZwRJQd0LNo for ; Thu, 28 Aug 2008 08:07:23 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 97F8828C1DB for ; Thu, 28 Aug 2008 08:07:22 -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); Thu, 28 Aug 2008 16:07:24 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Aug 2008 16:07:24 +0100 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 1219936054561; Thu, 28 Aug 2008 16:07:34 +0100 Received: from mut.jungle.bt.co.uk ([10.73.69.128]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m7SF7JtG024242; Thu, 28 Aug 2008 16:07:20 +0100 Message-Id: <200808281507.m7SF7JtG024242@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Aug 2008 16:06:39 +0100 To: "Georgios Karagiannis" From: Bob Briscoe In-Reply-To: <001d01c90907$a91beb10$810c5982@dynamic.ewi.utwente.nl> References: <002101c9083b$de8d88c0$810c5982@dynamic.ewi.utwente.nl> <4A916DBC72536E419A0BD955EDECEDEC03DAA1CB@E03MVB1-UKBR.domain1.systemhost.net> <200808281130.m7SBULJA004422@bagheera.jungle.bt.co.uk> <001d01c90907$a91beb10$810c5982@dynamic.ewi.utwente.nl> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 28 Aug 2008 15:07:24.0082 (UTC) FILETIME=[C6CE6120:01C9091F] Cc: pcn@ietf.org Subject: Re: [PCN] MP2P aggregates 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, At 13:14 28/08/2008, Georgios Karagiannis wrote: >Hi Bob > >I do not want to hold the publication of the architecture draft. >I will be happy if, related to this issue, the sentence proposed by >Ken in the previous email is used. Good, thanks >Regarding one of your comments: > > > If you want an assured MP2P aggregate, you have to build it > > using a set of P2P > > (point-to-point) aggregates. > >Georgios: using a set of P2P aggregates to achieve this is not required. >The MP2P aggregation is solved by using affected marking and just using one >state. >Please also note that at the same time this solution solves the ecmp >problem. Pls be careful with the word 'solved'. Affected marking only gives a partial solution - if the circumstances happen to be fortunate. a) If there is pre-congestion on more than one parallel path, the metering of marking as a proportion of affected marking becomes a confusion of all the paths that are affected. Multiple parallel congested links may seem a corner case, but it's not really. PCN is intended to deal with unexpected events. Flash crowds rarely affect only one path. Disasters also tend not to be well-behaved. b) queues on interior nodes have to switch into affected mode, and decide to switch out of it after some time-out once the congestion episode seems to have gone away. a) and b) can interact, so that one queue is still doing affected marking but timing out after an episode has ended, while another queue on a parallel path can be starting an episode. Again the markings would get confused. I'm not saying Affected Marking is not interesting (as research) and possibly useful, but it relies on a wing and a prayer (excuse the use of english idiom - this means it's a rather precarious mechanism that isn't very deterministic). I try to separate solid stuff ready for standards from research, even tho I do both. Bob >Best regards, >Georgios > > > > > -----Original Message----- > > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > > Sent: donderdag 28 augustus 2008 13:30 > > To: karagian@cs.utwente.nl > > Cc: philip.eardley@bt.com; slblake@petri-meat.com; pcn@ietf.org > > Subject: Re: MP2P aggregates (was: [PCN] PCN WG last call for > > draft-ietf-pcn-architecture-05.txt) > > > > Georgios, > > > > I've started a different thread on this, because I think > > there is general consensus that it is not relevant to the > > last call on the current PCN architecture. > > > > Bringing in a completely different architecture at the last > > minute requires another informational doc about that > > architecture, not holding up the current one. Here's why I > > say it's a completely different architecture... > > > > Using your multipoint-to-point (MP2P) (so-called 'hose') > > scenario and Phil's notation from earlier in the thread > > below, with traffic from b,c,d,e,f to A. > > > > b___X__________ > > c___________ \ > > \ \ > > d------------+---+--> A > > e___________/ / > > f______________/ > > > > - if there's high pre-congestion on link X just after traffic > > leaves b (say) > > - but traffic from c,d,e,f to A doesn't go through this > > pre-congested link > > - you claim A can average all the markings from b,c,d,e,f together, > > - giving an average for the MP2P aggregate lower than > > pre-congestion on b-A > > - then A could continue to tell any of b,c,d,e,f to accept new flows > > - then flows will still be added to a highly pre-congested path b-A > > > > If you have invented a way to solve this problem, it will > > involve discriminating between each of the ingress-egress > > paths within the MP2P aggregate (perhaps using affected > > marking). So you will need to store state for each path and > > you're no longer storing just a single state for the MP2P > > aggregate any more. > > > > In MPLS fora, the implications of allowing MP2P aggregates > > have caused years of arguments. We didn't include MP2P in the > > PCN architecture for a very good reason: you cannot create > > the assurances we're trying to create with MP2P aggregates. > > If you want an assured MP2P aggregate, you have to build it > > using a set of P2P > > (point-to-point) aggregates. > > > > We're doing other work on MP2P aggregates, but we're not > > bringing it to the PCN w-g. Please respect that the IETF has > > to limit the scope of each work item in order to achieve anything. > > > > Finally, if you've ever watered your garden with a hose that > > sucks the water off the grass back into the hose, then I will > > allow you to use the term hose for an MP2P aggregate. Until > > you can demonstrate this feat experimentally in your garden, > > please use words that mean what they say. Video footage > > running backwards will not be acceptable evidence. > > > > > > Bob > > > > At 13:03 27/08/2008, philip.eardley@bt.com wrote: > > >You appear to be saying all 3 definitions are the same. I > > think they're > > >all different. > > > > > >Let's call the gateway nodes A, B, C, D ,E and F. > > > > > >Duffield: hose at A is all traffic to b,c,d,e,f and all traffic from > > >b,c,d,e,f > > > > > >DiffServ: hose at A is all traffic to b,c,d,e,f > > > > > >Georgios: hose at A is all traffic from b,c,d,e,f > > > > > >{ -----Original Message----- > > >{ From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > { Sent: 27 > > >August 2008 12:56 { To: Eardley,PL,Philip,CXR9 R; > > >slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: > > [PCN] PCN WG > > >last call for draft-ietf-pcn-architecture-05.txt > > >{ > > >{ Hi Phil > > >{ > > >{ Assuming that ingresses can only send data traffic and > > egresses can { > > >receive { data traffic, { a HOSE model that is used in the > > PCN domain > > >between ingress nodes and { egress { edge nodes, { is refering to > > >aggregates between ingress and egress edge nodes, where { > > ingresses are > > >{ sending traffic and egresses are receiving data traffic. > > >{ > > >{ Thus the HOSE aggregation model used in PCN is a HOSE aggregation > > >model { used between ingress and egress nodes. > > >{ > > >{ > > >{ Best regards, > > >{ Georgios > > >{ > > >{ > -----Original Message----- > > >{ > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] { > > > >Sent: woensdag 27 augustus 2008 13:35 { > To: > > karagian@cs.utwente.nl; > > >slblake@petri-meat.com { > Cc: pcn@ietf.org { > Subject: RE: > > [PCN] PCN > > >WG last call for { > draft-ietf-pcn-architecture-05.txt > > >{ > > > >{ > I note that the Duffield et al definition below is different { > > > >from what your talking about, since their definition includes { > > > >traffic in both directions, whilst yours is a one way { > > > definition. I > > >think other people, with a DiffServ { > architecture > > background, would > > >interpret it as traffic from { > one ingress going to any egress. So > > >that's 3 possibilities. > > >{ > > > >{ > In any case, this is really a side issue, compared with > > my { > main > > >points /questions in earlier email. > > >{ > > > >{ > { -----Original Message----- > > >{ > { From: Georgios Karagiannis > > [mailto:karagian@cs.utwente.nl] { > { > > >Sent: 27 August 2008 11:37 { To: Eardley,PL,Philip,CXR9 R; { > > > >slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: > > >{ > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt > > >{ > { > > >{ > { Hi Phil > > >{ > { > > >{ > { HOSE model is defined some 20 years ago, please see > > e.g the { > > > >following { article: > > >{ > { > > >{ > { N. G. Duffield, P. Goyal and A. Greenberg, "A Flexible > > { > Model > > >{ for Resource Management in Virtual Private Networks", in: > > >{ > { Proc. of ACM SIGCOMM, 1999. > > >{ > { > > >{ > { In the above article I found the following definition: > > >{ > { > > >{ > { "A hose is characterized by the aggregate traffic { to and { > > > >from one endpoint in the VPN to the set of other { endpoints > > { > in the > > >VPN" > > >{ > { > > >{ > { Thus the definition refers to aggregated traffic to > > and { > from > > >one edge to { and { from all other endpoints. > > >{ > { > > >{ > { > > >{ > { In our case we refer only to the aggregated traffic from { > > > >other endpoints { to { one endpoint. > > >{ > { > > >{ > { Thus what we use is in line with the definition of the > > HOSE model. > > >{ > { > > >{ > { Best regards, > > >{ > { Georgios > > >{ > { > > >{ > { > > >{ > { > > >{ > { > > >{ > { > -----Original Message----- > > >{ > { > From: philip.eardley@bt.com > > >{ > [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 > > augustus { > > > >2008 11:31 { > To: karagian@cs.utwente.nl; { > > > slblake@petri-meat.com { > > >> Cc: pcn@ietf.org { > Subject: RE: > > >{ > [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt > > >{ > { > > > >{ > { > I thought your emails with steve had revealed that your { > > > >model { > was the exact opposite of the well known hose model? > > >{ > { > > > >{ > { > > > >{ > { > { -----Original Message----- > > >{ > { > { From: Georgios Karagiannis > > >{ > [mailto:karagian@cs.utwente.nl] { > { Sent: 27 August 2008 { > > > >09:41 { To: Eardley,PL,Philip,CXR9 R; { > { > > > slblake@petri-meat.com { > > >Cc: pcn@ietf.org { Subject: RE: > > >{ > { > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt > > >{ > { > { > > >{ > { > { Hi Phil > > >{ > { > { > > >{ > { > { What I explained is the well know HOSE bandwidth { > > > >management model. > > >{ > { > { During the IETF in Dublin, Hein also shown also > > some { { > > > > >results { that were obtrained using the HOSE model. > > >{ > { > { > > >{ > { > { > > >{ > { > { Best regards, > > >{ > { > { Georgios > > >{ > { > { > > >{ > { > { > > >{ > { > { > -----Original Message----- > > >{ > { > { > From: philip.eardley@bt.com { > { > > > >[mailto:philip.eardley@bt.com] { > Sent: woensdag 27 { > > > augustus { > > > >2008 10:20 { > To: karagian@cs.utwente.nl; { > { > > > >slblake@petri-meat.com { > Cc: pcn@ietf.org { > Subject: RE: > > >{ > { > [PCN] PCN WG last call for { > > > >draft-ietf-pcn-architecture-05.txt > > >{ > { > { > > > >{ > { > { > So the question is about adding to the draft: > > >{ > { > { > A model where the egress measures marks coming > > from { > all > > >{ > the { > ingresses, and makes admission decision based on that. > > >{ > { > { > > > >{ > { > { > Before adding anything about this to the draft, I'd { > > > >like { > to { > understand if this is a genuine practical, { > > > >understood { > option { > (if so, OK), or if it's a { > theoretical > > >possibility { > or one not { > well understood. > > >{ > { > { > (there are many things in the latter category that { > > > >aren't { > { > mentioned in the draft.) { > { > Questions > > are { > why > > >this { > is interesting, why is it better than { > the { > models > > >already { > well-known, are there comparative analysis { > { > > > >/simulations? > > >{ > { > { > > > >{ > { > { > I suppose I've got 2 general issues: > > >{ > { > { > [1] every time something is added, overall the { > > document > > >{ { > becomes harder to understand, more daunting to { > > > read & it { > > > >> looks { less { like the WG has consensus. > > >{ > { > { > [2] this is an INFO doc. People are free to > > invent { > ways > > >{ > of { > using the standards pieces other than the { > > > architecture { > > >> draft { > says, and indeed in ways not yet dreamt of. > > >{ > { > { > > > >{ > { > { > Phil. > > >{ > { > { > > > >{ > { > { > { -----Original Message----- { > { > { > { From: > > >pcn-bounces@ietf.org { > { > [mailto:pcn-bounces@ietf.org] On { > > > >Behalf Of { Georgios { > { > Karagiannis { Sent: 27 August > > 2008 08:54 { > > >> { To: 'Steven Blake' > > >{ > { > { > { Cc: pcn@ietf.org > > >{ > { > { > { Subject: Re: [PCN] PCN WG last call for { > { > { > > > >draft-ietf-pcn-architecture-05.txt > > >{ > { > { > { > > >{ > { > { > { Hi Steven > > >{ > { > { > { > > >{ > { > { > { > -----Original Message----- { > { > { > { > > > From: Steven > > >Blake { > [mailto:slblake@petri-meat.com] { { > > { > Sent: > > woensdag 27 > > >{ > augustus 2008 6:18 { > To: Georgios { { > Karagiannis { > Cc: > > >{ > pcn@ietf.org { > Subject: RE: [PCN] PCN > { > WG { last > > { { > call > > >for { > draft-ietf-pcn-architecture-05.txt > > >{ > { > { > { > > > >{ > { > { > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios > > Karagiannis > > >{ > wrote: > > >{ > { > { > { > > > >{ > { > { > { > > Hi Steven > > >{ > { > { > { > > > > >{ > { > { > { > > > > >{ > { > { > { > > Please see in line! > > >{ > { > { > { > > > > >{ > { > { > { > > > > >{ > { > { > { > > > -----Original Message----- { > { > { > > > { > > > >From: Steven Blake { > [mailto:slblake@petri-meat.com] { { > > > { > > > > > > >Sent: dinsdag 26 { > augustus 2008 14:46 { > > > To: > > >{ > { > { > Georgios Karagiannis { > > > Cc: pcn@ietf.org { > > > > > { > { > > >> { > Subject: Re: [PCN] PCN WG last call for { > > > { > { { > > > >draft-ietf-pcn-architecture-05.txt > > >{ > { > { > { > > > > > >{ > { > { > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios { > > > >Karagiannis { > wrote: > > >{ > { > { > { > > > > > >{ > { > { > { > > > > Hi Phil, Hi all > > >{ > { > { > { > > > > > > >{ > { > { > { > > > > Here are some comments on the PCN { > > > >architecture draft: > > >{ > { > { > { > > > > > > >{ > { > { > { > > > > 1) Thank you for clarifying the bullet > > in { { > > > >Setion { > 3.2 about flow { > > > > termination. > > >{ > { > { > { > > > > > > >{ > { > { > { > > > > 2) From what I understand the PCN { > > > >architecture { > { > draft { > > > mentions that PCN { > > > { > > > > >supports only { > the { > trunk (ingress-egress-aggregate) { > > and not > > >the { > > > { > > HOSE model. > > >{ > { > { > { > > > > Is the PCN architecture draft > > excluding { > { > > > >solutions { > that { > support the { > > > > HOSE model? If > > { { > not, > > >please { > emphasize in the PCN { > architecture draft { > { > > > > > > > > >{ > > > >{ that { > "solutions that are based on other types { > of > > > flow { { > > > >> > { > { > { > { { > aggregation than { > > > > the { > { > > > >ingress-egress-aggregate { > method of flow { > { > aggregation, { > > > >are not { > > > > excluded { > from the PCN { > WG activities." > > >{ > { > { > { > > > > > >{ > { > { > { > > > Actually they are, by our charter. > > >{ > { > { > { > > > > >{ > { > { > { > > I have not seen that the PCN charter excludes { > > > >other { > { > types { > of aggregation. > > >{ > { > { > { > > > >{ > { > { > { > Well, I checked, and you are correct (mea culpa). > > >{ > { > { > { Georgios: No problem > > >{ > { > { > { > > >{ > { > { > { > > > >{ > { > { > { > > Please note > > >{ > { > { > { > > that I am refering to the HOSE model where > > the { > { > > >> traffic { > sent { > by one or { > > more than one { > > > ingresses { > > > >towards one { > egress is aggregated at the { > { > > egress. In { > > > >this way higgher { > traffic aggregation can { > be > > accomplished { > { > > >> > than in the { > situation that the { > pipe/trunk { > { > > > >(ingress-egress-aggregate) { > { > > is { > used, where the > > { > traffic > > >sent by only one ingress in { > { > aggegated at { > > the egress. > > >{ > { > { > { > > > >{ > { > { > { > Typically the "hose" model refers to { > { > > > >point-to-multipoint { > { > traffic flow, not multipoint-to-point. > > >{ > { > { > { Georgios: Typically yes, but in this case we > > refer { > to > > >{ { > bandwidth allocation { in a multipoint-to-point fashion. > > >{ > { > { > { > > >{ > { > { > { > > > >{ > { > { > { > > > >{ > { > { > { > Regards, > > >{ > { > { > { > > > >{ > { > { > { > // Steve > > >{ > { > { > { > > > >{ > { > { > { > > >{ > { > { > { > > >{ > { > { > { _______________________________________________ > > >{ > { > { > { 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 > > > > ______________________________________________________________ > > ______________ > > 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 Thu Aug 28 08:54:55 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E021328C152; Thu, 28 Aug 2008 08:54: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 8E4103A6CC5 for ; Thu, 28 Aug 2008 08:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.413 X-Spam-Level: * X-Spam-Status: No, score=1.413 tagged_above=-999 required=5 tests=[AWL=-0.772, BAYES_05=-1.11, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_57=0.6, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6gju-hjww1x for ; Thu, 28 Aug 2008 08:54:52 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 3EEA73A6A43 for ; Thu, 28 Aug 2008 08:54: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 m7SFs8C6026929; Thu, 28 Aug 2008 17:54:11 +0200 (MEST) From: "Georgios Karagiannis" To: "'Bob Briscoe'" References: <002101c9083b$de8d88c0$810c5982@dynamic.ewi.utwente.nl> <4A916DBC72536E419A0BD955EDECEDEC03DAA1CB@E03MVB1-UKBR.domain1.systemhost.net> <200808281130.m7SBULJA004422@bagheera.jungle.bt.co.uk> <001d01c90907$a91beb10$810c5982@dynamic.ewi.utwente.nl> <200808281507.m7SF7JtG024242@bagheera.jungle.bt.co.uk> Date: Thu, 28 Aug 2008 17:54:01 +0200 Message-ID: <002401c90926$4d6b3a90$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <200808281507.m7SF7JtG024242@bagheera.jungle.bt.co.uk> Thread-Index: AckJJJf6ntHTW0h+RJ+CxdRSYmCyiQAAFyfA 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, 28 Aug 2008 17:54:14 +0200 (MEST) Cc: pcn@ietf.org Subject: Re: [PCN] MP2P aggregates 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! > -----Original Message----- > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > Sent: donderdag 28 augustus 2008 17:07 > To: Georgios Karagiannis > Cc: philip.eardley@bt.com; slblake@petri-meat.com; pcn@ietf.org > Subject: RE: MP2P aggregates > > Georgios, > > At 13:14 28/08/2008, Georgios Karagiannis wrote: > >Hi Bob > > > >I do not want to hold the publication of the architecture draft. > >I will be happy if, related to this issue, the sentence > proposed by Ken > >in the previous email is used. > > Good, thanks > > >Regarding one of your comments: > > > > > If you want an assured MP2P aggregate, you have to build > it using a > > > set of P2P > > > (point-to-point) aggregates. > > > >Georgios: using a set of P2P aggregates to achieve this is > not required. > >The MP2P aggregation is solved by using affected marking and > just using > >one state. > >Please also note that at the same time this solution solves the ecmp > >problem. > > Pls be careful with the word 'solved'. Affected marking only > gives a partial solution - if the circumstances happen to be > fortunate. > > a) If there is pre-congestion on more than one parallel path, > the metering of marking as a proportion of affected marking > becomes a confusion of all the paths that are affected. > Multiple parallel congested links may seem a corner case, but > it's not really. PCN is intended to deal with unexpected > events. Flash crowds rarely affect only one path. Disasters > also tend not to be well-behaved. Georgios: This situation is also solved. > > b) queues on interior nodes have to switch into affected > mode, and decide to switch out of it after some time-out once > the congestion episode seems to have gone away. Georgios: If the interior mnode goes into flo termination state that affected marking is used If it goes out the flow termination then affected marking is not anymore used. > > a) and b) can interact, so that one queue is still doing > affected marking but timing out after an episode has ended, > while another queue on a parallel path can be starting an > episode. Again the markings would get confused. Georgios: Affected marking is associated with flow termination. So if a node is in flow termination will generate affecetd marking traffic. The egress node will only select flows for termination that contain marked packets encoded with either Affected marking encoding or with PC_marking encoding. So no confusion wiil take place. > > I'm not saying Affected Marking is not interesting (as > research) and possibly useful, but it relies on a wing and a > prayer (excuse the use of english idiom - this means it's a > rather precarious mechanism that isn't very deterministic). I > try to separate solid stuff ready for standards from > research, even tho I do both. Georgios: I think that the solution provided by affected mechanism behaves deterministic enough. Best regards, Georgios > > > Bob > > > >Best regards, > >Georgios > > > > > > > > > -----Original Message----- > > > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > > > Sent: donderdag 28 augustus 2008 13:30 > > > To: karagian@cs.utwente.nl > > > Cc: philip.eardley@bt.com; slblake@petri-meat.com; pcn@ietf.org > > > Subject: Re: MP2P aggregates (was: [PCN] PCN WG last call for > > > draft-ietf-pcn-architecture-05.txt) > > > > > > Georgios, > > > > > > I've started a different thread on this, because I think there is > > > general consensus that it is not relevant to the last call on the > > > current PCN architecture. > > > > > > Bringing in a completely different architecture at the > last minute > > > requires another informational doc about that architecture, not > > > holding up the current one. Here's why I say it's a completely > > > different architecture... > > > > > > Using your multipoint-to-point (MP2P) (so-called 'hose') scenario > > > and Phil's notation from earlier in the thread below, > with traffic > > > from b,c,d,e,f to A. > > > > > > b___X__________ > > > c___________ \ > > > \ \ > > > d------------+---+--> A > > > e___________/ / > > > f______________/ > > > > > > - if there's high pre-congestion on link X just after > traffic leaves > > > b (say) > > > - but traffic from c,d,e,f to A doesn't go through this > > > pre-congested link > > > - you claim A can average all the markings from b,c,d,e,f > together, > > > - giving an average for the MP2P aggregate lower than > pre-congestion > > > on b-A > > > - then A could continue to tell any of b,c,d,e,f to > accept new flows > > > - then flows will still be added to a highly > pre-congested path b-A > > > > > > If you have invented a way to solve this problem, it will involve > > > discriminating between each of the ingress-egress paths > within the > > > MP2P aggregate (perhaps using affected marking). So you > will need to > > > store state for each path and you're no longer storing > just a single > > > state for the MP2P aggregate any more. > > > > > > In MPLS fora, the implications of allowing MP2P aggregates have > > > caused years of arguments. We didn't include MP2P in the PCN > > > architecture for a very good reason: you cannot create the > > > assurances we're trying to create with MP2P aggregates. > > > If you want an assured MP2P aggregate, you have to build > it using a > > > set of P2P > > > (point-to-point) aggregates. > > > > > > We're doing other work on MP2P aggregates, but we're not > bringing it > > > to the PCN w-g. Please respect that the IETF has to limit > the scope > > > of each work item in order to achieve anything. > > > > > > Finally, if you've ever watered your garden with a hose > that sucks > > > the water off the grass back into the hose, then I will > allow you to > > > use the term hose for an MP2P aggregate. Until you can > demonstrate > > > this feat experimentally in your garden, please use words > that mean > > > what they say. Video footage running backwards will not be > > > acceptable evidence. > > > > > > > > > Bob > > > > > > At 13:03 27/08/2008, philip.eardley@bt.com wrote: > > > >You appear to be saying all 3 definitions are the same. I > > > think they're > > > >all different. > > > > > > > >Let's call the gateway nodes A, B, C, D ,E and F. > > > > > > > >Duffield: hose at A is all traffic to b,c,d,e,f and all traffic > > > >from b,c,d,e,f > > > > > > > >DiffServ: hose at A is all traffic to b,c,d,e,f > > > > > > > >Georgios: hose at A is all traffic from b,c,d,e,f > > > > > > > >{ -----Original Message----- > > > >{ From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > > > { Sent: 27 > > > >August 2008 12:56 { To: Eardley,PL,Philip,CXR9 R; > > > >slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: > > > [PCN] PCN WG > > > >last call for draft-ietf-pcn-architecture-05.txt > > > >{ > > > >{ Hi Phil > > > >{ > > > >{ Assuming that ingresses can only send data traffic and > > > egresses can { > > > >receive { data traffic, { a HOSE model that is used in the > > > PCN domain > > > >between ingress nodes and { egress { edge nodes, { is > refering to > > > >aggregates between ingress and egress edge nodes, where { > > > ingresses are > > > >{ sending traffic and egresses are receiving data traffic. > > > >{ > > > >{ Thus the HOSE aggregation model used in PCN is a HOSE > aggregation > > > >model { used between ingress and egress nodes. > > > >{ > > > >{ > > > >{ Best regards, > > > >{ Georgios > > > >{ > > > >{ > -----Original Message----- > > > >{ > From: philip.eardley@bt.com > [mailto:philip.eardley@bt.com] { > > > > >Sent: woensdag 27 augustus 2008 13:35 { > To: > > > karagian@cs.utwente.nl; > > > >slblake@petri-meat.com { > Cc: pcn@ietf.org { > Subject: RE: > > > [PCN] PCN > > > >WG last call for { > draft-ietf-pcn-architecture-05.txt > > > >{ > > > > >{ > I note that the Duffield et al definition below is > different { > > > >> from what your talking about, since their definition > includes { > > > > >traffic in both directions, whilst yours is a one way { > > > > definition. I > > > >think other people, with a DiffServ { > architecture > > > background, would > > > >interpret it as traffic from { > one ingress going to > any egress. > > > >So that's 3 possibilities. > > > >{ > > > > >{ > In any case, this is really a side issue, compared with > > > my { > main > > > >points /questions in earlier email. > > > >{ > > > > >{ > { -----Original Message----- > > > >{ > { From: Georgios Karagiannis > > > [mailto:karagian@cs.utwente.nl] { > { > > > >Sent: 27 August 2008 11:37 { To: Eardley,PL,Philip,CXR9 R; { > > > > >slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: > > > >{ > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt > > > >{ > { > > > >{ > { Hi Phil > > > >{ > { > > > >{ > { HOSE model is defined some 20 years ago, please see > > > e.g the { > > > > >following { article: > > > >{ > { > > > >{ > { N. G. Duffield, P. Goyal and A. Greenberg, "A Flexible > > > { > Model > > > >{ for Resource Management in Virtual Private Networks", in: > > > >{ > { Proc. of ACM SIGCOMM, 1999. > > > >{ > { > > > >{ > { In the above article I found the following definition: > > > >{ > { > > > >{ > { "A hose is characterized by the aggregate traffic > { to and { > > > >> from one endpoint in the VPN to the set of other { endpoints > > > { > in the > > > >VPN" > > > >{ > { > > > >{ > { Thus the definition refers to aggregated traffic to > > > and { > from > > > >one edge to { and { from all other endpoints. > > > >{ > { > > > >{ > { > > > >{ > { In our case we refer only to the aggregated > traffic from { > > > > >other endpoints { to { one endpoint. > > > >{ > { > > > >{ > { Thus what we use is in line with the definition of the > > > HOSE model. > > > >{ > { > > > >{ > { Best regards, > > > >{ > { Georgios > > > >{ > { > > > >{ > { > > > >{ > { > > > >{ > { > > > >{ > { > -----Original Message----- > > > >{ > { > From: philip.eardley@bt.com { > > > > >[mailto:philip.eardley@bt.com] { > Sent: woensdag 27 > > > augustus { > > > > >2008 11:31 { > To: karagian@cs.utwente.nl; { > > > > slblake@petri-meat.com { > > > >> Cc: pcn@ietf.org { > Subject: RE: > > > >{ > [PCN] PCN WG last call for { > > > > >draft-ietf-pcn-architecture-05.txt > > > >{ > { > > > > >{ > { > I thought your emails with steve had revealed > that your { > > > > >model { > was the exact opposite of the well known hose model? > > > >{ > { > > > > >{ > { > > > > >{ > { > { -----Original Message----- { > { > { From: Georgios > > > >Karagiannis { > [mailto:karagian@cs.utwente.nl] { > { Sent: 27 > > > >August 2008 { > > > > >09:41 { To: Eardley,PL,Philip,CXR9 R; { > { > > > > slblake@petri-meat.com { > > > >Cc: pcn@ietf.org { Subject: RE: > > > >{ > { > [PCN] PCN WG last call for > > > >draft-ietf-pcn-architecture-05.txt > > > >{ > { > { > > > >{ > { > { Hi Phil > > > >{ > { > { > > > >{ > { > { What I explained is the well know HOSE bandwidth { > > > > >management model. > > > >{ > { > { During the IETF in Dublin, Hein also shown also > > > some { { > > > > > >results { that were obtrained using the HOSE model. > > > >{ > { > { > > > >{ > { > { > > > >{ > { > { Best regards, > > > >{ > { > { Georgios > > > >{ > { > { > > > >{ > { > { > > > >{ > { > { > -----Original Message----- { > { > { > From: > > > >philip.eardley@bt.com { > { > [mailto:philip.eardley@bt.com] { > > > > >Sent: woensdag 27 { > > > > augustus { > > > > >2008 10:20 { > To: karagian@cs.utwente.nl; { > { > > > > >slblake@petri-meat.com { > Cc: pcn@ietf.org { > Subject: RE: > > > >{ > { > [PCN] PCN WG last call for { > > > > >draft-ietf-pcn-architecture-05.txt > > > >{ > { > { > > > > >{ > { > { > So the question is about adding to the draft: > > > >{ > { > { > A model where the egress measures marks coming > > > from { > all > > > >{ > the { > ingresses, and makes admission decision > based on that. > > > >{ > { > { > > > > >{ > { > { > Before adding anything about this to the > draft, I'd { > > > > >like { > to { > understand if this is a genuine practical, { > > > > >understood { > option { > (if so, OK), or if it's a { > > theoretical > > > >possibility { > or one not { > well understood. > > > >{ > { > { > (there are many things in the latter > category that { > > > > >aren't { > { > mentioned in the draft.) { > { > Questions > > > are { > why > > > >this { > is interesting, why is it better than { > the { > models > > > >already { > well-known, are there comparative analysis { > { > > > > >/simulations? > > > >{ > { > { > > > > >{ > { > { > I suppose I've got 2 general issues: > > > >{ > { > { > [1] every time something is added, overall the { > > > document > > > >{ { > becomes harder to understand, more daunting to { > > > > read & it { > > > > >> looks { less { like the WG has consensus. > > > >{ > { > { > [2] this is an INFO doc. People are free to > > > invent { > ways > > > >{ > of { > using the standards pieces other than the { > > > > architecture { > > > >> draft { > says, and indeed in ways not yet dreamt of. > > > >{ > { > { > > > > >{ > { > { > Phil. > > > >{ > { > { > > > > >{ > { > { > { -----Original Message----- { > { > { > { From: > > > >pcn-bounces@ietf.org { > { > > [mailto:pcn-bounces@ietf.org] On { > > > > >Behalf Of { Georgios { > { > Karagiannis { Sent: 27 August > > > 2008 08:54 { > > > >> { To: 'Steven Blake' > > > >{ > { > { > { Cc: pcn@ietf.org > > > >{ > { > { > { Subject: Re: [PCN] PCN WG last call for { > > { > { > > > > >draft-ietf-pcn-architecture-05.txt > > > >{ > { > { > { > > > >{ > { > { > { Hi Steven > > > >{ > { > { > { > > > >{ > { > { > { > -----Original Message----- { > { > { > { > > > > From: Steven > > > >Blake { > [mailto:slblake@petri-meat.com] { { > > { > Sent: > > > woensdag 27 > > > >{ > augustus 2008 6:18 { > To: Georgios { { > Karagiannis { > Cc: > > > >{ > pcn@ietf.org { > Subject: RE: [PCN] PCN > { > WG { last > > > { { > call > > > >for { > draft-ietf-pcn-architecture-05.txt > > > >{ > { > { > { > > > > >{ > { > { > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios > > > Karagiannis > > > >{ > wrote: > > > >{ > { > { > { > > > > >{ > { > { > { > > Hi Steven > > > >{ > { > { > { > > > > > >{ > { > { > { > > > > > >{ > { > { > { > > Please see in line! > > > >{ > { > { > { > > > > > >{ > { > { > { > > > > > >{ > { > { > { > > > -----Original Message----- { > { > { > > > { > > > > >From: Steven Blake { > [mailto:slblake@petri-meat.com] { { > > > > { > > > > > > > >Sent: dinsdag 26 { > augustus 2008 14:46 { > > > To: > > > >{ > { > { > Georgios Karagiannis { > > > Cc: pcn@ietf.org { > > > > > > { > { > > > >> { > Subject: Re: [PCN] PCN WG last call for { > > > { > { { > > > > >draft-ietf-pcn-architecture-05.txt > > > >{ > { > { > { > > > > > > >{ > { > { > { > > > On Tue, 2008-08-26 at 11:44 +0000, > Georgios { > > > > >Karagiannis { > wrote: > > > >{ > { > { > { > > > > > > >{ > { > { > { > > > > Hi Phil, Hi all { > { > { > { > > > > > { > { > > > > >{ > { > > > > Here are some comments on the PCN { > > architecture > > > >draft: > > > >{ > { > { > { > > > > > > > >{ > { > { > { > > > > 1) Thank you for clarifying the bullet > > > in { { > > > > >Setion { > 3.2 about flow { > > > > termination. > > > >{ > { > { > { > > > > > > > >{ > { > { > { > > > > 2) From what I understand the PCN { > > > > >architecture { > { > draft { > > > mentions that PCN { > > > > { > > > > > >supports only { > the { > trunk (ingress-egress-aggregate) { > > > and not > > > >the { > > > { > > HOSE model. > > > >{ > { > { > { > > > > Is the PCN architecture draft > > > excluding { > { > > > > >solutions { > that { > support the { > > > > HOSE model? If > > > { { > not, > > > >please { > emphasize in the PCN { > architecture draft { > { > > > > > > > > > > >{ > > > > >{ that { > "solutions that are based on other types { > of > > > > flow { { > > > > >> > { > { > { > { { > aggregation than { > > > > the { > { > > > > >ingress-egress-aggregate { > method of flow { > { > > aggregation, { > > > >> are not { > > > > excluded { > from the PCN { > WG activities." > > > >{ > { > { > { > > > > > > >{ > { > { > { > > > Actually they are, by our charter. > > > >{ > { > { > { > > > > > >{ > { > { > { > > I have not seen that the PCN charter > excludes { > > > > >other { > { > types { > of aggregation. > > > >{ > { > { > { > > > > >{ > { > { > { > Well, I checked, and you are correct (mea culpa). > > > >{ > { > { > { Georgios: No problem > > > >{ > { > { > { > > > >{ > { > { > { > > > > >{ > { > { > { > > Please note > > > >{ > { > { > { > > that I am refering to the HOSE model where > > > the { > { > > > >> traffic { > sent { > by one or { > > more than one { > > > > ingresses { > > > > >towards one { > egress is aggregated at the { > { > > > egress. In { > > > >> this way higgher { > traffic aggregation can { > be > > > accomplished { > { > > > >> > than in the { > situation that the { > pipe/trunk { > { > > > > >(ingress-egress-aggregate) { > { > > is { > used, where the > > > { > traffic > > > >sent by only one ingress in { > { > aggegated at { > > > the egress. > > > >{ > { > { > { > > > > >{ > { > { > { > Typically the "hose" model refers to { > { > > > > >point-to-multipoint { > { > traffic flow, not > multipoint-to-point. > > > >{ > { > { > { Georgios: Typically yes, but in this case we > > > refer { > to > > > >{ { > bandwidth allocation { in a multipoint-to-point fashion. > > > >{ > { > { > { > > > >{ > { > { > { > > > > >{ > { > { > { > > > > >{ > { > { > { > Regards, > > > >{ > { > { > { > > > > >{ > { > { > { > // Steve > > > >{ > { > { > { > > > > >{ > { > { > { > > > >{ > { > { > { > > > >{ > { > { > { _______________________________________________ > > > >{ > { > { > { 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 > > > > > > ______________________________________________________________ > > > ______________ > > > 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 Thu Aug 28 09:23:24 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70EB3A694E; Thu, 28 Aug 2008 09:23: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 0360C3A692B for ; Thu, 28 Aug 2008 09:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.017 X-Spam-Level: X-Spam-Status: No, score=-1.017 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_57=0.6, 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 NYhkSNYJZMhH for ; Thu, 28 Aug 2008 09:23:17 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id D92273A67DF for ; Thu, 28 Aug 2008 09:23:16 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Aug 2008 17:23:18 +0100 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, 28 Aug 2008 17:23:17 +0100 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 1219940597354; Thu, 28 Aug 2008 17:23:17 +0100 Received: from mut.jungle.bt.co.uk ([10.73.69.128]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m7SGNFau030501; Thu, 28 Aug 2008 17:23:15 +0100 Message-Id: <200808281623.m7SGNFau030501@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 28 Aug 2008 17:23:14 +0100 To: From: Bob Briscoe In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA1E6@E03MVB1-UKBR.doma in1.systemhost.net> References: <200808281217.m7SCHPQc008585@bagheera.jungle.bt.co.uk> <4A916DBC72536E419A0BD955EDECEDEC03DAA1E6@E03MVB1-UKBR.domain1.systemhost.net> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 28 Aug 2008 16:23:17.0979 (UTC) FILETIME=[6123EAB0:01C9092A] Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 & list, For a bit of light relief... I did consider suggesting that an operator wanting to deploy PCN in a domain that also used non-IPSec tunnels could create COTS (common off-the-shelf) IP in IP tunnels that exhibit the required behaviour for PCN by using null encryption [RFC2410] with ESP (encrypting security payload). This would use IPSec to copy ECN at tunnel ingress, but not require any key management. RFC2410 is probably the closest that security people get to smiling. Bob At 14:16 28/08/2008, philip.eardley@bt.com wrote: >Sounds good clarification to me, thanks bob > >phil > >{ -----Original Message----- >{ From: Briscoe,RJ,Bob,XVR9 BRISCORJ R >{ Sent: 28 August 2008 13:16 >{ To: Eardley,PL,Philip,CXR9 R >{ Cc: pcn; Steven Blake >{ Subject: Re: [PCN] PCN WG last call for >draft-ietf-pcn-architecture-05.txt >{ >{ Phil, >{ >{ I know the last call ended yesterday, but as I think you agreed to >{ make some tweaks to the text, you might want to consider this >{ addition to "Sec 7.7 Tunnelling" as well. >{ >{ Current text: >{ o any PCN-marking is copied into the outer header >{ >{ Suggested new text >{ o any PCN-marking is copied into the outer header >{ >{ Note that a tunnel will not provide this behaviour if it complies >{ with [RFC3168] tunnelling in either mode, but it will if it >complies >{ with [RFC4301] IPSec tunnelling. >{ >----------------------------------------------------------------------- >{ >{ Current text: >{ Similarly, in line with the "uniform conceptual model" of >[RFC2983] >{ and the "full-functionality option" of [RFC3168], the following >rule >{ is applied if decapsulation is done within the PCN-domain: >{ >{ Suggested new text >{ Similarly, in line with the "uniform conceptual model" of >[RFC2983], >{ with [RFC4301] and with the "full-functionality mode" of >[RFC3168], >{ the following rule is applied if decapsulation is done within the >PCN- >{ domain: >{ >----------------------------------------------------------------------- >{ >{ >{ Bob >{ >{ At 13:35 22/08/2008, Steven Blake wrote: >{ >On Fri, 2008-08-08 at 20:03 -0400, Steven Blake wrote: >{ > >{ > > This message starts a 2+-week PCN working group last call for >{ advancing >{ > > >{ > > Title : Pre-Congestion Notification Architecture >{ > > Author(s) : P. Eardley >{ > > Filename : draft-ietf-pcn-architecture-05.txt >{ > > Pages : 54 >{ > > Date : 2008-08-07 >{ > > >{ > > as an Informational RFC. Substantive comments and statements of >{ support >{ > > for this draft should be sent to the pcn mailing list. Editorial >{ > > suggestions can be sent directly to the document editor. >{ > > The last call will end on Wednesday August 27. >{ > >{ >A reminder that this last call closes next Wednesday. >{ > >{ > >{ >Regards, >{ > >{ >// Steve >{ > >{ >_______________________________________________ >{ >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 ____________________________________________________________________________ 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 Aug 28 23:25:34 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E7363A6964; Thu, 28 Aug 2008 23:25: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 C6F4A3A696C for ; Thu, 28 Aug 2008 23:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 s10cAKnm6BA5 for ; Thu, 28 Aug 2008 23:25:31 -0700 (PDT) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id D15B23A6964 for ; Thu, 28 Aug 2008 23:25:30 -0700 (PDT) Received: from s4de8psaans.mitte.t-com.de (s4de8psaans.mitte.t-com.de [10.151.180.168]) by tcmail21.telekom.de with ESMTP; Fri, 29 Aug 2008 08:25:31 +0200 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 29 Aug 2008 08:25:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Aug 2008 08:25:30 +0200 Message-Id: <1B6169C658325341A3B8066E23919E1C01B115ED@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: <001301c908fb$13807910$810c5982@dynamic.ewi.utwente.nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt thread-index: AckH+/QV3Y45tt6jSHmIy28ziDldOAAHfAOAAACCC8AAAQ+VQAABwDwQAAIzkmAAMG5/AAACOGNQAABYCEA= References: <000501c90820$b1efaca0$810c5982@dynamic.ewi.utwente.nl><4A916DBC72536E419A0BD955EDECEDEC03DAA1C6@E03MVB1-UKBR.domain1.systemhost.net> <001c01c90830$dc8f96e0$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1C01B11310@S4DE8PSAANK.mitte.t-com.de> <001301c908fb$13807910$810c5982@dynamic.ewi.utwente.nl> From: "Geib, Ruediger" To: X-OriginalArrivalTime: 29 Aug 2008 06:25:31.0070 (UTC) FILETIME=[0935ADE0:01C909A0] Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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, sorry for the rude reaction yesterday. I appreciate the contribution of you and your team to the experiments = around PCN as I do appreciate all other PCN experiments known to me. = This holds whether the text of the architecture document remains as = is or not. = Regards, Ruediger = -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] = Sent: Thursday, August 28, 2008 12:45 PM To: Geib, R=FCdiger Cc: pcn@ietf.org Subject: RE: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt Hi Ruediger As I shown in previous emails, the definition of the HOSE model covers an wide area = and its interpretation depends on the context. Thus the mentioned model can be seen as a HOSE model in the PCN context. As you could follow the discussion with Steven, this model is = not out of the PCN WG scope. Best regards, Georgios > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] = > Sent: donderdag 28 augustus 2008 11:44 > To: karagian@cs.utwente.nl > Cc: pcn@ietf.org > Subject: RE: [PCN] PCN WG last call for = > draft-ietf-pcn-architecture-05.txt > = > Georgios, > = > the hose model on an ingress node requires functionalities = > treating packets irrespective disregarding the destination = > address and the hose model applied to an egress node there = > require functionalities working on all packets disregarding = > their origin address. = > = > I've copied in two sections of draft westberg. The mechanisms = > mentioned there with regard to the hose model: > - are obviously not related to the hose model. > - are out of scope of the PCN WG. > = > I think the WG can go on now. > = > Regards, > = > Ruediger > = > = > = > Quotes from draft-westberg-pcn-load-control-04 > = > 3.1.2.2. PCN-egress-node features > = > [snip] > = > Note that if an edge-to-edge pair aggregated state is not available > at the PCN-egress-node, e.g., when the HOSE model is used then the > PCN-egress-node cannot determine whether a PCN-egress-node = > associated > with the edge-to-edge pair PCN aggregate operates in Normal state, > Admission Control state or Flow Termination state. = > However, even in > this case, when a probe packet arrives at the PCN-egress-node, then > this request should be rejected if the probe packet is PCN_marking > encoded. Otherwise, i.e., if the probe packet is not PCN_marking > encoded, it should be accepted. = > = > 3.2.2. PCN-egress-node > = > [snip] > = > Note that in the ingress-egress-aggregate model the excess rate and > the flows to be terminated are associated with the same = > edge-to-edge > (i.e., ingress-egress) pair PCN aggregate and with the same traffic > class, i.e., PHB. In the HOSE model the excess rate and = > the flows to > be terminated are associated with the same traffic class, = > i.e., PHB. > The PCN-egress-node needs to store for each flow the address, e.g., > IP address and port number, of the PCN-ingress-node from where the > particular flow passed before arriving to the = > PCN-egress-node. This > can be for example done by using information that is carried by the > external protocols used in combination with the LC-PCN = > solution. For > the flows that should be terminated the PCN-egress-node informs the > associated PCN-ingress-node to terminate them. If the PCN domain > uses thet ingress-egress-aggregate model and if the PCN-egress-node > receives any admission flow request, belonging to a ingress-egress- > aggregate state operating in flow termination state then = > the request > must be rejected. = > = > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On = > Behalf Of Georgios Karagiannis > Sent: Wednesday, August 27, 2008 12:37 PM > To: philip.eardley@bt.com; slblake@petri-meat.com > Cc: pcn@ietf.org > Subject: Re: [PCN] PCN WG last call for = > draft-ietf-pcn-architecture-05.txt > = > Hi Phil > = > HOSE model is defined some 20 years ago, please see e.g the following > article: > = > N. G. Duffield, P. Goyal and A. Greenberg, "A Flexible Model = > for Resource Management in Virtual Private Networks", in: > Proc. of ACM SIGCOMM, 1999. > = > In the above article I found the following definition: > = > "A hose is characterized by the aggregate traffic to and from = > one endpoint in the VPN to the set of other endpoints in the VPN" > = > Thus the definition refers to aggregated traffic to and from = > one edge to and from all other endpoints. > = > = > In our case we refer only to the aggregated traffic from = > other endpoints to one endpoint. > = > Thus what we use is in line with the definition of the HOSE model. > = > Best regards, > Georgios > = > = > = > = > > -----Original Message----- > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > Sent: woensdag 27 augustus 2008 11:31 > > To: karagian@cs.utwente.nl; slblake@petri-meat.com > > Cc: pcn@ietf.org > > Subject: RE: [PCN] PCN WG last call for = > > draft-ietf-pcn-architecture-05.txt > > = > > I thought your emails with steve had revealed that your = > model was the = > > exact opposite of the well known hose model? > > = > > = > > { -----Original Message----- > > { From: Georgios Karagiannis = > [mailto:karagian@cs.utwente.nl] { Sent: = > > 27 August 2008 09:41 { To: Eardley,PL,Philip,CXR9 R; = > > slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: > > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt > > { > > { Hi Phil > > { > > { What I explained is the well know HOSE bandwidth management model. > > { During the IETF in Dublin, Hein also shown also some = > results { that = > > were obtrained using the HOSE model. > > { > > { > > { Best regards, > > { Georgios > > { > > { > > { > -----Original Message----- > > { > From: philip.eardley@bt.com > > [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 augustus > > 2008 10:20 { > To: karagian@cs.utwente.nl; = > slblake@petri-meat.com { > = > > Cc: pcn@ietf.org { > Subject: RE: > > [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt > > { > > > { > So the question is about adding to the draft: > > { > A model where the egress measures marks coming from all the { > = > > ingresses, and makes admission decision based on that. > > { > > > { > Before adding anything about this to the draft, I'd like to { > = > > understand if this is a genuine practical, understood = > option { > (if = > > so, OK), or if it's a theoretical possibility or one not { > well = > > understood. > > { > (there are many things in the latter category that aren't { > = > > mentioned in the draft.) { > { > Questions are why this is = > > interesting, why is it better than { > the models already = > well-known, = > > are there comparative analysis { > /simulations? > > { > > > { > I suppose I've got 2 general issues: > > { > [1] every time something is added, overall the document = > { becomes = > > harder to understand, more daunting to read & it { > > looks less > like the WG has consensus. > > { > [2] this is an INFO doc. People are free to invent ways of { > = > > using the standards pieces other than the architecture = > draft { > says, = > > and indeed in ways not yet dreamt of. > > { > > > { > Phil. > > { > > > { > { -----Original Message----- > > { > { From: pcn-bounces@ietf.org > > [mailto:pcn-bounces@ietf.org] On { > Behalf Of { Georgios = > Karagiannis = > > { Sent: 27 August 2008 08:54 { > { To: 'Steven Blake' > > { > { Cc: pcn@ietf.org > > { > { Subject: Re: [PCN] PCN WG last call for { > = > > draft-ietf-pcn-architecture-05.txt > > { > { > > { > { Hi Steven > > { > { > > { > { > -----Original Message----- > > { > { > From: Steven Blake [mailto:slblake@petri-meat.com] { > > > { > Sent: woensdag 27 augustus 2008 6:18 { > To: Georgios { > > Karagiannis { > Cc: pcn@ietf.org { > Subject: RE: [PCN] PCN = > > { > WG = > > last > call for { > draft-ietf-pcn-architecture-05.txt > > { > { > > > { > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios = > Karagiannis wrote: > > { > { > > > { > { > > Hi Steven > > { > { > > > > { > { > > > > { > { > > Please see in line! > > { > { > > > > { > { > > > > { > { > > > -----Original Message----- { > { > > > From: = > Steven Blake = > > [mailto:slblake@petri-meat.com] { { > > > > Sent: dinsdag = > 26 augustus = > > 2008 14:46 { > > > To: > > { > Georgios Karagiannis { > > > Cc: pcn@ietf.org { > > > { > > > Subject: Re: [PCN] PCN WG last call for { > > > { > = > > draft-ietf-pcn-architecture-05.txt > > { > { > > > > > { > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios Karagiannis > > wrote: > > { > { > > > > > { > { > > > > Hi Phil, Hi all > > { > { > > > > > > { > { > > > > Here are some comments on the PCN architecture draft: > > { > { > > > > > > { > { > > > > 1) Thank you for clarifying the bullet in = > Setion { > 3.2 = > > about flow { > > > > termination. > > { > { > > > > > > { > { > > > > 2) From what I understand the PCN = > architecture { > draft = > > { > > > mentions that PCN { > > > > supports only the { > trunk = > > (ingress-egress-aggregate) and not the { > > > > > > HOSE model. > > { > { > > > > Is the PCN architecture draft excluding solutions { > = > > that { > support the { > > > > HOSE model? If not, please { > = > > emphasize in the PCN { > architecture draft { > > > > > that { > "solutions that are based on other types of = > > flow { > = > > > > > > > > { > aggregation than { > > > > the = > > ingress-egress-aggregate { > method of flow { > = > aggregation, are not { = > > > > > > excluded { > from the PCN WG activities." > > { > { > > > > > { > { > > > Actually they are, by our charter. > > { > { > > > > { > { > > I have not seen that the PCN charter excludes other { > = > > types { > of aggregation. > > { > { > > > { > { > Well, I checked, and you are correct (mea culpa). > > { > { Georgios: No problem > > { > { > > { > { > > > { > { > > Please note > > { > { > > that I am refering to the HOSE model where the = > traffic { > = > > sent { > by one or { > > more than one ingresses towards one { > = > > egress is aggregated at the { > > egress. In this way higgher { > = > > traffic aggregation can be accomplished { > > than in the { > = > > situation that the pipe/trunk { > > > (ingress-egress-aggregate) { > { > > is used, where the = > traffic sent = > > by only one ingress in { > aggegated at { > > the egress. > > { > { > > > { > { > Typically the "hose" model refers to = > point-to-multipoint { > { = > > > traffic flow, not multipoint-to-point. > > { > { Georgios: Typically yes, but in this case we refer to { = > > bandwidth allocation { in a multipoint-to-point fashion. > > { > { > > { > { > > > { > { > > > { > { > Regards, > > { > { > > > { > { > // Steve > > { > { > > > { > { > > { > { > > { > { _______________________________________________ > > { > { 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 Aug 28 23:38:58 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0EF828C0E7; Thu, 28 Aug 2008 23:38: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 17F2E3A6945 for ; Thu, 28 Aug 2008 23:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_72=0.6, 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 4lgH8IbImaxD for ; Thu, 28 Aug 2008 23:38:52 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 1D42128C0E7 for ; Thu, 28 Aug 2008 23:38:51 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id E27B521253; Fri, 29 Aug 2008 08:38:43 +0200 (CEST) X-AuditID: c1b4fb3e-a9e87bb000007a96-66-48b7997332df Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id B6E59200EB; Fri, 29 Aug 2008 08:38:43 +0200 (CEST) Received: from esealmw106.eemea.ericsson.se ([153.88.200.69]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Aug 2008 08:38:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Aug 2008 08:38:42 +0200 Message-ID: In-Reply-To: <1B6169C658325341A3B8066E23919E1C01B115ED@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt Thread-Index: AckH+/QV3Y45tt6jSHmIy28ziDldOAAHfAOAAACCC8AAAQ+VQAABwDwQAAIzkmAAMG5/AAACOGNQAABYCEAAKQ/k4A== References: <000501c90820$b1efaca0$810c5982@dynamic.ewi.utwente.nl><4A916DBC72536E419A0BD955EDECEDEC03DAA1C6@E03MVB1-UKBR.domain1.systemhost.net><001c01c90830$dc8f96e0$810c5982@dynamic.ewi.utwente.nl><1B6169C658325341A3B8066E23919E1C01B11310@S4DE8PSAANK.mitte.t-com.de><001301c908fb$13807910$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1C01B115ED@S4DE8PSAANK.mitte.t-com.de> From: "Lars Westberg" To: "Geib, Ruediger" , X-OriginalArrivalTime: 29 Aug 2008 06:38:43.0229 (UTC) FILETIME=[E15F8CD0:01C909A1] X-Brightmail-Tracker: AAAAAA== Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 am sorry, but you probably do not know about all experiments regarding PC= N even if it was not denoted PCN at that time. We started nine years ago, s= o there several experiments that have not ben presented in this forum. many= of the discussion are identical what we investigated at that time. = We also discussed the trunk vs hose model (and combination of them) and the= issues regarding scalalabillity of the trunk-model is a real issue. The nu= mber of trunks is cuasing a N^2 mesh configuration problem. = -Lasse = -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Geib,= Ruediger Sent: den 29 augusti 2008 08:26 To: karagian@cs.utwente.nl Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt Georgios, sorry for the rude reaction yesterday. I appreciate the contribution of you and your team to the experiments aroun= d PCN as I do appreciate all other PCN experiments known to me. = This holds whether the text of the architecture document remains as is or n= ot. = Regards, Ruediger = -----Original Message----- From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] Sent: Thursday, August 28, 2008 12:45 PM To: Geib, R=FCdiger Cc: pcn@ietf.org Subject: RE: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt Hi Ruediger As I shown in previous emails, the definition of the HOSE model covers an w= ide area and its interpretation depends on the context. Thus the mentioned model can be seen as a HOSE model in the PCN context. As you could follow the discussion with Steven, this model is not out of th= e PCN WG scope. Best regards, Georgios > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > Sent: donderdag 28 augustus 2008 11:44 > To: karagian@cs.utwente.nl > Cc: pcn@ietf.org > Subject: RE: [PCN] PCN WG last call for = > draft-ietf-pcn-architecture-05.txt > = > Georgios, > = > the hose model on an ingress node requires functionalities treating = > packets irrespective disregarding the destination address and the hose = > model applied to an egress node there require functionalities working = > on all packets disregarding their origin address. > = > I've copied in two sections of draft westberg. The mechanisms = > mentioned there with regard to the hose model: > - are obviously not related to the hose model. > - are out of scope of the PCN WG. > = > I think the WG can go on now. > = > Regards, > = > Ruediger > = > = > = > Quotes from draft-westberg-pcn-load-control-04 > = > 3.1.2.2. PCN-egress-node features > = > [snip] > = > Note that if an edge-to-edge pair aggregated state is not available > at the PCN-egress-node, e.g., when the HOSE model is used then the > PCN-egress-node cannot determine whether a PCN-egress-node = > associated > with the edge-to-edge pair PCN aggregate operates in Normal state, > Admission Control state or Flow Termination state. = > However, even in > this case, when a probe packet arrives at the PCN-egress-node, then > this request should be rejected if the probe packet is PCN_marking > encoded. Otherwise, i.e., if the probe packet is not PCN_marking > encoded, it should be accepted. = > = > 3.2.2. PCN-egress-node > = > [snip] > = > Note that in the ingress-egress-aggregate model the excess rate and > the flows to be terminated are associated with the same = > edge-to-edge > (i.e., ingress-egress) pair PCN aggregate and with the same traffic > class, i.e., PHB. In the HOSE model the excess rate and the flows = > to > be terminated are associated with the same traffic class, i.e., = > PHB. > The PCN-egress-node needs to store for each flow the address, e.g., > IP address and port number, of the PCN-ingress-node from where the > particular flow passed before arriving to the PCN-egress-node. = > This > can be for example done by using information that is carried by the > external protocols used in combination with the LC-PCN solution. = > For > the flows that should be terminated the PCN-egress-node informs the > associated PCN-ingress-node to terminate them. If the PCN domain > uses thet ingress-egress-aggregate model and if the PCN-egress-node > receives any admission flow request, belonging to a ingress-egress- > aggregate state operating in flow termination state then the = > request > must be rejected. = > = > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = > Georgios Karagiannis > Sent: Wednesday, August 27, 2008 12:37 PM > To: philip.eardley@bt.com; slblake@petri-meat.com > Cc: pcn@ietf.org > Subject: Re: [PCN] PCN WG last call for = > draft-ietf-pcn-architecture-05.txt > = > Hi Phil > = > HOSE model is defined some 20 years ago, please see e.g the following > article: > = > N. G. Duffield, P. Goyal and A. Greenberg, "A Flexible Model for = > Resource Management in Virtual Private Networks", in: > Proc. of ACM SIGCOMM, 1999. > = > In the above article I found the following definition: > = > "A hose is characterized by the aggregate traffic to and from one = > endpoint in the VPN to the set of other endpoints in the VPN" > = > Thus the definition refers to aggregated traffic to and from one edge = > to and from all other endpoints. > = > = > In our case we refer only to the aggregated traffic from other = > endpoints to one endpoint. > = > Thus what we use is in line with the definition of the HOSE model. > = > Best regards, > Georgios > = > = > = > = > > -----Original Message----- > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > Sent: woensdag 27 augustus 2008 11:31 > > To: karagian@cs.utwente.nl; slblake@petri-meat.com > > Cc: pcn@ietf.org > > Subject: RE: [PCN] PCN WG last call for = > > draft-ietf-pcn-architecture-05.txt > > = > > I thought your emails with steve had revealed that your > model was the > > exact opposite of the well known hose model? > > = > > = > > { -----Original Message----- > > { From: Georgios Karagiannis > [mailto:karagian@cs.utwente.nl] { Sent: = > > 27 August 2008 09:41 { To: Eardley,PL,Philip,CXR9 R; = > > slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: > > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt > > { > > { Hi Phil > > { > > { What I explained is the well know HOSE bandwidth management model. > > { During the IETF in Dublin, Hein also shown also some > results { that > > were obtrained using the HOSE model. > > { > > { > > { Best regards, > > { Georgios > > { > > { > > { > -----Original Message----- > > { > From: philip.eardley@bt.com > > [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 augustus > > 2008 10:20 { > To: karagian@cs.utwente.nl; > slblake@petri-meat.com { > > > Cc: pcn@ietf.org { > Subject: RE: > > [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt > > { > > > { > So the question is about adding to the draft: > > { > A model where the egress measures marks coming from all the { > = > > ingresses, and makes admission decision based on that. > > { > > > { > Before adding anything about this to the draft, I'd like to { > = > > understand if this is a genuine practical, understood > option { > (if > > so, OK), or if it's a theoretical possibility or one not { > well = > > understood. > > { > (there are many things in the latter category that aren't { > = > > mentioned in the draft.) { > { > Questions are why this is = > > interesting, why is it better than { > the models already > well-known, > > are there comparative analysis { > /simulations? > > { > > > { > I suppose I've got 2 general issues: > > { > [1] every time something is added, overall the document > { becomes > > harder to understand, more daunting to read & it { > > looks less > like the WG has consensus. > > { > [2] this is an INFO doc. People are free to invent ways of { > = > > using the standards pieces other than the architecture > draft { > says, > > and indeed in ways not yet dreamt of. > > { > > > { > Phil. > > { > > > { > { -----Original Message----- > > { > { From: pcn-bounces@ietf.org > > [mailto:pcn-bounces@ietf.org] On { > Behalf Of { Georgios > Karagiannis > > { Sent: 27 August 2008 08:54 { > { To: 'Steven Blake' > > { > { Cc: pcn@ietf.org > > { > { Subject: Re: [PCN] PCN WG last call for { > = > > draft-ietf-pcn-architecture-05.txt > > { > { > > { > { Hi Steven > > { > { > > { > { > -----Original Message----- > > { > { > From: Steven Blake [mailto:slblake@petri-meat.com] { > > > { > Sent: woensdag 27 augustus 2008 6:18 { > To: Georgios { > > Karagiannis { > Cc: pcn@ietf.org { > Subject: RE: [PCN] PCN { > WG = > > last > call for { > draft-ietf-pcn-architecture-05.txt > > { > { > > > { > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios > Karagiannis wrote: > > { > { > > > { > { > > Hi Steven > > { > { > > > > { > { > > > > { > { > > Please see in line! > > { > { > > > > { > { > > > > { > { > > > -----Original Message----- { > { > > > From: = > Steven Blake > > [mailto:slblake@petri-meat.com] { { > > > > Sent: dinsdag > 26 augustus > > 2008 14:46 { > > > To: > > { > Georgios Karagiannis { > > > Cc: pcn@ietf.org { > > > { > > > Subject: Re: [PCN] PCN WG last call for { > > > { > = > > draft-ietf-pcn-architecture-05.txt > > { > { > > > > > { > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios Karagiannis > > wrote: > > { > { > > > > > { > { > > > > Hi Phil, Hi all > > { > { > > > > > > { > { > > > > Here are some comments on the PCN architecture draft: > > { > { > > > > > > { > { > > > > 1) Thank you for clarifying the bullet in > Setion { > 3.2 > > about flow { > > > > termination. > > { > { > > > > > > { > { > > > > 2) From what I understand the PCN > architecture { > draft > > { > > > mentions that PCN { > > > > supports only the { > trunk > > (ingress-egress-aggregate) and not the { > > > > > > HOSE model. > > { > { > > > > Is the PCN architecture draft excluding solutions { > = > > that { > support the { > > > > HOSE model? If not, please { > = > > emphasize in the PCN { > architecture draft { > > > > > that { > "solutions that are based on other types of > > flow { > > > > > > > > > { > aggregation than { > > > > the > > ingress-egress-aggregate { > method of flow { > > aggregation, are not { > > > > > > excluded { > from the PCN WG activities." > > { > { > > > > > { > { > > > Actually they are, by our charter. > > { > { > > > > { > { > > I have not seen that the PCN charter excludes other { > = > > types { > of aggregation. > > { > { > > > { > { > Well, I checked, and you are correct (mea culpa). > > { > { Georgios: No problem > > { > { > > { > { > > > { > { > > Please note > > { > { > > that I am refering to the HOSE model where the > traffic { > > > sent { > by one or { > > more than one ingresses towards one { > = > > egress is aggregated at the { > > egress. In this way higgher { > = > > traffic aggregation can be accomplished { > > than in the { > = > > situation that the pipe/trunk { > > > (ingress-egress-aggregate) { > { > > is used, where the > traffic sent > > by only one ingress in { > aggegated at { > > the egress. > > { > { > > > { > { > Typically the "hose" model refers to > point-to-multipoint { > { > > > traffic flow, not multipoint-to-point. > > { > { Georgios: Typically yes, but in this case we refer to { = > > bandwidth allocation { in a multipoint-to-point fashion. > > { > { > > { > { > > > { > { > > > { > { > Regards, > > { > { > > > { > { > // Steve > > { > { > > > { > { > > { > { > > { > { _______________________________________________ > > { > { 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 Mon Sep 1 01:03:27 2008 Return-Path: X-Original-To: pcn-archive@optimus.ietf.org Delivered-To: ietfarch-pcn-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 841DD3A68E3; Mon, 1 Sep 2008 01:03: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 0BB4A3A68E3 for ; Mon, 1 Sep 2008 01:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.707 X-Spam-Level: * X-Spam-Status: No, score=1.707 tagged_above=-999 required=5 tests=[AWL=-0.989, BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZiIZBavteqmE for ; Mon, 1 Sep 2008 01:03: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 68BD53A67A4 for ; Mon, 1 Sep 2008 01:03: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 m8183MQa007156; Mon, 1 Sep 2008 10:03:26 +0200 (MEST) From: "Georgios Karagiannis" To: "'Geib, Ruediger'" References: <000501c90820$b1efaca0$810c5982@dynamic.ewi.utwente.nl><4A916DBC72536E419A0BD955EDECEDEC03DAA1C6@E03MVB1-UKBR.domain1.systemhost.net> <001c01c90830$dc8f96e0$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1C01B11310@S4DE8PSAANK.mitte.t-com.de> <001301c908fb$13807910$810c5982@dynamic.ewi.utwente.nl> <1B6169C658325341A3B8066E23919E1C01B115ED@S4DE8PSAANK.mitte.t-com.de> Date: Mon, 1 Sep 2008 10:03:19 +0200 Message-ID: <001301c90c09$36254160$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: AckH+/QV3Y45tt6jSHmIy28ziDldOAAHfAOAAACCC8AAAQ+VQAABwDwQAAIzkmAAMG5/AAACOGNQAABYCEAAwzn5kA== In-Reply-To: <1B6169C658325341A3B8066E23919E1C01B115ED@S4DE8PSAANK.mitte.t-com.de> 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, 01 Sep 2008 10:03:27 +0200 (MEST) Cc: pcn@ietf.org Subject: Re: [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt 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 Thank you for sending this email! Apology is accepted! Best regards, Georgios = > -----Original Message----- > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] = > Sent: vrijdag 29 augustus 2008 8:26 > To: karagian@cs.utwente.nl > Cc: pcn@ietf.org > Subject: RE: [PCN] PCN WG last call for = > draft-ietf-pcn-architecture-05.txt > = > Georgios, > = > sorry for the rude reaction yesterday. > = > I appreciate the contribution of you and your team to the = > experiments around PCN as I do appreciate all other PCN = > experiments known to me. = > = > This holds whether the text of the architecture document = > remains as is or not. = > = > Regards, > = > Ruediger = > = > -----Original Message----- > From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] > Sent: Thursday, August 28, 2008 12:45 PM > To: Geib, R=FCdiger > Cc: pcn@ietf.org > Subject: RE: [PCN] PCN WG last call for = > draft-ietf-pcn-architecture-05.txt > = > Hi Ruediger > = > As I shown in previous emails, the definition of the HOSE = > model covers an wide area and its interpretation depends on = > the context. > Thus the mentioned model can be seen as a HOSE model in the = > PCN context. > = > As you could follow the discussion with Steven, this model is = > not out of the PCN WG scope. > = > Best regards, > Georgios > = > = > = > = > > -----Original Message----- > > From: Geib, Ruediger [mailto:Ruediger.Geib@t-systems.com] > > Sent: donderdag 28 augustus 2008 11:44 > > To: karagian@cs.utwente.nl > > Cc: pcn@ietf.org > > Subject: RE: [PCN] PCN WG last call for = > > draft-ietf-pcn-architecture-05.txt > > = > > Georgios, > > = > > the hose model on an ingress node requires functionalities treating = > > packets irrespective disregarding the destination address = > and the hose = > > model applied to an egress node there require = > functionalities working = > > on all packets disregarding their origin address. > > = > > I've copied in two sections of draft westberg. The mechanisms = > > mentioned there with regard to the hose model: > > - are obviously not related to the hose model. > > - are out of scope of the PCN WG. > > = > > I think the WG can go on now. > > = > > Regards, > > = > > Ruediger > > = > > = > > = > > Quotes from draft-westberg-pcn-load-control-04 > > = > > 3.1.2.2. PCN-egress-node features > > = > > [snip] > > = > > Note that if an edge-to-edge pair aggregated state is = > not available > > at the PCN-egress-node, e.g., when the HOSE model is = > used then the > > PCN-egress-node cannot determine whether a PCN-egress-node = > > associated > > with the edge-to-edge pair PCN aggregate operates in = > Normal state, > > Admission Control state or Flow Termination state. = > > However, even in > > this case, when a probe packet arrives at the = > PCN-egress-node, then > > this request should be rejected if the probe packet is = > PCN_marking > > encoded. Otherwise, i.e., if the probe packet is not PCN_marking > > encoded, it should be accepted. = > > = > > 3.2.2. PCN-egress-node > > = > > [snip] > > = > > Note that in the ingress-egress-aggregate model the = > excess rate and > > the flows to be terminated are associated with the same = > > edge-to-edge > > (i.e., ingress-egress) pair PCN aggregate and with the = > same traffic > > class, i.e., PHB. In the HOSE model the excess rate and = > the flows = > > to > > be terminated are associated with the same traffic class, i.e., = > > PHB. > > The PCN-egress-node needs to store for each flow the = > address, e.g., > > IP address and port number, of the PCN-ingress-node from = > where the > > particular flow passed before arriving to the PCN-egress-node. = > > This > > can be for example done by using information that is = > carried by the > > external protocols used in combination with the LC-PCN = > solution. = > > For > > the flows that should be terminated the PCN-egress-node = > informs the > > associated PCN-ingress-node to terminate them. If the PCN domain > > uses thet ingress-egress-aggregate model and if the = > PCN-egress-node > > receives any admission flow request, belonging to a = > ingress-egress- > > aggregate state operating in flow termination state then the = > > request > > must be rejected. = > > = > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On = > Behalf Of = > > Georgios Karagiannis > > Sent: Wednesday, August 27, 2008 12:37 PM > > To: philip.eardley@bt.com; slblake@petri-meat.com > > Cc: pcn@ietf.org > > Subject: Re: [PCN] PCN WG last call for = > > draft-ietf-pcn-architecture-05.txt > > = > > Hi Phil > > = > > HOSE model is defined some 20 years ago, please see e.g the = > following > > article: > > = > > N. G. Duffield, P. Goyal and A. Greenberg, "A Flexible Model for = > > Resource Management in Virtual Private Networks", in: > > Proc. of ACM SIGCOMM, 1999. > > = > > In the above article I found the following definition: > > = > > "A hose is characterized by the aggregate traffic to and from one = > > endpoint in the VPN to the set of other endpoints in the VPN" > > = > > Thus the definition refers to aggregated traffic to and = > from one edge = > > to and from all other endpoints. > > = > > = > > In our case we refer only to the aggregated traffic from other = > > endpoints to one endpoint. > > = > > Thus what we use is in line with the definition of the HOSE model. > > = > > Best regards, > > Georgios > > = > > = > > = > > = > > > -----Original Message----- > > > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > > Sent: woensdag 27 augustus 2008 11:31 > > > To: karagian@cs.utwente.nl; slblake@petri-meat.com > > > Cc: pcn@ietf.org > > > Subject: RE: [PCN] PCN WG last call for = > > > draft-ietf-pcn-architecture-05.txt > > > = > > > I thought your emails with steve had revealed that your > > model was the > > > exact opposite of the well known hose model? > > > = > > > = > > > { -----Original Message----- > > > { From: Georgios Karagiannis > > [mailto:karagian@cs.utwente.nl] { Sent: = > > > 27 August 2008 09:41 { To: Eardley,PL,Philip,CXR9 R; = > > > slblake@petri-meat.com { Cc: pcn@ietf.org { Subject: RE: > > > [PCN] PCN WG last call for draft-ietf-pcn-architecture-05.txt > > > { > > > { Hi Phil > > > { > > > { What I explained is the well know HOSE bandwidth = > management model. > > > { During the IETF in Dublin, Hein also shown also some > > results { that > > > were obtrained using the HOSE model. > > > { > > > { > > > { Best regards, > > > { Georgios > > > { > > > { > > > { > -----Original Message----- > > > { > From: philip.eardley@bt.com > > > [mailto:philip.eardley@bt.com] { > Sent: woensdag 27 augustus > > > 2008 10:20 { > To: karagian@cs.utwente.nl; > > slblake@petri-meat.com { > > > > Cc: pcn@ietf.org { > Subject: RE: > > > [PCN] PCN WG last call for { > draft-ietf-pcn-architecture-05.txt > > > { > > > > { > So the question is about adding to the draft: > > > { > A model where the egress measures marks coming from = > all the { > = > > > ingresses, and makes admission decision based on that. > > > { > > > > { > Before adding anything about this to the draft, I'd = > like to { > = > > > understand if this is a genuine practical, understood > > option { > (if > > > so, OK), or if it's a theoretical possibility or one not { > well = > > > understood. > > > { > (there are many things in the latter category that aren't { > = > > > mentioned in the draft.) { > { > Questions are why this is = > > > interesting, why is it better than { > the models already > > well-known, > > > are there comparative analysis { > /simulations? > > > { > > > > { > I suppose I've got 2 general issues: > > > { > [1] every time something is added, overall the document > > { becomes > > > harder to understand, more daunting to read & it { > > looks less > > like the WG has consensus. > > > { > [2] this is an INFO doc. People are free to invent = > ways of { > = > > > using the standards pieces other than the architecture > > draft { > says, > > > and indeed in ways not yet dreamt of. > > > { > > > > { > Phil. > > > { > > > > { > { -----Original Message----- > > > { > { From: pcn-bounces@ietf.org > > > [mailto:pcn-bounces@ietf.org] On { > Behalf Of { Georgios > > Karagiannis > > > { Sent: 27 August 2008 08:54 { > { To: 'Steven Blake' > > > { > { Cc: pcn@ietf.org > > > { > { Subject: Re: [PCN] PCN WG last call for { > = > > > draft-ietf-pcn-architecture-05.txt > > > { > { > > > { > { Hi Steven > > > { > { > > > { > { > -----Original Message----- > > > { > { > From: Steven Blake [mailto:slblake@petri-meat.com] { > > > > { > Sent: woensdag 27 augustus 2008 6:18 { > To: Georgios { > > > Karagiannis { > Cc: pcn@ietf.org { > Subject: RE: [PCN] = > PCN { > WG = > > > last > > call for { > draft-ietf-pcn-architecture-05.txt > > > { > { > > > > { > { > On Tue, 2008-08-26 at 16:11 +0200, Georgios > > Karagiannis wrote: > > > { > { > > > > { > { > > Hi Steven > > > { > { > > > > > { > { > > > > > { > { > > Please see in line! > > > { > { > > > > > { > { > > > > > { > { > > > -----Original Message----- { > { > > > From: = > > Steven Blake > > > [mailto:slblake@petri-meat.com] { { > > > > Sent: dinsdag > > 26 augustus > > > 2008 14:46 { > > > To: > > > { > Georgios Karagiannis { > > > Cc: pcn@ietf.org { > > > { > > > > Subject: Re: [PCN] PCN WG last call for { > > > { > = > > > draft-ietf-pcn-architecture-05.txt > > > { > { > > > > > > { > { > > > On Tue, 2008-08-26 at 11:44 +0000, Georgios = > Karagiannis > > > wrote: > > > { > { > > > > > > { > { > > > > Hi Phil, Hi all > > > { > { > > > > > > > { > { > > > > Here are some comments on the PCN = > architecture draft: > > > { > { > > > > > > > { > { > > > > 1) Thank you for clarifying the bullet in > > Setion { > 3.2 > > > about flow { > > > > termination. > > > { > { > > > > > > > { > { > > > > 2) From what I understand the PCN > > architecture { > draft > > > { > > > mentions that PCN { > > > > supports only the { > trunk > > > (ingress-egress-aggregate) and not the { > > > > > > > HOSE model. > > > { > { > > > > Is the PCN architecture draft excluding = > solutions { > = > > > that { > support the { > > > > HOSE model? If not, please { > = > > > emphasize in the PCN { > architecture draft { > > > > > > that { > "solutions that are based on other types of > > > flow { > > > > > > > > > > > { > aggregation than { > > > > the > > > ingress-egress-aggregate { > method of flow { > > > aggregation, are not { > > > > > > > excluded { > from the PCN WG activities." > > > { > { > > > > > > { > { > > > Actually they are, by our charter. > > > { > { > > > > > { > { > > I have not seen that the PCN charter excludes other { > = > > > types { > of aggregation. > > > { > { > > > > { > { > Well, I checked, and you are correct (mea culpa). > > > { > { Georgios: No problem > > > { > { > > > { > { > > > > { > { > > Please note > > > { > { > > that I am refering to the HOSE model where the > > traffic { > > > > sent { > by one or { > > more than one ingresses towards one { > = > > > egress is aggregated at the { > > egress. In this way higgher { > = > > > traffic aggregation can be accomplished { > > than in the { > = > > > situation that the pipe/trunk { > > > > (ingress-egress-aggregate) { > { > > is used, where the > > traffic sent > > > by only one ingress in { > aggegated at { > > the egress. > > > { > { > > > > { > { > Typically the "hose" model refers to > > point-to-multipoint { > { > > > > traffic flow, not multipoint-to-point. > > > { > { Georgios: Typically yes, but in this case we refer to { = > > > bandwidth allocation { in a multipoint-to-point fashion. > > > { > { > > > { > { > > > > { > { > > > > { > { > Regards, > > > { > { > > > > { > { > // Steve > > > { > { > > > > { > { > > > { > { > > > { > { _______________________________________________ > > > { > { 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