From pcn-bounces@ietf.org Wed Nov 5 21:14: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 3F6113A68AF; Wed, 5 Nov 2008 21:14:31 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D27C13A68AF for ; Wed, 5 Nov 2008 21:14:30 -0800 (PST) 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 0ORFAoIvU6rA for ; Wed, 5 Nov 2008 21:14:30 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id EA2693A688F for ; Wed, 5 Nov 2008 21:14:29 -0800 (PST) Received: from cpe-066-057-117-096.nc.res.rr.com ([66.57.117.96]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1KxxBV-0005EV-FU for pcn@ietf.org; Thu, 06 Nov 2008 00:13:33 -0500 From: Steven Blake To: pcn Content-Type: multipart/mixed; boundary="=-ZM/G9IO1lC6VnCXhjvzT" Date: Thu, 06 Nov 2008 00:13:36 -0500 Message-Id: <1225948416.3472.3.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 IETF 73 **DRAFT** Agenda 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 --=-ZM/G9IO1lC6VnCXhjvzT Content-Type: text/plain Content-Transfer-Encoding: 7bit The draft agenda for the Minneapolis meeting is at http://www.ietf.org/proceedings/08nov/agenda/pcn.txt and is also attached. Please send comments to the list ASAP. Regards, // Steve --=-ZM/G9IO1lC6VnCXhjvzT Content-Disposition: attachment; filename=pcn.txt Content-Type: text/plain; name=pcn.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit Congestion and Pre-Congestion Notification WG (pcn) IETF73 Meeting **DRAFT** Agenda CHAIRs: Scott Bradner Steven Blake TUESDAY, November 18, 2008 0900-1130 Morning Session I Salon E ==================================== AGENDA: o Administrivia chairs 10 min - Blue sheets - Scribe - Agenda bash - Milestones status o PCN Architecture Eardley 10 min draft-ietf-pcn-architecture-08 o Marking Behavior Eardley 20 min draft-ietf-pcn-marking-behavior-01 o Baseline Encoding Briscoe 5 min draft-ietf-pcn-baseline-encoding-01 o 3-in-1 PCN Encoding Briscoe 5 min draft-briscoe-pcn-3-in-1-encoding-00 o PSDM Edge Behavior Eardley 20 min draft-menth-pcn-psdm-deployment-00 o Single PCN-Threshold-Marking Using PCN Baseline Encoding Satoh 15 min Draft pending o ECN Tunneling Briscoe 10 min draft-ietf-tsvwg-ecn-tunnel-01 o Rethinking TCP-friendly Mathis 5 min --=-ZM/G9IO1lC6VnCXhjvzT 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 --=-ZM/G9IO1lC6VnCXhjvzT-- From pcn-bounces@ietf.org Thu Nov 6 05:05: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 1636A3A6931; Thu, 6 Nov 2008 05:05:52 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20FB13A6931 for ; Thu, 6 Nov 2008 05:05:51 -0800 (PST) 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, J_CHICKENPOX_57=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 j6Tlyr+DQsJw for ; Thu, 6 Nov 2008 05:05:49 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 5EC533A67F0 for ; Thu, 6 Nov 2008 05:05:48 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 69586A070A; Thu, 6 Nov 2008 14:05:06 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 5D61DA0707; Thu, 6 Nov 2008 14:05:06 +0100 (CET) Received: from [132.187.12.123] (win3123.informatik.uni-wuerzburg.de [132.187.12.123]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 3ECEDA06A0; Thu, 6 Nov 2008 14:05:06 +0100 (CET) Message-ID: <4912EB1D.2080501@informatik.uni-wuerzburg.de> Date: Thu, 06 Nov 2008 14:03:25 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Bob Briscoe References: <200810271913.m9RJDuZi013673@bagheera.jungle.bt.co.uk> In-Reply-To: <200810271913.m9RJDuZi013673@bagheera.jungle.bt.co.uk> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: PCN IETF list Subject: Re: [PCN] Initial Draft: draft-briscoe-pcn-3-in-1-encoding-00 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 Bob, also from my perspective this encoding proposal is most sensible IF the tunneling issues will ever be resolved. Prerequisite for its application is that all tunnel ingress and egress nodes within a PCN domain use the new tunneling modes specified in http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-ecn-tunnel-01.txt Correct? Regards, Michael Bob Briscoe wrote: > Hi, > > I just posted this new draft-briscoe-pcn-3-in-1-encoding-00.txt > documenting another proposed experimental encoding that Toby described > in a slide at the Dublin IETF. > > I just wrote this because draft-ietf-tsvwg-ecn-tunnel-01.txt recenty > became a WG item in tswvwg, so there's a chance we could finally fix > ECN tunnelling behaviour. If we do, then we can have this much simpler > 3-state PCN encoding in one Diffserv codepoint. I've called it the > 3-in-1 PCN encoding. > > It's just to put a stake in the ground so people can refer to it. We > won't be pushing for this to become a PCN WG item until the baseline > encoding has gone thru, and until draft-ietf-tsvwg-ecn-tunnel-01.txt > has got a bit further in TSVWG. > > > Bob > > >> From: IETF I-D Submission Tool >> To: >> Subject: New Version Notification for >> draft-briscoe-pcn-3-in-1-encoding-00 >> Date: Mon, 27 Oct 2008 08:46:29 -0700 >> X-OriginalArrivalTime: 27 Oct 2008 15:46:37.0589 (UTC) >> FILETIME=[32640C50:01C9384B] >> X-Spam-Score: 0 () >> X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 >> >> >> A new version of I-D, draft-briscoe-pcn-3-in-1-encoding-00.txt has >> been successfuly submitted by Bob Briscoe and posted to the IETF >> repository. >> >> Filename: draft-briscoe-pcn-3-in-1-encoding >> Revision: 00 >> Title: PCN 3-State Encoding Extension in a single DSCP >> Creation_date: 2008-10-27 >> WG ID: Independent Submission >> Number_of_pages: 8 >> >> Abstract: >> Pre-congestion notification (PCN) is a mechanism designed to protect >> the quality of service of inelastic flows. It does this by marking >> packets when traffic load on a link is approaching or has exceeded a >> threshold below the physical link rate. This document specifies an >> extension to the two-state PCN baseline encoding that enables three >> encoding states to be carried in the IP header without using more >> than one Diffserv codepoint. It presupposes a standards action has >> removed the limit of two encoding states in current tunnelling >> mechanisms. >> >> >> >> >> The IETF Secretariat. > > ____________________________________________________________________________ > > Bob Briscoe, Networks Research Centre, BT > Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Nov 6 05:25: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 723D63A6A17; Thu, 6 Nov 2008 05:25:32 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BD8F3A6A12 for ; Thu, 6 Nov 2008 05:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.729 X-Spam-Level: X-Spam-Status: No, score=-2.729 tagged_above=-999 required=5 tests=[AWL=-0.330, 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 Mz-mOrl9fOKC for ; Thu, 6 Nov 2008 05:25:30 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 132AD3A6A17 for ; Thu, 6 Nov 2008 05:25:29 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.111]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Nov 2008 13:24:41 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 6 Nov 2008 13:24:41 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC03DAA462@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4912EB1D.2080501@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Initial Draft: draft-briscoe-pcn-3-in-1-encoding-00 Thread-Index: AclAEGkko1meg0FNR3uLnGysQtsPuAAAWBIw From: To: , X-OriginalArrivalTime: 06 Nov 2008 13:24:41.0822 (UTC) FILETIME=[06BA9FE0:01C94013] Cc: pcn@ietf.org Subject: Re: [PCN] Initial Draft: draft-briscoe-pcn-3-in-1-encoding-00 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Michael, Yes, I believe that's right - If the tunnelling issue are sorted (in general), then something on the lines of this proposal is the most sensible option - if the tunnelling issues are sorted in a specific PCN domain (but not sorted out in general), then this encoding proposal would be possible in that domain. - otherwise this encoding is not a good choice. - the tunnelling work should make progress before it's worth the proposal progressing much further (eg before it becomes a WG doc) phil { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { Michael Menth { Sent: 06 November 2008 13:03 { To: Briscoe,RJ,Bob,XVR9 BRISCORJ R { Cc: PCN IETF list { Subject: Re: [PCN] Initial Draft: draft-briscoe-pcn-3-in-1-encoding-00 { { Hi Bob, { { also from my perspective this encoding proposal is most sensible IF the { tunneling issues will ever be resolved. Prerequisite for its application { is that all tunnel ingress and egress nodes within a PCN domain use the { new tunneling modes specified in { { http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-ecn-tunnel-01.txt { { Correct? { { Regards, { { Michael { { Bob Briscoe wrote: { > Hi, { > { > I just posted this new draft-briscoe-pcn-3-in-1-encoding-00.txt { > documenting another proposed experimental encoding that Toby described { > in a slide at the Dublin IETF. { > { > I just wrote this because draft-ietf-tsvwg-ecn-tunnel-01.txt recenty { > became a WG item in tswvwg, so there's a chance we could finally fix { > ECN tunnelling behaviour. If we do, then we can have this much simpler { > 3-state PCN encoding in one Diffserv codepoint. I've called it the { > 3-in-1 PCN encoding. { > { > It's just to put a stake in the ground so people can refer to it. We { > won't be pushing for this to become a PCN WG item until the baseline { > encoding has gone thru, and until draft-ietf-tsvwg-ecn-tunnel-01.txt { > has got a bit further in TSVWG. { > { > { > Bob { > { > { >> From: IETF I-D Submission Tool { >> To: { >> Subject: New Version Notification for { >> draft-briscoe-pcn-3-in-1-encoding-00 { >> Date: Mon, 27 Oct 2008 08:46:29 -0700 { >> X-OriginalArrivalTime: 27 Oct 2008 15:46:37.0589 (UTC) { >> FILETIME=[32640C50:01C9384B] { >> X-Spam-Score: 0 () { >> X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 { >> { >> { >> A new version of I-D, draft-briscoe-pcn-3-in-1-encoding-00.txt has { >> been successfuly submitted by Bob Briscoe and posted to the IETF { >> repository. { >> { >> Filename: draft-briscoe-pcn-3-in-1-encoding { >> Revision: 00 { >> Title: PCN 3-State Encoding Extension in a single DSCP { >> Creation_date: 2008-10-27 { >> WG ID: Independent Submission { >> Number_of_pages: 8 { >> { >> Abstract: { >> Pre-congestion notification (PCN) is a mechanism designed to protect { >> the quality of service of inelastic flows. It does this by marking { >> packets when traffic load on a link is approaching or has exceeded a { >> threshold below the physical link rate. This document specifies an { >> extension to the two-state PCN baseline encoding that enables three { >> encoding states to be carried in the IP header without using more { >> than one Diffserv codepoint. It presupposes a standards action has { >> removed the limit of two encoding states in current tunnelling { >> mechanisms. { >> { >> { >> { >> { >> The IETF Secretariat. { > { > { ________________________________________________________________________ __ { __ { > { > Bob Briscoe, Networks Research Centre, BT { > Research { > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 { > 645196 { > _______________________________________________ { > PCN mailing list { > PCN@ietf.org { > https://www.ietf.org/mailman/listinfo/pcn { { -- { Dr. Michael Menth, Assistant Professor { University of Wuerzburg, Institute of Computer Science { Am Hubland, D-97074 Wuerzburg, Germany, room B206 { phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 { mailto:menth@informatik.uni-wuerzburg.de { http://www3.informatik.uni-wuerzburg.de/research/ngn { { _______________________________________________ { PCN mailing list { PCN@ietf.org { https://www.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Nov 6 08:46: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 A34543A69B5; Thu, 6 Nov 2008 08:46:10 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D63AB3A69B5 for ; Thu, 6 Nov 2008 08:46:09 -0800 (PST) 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.057, 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 UxCJ5haKkAGh for ; Thu, 6 Nov 2008 08:46:03 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 41DBE3A6973 for ; Thu, 6 Nov 2008 08:46:03 -0800 (PST) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Nov 2008 16:46:00 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Nov 2008 16:45:59 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1225989959287; Thu, 6 Nov 2008 16:45:59 +0000 Received: from mut.jungle.bt.co.uk ([10.73.217.16]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id mA6Gjuvv023365; Thu, 6 Nov 2008 16:45:56 GMT Message-Id: <200811061645.mA6Gjuvv023365@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 06 Nov 2008 16:45:53 +0000 To: From: Bob Briscoe In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC03DAA462@E03MVB1-UKBR.doma in1.systemhost.net> References: <4912EB1D.2080501@informatik.uni-wuerzburg.de> <4A916DBC72536E419A0BD955EDECEDEC03DAA462@E03MVB1-UKBR.domain1.systemhost.net> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 06 Nov 2008 16:45:59.0852 (UTC) FILETIME=[25CBBEC0:01C9402F] Cc: pcn@ietf.org Subject: Re: [PCN] Initial Draft: draft-briscoe-pcn-3-in-1-encoding-00 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 Michael, At 13:24 06/11/2008, philip.eardley@bt.com wrote: >Michael, > >Yes, I believe that's right >- If the tunnelling issue are sorted (in general), then something on the >lines of this proposal is the most sensible option >- if the tunnelling issues are sorted in a specific PCN domain (but not >sorted out in general), then this encoding proposal would be possible in >that domain. ecn-tunnel contains a new ECN encap and decap. The idea is: * All docs say PCN excess-rate marking needs the new ECN encap * The experimental PCN 3-in-1 encoding needs the new ECN decap - new ECN encap behaviour (S.5): looks hopeful for stds track - new ECN decap behaviour (Appx C): possible for stds track, otherwise I'll put it in for expt track If Appx C goes to: - stds track, it would seem obvious to make the 3-in-1 coding stds track too. - expt track, the 3-in-1 coding ought to be expt track too, and the two together would be needed to define the experiment with this encoding. Bob >- otherwise this encoding is not a good choice. >- the tunnelling work should make progress before it's worth the >proposal progressing much further (eg before it becomes a WG doc) > >phil >{ -----Original Message----- >{ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >{ Michael Menth >{ Sent: 06 November 2008 13:03 >{ To: Briscoe,RJ,Bob,XVR9 BRISCORJ R >{ Cc: PCN IETF list >{ Subject: Re: [PCN] Initial Draft: draft-briscoe-pcn-3-in-1-encoding-00 >{ >{ Hi Bob, >{ >{ also from my perspective this encoding proposal is most sensible IF >the >{ tunneling issues will ever be resolved. Prerequisite for its >application >{ is that all tunnel ingress and egress nodes within a PCN domain use >the >{ new tunneling modes specified in >{ >{ http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-ecn-tunnel-01.txt >{ >{ Correct? >{ >{ Regards, >{ >{ Michael >{ >{ Bob Briscoe wrote: >{ > Hi, >{ > >{ > I just posted this new draft-briscoe-pcn-3-in-1-encoding-00.txt >{ > documenting another proposed experimental encoding that Toby >described >{ > in a slide at the Dublin IETF. >{ > >{ > I just wrote this because draft-ietf-tsvwg-ecn-tunnel-01.txt recenty >{ > became a WG item in tswvwg, so there's a chance we could finally fix >{ > ECN tunnelling behaviour. If we do, then we can have this much >simpler >{ > 3-state PCN encoding in one Diffserv codepoint. I've called it the >{ > 3-in-1 PCN encoding. >{ > >{ > It's just to put a stake in the ground so people can refer to it. We >{ > won't be pushing for this to become a PCN WG item until the baseline >{ > encoding has gone thru, and until draft-ietf-tsvwg-ecn-tunnel-01.txt >{ > has got a bit further in TSVWG. >{ > >{ > >{ > Bob >{ > >{ > >{ >> From: IETF I-D Submission Tool >{ >> To: >{ >> Subject: New Version Notification for >{ >> draft-briscoe-pcn-3-in-1-encoding-00 >{ >> Date: Mon, 27 Oct 2008 08:46:29 -0700 >{ >> X-OriginalArrivalTime: 27 Oct 2008 15:46:37.0589 (UTC) >{ >> FILETIME=[32640C50:01C9384B] >{ >> X-Spam-Score: 0 () >{ >> X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 >{ >> >{ >> >{ >> A new version of I-D, draft-briscoe-pcn-3-in-1-encoding-00.txt has >{ >> been successfuly submitted by Bob Briscoe and posted to the IETF >{ >> repository. >{ >> >{ >> Filename: draft-briscoe-pcn-3-in-1-encoding >{ >> Revision: 00 >{ >> Title: PCN 3-State Encoding Extension in a single DSCP >{ >> Creation_date: 2008-10-27 >{ >> WG ID: Independent Submission >{ >> Number_of_pages: 8 >{ >> >{ >> Abstract: >{ >> Pre-congestion notification (PCN) is a mechanism designed to >protect >{ >> the quality of service of inelastic flows. It does this by marking >{ >> packets when traffic load on a link is approaching or has exceeded >a >{ >> threshold below the physical link rate. This document specifies an >{ >> extension to the two-state PCN baseline encoding that enables three >{ >> encoding states to be carried in the IP header without using more >{ >> than one Diffserv codepoint. It presupposes a standards action has >{ >> removed the limit of two encoding states in current tunnelling >{ >> mechanisms. >{ >> >{ >> >{ >> >{ >> >{ >> The IETF Secretariat. >{ > >{ > >{ >________________________________________________________________________ >__ >{ __ >{ > >{ > Bob Briscoe, Networks Research Centre, BT >{ > Research >{ > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 >1473 >{ > 645196 >{ > _______________________________________________ >{ > PCN mailing list >{ > PCN@ietf.org >{ > https://www.ietf.org/mailman/listinfo/pcn >{ >{ -- >{ Dr. Michael Menth, Assistant Professor >{ University of Wuerzburg, Institute of Computer Science >{ Am Hubland, D-97074 Wuerzburg, Germany, room B206 >{ phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 >{ mailto:menth@informatik.uni-wuerzburg.de >{ http://www3.informatik.uni-wuerzburg.de/research/ngn >{ >{ _______________________________________________ >{ PCN mailing list >{ PCN@ietf.org >{ https://www.ietf.org/mailman/listinfo/pcn ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Nov 10 00:57:14 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 0023D3A6A1E; Mon, 10 Nov 2008 00:57:13 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 052AE3A6A20; Mon, 10 Nov 2008 00:57:13 -0800 (PST) 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.150, 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 sMqY2rRVzg2v; Mon, 10 Nov 2008 00:57:11 -0800 (PST) Received: from tcmail23.telekom.de (tcmail23.telekom.de [217.6.95.237]) by core3.amsl.com (Postfix) with ESMTP id 5BE2F3A6A1E; Mon, 10 Nov 2008 00:57:11 -0800 (PST) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail21.telekom.de with ESMTP; Mon, 10 Nov 2008 09:57:05 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Nov 2008 09:57:04 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 10 Nov 2008 09:57:04 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C01FA9AC3@S4DE8PSAANK.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [Tsvwg] New Version: draft-ietf-tsvwg-ecn-tunnel-01 Thread-Index: AclDEkzl57nP/l2aQdeJGlGbEVXzbg== From: "Geib, Ruediger" To: X-OriginalArrivalTime: 10 Nov 2008 08:57:04.0951 (UTC) FILETIME=[4DBD8C70:01C94312] Cc: pcn@ietf.org, tsvwg@ietf.org Subject: Re: [PCN] [Tsvwg] New Version: draft-ietf-tsvwg-ecn-tunnel-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: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Bob, I support making the behaviour proposed by your draft as standards track to be put on that track. You further propose a slightly different tunnel marking behaviour in Appendix C. The Appendix C behaviour should at least be put on informational track (however I will not object against putting Appendix C behaviour on standards track). Further, you suggest to have a separate informational document discussing general L2 tunnel issues (Ethernet, MPLS and others). I favour this split, as I hope this split will speed up progress of the standards track content (and that of Appendix C). Regards, Rudiger Please note, that I won't respond to emails from 11. November until 20. November. ------- Original message posted by Bob Briscoe --------------- Hi, As of a couple of weeks ago, this became a tsvwg wg item. I posted an -00 then, but I've just posted a corrected -01. I'd appreciate review comments as this is effectively a (minor) change to IP forwarding, so there could be weird dependencies I've not thought of (I've tried my hardest to make sure there aren't). The top level questions I'd like to pose for reviewers are: Q1. I've convinced myself no harm to any existing mechanisms would result if I made the proposed new decapsualtion behaviour in Appendix C normative for standards track. Do you agree? Have I missed anything? Q2. I'm planning on splitting this into two docs as it's trying to cover two different scopes: 1/ Stand's track: define specific changes to IP in IP tunnelling of ECN 2/ Informational: give guidelines on how to design encapsulation of congestion notification by general L2 protocols (e.g. Ethernet etc). As it stands, a reader in a hurry could mistake guidelines for encapsulating IP in ethernet etc as instructions for how to implement standard IP in IP tunnelling. Do people agree I should avoid having two different scopes in the same doc? Cheers Bob From: IETF I-D Submission Tool To: Subject: New Version Notification for draft-ietf-tsvwg-ecn-tunnel-01 Date: Mon, 27 Oct 2008 11:05:28 -0700 X-OriginalArrivalTime: 27 Oct 2008 18:05:35.0563 (UTC) FILETIME=[9C35E9B0:01C9385E] X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 A new version of I-D, draft-ietf-tsvwg-ecn-tunnel-01.txt has been successfuly submitted by Bob Briscoe and posted to the IETF repository. Filename: draft-ietf-tsvwg-ecn-tunnel Revision: 01 Title: Layered Encapsulation of Congestion Notification Creation_date: 2008-10-27 WG ID: tsvwg Number_of_pages: 37 Abstract: This document redefines how the explicit congestion notification (ECN) field of the outer IP header of a tunnel should be constructed. It brings all IP in IP tunnels (v4 or v6) into line with the way IPsec tunnels now construct the ECN field. It includes a thorough analysis of the reasoning for this change and the implications. It also gives guidelines on the encapsulation of IP congestion notification by any outer header, whether encapsulated in an IP tunnel or in a lower layer header. Following these guidelines should help interworking, if the IETF or other standards bodies specify any new encapsulation of congestion notification. The IETF Secretariat. _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Nov 10 06:50: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 F15403A69B7; Mon, 10 Nov 2008 06:49:59 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 497163A69B7 for ; Mon, 10 Nov 2008 06:49:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.172 X-Spam-Level: X-Spam-Status: No, score=-1.172 tagged_above=-999 required=5 tests=[AWL=0.345, 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 oS44UxamaxTf for ; Mon, 10 Nov 2008 06:49:59 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id B65B33A6874 for ; Mon, 10 Nov 2008 06:49:58 -0800 (PST) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Nov 2008 14:49:55 +0000 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Nov 2008 14:28:20 +0000 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1226321379457; Mon, 10 Nov 2008 12:49:39 +0000 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id mAACnYng010027; Mon, 10 Nov 2008 12:49:34 GMT Message-Id: <200811101249.mAACnYng010027@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 10 Nov 2008 12:49:37 +0000 To: "Geib, Ruediger" From: Bob Briscoe In-Reply-To: <1B6169C658325341A3B8066E23919E1C01FA9AC3@S4DE8PSAANK.mitte .t-com.de> References: <1B6169C658325341A3B8066E23919E1C01FA9AC3@S4DE8PSAANK.mitte.t-com.de> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 10 Nov 2008 14:28:20.0583 (UTC) FILETIME=[948A4F70:01C94340] Cc: pcn@ietf.org, tsvwg@ietf.org Subject: Re: [PCN] [Tsvwg] New Version: draft-ietf-tsvwg-ecn-tunnel-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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Ruediger, At 08:57 10/11/2008, Geib, Ruediger wrote: >Hi Bob, > >I support making the behaviour proposed by your draft as standards >track to be put on that track. > >You further propose a slightly different tunnel marking behaviour in >Appendix C. The Appendix C >behaviour should at least be put on informational track (however I >will not object against putting >Appendix C behaviour on standards track). I've decided to ask to put Appx C on the stds track for the next rev, as I've realised it proposes a change to a behaviour that no other standard relies on, and as far as I can work out, no app can ever have relied on it as it was, so there will be no harm changing it. If I didn't put Appx C on the stds track, I'd go for experimental track (not informational) because it's a protocol behaviour change. Thanks for your comments. Cheers Bob >Further, you suggest to have a separate informational document >discussing general L2 tunnel issues >(Ethernet, MPLS and others). I favour this split, as I hope this >split will speed up progress of >the standards track content (and that of Appendix C). > >Regards, Rudiger > >Please note, that I won't respond to emails from 11. November until >20. November. > > > >------- Original message posted by Bob Briscoe --------------- >Hi, > > >As of a couple of weeks ago, this became a tsvwg wg item. I posted >an -00 then, but I've just posted a corrected -01. > >I'd appreciate review comments as this is effectively a (minor) >change to IP forwarding, so there could be weird dependencies I've >not thought of (I've tried my hardest to make sure there aren't). > >The top level questions I'd like to pose for reviewers are: > > >Q1. I've convinced myself no harm to any existing mechanisms would >result if I made the proposed new decapsualtion behaviour in >Appendix C normative for standards track. Do you agree? Have I missed anything? > >Q2. I'm planning on splitting this into two docs as it's trying to >cover two different scopes: > >1/ Stand's track: define specific changes to IP in IP tunnelling of ECN > >2/ Informational: give guidelines on how to design encapsulation of >congestion notification by general L2 protocols (e.g. Ethernet etc). > >As it stands, a reader in a hurry could mistake guidelines for >encapsulating IP in ethernet etc as instructions for how to >implement standard IP in IP tunnelling. Do people agree I should >avoid having two different scopes in the same doc? > >Cheers > > > >Bob > > > From: IETF I-D Submission Tool > To: > Subject: New Version Notification for draft-ietf-tsvwg-ecn-tunnel-01 > Date: Mon, 27 Oct 2008 11:05:28 -0700 > > X-OriginalArrivalTime: 27 Oct 2008 18:05:35.0563 (UTC) > FILETIME=[9C35E9B0:01C9385E] > > X-Spam-Score: 0 () > X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 > > > > A new version of I-D, draft-ietf-tsvwg-ecn-tunnel-01.txt has > been successfuly submitted by Bob Briscoe and posted to the IETF repository. > > Filename: draft-ietf-tsvwg-ecn-tunnel > Revision: 01 > Title: Layered Encapsulation of Congestion Notification > Creation_date: 2008-10-27 > WG ID: tsvwg > Number_of_pages: 37 > > Abstract: > This document redefines how the explicit congestion notification > (ECN) field of the outer IP header of a tunnel should be constructed. > It brings all IP in IP tunnels (v4 or v6) into line with the way > IPsec tunnels now construct the ECN field. It includes a thorough > analysis of the reasoning for this change and the implications. It > also gives guidelines on the encapsulation of IP congestion > notification by any outer header, whether encapsulated in an IP > tunnel or in a lower layer header. Following these guidelines should > help interworking, if the IETF or other standards bodies specify any > new encapsulation of congestion notification. > > > > > The IETF Secretariat. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Nov 10 11:05: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 D8D6028C1B1; Mon, 10 Nov 2008 11:05:13 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34F8628C1B2 for ; Mon, 10 Nov 2008 11:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.370, 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 SiuArh8craa2 for ; Mon, 10 Nov 2008 11:05:11 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 642D828C1AE for ; Mon, 10 Nov 2008 11:05:11 -0800 (PST) Received: from localhost ([127.0.0.1] helo=petri-meat.com) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1Kzc4Q-0007yz-4g for pcn@ietf.org; Mon, 10 Nov 2008 14:05:06 -0500 MIME-Version: 1.0 Date: Mon, 10 Nov 2008 14:05:06 -0500 From: To: pcn@ietf.org Message-ID: <07ffbb54b081598da6518a1ad92e1a39@petri-meat.com> X-Sender: slblake@petri-meat.com User-Agent: RoundCube Webmail/0.1 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] Minneapolis PCN agenda 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 didn't receive any comments on the draft agenda, so we will go forward with it. See you in Minneapolis. // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Nov 11 09:16: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 50AE928C18D; Tue, 11 Nov 2008 09:16:13 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B58F23A68C5 for ; Tue, 11 Nov 2008 09:16:11 -0800 (PST) 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 U4I04OvmVNbb for ; Tue, 11 Nov 2008 09:16:08 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 70B1F28C1C7 for ; Tue, 11 Nov 2008 09:16:07 -0800 (PST) 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 mABHG6S5021555 for ; Tue, 11 Nov 2008 18:16:07 +0100 (MET) Received: from 84.82.109.231 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Tue, 11 Nov 2008 17:16:06 +0000 To: "pcn@ietf.org" Date: Tue, 11 Nov 2008 17:16:05 +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]); Tue, 11 Nov 2008 18:16:07 +0100 (MET) Subject: [PCN] new version LC-PCN draft + conclusions 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 Please note that a new version of the LC-PCN draft has been submitted, see: http://www.ietf.org/internet-drafts/draft-westberg-pcn-load-control-05.txt This version contains among other results also the results that were presented during the IETF in Dublin. Section 5.8 contains the following experiment conclusions. Based on the results obtained from the experiments presented in Sections 5.5, 5.6 and 5.7 this document recommends the following: o Leave open the option to use PCN_Affected_Marking encoding since it can solve the ECMP problem and it can provide an efficient solution for the HOSE model. In this document the term HOSE is referring to the aggregation of incoming traffic from all ingress edges, which is associated with one traffic class, i.e., PHB, towards one egress edge. This type of HOSE model is equivalent to the Multiple to Point (MP2P) type of aggregation. o Leave open the option of using random dropping in PCN-interior- nodes for PCN_Marking, PCN_Affected_Marking and PCN_unmarked encoded packets. o Leave open the option of using the parameter N such that the marked excess rate can represent also high level of measured excess rate: **** Implemented by marking every N-th packet (or byte) instead of marking each packet (or byte). Best regards, Georgios _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Nov 12 05:45: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 182AD3A6958; Wed, 12 Nov 2008 05:45:07 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7F2E3A6958 for ; Wed, 12 Nov 2008 05:45:05 -0800 (PST) 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=[AWL=3.206, 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 B8cV5XB8-7PL for ; Wed, 12 Nov 2008 05:45:05 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 33ED23A67AE for ; Wed, 12 Nov 2008 05:45:05 -0800 (PST) Received: from cpe-066-057-117-096.nc.res.rr.com ([66.57.117.96]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1L0G1o-0007lA-O9 for pcn@ietf.org; Wed, 12 Nov 2008 08:45:04 -0500 From: Steven Blake To: pcn Date: Wed, 12 Nov 2008 08:45:04 -0500 Message-Id: <1226497505.1844.15.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] Testing X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Please ignore // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Nov 12 05:47:41 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 4D3F43A68FF; Wed, 12 Nov 2008 05:47:41 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBF943A68FF for ; Wed, 12 Nov 2008 05:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.698 X-Spam-Level: *** X-Spam-Status: No, score=3.698 tagged_above=-999 required=5 tests=[AWL=-1.603, BAYES_50=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_75=0.6, MANGLED_SAVELE=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 Mi+gvdFU+FD6 for ; Wed, 12 Nov 2008 05:47:36 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 61E983A67AE for ; Wed, 12 Nov 2008 05:47:36 -0800 (PST) Received: from cpe-066-057-117-096.nc.res.rr.com ([66.57.117.96]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1L0G4F-0008Fp-0Z for pcn@ietf.org; Wed, 12 Nov 2008 08:47:36 -0500 From: Steven Blake To: pcn Content-Type: multipart/mixed; boundary="=-z4jx7cYe0hevt38FvtMT" Date: Wed, 12 Nov 2008 08:47:35 -0500 Message-Id: <1226497655.1844.18.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-satoh-pcn-ST-marking-00.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 --=-z4jx7cYe0hevt38FvtMT Content-Type: text/plain Content-Transfer-Encoding: 7bit Submitting for a second time, on behalf of the authors (who posted the draft, which never managed to pop out on the list). // Steve --=-z4jx7cYe0hevt38FvtMT Content-Disposition: attachment; filename=draft-satoh-pcn-ST-marking-00.txt Content-Type: text/plain; name=draft-satoh-pcn-ST-marking-00.txt; charset=UTF-8 Content-Transfer-Encoding: 7bit PCN Working Group D. Satoh Internet-Draft M. Ishizuka Intended status: Informational O. Phanachet Expires: May 15, 2009 Y. Maeda NTT-AT November 11, 2008 Single PCN Threshold Marking by using PCN baseline encoding for both admission and termination controls draft-satoh-pcn-ST-marking-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 15, 2009. Abstract This document proposes an algorithm for marking and metering by using pre-congestion notification (PCN) baseline encoding for both flow admission and flow termination. The proposed algorithm uses threshold marking whose TBthreshold.threshold is set to the number of bits of a metered-packet smaller than the token bucket size. Another threshold for the token bucket is required to change the marking. frequency. Under the flow termination state, all the packets are to be threshold-marked. Under the admission stop state, 1/Nth of packets are to be threshold-marked when the meter indicates. We Satoh, et al. Expires May 15, 2009 [Page 1] Internet-Draft ST Marking November 2008 evaluates the performance of the proposed algorithm by simulations. Our simulation indicates that the performance is almost the same as that of the CL[I-D.briscoe-tsvwg-cl-architecture] algorithm. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Single Threshold-Marking . . . . . . . . . . . . . . . . . . . 3 3.1. Operation at the PCN-interior-node . . . . . . . . . . . . 4 3.2. Operation at the PCN-egress-node . . . . . . . . . . . . . 7 3.3. Operation at the PCN-ingress-node . . . . . . . . . . . . 7 3.3.1. Admission Decision . . . . . . . . . . . . . . . . . . 7 3.3.2. Flow Termination Decision . . . . . . . . . . . . . . 7 4. Impact on PCN marking behaviour . . . . . . . . . . . . . . . 8 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 6. Appendix A: Simulation Setup and Environment . . . . . . . . . 8 6.1. Network and Signaling Models . . . . . . . . . . . . . . . 8 6.2. Traffic Models . . . . . . . . . . . . . . . . . . . . . . 10 6.3. Performance Metrics . . . . . . . . . . . . . . . . . . . 12 6.4. Parameter setting for STM . . . . . . . . . . . . . . . . 12 6.5. Parameter setting for CL . . . . . . . . . . . . . . . . . 12 6.6. Simulation Environment . . . . . . . . . . . . . . . . . . 13 7. Appendix B: Admission Control Simulation . . . . . . . . . . . 13 7.1. Parameter setting for admission control . . . . . . . . . 13 7.2. Basic evaluation . . . . . . . . . . . . . . . . . . . . . 13 7.3. Effect of Ingress-Egress Aggregation . . . . . . . . . . . 14 7.3.1. CBR . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.3.2. VBR . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.3.3. SVD . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.4. Effect of multi-bottleneck . . . . . . . . . . . . . . . . 16 7.5. Fairness among different Ingress-Egress pairs . . . . . . 17 8. Appendix C: Flow termination . . . . . . . . . . . . . . . . . 18 8.1. Basic evaluation . . . . . . . . . . . . . . . . . . . . . 18 9. Appendix D: Another Flow Termination Control . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . . . 19 12. Informative References . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Satoh, et al. Expires May 15, 2009 [Page 2] Internet-Draft ST Marking November 2008 1. Introduction Pre-congestion notification (PCN) gives information to support admission control and flow termination in order to protect the quality of service (QoS) of inelastic flows. Although several algorithms (e.g., [I-D.briscoe-tsvwg-cl-phb], [I-D.charny-pcn-single- marking],[I-D.babiarz-pcn-3sm]) have been proposed to achieve PCN, only the single marking algorithm (SM) [I-D.charny-pcnsingle- marking] meets the requirement of baseline encoding. This document proposes an algorithm for marking and metering by using PCN baseline encoding for both flow admission and flow termination. Our algorithm uses PCN-threshold marking although SM uses PCN-excess- traffic marking. Although our algorithm uses an elaborate mechanism, it chooses PCN-admissible and PCN-supportable rates independently. 2. Terminology The terminology used in this document conforms to the terminology of [ID.ietf-pcn-architecture] and [I-D.ietf-pcn-marking-behaviour]. 3. Single Threshold-Marking We propose an algorithm of marking and metering by using PCN baseline encoding for both flow admission and flow termination. This algorithm for marking uses only the PCN-threshold-rate as PCN- supportablerate and does not use the PCN-excess-rate. We show a schematic of how the PCN admission control and flow termination mechanisms operate as the rate of PCN-traffic increases, for a PCN- domain with three type of ratios of PCN-threshold-marked packets and three states of Marking.ratio at Fig. 1. As shown Fig. 1, no packets are PCN-marked at a rate less than the PCN-admissible-rate. Some packets are PCN-marked at rates between PCNadmissible and PCN- supportable rates, and all the packets are PCN-marked at rates greater than the PCN-supportable-rate. Single threshold-marking algorithm (STM) uses a PCN-threshold-rate with a very large TBthreshold. threshold and one-N-th packets are marked (Marking.frequency: 1/N) according to PCN-threshold marking with a very large TBthreshold.threshold to accomplish having some packets PCN-marked. Marking.frequency is a ratio of actual marking to marking according to PCN-threshold marking. One-N-th packets are regularly marked according to PCN-threshold marking with a very large TBthreshold.threshold. Marking with Marking.frequency: 1/N is similar to N-th packet marking of [I-D. westberg-pcn-load-control]. The marking.frequeny is applied to threshold marking although N-th packet marking is applied to excess traffic marking. To achieve Satoh, et al. Expires May 15, 2009 [Page 3] Internet-Draft ST Marking November 2008 having no packets being PCN-marked under the PCN-admissible rate, the marking switch is turned off under the PCN-admissible rate. To achieve having all the packets PCN-threshold marked, the proposed algorithm uses PCN-threshold marking with another TBthreshold. This marking.frequency is 1, and this is the same as described in [I-D. pcn-marking-behaviour] when the other TBthreshold is regarded as TBthreshold.threshold in [I-D. pcn-marking-behaviour]. We explain it in detail in the following subsections. PCN traffic rate 100% | Terminate some |All the packets admitted flows |PCN-threshold-marked & Marking.frequency: 1 PCN- | Block new flows Supportable| rate +------------------------------------------------------- (PCN- | threshold- | rate) | Some packets Block Marking.frequency: 1/N | PCN-threshold-marked new flows PCN- | Admissible | rate +------------------------------------------------------- | | No packets Admit new flows not defined | PCN marked | 0% +------------------------------------------------------- Figure 1: Ratio of PCN-threshold-marked packets, Control operations, and Marking.frequency 3.1. Operation at the PCN-interior-node We assume that a token bucket mechanism is used; other implementations are possible. We explain how to mark by using two token buckets in cooperation. The first token bucket is not used for marking but for a marking switch. The second token bucket is used for marking. When the marking switch is OFF, no packet is marked. When the switch is ON, some or all packets are marked according to the second token bucket. We explain the first token bucket in detail. Tokens of the first token bucket are added at the PCN-admissible-rate. Tokens are removed equal to the size in bits of the metered-packet. These Satoh, et al. Expires May 15, 2009 [Page 4] Internet-Draft ST Marking November 2008 additions and removals are independent of the second token bucket. If the metered traffic is sustained at a level greater than the PCN- admissible-rate, then the marking switch is set to ON. However, a short burst of traffic at greater than the PCN-admissible-rate may not trigger the switch to go ON. If the burst is sufficiently long such that the amount of tokens in the first token bucket are less than threshold (TB1.threshold), the marking switch is set to ON. Otherwise, the marking switch is OFF. The behavior of the first token bucket is similar to that of Threshold-marking although there is a difference between actual marking and having the marking switch ON. When the marking switch is ON, packets are PCN-threshold-marked according to the meter based on the second token bucket. When the marking switch is OFF, no packet is marked regardless of the meter of the second token bucket. We explain the second token bucket in detail. Regardless of the marking switch being ON or OFF, tokens of the second token bucket are added at the PCN threshold-rate, which is the PCN-supportable-rate and tokens are removed equal to the size in bits of the metered- packet. These additions and removals are independent of the first token bucket. The TBthreshold.threshold should be set to the number of bits of a metered packet smaller than the token bucket size although it is not an *intermediate* depth described in [I-D. ietf- pcn-marking-behaviour]. This is the same as the second token bucket size before the removal of tokens for the arrived packet. If the marking switch is ON and Marking.frequency is 1, an arrived packet is marked. If the marking switch is ON and Marking.frequency is 1/N, 1/Nth of arrived packets are marked. The Marking.frequency has two values: 1 and 1/N. If the amount of tokens in the second token bucket is not more than TB2.threshold, the Marking.frequency is 1. Otherwise, it is 1/N. The TB2.threshold is set at a deep depth of the second token bucket. The number of N MUST be the same in the domain. This PCN-domain-wide constant does not impose any constraint except the PCN-domain-wide constant itself. Note that marking by metering whether the amount of token in the second token bucket is less than the TBthreshold.threshold or not gives a good approximation of utilization of a single link. If packets arrive according to the Poisson process, the marking ratio is the utilization of a single link [Kleinrock]. Furthremore, if an arrival process is a superposition of renewal processes, the arrival process approaches the Poisson process as the number of superpositions approaches infinity [Cox]. Therefore, when the number of superpositions of renewal processes is sufficiently large, this metering gives a good approximation of the utilization of a single link. An arrived packet is PCN-threshold-marked per one-Nth when the Satoh, et al. Expires May 15, 2009 [Page 5] Internet-Draft ST Marking November 2008 marking switch is ON and the Marking.frequency is 1/N, that is, the amount of tokens of the second token buckets is less than the TBthreshold.threshold. If the amount of tokens of the second token bucket is less than a configured intermediate depth, termed TB2.threshold, the Marking.frequency is changed 1/N to 1. The Marking.frequency is changed from 1 to 1/N when tokens of the second token bucket is larger than the TB2.threshold. This marking is expressed by the following pseudo code: Input: pcn packet Marking.ratio = 1/N; n = 0; FOR i = 1 to 2 TBi.fill = min(TBi.size,TBi.fill + TBi.rate*(now - TBi.lastUpdate)); // add tokens to the two token buckets TBi.fill = min(TBi.fill - packet.size, 0); //remove tokens from each token bucket ENDFOR IF TB1.fill <= TB1.threshold THEN //marking switch is ON IF TB2.fill < TB2threshold.threshold THEN IF TB2.fill > TB2.threshold THEN markCnt++; IF mod(markCnt, N) == 0 THEN //Marking.frequency = 1/N markCnt = 0; packet.mark = TM; ENDIF ELSE markCnt = 0; packet.mark = TM; ENDIF ENDIF ELSE //marking switch is OFF ENDIF output: void where TB2.fill represents TBthreshold.fill in [I-D. pcn-marking- behaviour], TB2.size represents TBthreshold.max in [I-D. pcn-marking- behaviour], TB2.rate represents the PCN-threshold-rate (as PCN- supportable-rate), TB2.lastUpdate represents TBthreshold.lastUpdate, and TB2threshold.threshold represents TBthreshold.threshold in [I-D. pcn-marking-behaviour]. TB2.threhold represents a threshold at which the Marking.frequency from is changed from 1/N to 1 or from 1 to 1/N, as explained above, which is not defined in [I-D. pcn-marking- behaviour]. Threshold marked(TM) represents PCN-thresholdmarked according to Supportable rate. Satoh, et al. Expires May 15, 2009 [Page 6] Internet-Draft ST Marking November 2008 3.2. Operation at the PCN-egress-node A PCN-egress-node measures the ratio of PCN-threshold-marked packets on a per-ingress basis, and reports to the PCN-ingress-node one value. The value is the Congestion Level Estimate (CLE), which is the fraction of the marked traffic received from the ingress node and is exactly the same as that of CL, SM, and three state PCN marking algorithm(3sM). Furthremore, PCN-egress-node measures L-sequential marked packets per PCN-ingress-node. When the PCN-egress-node receives those packets from a PCN-ingress-node, it starts measuring the receiving rate of this PCN-ingressnode. L-sequential marked packets received during the measurement interval are ignored. The PCN-egress-node sends a packet of information about the receiving rate to the PCN-ingress- node after the measurement interval. After that, the PCN-egress-node again starts measuring the receiving rate if it receives L-sequential marked packets. 3.3. Operation at the PCN-ingress-node 3.3.1. Admission Decision Just as in CL and SM, the admission decision is based on the CLE. The ingress node stops admission of new flows if the CLE is greater than a predefined threshold (CLE threshold). The CLE threshold is chosen under the following maximum value. The maximum of the CLE threshold MUST be CLE threshold = (1/N)*rho , (1) where rho represents the minimum ratio between the PCN-admissible- rate and PCN-supportable-rate via all the links between PCN-ingress and egress nodes and N is the denominator of marking.frequency 1/N. Note that the marking ratio approaches to the maximum CLE threshold described above when the load is PCN-admissible-rate at a bottleneck link via all the links between PCN-ingress and egress nodes as the number of superpositions of flows approaches infinity, as described in Sect 3.1. 3.3.2. Flow Termination Decision When a PCN-ingress-node receives a packet with information about a receiving rate from a PCN-egress-node, it starts measuring a sending rate for this PCN-egress-node immediately. If the PCN-ingress-node receives a new receiving rate from the same PCN-egress-node during measurement interval, the new rate is ignored. At the end of the Satoh, et al. Expires May 15, 2009 [Page 7] Internet-Draft ST Marking November 2008 measurement interval, the PCNingress- node terminates flows whose bandwidth is the same as the sending rate - (1-y)* receiving rate. The value of y is small enough to tolerate over termination. This termination spends more time when the PCN-supportable rate is much less than the physical rate because the sending rate is almost the same as the receiving rate even under a congested situation. 4. Impact on PCN marking behaviour The goal of this section is to propose several minor changes to the PCNmarking- behaviour framework as currently described in [I-D.ietf- pcn-marking-behaviour] in order to enable the Single Threshold marking approach. Threshold marking in this draft conforms to [I-D.pcn-marking-behaviour] except for "intermediate depth". We propose an addition of two marking parameters: Marking.frequency, which is a ratio between actual marking and marking according to PCN- threshold marking. 5. Acknowledgements This research was partially supported by the National Institute of Information and Communications Technology (NICT), Tokyo, Japan. We thank Mr. Takayuki Uchida at U-software Corporation for his helping simulations and giving technical advices, and Professor Shigeo Shioda at Chiba University for his fruitful discussion. 6. Appendix A: Simulation Setup and Environment 6.1. Network and Signaling Models We used three types of network topologies shown in the Figures below for simulations. They are the same as those in [I-D.charny-pcn- single-marking] and the first two figures are the same as those in [I-D. briscoe-tsvwg-cl-phb]. The first type of network topology is Single Link, as shown in Fig. A.1. The second type is a multi-link network with a single bottleneck (termed "RTT"), as shown in Fig.A.2. The third type is a range of multi-bottleneck topologies shown in Fig.A.3 (termed "Parking Lot"). A single link between an ingress and an egress node is shown in Fig.A.1, where all floes enter at node A and depart from node B. This topology is used for the basic verification of the behavior of the algorithms with respect to a single IEA in isolation. Satoh, et al. Expires May 15, 2009 [Page 8] Internet-Draft ST Marking November 2008 A --- B Figure A.1: Simulated Single-Link Network. A \ B - D - F / C Figure A.2: Simulated Multi-Link Network. A--B--C A--B--C--D A--B--C--D--E--F | | | | | | | | | | | | | | | | | | | | | | | | | | D E F E F G H G H I J K L (a) (b) (c) Figure A.3: Simulated Multi-Link Network. As shown in Fig. A.2, a set of ingresses (A;B;C) are connected to an interior node in the network (D). This topology is used to study the behavior of the algorithm where many IEAs share a single bottleneck link. The number of ingresses varied in different simulation experiments in the range of 10-1000. All links generally have different propagation delays. So this propagation delays were chosen randomly in the range of 1ms - 100 ms (although in some experiments all propagation delays are set the same). This node D in turn is connected to the egress (F). In this topology, different sets of flows between each ingress and the egress converge on a single link D-F, where the PCN algorithm is enabled. The capacities of the ingress links are not limiting, and hence, no PCN is enabled on those. The bottleneck link D-F is modeled with a 10ms propagation delay in all simulations. Therefore, the range of round-trip delays in the experiments is from 40ms to 220ms. Another type of network of interest is parking lot (PLT) topology, which has multi-bottleneck links. The simplest PLT with 2 bottlenecks is illustrated in Fig A.3(a). A traffic matrix with this network on this topology is as follows: o an aggregate of "2-hop" flows entering the network at A and leaving at C (via the two links A-B-C) Satoh, et al. Expires May 15, 2009 [Page 9] Internet-Draft ST Marking November 2008 o an aggregate of "1-hop" flows entering the network at D and leaving at E (via A-B) o an aggregate of "1-hop" flows entering the network at E and leaving at F (via B-C). In the 2-hop PLT shown in Fig. A.3 (a) the points of congestion are links A-B and B-C. The capacity of all other links is not-limited. We also experiment with larger PLT topologies with 3 bottlenecks (see Fig A.3(b)) and 5 bottlenecks (Fig A.3 (c)). In all cases, we simulated one ingress-egress pair that carries the aggregate of "long" flows traversing all N bottlenecks (where N is the number of bottleneck links in the PLT topology), and N ingress-egress pairs that carry flows traversing a single bottleneck link and exiting at the next "hop". In all cases, only the "horizontal" links in Fig. A.3 were the bottlenecks, with non-limiting capacities of all "vertical" links. Propagation delays for all links in all PLT topologies are set to 1 ms. Our simulations concentrated primarily on the range of capacities of "bottleneck" links with sufficient aggregation - above 128 Mbps for voice and 2.4Gbps Mbps for SVD. It should generally be expected that the higher link speeds will result in higher levels of aggregation, and hence generally better performance of the measurement-based algorithms. Therefore it seems reasonable to believe that the studied link speeds do provide meaningful evaluation targets. In the simulation model, a call request arrives at the ingress and immediately sends a message to the egress. The message arrives at the egress after the propagation time plus link processing time (but no queuing delay). When the egress receives this message, it immediately responds to the ingress with the current CLE. If the CLE is below the specified CLE-threshold, the call is admitted, otherwise it is rejected. An admitted call sends packets according to one of the chosen traffic models for the duration of the call (see next section). Propagation delay from source to the ingress and from destination to the egress is assumed to be negligible and is not modeled. Admissible and Supportable rates are half link speed and 90% of link speed, respectively, in all the links. Actual queue size is 80,000 packets, which is not the byte size because queue size is set by only packet in NS2 simulator. 6.2. Traffic Models We use the same types of traffic as those of [I-D. briscoe-tsvwg-cl- phb], [I-D. charny-pcn-single-marking]. These are CBR voice, on-off Satoh, et al. Expires May 15, 2009 [Page 10] Internet-Draft ST Marking November 2008 traffic approximating voice with silence compression (we termed "VBR"), and on-off traffic with higher peak and mean rates (we termed the latter "Synthetic Video" (SVD). On-off traffic (VBR and SVD) is described with two state Markov chain and on and off periods were exponentially distributed with the specified mean. Each flow arrives according to the Poisson process and the distribution of flow duration was chosen to be exponentially distributed with a mean of 1 min, regardless of the traffic type, which is the same as that in [I-D. briscoe-tsvwg-cl-phb] and [I-D. charny-pcn-single-marking]. Traffic parameters for each type are summarized below: CBR voice o Packet length: 160 bytes o Packet inter-arraival time: 20ms ((160*8)/(64*1000)sec) o Average rate: 64Kbps On-off traffic approximating voice with silence compression o Packet length: 160 bytes o Packet inter-arrival time during On period: 20ms o Long-term average rate: 21.76 Kbps o On period mean duration: 340ms; during the on period traffic is sent with CBR voice parameters described above o Off period mean duration 660ms; no traffic is sent for the duration of the off period SVD o Packet length: 1500 bytes o Packet inter-arrival time during On period: 1ms o Long term average rate: 4 Mbps o On period mean duration: 340 ms o Off period mean duration: 660 ms Satoh, et al. Expires May 15, 2009 [Page 11] Internet-Draft ST Marking November 2008 6.3. Performance Metrics In all our experiments, we use the percent deviation of the mean rate achieved in the experiment from the expected load level as performance metric. We term these "over-admission" and "over- termination" percentages, depending on the type of the experiment. In our experiments of admission control, we compare the actual achieved average throughput to the desired traffic load (admissible rate) and measure the standard deviation of throughput at 500 ms intervals to the desired traffic load. The desired traffic load is not admissible rate exactly because a signal packet for a new flow is sent for admission. Therefore, the desired traffic load is the amount of the signal packets including not admitted flows less than admissible rate. 6.4. Parameter setting for STM All the simulations were run with the following values: o TB1.size = 20 ms at Admissible rate, o TB1.threshold = 10ms at Admissible rate, o TB2.size = 10ms at Supportable rate, o TB2.threshold = 8ms at Supportable rate, o Marking.frequency =1/3 and 1 o CLE threshold = 0.05 (less than Marking.frequency times ratio between admissible and supportable rates) o CLEweight = 0.0005 o The number of sequential marked packets for termination = 100 o Extra percentage of receiving rate more than the difference between sending and receiving rates for termination at one time = 5.0 o Interval for measureing sending rate or receiving rate = 100ms. 6.5. Parameter setting for CL All the simulations were run with 5ms at Supportable rate as token bucket size for Termination and the following Virtual Queue thresholds: Satoh, et al. Expires May 15, 2009 [Page 12] Internet-Draft ST Marking November 2008 o min-marking-threshold: 5ms at link speed, o max-marking-threshold: 15ms at link speed, o virtual-queue-upper-limit: 20ms at link speed. The virtual-queue-upper-limit puts an upper bound on how much the virtual queue can grow. In Admission control simulation, CLE and CLE weight are chosen as 0.05 and 0.3 respectively. 6.6. Simulation Environment We used NS2 for our simulation experiments. Simulations were run on Red Hat Enterprise Linux (64bit), Dell Power Edge 1950, Intel Quad- core Xeon 2.66GHz, 32GB RAM. 7. Appendix B: Admission Control Simulation 7.1. Parameter setting for admission control We evaluate over-admission percentages when the load of the bottleneck is five times of the Admissible rate, that is, 2.5 times of the link speed. The simulation time is 300 sec and simulation results during time interval between 200 sec and 300sec are used for performance metric to obtain the results in the steady state. Egress measurement parameters for STM : In our simulations, the CLE is computed as an exponential weighted moving average (EWMA) with a weight of 0.0005. The CLE is computed on a per-packet basis. Egress measurement parameters for CL : In our simulations, the CLEthreshold was chosen as 0.05. The CLE is computed as an exponential weighted moving average (EWMA) with a weight of 0.3. The CLE is computed on a per-packet basis. These values are the same as those in Sect. 8.2.3 in [I-D.charny-pcn-single-marking]. 7.2. Basic evaluation Over-admission percentage statistics are evaluated using the Single Link topology. Table B.1 gives results of an admission control simulation when the load is the five times the Admissible rate. When the traffic type is CBR, the link speed is 128Mbps and the load is the rate of 5000 flows. The call interval per Ingress-Egress Aggregate(IEA) is 0.012sec. When the traffic type is VBR, the link speed is 78.3Mbps and the load is the rate of 9000 flows. The call interval per Ingress-Egress Aggregate(IEA) is 0.0067sec. When the traffic type is SVD, the link speed is 2.45Gbps and the load is the Satoh, et al. Expires May 15, 2009 [Page 13] Internet-Draft ST Marking November 2008 rate of 1500 flows. The call interval per Ingress-Egress Aggregate(IEA) is 0.04sec. We show the average of results of five simulations with different random seeds each traffic type. The performance of STM is very good although it is inferior to that of CL. We repeated this simulation by using different random seeds. ------------------------------------------------- Type | Over Admission % | Standard deviation % |------------------------------------------- | STM | CL | STM | CL ----------------------- ------------------------- CBR | 0.285 | 0.028 | 1.243 | 0.818 ------------------------------------------------- VBR | 1.017 | 0.979 | 2.761 | 2.587 ------------------------------------------------- SVD | 4.308 | 4.476 | 6.002 | 5.922 ------------------------------------------------- Table B.1: Over admission percentage and standard deviation statistics obtained with Single Link 7.3. Effect of Ingress-Egress Aggregation We evaluated the effect of Ingress-Egress Aggregation using RTT topology. As simulations in [I-D. charny-pcn-single-marking], the aggregate load on the bottleneck is the same across each traffic type with the aggregate load being evenly divided among all ingresses. 7.3.1. CBR Table B.2 shows simulation results with traffic load condition when the traffic type is CBR. In this case, link speed of the bottleneck is 128Mbps for all the case of number of ingresses. Satoh, et al. Expires May 15, 2009 [Page 14] Internet-Draft ST Marking November 2008 --------------------------------------------------------------------- No. of |No. of |Call |Over Admission |Standard deviation ingresses|connections|Interval | (%) | (%) |per IE pair|per IEA |------------------------------------ | |(sec) | STM | CL | STM | CL --------------------------------------------------------------------- 10 | 500 | 0.12 | 0.585 | 0.761 | 2.255 | 1.745 --------------------------------------------------------------------- 70 | 71 | 0.84 | -1.656 | 0.727 | 2.628 | 1.751 --------------------------------------------------------------------- 600 | 8 | 7.20 | -5.218 | 0.038 | 4.114 | 1.369 --------------------------------------------------------------------- 1000 | 5 | 12.0 | -6.030 |-0.179 | 4.342 | 1.262 --------------------------------------------------------------------- Table B.2: Over admission percentage statistics with CBR, RTT 7.3.2. VBR Table B.3 shows simulation results with traffic load condition when the traffic type is VBR. In this case, link speed of the bottleneck is 78Mbps for all the case of number of ingresses. --------------------------------------------------------------------- No. of |No. of |Call |Over Admission |Standard deviation ingresses|connections|Interval | (%) | (%) |per IE pair|per IEA |------------------------------------ | |(sec) | STM | CL | STM | CL --------------------------------------------------------------------- 10 | 900 | 0.07 | -0.753 | 1.345 | 3.381 | 3.102 --------------------------------------------------------------------- 70 | 128 | 0.47 | -3.249 | 1.462 | 4.034 | 3.130 --------------------------------------------------------------------- 600 | 15 | 4.00 | -5.427 | 0.699 | 4.954 | 3.051 --------------------------------------------------------------------- 1000 | 5 | 12.0 | -5.870 | -0.077 | 4.395 | 3.001 --------------------------------------------------------------------- Table B.3: Over admission percentage statistics with VBR, RTT 7.3.3. SVD Table B.4 shows simulation results with traffic load condition when the traffic type is SVD. In this case, link speed of the bottleneck is 2448Mbps for all the case of number of ingresses. Satoh, et al. Expires May 15, 2009 [Page 15] Internet-Draft ST Marking November 2008 --------------------------------------------------------------------- No. of |No. of |Call |Over Admission |Standard deviation ingresses|connections|Interval | (%) | (%) |per IE pair|per IEA |------------------------------------ | |(sec) | STM | CL | STM | CL --------------------------------------------------------------------- 10 | 150 | 0.4 | 1.593 | 4.870 | 6.627 | 6.272 --------------------------------------------------------------------- 70 | 42 | 1.4 | -1.981 | 4.898 | 6.624 | 6.455 --------------------------------------------------------------------- 600 | 10 | 5.6 | -5.502 | 2.597 | 6.859 | 6.224 --------------------------------------------------------------------- 1000 | 5 | 12.0 | -7.192 | 0.221 | 6.644 | 6.431 --------------------------------------------------------------------- Table B.4: Over admission percentage statistics with SVD, RTT 7.4. Effect of multi-bottleneck We evaluated the effect of multi-bottleneck with PLT topology. Over- admission-percentage of each bottleneck ID is shown in Tablle B.5. Standard deviation of over admission with multibottleneck of each bottleneck ID is shown Table B.6. When CBR was used as traffic type, link speed of all the bottleneck is 128Mbps and call-interval per IEA is 0.024sec. When VBR was used as traffic type, link speed of all the bottleneck is 78Mbps and call-interval per IEA is 0.01sec. When SVD was used as traffic type, link speed of all the bottleneck is 2448Mbps and call-interval per IEA is 0.08sec. ------------------------------------------------------------- Traffic |Algorithm| Bottleneck LinkId Type | | 1 | 2 | 3 | 4 | 5 ------------------------------------------------------------- CBR | STM | 1.587 | 1.589 | 1.617 | 1.565 | 1.694 | CL | 0.019 | 0.025 | 0.015 | 0.005 | 0.009 ------------------------------------------------------------- VBR | STM | 2.567 | 2.320 | 2.168 | 2.269 | 2.341 | CL | 0.560 | 0.540 | 0.585 | 0.614 | 0.620 ------------------------------------------------------------- SVD | STM | 2.541 | 2.279 | 2.537 | 2.297 | 2.594 | CL | 1.887 | 1.908 | 1.952 | 2.123 | 2.382 ------------------------------------------------------------- Table B.5: Over admission percentage with multibottleneck Satoh, et al. Expires May 15, 2009 [Page 16] Internet-Draft ST Marking November 2008 ------------------------------------------------------------- Traffic |Algorithm| Bottleneck LinkId Type | | 1 | 2 | 3 | 4 | 5 ------------------------------------------------------------- CBR | STM | 2.270 | 2.245 | 2.329 | 2.293 | 2.287 | CL | 1.002 | 1.105 | 1.036 | 0.975 | 0.945 ------------------------------------------------------------- VBR | STM | 5.293 | 5.343 | 5.019 | 5.256 | 5.312 | CL | 2.385 | 2.350 | 2.423 | 2.387 | 2.476 ------------------------------------------------------------- SVD | STM | 6.474 | 6.772 | 6.243 | 6.125 | 6.524 | CL | 6.042 | 5.551 | 5.844 | 6.030 | 6.021 ------------------------------------------------------------- Table B.6: Standard deviation of over admission with multibottleneck 7.5. Fairness among different Ingress-Egress pairs In [I-D.charny-pcn-single-marking], the fairness is illustrated using the ratio between bandwidth of the long-haul aggregates and the short-haul aggregates. We used CBR traffic with the load of each bottleneck is five times of the Admissible rate. Table B.7 summarizes the fairness results at different topologies. We measure ratios of average throughput of short-haul aggregates to that of long-haul aggregates during the simulation time at the first bottleneck. We display the average of the five simulations. The same link speed and call interval conditions in Table B.5 are used in this experiment. ----------------------------------------------------------------- |Topo| Simulation Time (s) | | 10 | 20 | 30 | 40 | 50 | 60 | 70 | 80 ----------------------------------------------------------------- STM |PLT2| 1.00 | 1.02 | 1.06 | 1.12 | 1.19 | 1.25 | 1.32 | 1.39 CL | | 1.02 | 1.04 | 1.08 | 1.15 | 1.22 | 1.30 | 1.38 | 1.46 ----------------------------------------------------------------- STM |PLT3| 1.02 | 1.02 | 1.11 | 1.23 | 1.36 | 1.49 | 1.62 | 1.74 CL | | 0.98 | 1.00 | 1.05 | 1.12 | 1.21 | 1.30 | 1.41 | 1.52 ----------------------------------------------------------------- STM |PLT5| 1.07 | 1.22 | 1.39 | 1.57 | 1.77 | 1.98 | 2.20 | 2.42 CL | | 1.02 | 1.05 | 1.14 | 1.28 | 1.43 | 1.59 | 1.75 | 1.93 ----------------------------------------------------------------- Table B.7: Fairness performance Satoh, et al. Expires May 15, 2009 [Page 17] Internet-Draft ST Marking November 2008 8. Appendix C: Flow termination We evaluate over-termination percentages when the load of the bottleneck is 1.0, 1.5 and 3.0 times of link speed. The load was lower than the Admissible rate at the beginning of the simulation. The simulation time is 100 sec. The load was changed at half the simulation time, that is 50sec. Simulation results during time interval between 70 sec and 100sec are used for performance metric to obtain the results in the steady state. The rate of one IE-pair was changed from 0 to the load of 1.0, 1.5 and 3.0 times of link speed at bottleneck links with no admission control within 2.0 sec. This simulated changing of a route when there was a failure. When a failure happened, a new Ingree-Egress pair was generated. Their traffic was regarded as traffic added by changing of a route. The flows of the new Ingress-Egress pair were generated according to the Poisson process whose rate was the value of the generated flows divided by 2 sec. The flow generation stopped at the generated flows whose bandwidth is the same as the load. The duration time of all the flows is infinity. 8.1. Basic evaluation Over termination percentages are evaluated with the Single Link topology. Table C.1 gives results of a termination control simulation when the load is the 1.0, 1.5 and 3.0 times Link speed. When the traffic type is CBR, the link speed is 40.5Mbps and the load is the rate of 633, 950, and 1900 flows. When the traffic type is VBR, the link speed is 41.1Mbps and the load is the rate of 1886, 2830, and 5660 flows. When the traffic type is SVD, the link speed is 613Mbps and the load is the rate of 153, 230, and 460 flows. We show the average of results of five simulations with different random seeds each traffic type. Satoh, et al. Expires May 15, 2009 [Page 18] Internet-Draft ST Marking November 2008 ----------------------------------------------------- Traffic | Load | Over Termination % Type |(x Link |---------------------------------- | speed) | STM | CL ------------------------------------------------------ CBR | | 5.54 | 3.57 VBR | 1.0 | 17.66 | 29.03 SVD | | 17.59 | 21.87 ------------------------------------------------------ CBR | | 4.60 | 10.07 VBR | 1.5 | 28.34 | 47.95 SVD | | 33.43 | 46.26 ------------------------------------------------------ CBR | | 3.86 | 21.02 VBR | 3.0 | 30.82 | 48.65 SVD | | 38.21 | 56.55 ------------------------------------------------------- Table C.1: Over termination percentage statistics obtained with Single Link 9. Appendix D: Another Flow Termination Control When PCN-supportable rate is much less than the Physical rate, the flow termination control described in Sect.?? takes much time to control. We describe another flow termination control. A PCN- ingress node measures sending rate per PCN-egress nodes all the time. If a PCN-egress node receives L-sequential marked packets, it sends a message of termination to the PCNingress node. When the PCN-ingress node receives the message, it terminates flows according to x-% of sending rate. PCN-ingress node ignore the message during a time interval after termination. The value of x is small and the time interval is short. 10. IANA Considerations TBD 11. Security Considerations TBD Satoh, et al. Expires May 15, 2009 [Page 19] Internet-Draft ST Marking November 2008 12. Informative References [I-D.babiarz-pcn-3sm] Babiarz, J., "Three State PCN Marking", November 2007. [I-D.briscoe-tsvwg-cl-phb] Briscoe, B., "Pre-Congestion Notification Marking", October 2006. [I-D.charny-pcn-single-marking] Charny, A., "Pre-Congestion Notification Using Single Marking for Admission and Termination", November 2007. [I-D.ietf-pcn-architecture] Eardley, P., "Pre-Congestion Notification Architecture", (work in progress), October 2008. [I-D.ietf-pcn-baseline-encoding] Moncaster, T., Briscoe, B., and M. Menth, "Baseline Encoding and Transport of Pre-Congestion Information", (work in progress), October 2008. [I-D.ietf-pcn-marking-behaviour] Eardley, P., "Marking behaviour of PCN-nodes", (work in progress), October 2008. [I-D.westberg-pcn-load-control] Westberg, L., "LC-PCN: The Load Control PCN Solution", (work in progress), November 2008. Authors' Addresses Daisuke Satoh NTT Advanced Technology Corporation 1-19-18, Nakacho Musashino-shi, Tokyo 180-0006 Japan Email: daisuke.satoh@ntt-at.co.jp Mika Ishizuka NTT Advanced Technology Corporation Email: mika.ishizuka@ntt-at.co.jp Satoh, et al. Expires May 15, 2009 [Page 20] Internet-Draft ST Marking November 2008 Oratai Phanachet NTT Advanced Technology Corporation Email: oratai.phanachet@ntt-at.co.jp Yukari Maeda NTT Advanced Technology Corporation Email: yukari.maeda@ntt-at.co.jp Satoh, et al. Expires May 15, 2009 [Page 21] Internet-Draft ST Marking November 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Satoh, et al. Expires May 15, 2009 [Page 22] --=-z4jx7cYe0hevt38FvtMT 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 --=-z4jx7cYe0hevt38FvtMT-- From pcn-bounces@ietf.org Fri Nov 14 12:22: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 4A8493A6851; Fri, 14 Nov 2008 12:22:33 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0340A3A6851 for ; Fri, 14 Nov 2008 12:22:32 -0800 (PST) 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 6TV1aoZZg5I5 for ; Fri, 14 Nov 2008 12:22:31 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 427DA3A635F for ; Fri, 14 Nov 2008 12:22:31 -0800 (PST) Received: from localhost ([127.0.0.1] helo=petri-meat.com) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1L15BU-0002Ek-T2 for pcn@ietf.org; Fri, 14 Nov 2008 15:22:28 -0500 MIME-Version: 1.0 Date: Fri, 14 Nov 2008 15:22:28 -0500 From: To: pcn@ietf.org Message-ID: <23bc9ee3545a045c6d024acbe9df1f62@petri-meat.com> X-Sender: slblake@petri-meat.com User-Agent: RoundCube Webmail/0.1 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 meeting slides X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Please send me your presentation slides before the meeting Tuesday and I will post them. PDF preferred. Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Nov 17 14:17: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 0A8A83A6944; Mon, 17 Nov 2008 14:17:30 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A7293A6907 for ; Mon, 17 Nov 2008 14:17:28 -0800 (PST) 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=[AWL=0.000, 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 Gw-cc+o-Qy+d for ; Mon, 17 Nov 2008 14:17:27 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 4FF6628C127 for ; Mon, 17 Nov 2008 14:17:27 -0800 (PST) Received: from localhost ([127.0.0.1] helo=petri-meat.com) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1L2CPL-0007KS-TH for pcn@ietf.org; Mon, 17 Nov 2008 17:17:23 -0500 MIME-Version: 1.0 Date: Mon, 17 Nov 2008 17:17:23 -0500 From: To: pcn@ietf.org Message-ID: X-Sender: slblake@petri-meat.com User-Agent: RoundCube Webmail/0.1 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] Meeting presentations X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a reminder: please send me your meeting slides ASAP so that I can upload them here: https://datatracker.ietf.org/meeting/73/materials.html (Of course at the moment the upload server is not responding, so I can't post the agenda slides). Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Nov 17 17:31:41 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 EFF0A28C188; Mon, 17 Nov 2008 17:31:41 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F55428C188 for ; Mon, 17 Nov 2008 17:31:40 -0800 (PST) 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 gWEbfFryRoeO for ; Mon, 17 Nov 2008 17:31:40 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id C5BCB3A6922 for ; Mon, 17 Nov 2008 17:31:39 -0800 (PST) Received: from localhost ([127.0.0.1] helo=petri-meat.com) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1L2FRH-0005Yk-NT for pcn@ietf.org; Mon, 17 Nov 2008 20:31:35 -0500 MIME-Version: 1.0 Date: Mon, 17 Nov 2008 20:31:35 -0500 From: To: pcn@ietf.org Message-ID: X-Sender: slblake@petri-meat.com User-Agent: RoundCube Webmail/0.1 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] Uploaded presentations X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org FYI: I am still unable to upload presentations for tomorrow's meeting. I will keep trying this evening. Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Nov 18 12:04: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 C0AFD28C222; Tue, 18 Nov 2008 12:04:44 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C2D228C222 for ; Tue, 18 Nov 2008 12:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 3ag3KGG8tYEk for ; Tue, 18 Nov 2008 12:04:42 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id CDD2B28C217 for ; Tue, 18 Nov 2008 12:04:42 -0800 (PST) Received: from localhost ([127.0.0.1] helo=petri-meat.com) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1L2WoR-0007of-U1 for pcn@ietf.org; Tue, 18 Nov 2008 15:04:39 -0500 MIME-Version: 1.0 Date: Tue, 18 Nov 2008 15:04:39 -0500 From: To: pcn@ietf.org Message-ID: <90d03d69c9994b53246a1d384aa5697e@petri-meat.com> X-Sender: slblake@petri-meat.com User-Agent: RoundCube Webmail/0.1 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 meeting presentations - uploaded 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 have uploaded all of the meeting presentations here: https://datatracker.ietf.org/meeting/73/materials.html Regards, // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Nov 18 18:07: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 9E5883A6B3C; Tue, 18 Nov 2008 18:07:33 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C514E3A6931 for ; Tue, 18 Nov 2008 18:07:32 -0800 (PST) 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 MGLGycdvIjg4 for ; Tue, 18 Nov 2008 18:07:31 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 6D7803A6883 for ; Tue, 18 Nov 2008 18:07:31 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Nov 2008 02:07:29 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 02:07:25 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04440E9F@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] new version LC-PCN draft + conclusions Thread-Index: AclJ65CRaBa70dnERw+ExM7HzdY3iA== From: To: , X-OriginalArrivalTime: 19 Nov 2008 02:07:29.0691 (UTC) FILETIME=[937636B0:01C949EB] Subject: Re: [PCN] new version LC-PCN draft + conclusions 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 to answer the first point below. It would seem possible to devise an extension encoding that allowed for PCN affected marking - so i guess that means the option is open as you request. Incidentally, with the marking behaviour defined in the WG draft, if a node is excess traffic marking some pkts, then all the other pkts will be threshold marked. so ThM can be used as a kind of proxy for affected marking. it's not perfect (imagine if a different ECMP path in the same ingress egress aggregate is doing ThM but not ExM, then you might terminate a flow that doesnt go through the real problem link. would be interestign to see some realistic analysis /simulations of whether the chances are that this 'unhelpful termination' would happen just once & only very rarely, or whether it could keep happening. ie is it good enough?). phil ---------------------------- * Subject: [PCN] new version LC-PCN draft + conclusions * From: "Georgios Karagiannis" > * Date: Tue, 11 Nov 2008 17:16:05 +0000 Dear all Please note that a new version of the LC-PCN draft has been submitted, see: http://www.ietf.org/internet-drafts/draft-westberg-pcn-load-control-05.txt This version contains among other results also the results that were presented during the IETF in Dublin. Section 5.8 contains the following experiment conclusions. Based on the results obtained from the experiments presented in Sections 5.5, 5.6 and 5.7 this document recommends the following: o Leave open the option to use PCN_Affected_Marking encoding since it can solve the ECMP problem and it can provide an efficient solution for the HOSE model. In this document the term HOSE is referring to the aggregation of incoming traffic from all ingress edges, which is associated with one traffic class, i.e., PHB, towards one egress edge. This type of HOSE model is equivalent to the Multiple to Point (MP2P) type of aggregation. o Leave open the option of using random dropping in PCN-interior- nodes for PCN_Marking, PCN_Affected_Marking and PCN_unmarked encoded packets. o Leave open the option of using the parameter N such that the marked excess rate can represent also high level of measured excess rate: **** Implemented by marking every N-th packet (or byte) instead of marking each packet (or byte). Best regards, Georgios _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Nov 18 18:16: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 E0F3D3A6B39; Tue, 18 Nov 2008 18:16:05 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9578C3A6B39 for ; Tue, 18 Nov 2008 18:16:05 -0800 (PST) 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 VT1ncBVS-Fnl for ; Tue, 18 Nov 2008 18:16:04 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 92E623A6B31 for ; Tue, 18 Nov 2008 18:16:04 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Nov 2008 02:16:02 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 02:16:02 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04440EA0@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] new version LC-PCN draft + conclusions Thread-Index: AclJ65CRaBa70dnERw+ExM7HzdY3iAAAAnd1 References: <4A916DBC72536E419A0BD955EDECEDEC04440E9F@E03MVB1-UKBR.domain1.systemhost.net> From: To: , X-OriginalArrivalTime: 19 Nov 2008 02:16:02.0787 (UTC) FILETIME=[C54A7330:01C949EC] Subject: Re: [PCN] new version LC-PCN draft + conclusions 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 response to your third point below. this has already been discussed extensively on the mailing list. there seems no benefit to this, because the same system behaviour can be achieved by doing "1/N" behaviour at the PCN-boundary-node instead of at the PCN-interior-node. pointers to previous discussion: http://www.ietf.org/mail-archive/web/pcn/current/msg01642.html http://www.ietf.org/mail-archive/web/pcn/current/msg01091.html https://datatracker.ietf.org/drafts/draft-menth-pcn-emft/ so i am strongly opposed to including this option in the markng draft. phil ---------------------------- * Subject: [PCN] new version LC-PCN draft + conclusions * From: "Georgios Karagiannis" > * Date: Tue, 11 Nov 2008 17:16:05 +0000 Dear all Please note that a new version of the LC-PCN draft has been submitted, see: http://www.ietf.org/internet-drafts/draft-westberg-pcn-load-control-05.txt This version contains among other results also the results that were presented during the IETF in Dublin. Section 5.8 contains the following experiment conclusions. Based on the results obtained from the experiments presented in Sections 5.5, 5.6 and 5.7 this document recommends the following: o Leave open the option to use PCN_Affected_Marking encoding since it can solve the ECMP problem and it can provide an efficient solution for the HOSE model. In this document the term HOSE is referring to the aggregation of incoming traffic from all ingress edges, which is associated with one traffic class, i.e., PHB, towards one egress edge. This type of HOSE model is equivalent to the Multiple to Point (MP2P) type of aggregation. o Leave open the option of using random dropping in PCN-interior- nodes for PCN_Marking, PCN_Affected_Marking and PCN_unmarked encoded packets. o Leave open the option of using the parameter N such that the marked excess rate can represent also high level of measured excess rate: **** Implemented by marking every N-th packet (or byte) instead of marking each packet (or byte). Best regards, Georgios _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Nov 18 18:22: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 337A03A691D; Tue, 18 Nov 2008 18:22:00 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 447A23A691D for ; Tue, 18 Nov 2008 18:21:59 -0800 (PST) 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 VzDRdzZv7axY for ; Tue, 18 Nov 2008 18:21:58 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 623353A67B6 for ; Tue, 18 Nov 2008 18:21:58 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Nov 2008 02:21:56 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 02:21:56 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04440EA1@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Dropping preference as a configuration option Thread-Index: AclJ7Zf0x+lK08dATZq7YIEA6TblJQ== From: To: X-OriginalArrivalTime: 19 Nov 2008 02:21:56.0724 (UTC) FILETIME=[9840F340:01C949ED] Subject: [PCN] Dropping preference as a configuration option X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Michael and Georgios have raised this issue recently, and we've discussed it here in Minneapolis - both in a 'corridor' meeting and in the WG meeting. so i wanted to summarised the issue and the discussions so far. The issue is about if there are 2 bottlenecks on the path, the first one is pre-congested & excess-traffic-marking pkts and the second one is even more overloaded and is actually dropping pkts. the question is whether the second node should preferentially drop pkts that have already been marked or do something else instead. History of issue: In _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Nov 18 19:27: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 436D23A6B07; Tue, 18 Nov 2008 19:27:12 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9FBF3A6B07 for ; Tue, 18 Nov 2008 19:27:10 -0800 (PST) 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 r2K2eJVH8+mG for ; Tue, 18 Nov 2008 19:27:09 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 231913A6951 for ; Tue, 18 Nov 2008 19:27:08 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Nov 2008 03:27:07 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 03:27:07 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04440EA3@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Dropping preference as a configuration option Thread-Index: AclJ7Zf0x+lK08dATZq7YIEA6TblJQAACTdE References: <4A916DBC72536E419A0BD955EDECEDEC04440EA1@E03MVB1-UKBR.domain1.systemhost.net> From: To: X-OriginalArrivalTime: 19 Nov 2008 03:27:07.0621 (UTC) FILETIME=[B3547950:01C949F6] Subject: [PCN] Dropping preference as a configuration option X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Michael and Georgios have raised this issue recently, and we've discussed it here in Minneapolis - both in a 'corridor' meeting and in the WG meeting. so i wanted to summarised the issue and the discussions so far. Especially as neither of you could make it here. clearly this means we need to discuss and reach consensus on this on the mailing list. i'd really like to do this as quickly as poss, since i believe it's the only current discussion issue for the marking behaviour draft (plus perhaps the satoh draft). The issue is about if there are 2 bottlenecks on the path, the first one is pre-congested & excess-traffic-marking pkts and the second one is even more overloaded and is actually dropping pkts. the question is whether the second node should preferentially drop pkts that have already been marked or do something else instead. History of issue: ================== In Philadelphia we discussed the choice between: * MUST preferentially drop pkts that are already excess-traffic-marked OR * MUST drop independent of marking * a logical thid option that we didn't discuss: preferentially drop pkts that are not excess-traffic-marked) There was a consensus for option 1, as a SHOULD There was also a discussion afterwards on the mailing list (one of Steve's "Questions") which confirmed this consensus. I believe a fair summary of the thinking was as follows: (CL/SM = edge behaviour where egress measures rate of pkts that are not ExM (from an ingress), ingress measures rate of pkts (sent to that egress) (MFT = edge behaviour where egress terminates a flow (with some probability) when it sees a marked pkt on that flow * Preferentially drop ExM pkts: works Best for CL/SM ; Works ok for MFT * 'random' drop: breaks completely in some scenarios (terminates far too much) for CL/SM ; works OK (slightly slower than above) for MFT * Preferentially drop pkts not ExM: breaks completely in some scenarios (terminates all flows) for CL/SM ; best for MFT (much faster than above) Michael, i beleive this is what's shown by the paper of yours you pointed me at in your email http://www.ietf.org/mail-archive/web/pcn/current/msg01841.html ie Fig 9 in http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-MFT.pdf we should also bear in mind the pros and cons of CL/SM & MFT: * CL/SM: Can terminate fast ('1 shot') * MFT: Simpler (don't measure rates), but accept trade-off that won't terminate so fast See also more details in http://www.ietf.org/mail-archive/web/pcn/current/msg01449.html so the result of all the discussions at/after Philadelphia was the consensus decision to go for preferentially drop pkts that are already excess-traffic-marked, but as a SHOULD (rather than as a MUST) The latest proposal =================== The proposal from Michael & Georgios is that the preferential dropping behaviour is an Option. Summary of discussion in Minneapolis about proposal ======================================= Pros: All edge behaviours can choose their optimal preferential dropping behaviour Cons: Extra complexity to standardise, implement & operate (configure, manage etc) Quite a few people made comments at the mike. my impression was that the general feeling is that we should think very hard before having an Option - "have one choice" Another question is what a Std with such options would actually say. eg is one of them the default (MUST) and the other(s) a MAY? - making pref. drop the default MUST and 'random' dropping the MAY would be rather empty, since existing routers do tail drop, so you would be saying you MAY do something that the router does anyway! - marking 'random' dropping the default would therefore seem more likely But this then means that the default is something that we know is broken for CL/SM in scenarios that are easy to devise (basically if the link is greatly overloaded, say 5*, then you might over-terminate by 4*). which seems quite scay. - making them both MUSTs to implement (option which is used). this is actually tougher on vendors than what the current draft says (SHOULD for pref. drop - since the 'random dropping' is what the router does today, so it's trivial to offer it if that's demanded. So the conclusion of this discussion was that a SHOULD actually captures quite well what we want to say, ie this is the new behaviour, and this is the thing that means CL/SM can work, whilst MFT can also work OK. We also thought it would be worth adding a brief explanation why it's not a MUST (the Informative Appendix B would be the right place). so we could say something like: - you might instead want to do tail drop, as this is what today's routers do, so lowers the implementation step for PCN. But beware it has these trade-offs for CL/SM Edge behaviour - you might instead want to preferentially drop pkts that arent excess traffic marked, becuase this gives the best overall behaviour for MFT (ie if you know that this is your edge behaviour) Minneappers - Hopefully this captures OK our disussion, please add/correct if it doesnt. Michael, Gegorios, what do you think? thanks, phil _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Nov 19 01:50:22 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 A63EF3A67D0; Wed, 19 Nov 2008 01:50:22 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E07A93A67D0 for ; Wed, 19 Nov 2008 01:50:21 -0800 (PST) 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 bUnBvi6MkoiK for ; Wed, 19 Nov 2008 01:50:20 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 35EB83A676A for ; Wed, 19 Nov 2008 01:50:19 -0800 (PST) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Nov 2008 09:50:18 +0000 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 09:50:16 -0000 Message-ID: In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC04440EA3@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Dropping preference as a configuration option Thread-Index: AclJ7Zf0x+lK08dATZq7YIEA6TblJQAACTdEAA+AbbA= References: <4A916DBC72536E419A0BD955EDECEDEC04440EA1@E03MVB1-UKBR.domain1.systemhost.net> <4A916DBC72536E419A0BD955EDECEDEC04440EA3@E03MVB1-UKBR.domain1.systemhost.net> From: To: , X-OriginalArrivalTime: 19 Nov 2008 09:50:18.0678 (UTC) FILETIME=[3B115D60:01C94A2C] Subject: Re: [PCN] Dropping preference as a configuration option X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org So outcome of discussion is that we stick with a SHOULD for preferential drop, but include some proper explanation of the trade-offs that a vendor might consider when deciding if they can ignore it? This seems to be a very good compromise. Perhaps it could be phrased something like: "nodes SHOULD preferentially drop excess-traffic-marked packets. Alternatively they MAY choose to drop randomly but for many deployment scenarios this is NOT RECOMMENDED (see appendix n for explanation)." Toby > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > philip.eardley@bt.com > Sent: 19 November 2008 03:27 > To: pcn@ietf.org > Subject: [PCN] Dropping preference as a configuration option > > Michael and Georgios have raised this issue recently, and we've > discussed it here in Minneapolis - both in a 'corridor' meeting and in > the WG meeting. > so i wanted to summarised the issue and the discussions so far. > Especially as neither of you could make it here. clearly this means we > need to discuss and reach consensus on this on the mailing list. i'd > really like to do this as quickly as poss, since i believe it's the > only current discussion issue for the marking behaviour draft (plus > perhaps the satoh draft). > > The issue is about if there are 2 bottlenecks on the path, the first > one is pre-congested & excess-traffic-marking pkts and the second one > is even more overloaded and is actually dropping pkts. the question is > whether the second node should preferentially drop pkts that have > already been marked or do something else instead. > > History of issue: > ================== > In Philadelphia we discussed the choice between: > * MUST preferentially drop pkts that are already excess-traffic-marked > OR > * MUST drop independent of marking > * a logical thid option that we didn't discuss: preferentially drop > pkts that are not excess-traffic-marked) > There was a consensus for option 1, as a SHOULD > There was also a discussion afterwards on the mailing list (one of > Steve's "Questions") which confirmed this consensus. > > I believe a fair summary of the thinking was as follows: > (CL/SM = edge behaviour where egress measures rate of pkts that are not > ExM (from an ingress), ingress measures rate of pkts (sent to that > egress) > (MFT = edge behaviour where egress terminates a flow (with some > probability) when it sees a marked pkt on that flow > > * Preferentially drop ExM pkts: works Best for CL/SM ; Works ok for MFT > * 'random' drop: breaks completely in some scenarios (terminates far > too much) for CL/SM ; works OK (slightly slower than above) for MFT > * Preferentially drop pkts not ExM: breaks completely in some scenarios > (terminates all flows) for CL/SM ; best for MFT (much faster than > above) > > Michael, i beleive this is what's shown by the paper of yours you > pointed me at in your email http://www.ietf.org/mail- > archive/web/pcn/current/msg01841.html > ie Fig 9 in http://www3.informatik.uni- > wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-MFT.pdf > > we should also bear in mind the pros and cons of CL/SM & MFT: > * CL/SM: Can terminate fast ('1 shot') > * MFT: Simpler (don't measure rates), but accept trade-off that won't > terminate so fast > See also more details in http://www.ietf.org/mail- > archive/web/pcn/current/msg01449.html > > so the result of all the discussions at/after Philadelphia was the > consensus decision to go for preferentially drop pkts that are already > excess-traffic-marked, but as a SHOULD (rather than as a MUST) > > The latest proposal > =================== > The proposal from Michael & Georgios is that the preferential dropping > behaviour is an Option. > > > Summary of discussion in Minneapolis about proposal > ======================================= > Pros: All edge behaviours can choose their optimal preferential > dropping behaviour > Cons: Extra complexity to standardise, implement & operate (configure, > manage etc) > > Quite a few people made comments at the mike. my impression was that > the general feeling is that we should think very hard before having an > Option - "have one choice" > > Another question is what a Std with such options would actually say. > eg is one of them the default (MUST) and the other(s) a MAY? > - making pref. drop the default MUST and 'random' dropping the MAY > would be rather empty, since existing routers do tail drop, so you > would be saying you MAY do something that the router does anyway! > - marking 'random' dropping the default would therefore seem more > likely But this then means that the default is something that we know > is broken for CL/SM in scenarios that are easy to devise (basically if > the link is greatly overloaded, say 5*, then you might over-terminate > by 4*). which seems quite scay. > - making them both MUSTs to implement (option which is used). this is > actually tougher on vendors than what the current draft says (SHOULD > for pref. drop - since the 'random dropping' is what the router does > today, so it's trivial to offer it if that's demanded. > > So the conclusion of this discussion was that a SHOULD actually > captures quite well what we want to say, ie this is the new behaviour, > and this is the thing that means CL/SM can work, whilst MFT can also > work OK. > We also thought it would be worth adding a brief explanation why it's > not a MUST (the Informative Appendix B would be the right place). so we > could say something like: > - you might instead want to do tail drop, as this is what today's > routers do, so lowers the implementation step for PCN. But beware it > has these trade-offs for CL/SM Edge behaviour > - you might instead want to preferentially drop pkts that arent excess > traffic marked, becuase this gives the best overall behaviour for MFT > (ie if you know that this is your edge behaviour) > > Minneappers - Hopefully this captures OK our disussion, please > add/correct if it doesnt. > > Michael, Gegorios, what do you think? > > thanks, > 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 Wed Nov 19 02:01: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 D9B8A3A67F5; Wed, 19 Nov 2008 02:01:48 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 045AE3A67F5 for ; Wed, 19 Nov 2008 02:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvsl33CZwrQu for ; Wed, 19 Nov 2008 02:01:46 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 426AE3A67D0 for ; Wed, 19 Nov 2008 02:01:46 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id A2552A06EF; Wed, 19 Nov 2008 11:01:44 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 95C52A06EE; Wed, 19 Nov 2008 11:01:44 +0100 (CET) Received: from [132.187.12.151] (win3151.informatik.uni-wuerzburg.de [132.187.12.151]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 7493AA06E7; Wed, 19 Nov 2008 11:01:44 +0100 (CET) Message-ID: <4923E408.3040807@informatik.uni-wuerzburg.de> Date: Wed, 19 Nov 2008 11:01:44 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: toby.moncaster@bt.com References: <4A916DBC72536E419A0BD955EDECEDEC04440EA1@E03MVB1-UKBR.domain1.systemhost.net> <4A916DBC72536E419A0BD955EDECEDEC04440EA3@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Dropping preference as a configuration option 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 Toby and all, the issue of drop preferences highly depends on the edge behavior. E.g. direct measured rate termination or marked flow termination benefit from preferentially dropping unmarked packets while indirect measured rate termination requires preferential dropping of marked packets. Therefore, it makes most sense to demand a certain drop preference when defining the edge behavior (aka deployment model). Defining drop preferences independently of the deployment models is like erasing some of them. This could be done more directly just by saying, we want only this or that deployment model and others not (and not even for later in case the chosen one turns out to be too complex!). If this is not the strategy, the deployment model is the right place for the definition of drop preferences. Fact is that we discovered that drop preferences are an important issue. Therefore, it makes sense to require in general two options in the marking or architecture draft: dropping marked or unmarked packets. The deployment model indicates what's needed. Regards, Michael toby.moncaster@bt.com schrieb: > So outcome of discussion is that we stick with a SHOULD for preferential > drop, but include some proper explanation of the trade-offs that a > vendor might consider when deciding if they can ignore it? > > This seems to be a very good compromise. Perhaps it could be phrased > something like: > > "nodes SHOULD preferentially drop excess-traffic-marked packets. > Alternatively they MAY choose to drop randomly but for many deployment > scenarios this is NOT RECOMMENDED (see appendix n for explanation)." > > Toby > > >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >> philip.eardley@bt.com >> Sent: 19 November 2008 03:27 >> To: pcn@ietf.org >> Subject: [PCN] Dropping preference as a configuration option >> >> Michael and Georgios have raised this issue recently, and we've >> discussed it here in Minneapolis - both in a 'corridor' meeting and in >> the WG meeting. >> so i wanted to summarised the issue and the discussions so far. >> Especially as neither of you could make it here. clearly this means we >> need to discuss and reach consensus on this on the mailing list. i'd >> really like to do this as quickly as poss, since i believe it's the >> only current discussion issue for the marking behaviour draft (plus >> perhaps the satoh draft). >> >> The issue is about if there are 2 bottlenecks on the path, the first >> one is pre-congested & excess-traffic-marking pkts and the second one >> is even more overloaded and is actually dropping pkts. the question is >> whether the second node should preferentially drop pkts that have >> already been marked or do something else instead. >> >> History of issue: >> ================== >> In Philadelphia we discussed the choice between: >> * MUST preferentially drop pkts that are already excess-traffic-marked >> OR >> * MUST drop independent of marking >> * a logical thid option that we didn't discuss: preferentially drop >> pkts that are not excess-traffic-marked) >> There was a consensus for option 1, as a SHOULD >> There was also a discussion afterwards on the mailing list (one of >> Steve's "Questions") which confirmed this consensus. >> >> I believe a fair summary of the thinking was as follows: >> (CL/SM = edge behaviour where egress measures rate of pkts that are >> > not > >> ExM (from an ingress), ingress measures rate of pkts (sent to that >> egress) >> (MFT = edge behaviour where egress terminates a flow (with some >> probability) when it sees a marked pkt on that flow >> >> * Preferentially drop ExM pkts: works Best for CL/SM ; Works ok for >> > MFT > >> * 'random' drop: breaks completely in some scenarios (terminates far >> too much) for CL/SM ; works OK (slightly slower than above) for MFT >> * Preferentially drop pkts not ExM: breaks completely in some >> > scenarios > >> (terminates all flows) for CL/SM ; best for MFT (much faster than >> above) >> >> Michael, i beleive this is what's shown by the paper of yours you >> pointed me at in your email http://www.ietf.org/mail- >> archive/web/pcn/current/msg01841.html >> ie Fig 9 in http://www3.informatik.uni- >> wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-MFT.pdf >> >> we should also bear in mind the pros and cons of CL/SM & MFT: >> * CL/SM: Can terminate fast ('1 shot') >> * MFT: Simpler (don't measure rates), but accept trade-off that won't >> terminate so fast >> See also more details in http://www.ietf.org/mail- >> archive/web/pcn/current/msg01449.html >> >> so the result of all the discussions at/after Philadelphia was the >> consensus decision to go for preferentially drop pkts that are already >> excess-traffic-marked, but as a SHOULD (rather than as a MUST) >> >> The latest proposal >> =================== >> The proposal from Michael & Georgios is that the preferential dropping >> behaviour is an Option. >> >> >> Summary of discussion in Minneapolis about proposal >> ======================================= >> Pros: All edge behaviours can choose their optimal preferential >> dropping behaviour >> Cons: Extra complexity to standardise, implement & operate (configure, >> manage etc) >> >> Quite a few people made comments at the mike. my impression was that >> the general feeling is that we should think very hard before having an >> Option - "have one choice" >> >> Another question is what a Std with such options would actually say. >> eg is one of them the default (MUST) and the other(s) a MAY? >> - making pref. drop the default MUST and 'random' dropping the MAY >> would be rather empty, since existing routers do tail drop, so you >> would be saying you MAY do something that the router does anyway! >> - marking 'random' dropping the default would therefore seem more >> likely But this then means that the default is something that we know >> is broken for CL/SM in scenarios that are easy to devise (basically if >> the link is greatly overloaded, say 5*, then you might over-terminate >> by 4*). which seems quite scay. >> - making them both MUSTs to implement (option which is used). this is >> actually tougher on vendors than what the current draft says (SHOULD >> for pref. drop - since the 'random dropping' is what the router does >> today, so it's trivial to offer it if that's demanded. >> >> So the conclusion of this discussion was that a SHOULD actually >> captures quite well what we want to say, ie this is the new behaviour, >> and this is the thing that means CL/SM can work, whilst MFT can also >> work OK. >> We also thought it would be worth adding a brief explanation why it's >> not a MUST (the Informative Appendix B would be the right place). so >> > we > >> could say something like: >> - you might instead want to do tail drop, as this is what today's >> routers do, so lowers the implementation step for PCN. But beware it >> has these trade-offs for CL/SM Edge behaviour >> - you might instead want to preferentially drop pkts that arent excess >> traffic marked, becuase this gives the best overall behaviour for MFT >> (ie if you know that this is your edge behaviour) >> >> Minneappers - Hopefully this captures OK our disussion, please >> add/correct if it doesnt. >> >> Michael, Gegorios, what do you think? >> >> thanks, >> 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 Wed Nov 19 02:18: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 D48653A6936; Wed, 19 Nov 2008 02:18:23 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBD713A6988 for ; Wed, 19 Nov 2008 02:18:22 -0800 (PST) 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 nqsR4svNfieH for ; Wed, 19 Nov 2008 02:18:21 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 6F4773A6936 for ; Wed, 19 Nov 2008 02:18:21 -0800 (PST) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id mAJAIFLN007698; Wed, 19 Nov 2008 11:18:18 +0100 (MET) From: "Georgios Karagiannis" To: , References: <4A916DBC72536E419A0BD955EDECEDEC04440EA1@E03MVB1-UKBR.domain1.systemhost.net> <4A916DBC72536E419A0BD955EDECEDEC04440EA3@E03MVB1-UKBR.domain1.systemhost.net> Date: Wed, 19 Nov 2008 11:18:10 +0100 Message-ID: <001601c94a30$22768c90$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: <4A916DBC72536E419A0BD955EDECEDEC04440EA3@E03MVB1-UKBR.domain1.systemhost.net> Thread-Index: AclJ7Zf0x+lK08dATZq7YIEA6TblJQAACTdEABB0SdA= X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 19 Nov 2008 11:18:19 +0100 (MET) Subject: Re: [PCN] Dropping preference as a configuration option X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Phil I think that the conclusions, of the discussions, regarding SHOULD for dropping, see below, are reasonable to me. However, regarding the text that will be given in Appendix A should be carefully written! > > So the conclusion of this discussion was that a SHOULD > actually captures quite well what we want to say, ie this is > the new behaviour, and this is the thing that means CL/SM can > work, whilst MFT can also work OK. > We also thought it would be worth adding a brief explanation > why it's not a MUST (the Informative Appendix B would be the > right place). so we could say something like: > - you might instead want to do tail drop, as this is what > today's routers do, so lowers the implementation step for > PCN. But beware it has these trade-offs for CL/SM Edge behaviour > - you might instead want to preferentially drop pkts that > arent excess traffic marked, becuase this gives the best > overall behaviour for MFT (ie if you know that this is your > edge behaviour) Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of philip.eardley@bt.com > Sent: woensdag 19 november 2008 4:27 > To: pcn@ietf.org > Subject: [PCN] Dropping preference as a configuration option > > Michael and Georgios have raised this issue recently, and > we've discussed it here in Minneapolis - both in a 'corridor' > meeting and in the WG meeting. > so i wanted to summarised the issue and the discussions so > far. Especially as neither of you could make it here. clearly > this means we need to discuss and reach consensus on this on > the mailing list. i'd really like to do this as quickly as > poss, since i believe it's the only current discussion issue > for the marking behaviour draft (plus perhaps the satoh draft). > > The issue is about if there are 2 bottlenecks on the path, > the first one is pre-congested & excess-traffic-marking pkts > and the second one is even more overloaded and is actually > dropping pkts. the question is whether the second node should > preferentially drop pkts that have already been marked or do > something else instead. > > History of issue: > ================== > In Philadelphia we discussed the choice between: > * MUST preferentially drop pkts that are already > excess-traffic-marked OR > * MUST drop independent of marking > * a logical thid option that we didn't discuss: > preferentially drop pkts that are not excess-traffic-marked) > There was a consensus for option 1, as a SHOULD There was > also a discussion afterwards on the mailing list (one of > Steve's "Questions") which confirmed this consensus. > > I believe a fair summary of the thinking was as follows: > (CL/SM = edge behaviour where egress measures rate of pkts > that are not ExM (from an ingress), ingress measures rate of > pkts (sent to that egress) (MFT = edge behaviour where egress > terminates a flow (with some probability) when it sees a > marked pkt on that flow > > * Preferentially drop ExM pkts: works Best for CL/SM ; Works > ok for MFT > * 'random' drop: breaks completely in some scenarios > (terminates far too much) for CL/SM ; works OK (slightly > slower than above) for MFT > * Preferentially drop pkts not ExM: breaks completely in some > scenarios (terminates all flows) for CL/SM ; best for MFT > (much faster than above) > > Michael, i beleive this is what's shown by the paper of yours > you pointed me at in your email > http://www.ietf.org/mail-archive/web/pcn/current/msg01841.html > ie Fig 9 in > http://www3.informatik.uni-wuerzburg.de/staff/menth/Publicatio ns/papers/Menth08-PCN-MFT.pdf > > we should also bear in mind the pros and cons of CL/SM & MFT: > * CL/SM: Can terminate fast ('1 shot') > * MFT: Simpler (don't measure rates), but accept trade-off > that won't terminate so fast See also more details in > http://www.ietf.org/mail-archive/web/pcn/current/msg01449.html > > so the result of all the discussions at/after Philadelphia > was the consensus decision to go for preferentially drop pkts > that are already excess-traffic-marked, but as a SHOULD > (rather than as a MUST) > > The latest proposal > =================== > The proposal from Michael & Georgios is that the preferential > dropping behaviour is an Option. > > > Summary of discussion in Minneapolis about proposal > ======================================= > Pros: All edge behaviours can choose their optimal > preferential dropping behaviour > Cons: Extra complexity to standardise, implement & operate > (configure, manage etc) > > Quite a few people made comments at the mike. my impression > was that the general feeling is that we should think very > hard before having an Option - "have one choice" > > Another question is what a Std with such options would actually say. > eg is one of them the default (MUST) and the other(s) a MAY? > - making pref. drop the default MUST and 'random' dropping > the MAY would be rather empty, since existing routers do tail > drop, so you would be saying you MAY do something that the > router does anyway! > - marking 'random' dropping the default would therefore seem > more likely But this then means that the default is something > that we know is broken for CL/SM in scenarios that are easy > to devise (basically if the link is greatly overloaded, say > 5*, then you might over-terminate by 4*). which seems quite scay. > - making them both MUSTs to implement (option which is used). > this is actually tougher on vendors than what the current > draft says (SHOULD for pref. drop - since the 'random > dropping' is what the router does today, so it's trivial to > offer it if that's demanded. > > So the conclusion of this discussion was that a SHOULD > actually captures quite well what we want to say, ie this is > the new behaviour, and this is the thing that means CL/SM can > work, whilst MFT can also work OK. > We also thought it would be worth adding a brief explanation > why it's not a MUST (the Informative Appendix B would be the > right place). so we could say something like: > - you might instead want to do tail drop, as this is what > today's routers do, so lowers the implementation step for > PCN. But beware it has these trade-offs for CL/SM Edge behaviour > - you might instead want to preferentially drop pkts that > arent excess traffic marked, becuase this gives the best > overall behaviour for MFT (ie if you know that this is your > edge behaviour) > > Minneappers - Hopefully this captures OK our disussion, > please add/correct if it doesnt. > > Michael, Gegorios, what do you think? > > thanks, > 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 Wed Nov 19 02:27: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 770CF3A684B; Wed, 19 Nov 2008 02:27:13 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F64F3A684B for ; Wed, 19 Nov 2008 02:27:12 -0800 (PST) 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 yKmvlfuzfTPn for ; Wed, 19 Nov 2008 02:27:11 -0800 (PST) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id F25A23A67B2 for ; Wed, 19 Nov 2008 02:27:10 -0800 (PST) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id mAJAR5MU009239; Wed, 19 Nov 2008 11:27:08 +0100 (MET) From: "Georgios Karagiannis" To: , References: <4A916DBC72536E419A0BD955EDECEDEC04440E9F@E03MVB1-UKBR.domain1.systemhost.net> <4A916DBC72536E419A0BD955EDECEDEC04440EA0@E03MVB1-UKBR.domain1.systemhost.net> Date: Wed, 19 Nov 2008 11:27:00 +0100 Message-ID: <001801c94a31$5e857fb0$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: <4A916DBC72536E419A0BD955EDECEDEC04440EA0@E03MVB1-UKBR.domain1.systemhost.net> Thread-Index: AclJ65CRaBa70dnERw+ExM7HzdY3iAAAAnd1ABE6r1A= X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 19 Nov 2008 11:27:09 +0100 (MET) Subject: Re: [PCN] new version LC-PCN draft + conclusions 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 My argument was that doing the "1/N" at the PCN-boundary-node instead of the PCN-interior-node is not good enough! However, I would like to propose the following: * Work-out the option of doing 1/N at the PCN-boundary-node. * If this option is not good enough to satisfy the requirements for a PCN deployment scenario like LC-PCN, then allow to work out an experimental specification that can use the 1/N proportionality at PCN_interior_nodes. Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: woensdag 19 november 2008 3:16 > To: pcn@ietf.org; karagian@cs.utwente.nl > Subject: RE: [PCN] new version LC-PCN draft + conclusions > > HI Georgios > response to your third point below. > > this has already been discussed extensively on the mailing > list. there seems no benefit to this, because the same system > behaviour can be achieved by doing "1/N" behaviour at the > PCN-boundary-node instead of at the PCN-interior-node. > > pointers to previous discussion: > http://www.ietf.org/mail-archive/web/pcn/current/msg01642.html > http://www.ietf.org/mail-archive/web/pcn/current/msg01091.html > https://datatracker.ietf.org/drafts/draft-menth-pcn-emft/ > > so i am strongly opposed to including this option in the > markng draft. > > phil > > ---------------------------- > * Subject: [PCN] new version LC-PCN draft + conclusions > * From: "Georgios Karagiannis" > > * Date: Tue, 11 Nov 2008 17:16:05 +0000 > > Dear all > > Please note that a new version of the LC-PCN draft has been submitted, > see: > > http://www.ietf.org/internet-drafts/draft-westberg-pcn-load-co ntrol-05.txt > > This version contains among other results also the results > that were presented during the IETF in Dublin. > > Section 5.8 contains the following experiment conclusions. > > Based on the results obtained from the experiments presented in > Sections 5.5, 5.6 and 5.7 this document recommends the following: > > o Leave open the option to use PCN_Affected_Marking encoding since > it can solve the ECMP problem and it can provide an efficient > solution for the HOSE model. In this document the term HOSE is > referring to the aggregation of incoming traffic from > all ingress > edges, which is associated with one traffic class, i.e., PHB, > towards one egress edge. This type of HOSE model is > equivalent to > the Multiple to Point (MP2P) type of aggregation. > > o Leave open the option of using random dropping in PCN-interior- > nodes for PCN_Marking, PCN_Affected_Marking and PCN_unmarked > encoded packets. > > o Leave open the option of using the parameter N such that the > marked excess rate can represent also high level of measured > excess rate: > > **** Implemented by marking every N-th packet (or byte) instead of > marking each packet (or byte). > > Best regards, > Georgios > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Nov 19 07:58: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 DE86F3A6A8B; Wed, 19 Nov 2008 07:58:03 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE59C3A6A8B for ; Wed, 19 Nov 2008 07:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[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 JAE3SIJvctli for ; Wed, 19 Nov 2008 07:58:01 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 87B5D3A6805 for ; Wed, 19 Nov 2008 07:58:01 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Nov 2008 15:57:59 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 15:57:58 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04440EA5@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] new version LC-PCN draft + conclusions Thread-Index: AclJ65CRaBa70dnERw+ExM7HzdY3iAAAAnd1ABE6r1AAC268WA== References: <4A916DBC72536E419A0BD955EDECEDEC04440E9F@E03MVB1-UKBR.domain1.systemhost.net> <4A916DBC72536E419A0BD955EDECEDEC04440EA0@E03MVB1-UKBR.domain1.systemhost.net> <001801c94a31$5e857fb0$810c5982@dynamic.ewi.utwente.nl> From: To: , X-OriginalArrivalTime: 19 Nov 2008 15:57:59.0184 (UTC) FILETIME=[98277100:01C94A5F] Subject: Re: [PCN] new version LC-PCN draft + conclusions 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're saying that you're happy for the marking behaviour draft to go ahead as it is ie without any 1/N option in the marking behaviour - thank! yes, the 1/N boundary behaviour can be worked out further by those interested (there seems good evidence it works, but of course more evidence is always good). as to your proposal that if the evidence isnt good enough, then do an experimental specification for marking behaviour - i guess this would have to be considered as part of any re-chartering. best wishes phil ________________________________ From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] Sent: Wed 19/11/2008 10:27 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] new version LC-PCN draft + conclusions Hi Phil My argument was that doing the "1/N" at the PCN-boundary-node instead of the PCN-interior-node is not good enough! However, I would like to propose the following: * Work-out the option of doing 1/N at the PCN-boundary-node. * If this option is not good enough to satisfy the requirements for a PCN deployment scenario like LC-PCN, then allow to work out an experimental specification that can use the 1/N proportionality at PCN_interior_nodes. Best regards, Georgios > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: woensdag 19 november 2008 3:16 > To: pcn@ietf.org; karagian@cs.utwente.nl > Subject: RE: [PCN] new version LC-PCN draft + conclusions > > HI Georgios > response to your third point below. > > this has already been discussed extensively on the mailing > list. there seems no benefit to this, because the same system > behaviour can be achieved by doing "1/N" behaviour at the > PCN-boundary-node instead of at the PCN-interior-node. > > pointers to previous discussion: > http://www.ietf.org/mail-archive/web/pcn/current/msg01642.html > http://www.ietf.org/mail-archive/web/pcn/current/msg01091.html > https://datatracker.ietf.org/drafts/draft-menth-pcn-emft/ > > so i am strongly opposed to including this option in the > markng draft. > > phil > > ---------------------------- > * Subject: [PCN] new version LC-PCN draft + conclusions > * From: "Georgios Karagiannis" > > * Date: Tue, 11 Nov 2008 17:16:05 +0000 > > Dear all > > Please note that a new version of the LC-PCN draft has been submitted, > see: > > http://www.ietf.org/internet-drafts/draft-westberg-pcn-load-co ntrol-05.txt > > This version contains among other results also the results > that were presented during the IETF in Dublin. > > Section 5.8 contains the following experiment conclusions. > > Based on the results obtained from the experiments presented in > Sections 5.5, 5.6 and 5.7 this document recommends the following: > > o Leave open the option to use PCN_Affected_Marking encoding since > it can solve the ECMP problem and it can provide an efficient > solution for the HOSE model. In this document the term HOSE is > referring to the aggregation of incoming traffic from > all ingress > edges, which is associated with one traffic class, i.e., PHB, > towards one egress edge. This type of HOSE model is > equivalent to > the Multiple to Point (MP2P) type of aggregation. > > o Leave open the option of using random dropping in PCN-interior- > nodes for PCN_Marking, PCN_Affected_Marking and PCN_unmarked > encoded packets. > > o Leave open the option of using the parameter N such that the > marked excess rate can represent also high level of measured > excess rate: > > **** Implemented by marking every N-th packet (or byte) instead of > marking each packet (or byte). > > Best regards, > Georgios > _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Nov 19 13:58: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 7DE7B3A6AED; Wed, 19 Nov 2008 13:58:49 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E4403A6A84 for ; Wed, 19 Nov 2008 13:58:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[AWL=1.000, 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 vDD0RjAF2lU2 for ; Wed, 19 Nov 2008 13:58:47 -0800 (PST) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 9F80B3A6ABB for ; Wed, 19 Nov 2008 13:58:46 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Nov 2008 21:58:42 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 21:57:57 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04440EB3@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Dropping preference as a configuration option Thread-Index: AclJ7Zf0x+lK08dATZq7YIEA6TblJQAACTdEAA+AbbAAGYjRsg== References: <4A916DBC72536E419A0BD955EDECEDEC04440EA1@E03MVB1-UKBR.domain1.systemhost.net> <4A916DBC72536E419A0BD955EDECEDEC04440EA3@E03MVB1-UKBR.domain1.systemhost.net> From: To: , X-OriginalArrivalTime: 19 Nov 2008 21:58:42.0100 (UTC) FILETIME=[FC565740:01C94A91] Subject: Re: [PCN] Dropping preference as a configuration option X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org >> So outcome of discussion is that we stick with a SHOULD for preferential drop, but include some proper explanation of the trade-offs that a vendor might consider when deciding if they can ignore it? [phil] yes, that's right ________________________________ From: Moncaster,T,Toby,CXR9 R Sent: Wed 19/11/2008 09:50 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] Dropping preference as a configuration option So outcome of discussion is that we stick with a SHOULD for preferential drop, but include some proper explanation of the trade-offs that a vendor might consider when deciding if they can ignore it? This seems to be a very good compromise. Perhaps it could be phrased something like: "nodes SHOULD preferentially drop excess-traffic-marked packets. Alternatively they MAY choose to drop randomly but for many deployment scenarios this is NOT RECOMMENDED (see appendix n for explanation)." Toby > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > philip.eardley@bt.com > Sent: 19 November 2008 03:27 > To: pcn@ietf.org > Subject: [PCN] Dropping preference as a configuration option > > Michael and Georgios have raised this issue recently, and we've > discussed it here in Minneapolis - both in a 'corridor' meeting and in > the WG meeting. > so i wanted to summarised the issue and the discussions so far. > Especially as neither of you could make it here. clearly this means we > need to discuss and reach consensus on this on the mailing list. i'd > really like to do this as quickly as poss, since i believe it's the > only current discussion issue for the marking behaviour draft (plus > perhaps the satoh draft). > > The issue is about if there are 2 bottlenecks on the path, the first > one is pre-congested & excess-traffic-marking pkts and the second one > is even more overloaded and is actually dropping pkts. the question is > whether the second node should preferentially drop pkts that have > already been marked or do something else instead. > > History of issue: > ================== > In Philadelphia we discussed the choice between: > * MUST preferentially drop pkts that are already excess-traffic-marked > OR > * MUST drop independent of marking > * a logical thid option that we didn't discuss: preferentially drop > pkts that are not excess-traffic-marked) > There was a consensus for option 1, as a SHOULD > There was also a discussion afterwards on the mailing list (one of > Steve's "Questions") which confirmed this consensus. > > I believe a fair summary of the thinking was as follows: > (CL/SM = edge behaviour where egress measures rate of pkts that are not > ExM (from an ingress), ingress measures rate of pkts (sent to that > egress) > (MFT = edge behaviour where egress terminates a flow (with some > probability) when it sees a marked pkt on that flow > > * Preferentially drop ExM pkts: works Best for CL/SM ; Works ok for MFT > * 'random' drop: breaks completely in some scenarios (terminates far > too much) for CL/SM ; works OK (slightly slower than above) for MFT > * Preferentially drop pkts not ExM: breaks completely in some scenarios > (terminates all flows) for CL/SM ; best for MFT (much faster than > above) > > Michael, i beleive this is what's shown by the paper of yours you > pointed me at in your email http://www.ietf.org/mail- > archive/web/pcn/current/msg01841.html > ie Fig 9 in http://www3.informatik.uni- > wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-MFT.pdf > > we should also bear in mind the pros and cons of CL/SM & MFT: > * CL/SM: Can terminate fast ('1 shot') > * MFT: Simpler (don't measure rates), but accept trade-off that won't > terminate so fast > See also more details in http://www.ietf.org/mail- > archive/web/pcn/current/msg01449.html > > so the result of all the discussions at/after Philadelphia was the > consensus decision to go for preferentially drop pkts that are already > excess-traffic-marked, but as a SHOULD (rather than as a MUST) > > The latest proposal > =================== > The proposal from Michael & Georgios is that the preferential dropping > behaviour is an Option. > > > Summary of discussion in Minneapolis about proposal > ======================================= > Pros: All edge behaviours can choose their optimal preferential > dropping behaviour > Cons: Extra complexity to standardise, implement & operate (configure, > manage etc) > > Quite a few people made comments at the mike. my impression was that > the general feeling is that we should think very hard before having an > Option - "have one choice" > > Another question is what a Std with such options would actually say. > eg is one of them the default (MUST) and the other(s) a MAY? > - making pref. drop the default MUST and 'random' dropping the MAY > would be rather empty, since existing routers do tail drop, so you > would be saying you MAY do something that the router does anyway! > - marking 'random' dropping the default would therefore seem more > likely But this then means that the default is something that we know > is broken for CL/SM in scenarios that are easy to devise (basically if > the link is greatly overloaded, say 5*, then you might over-terminate > by 4*). which seems quite scay. > - making them both MUSTs to implement (option which is used). this is > actually tougher on vendors than what the current draft says (SHOULD > for pref. drop - since the 'random dropping' is what the router does > today, so it's trivial to offer it if that's demanded. > > So the conclusion of this discussion was that a SHOULD actually > captures quite well what we want to say, ie this is the new behaviour, > and this is the thing that means CL/SM can work, whilst MFT can also > work OK. > We also thought it would be worth adding a brief explanation why it's > not a MUST (the Informative Appendix B would be the right place). so we > could say something like: > - you might instead want to do tail drop, as this is what today's > routers do, so lowers the implementation step for PCN. But beware it > has these trade-offs for CL/SM Edge behaviour > - you might instead want to preferentially drop pkts that arent excess > traffic marked, becuase this gives the best overall behaviour for MFT > (ie if you know that this is your edge behaviour) > > Minneappers - Hopefully this captures OK our disussion, please > add/correct if it doesnt. > > Michael, Gegorios, what do you think? > > thanks, > 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 Wed Nov 19 14:07: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 59EA53A6931; Wed, 19 Nov 2008 14:07:10 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 525DB3A6931 for ; Wed, 19 Nov 2008 14:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=0.500, 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 OP23UOmRJ9si for ; Wed, 19 Nov 2008 14:07:08 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id A3F633A6895 for ; Wed, 19 Nov 2008 14:07:07 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Nov 2008 22:07:03 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 22:07:03 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04440EB4@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Dropping preference as a configuration option Thread-Index: AclKLeBhaj9/07lHQ2iM/4aQ5oNzpwAZDJZv References: <4A916DBC72536E419A0BD955EDECEDEC04440EA1@E03MVB1-UKBR.domain1.systemhost.net> <4A916DBC72536E419A0BD955EDECEDEC04440EA3@E03MVB1-UKBR.domain1.systemhost.net> <4923E408.3040807@informatik.uni-wuerzburg.de> From: To: , X-OriginalArrivalTime: 19 Nov 2008 22:07:03.0405 (UTC) FILETIME=[272369D0:01C94A93] Cc: pcn@ietf.org Subject: Re: [PCN] Dropping preference as a configuration option X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Michael firstly, i don't beleive it "highly" depends. marked flow termination still works with preferential dropping of exces-traffic-marked pkts, eg your paper showed that this was nearly as good as 'random' dropping for MFT (i remember 3.5secs vs 3secs). please see discussion below and pointers to other emails. secondly, independently of the above, any proposal needs to be phrased in standards language, since the Marking behaviour is a Stds doc. please see the paragrpah below that starts "Another question is what a Std with such options would actually say." thanks phil ________________________________ From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] Sent: Wed 19/11/2008 10:01 To: Moncaster,T,Toby,CXR9 R Cc: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: Re: [PCN] Dropping preference as a configuration option Hi Toby and all, the issue of drop preferences highly depends on the edge behavior. E.g. direct measured rate termination or marked flow termination benefit from preferentially dropping unmarked packets while indirect measured rate termination requires preferential dropping of marked packets. Therefore, it makes most sense to demand a certain drop preference when defining the edge behavior (aka deployment model). Defining drop preferences independently of the deployment models is like erasing some of them. This could be done more directly just by saying, we want only this or that deployment model and others not (and not even for later in case the chosen one turns out to be too complex!). If this is not the strategy, the deployment model is the right place for the definition of drop preferences. Fact is that we discovered that drop preferences are an important issue. Therefore, it makes sense to require in general two options in the marking or architecture draft: dropping marked or unmarked packets. The deployment model indicates what's needed. Regards, Michael toby.moncaster@bt.com schrieb: > So outcome of discussion is that we stick with a SHOULD for preferential > drop, but include some proper explanation of the trade-offs that a > vendor might consider when deciding if they can ignore it? > > This seems to be a very good compromise. Perhaps it could be phrased > something like: > > "nodes SHOULD preferentially drop excess-traffic-marked packets. > Alternatively they MAY choose to drop randomly but for many deployment > scenarios this is NOT RECOMMENDED (see appendix n for explanation)." > > Toby > > >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >> philip.eardley@bt.com >> Sent: 19 November 2008 03:27 >> To: pcn@ietf.org >> Subject: [PCN] Dropping preference as a configuration option >> >> Michael and Georgios have raised this issue recently, and we've >> discussed it here in Minneapolis - both in a 'corridor' meeting and in >> the WG meeting. >> so i wanted to summarised the issue and the discussions so far. >> Especially as neither of you could make it here. clearly this means we >> need to discuss and reach consensus on this on the mailing list. i'd >> really like to do this as quickly as poss, since i believe it's the >> only current discussion issue for the marking behaviour draft (plus >> perhaps the satoh draft). >> >> The issue is about if there are 2 bottlenecks on the path, the first >> one is pre-congested & excess-traffic-marking pkts and the second one >> is even more overloaded and is actually dropping pkts. the question is >> whether the second node should preferentially drop pkts that have >> already been marked or do something else instead. >> >> History of issue: >> ================== >> In Philadelphia we discussed the choice between: >> * MUST preferentially drop pkts that are already excess-traffic-marked >> OR >> * MUST drop independent of marking >> * a logical thid option that we didn't discuss: preferentially drop >> pkts that are not excess-traffic-marked) >> There was a consensus for option 1, as a SHOULD >> There was also a discussion afterwards on the mailing list (one of >> Steve's "Questions") which confirmed this consensus. >> >> I believe a fair summary of the thinking was as follows: >> (CL/SM = edge behaviour where egress measures rate of pkts that are >> > not > >> ExM (from an ingress), ingress measures rate of pkts (sent to that >> egress) >> (MFT = edge behaviour where egress terminates a flow (with some >> probability) when it sees a marked pkt on that flow >> >> * Preferentially drop ExM pkts: works Best for CL/SM ; Works ok for >> > MFT > >> * 'random' drop: breaks completely in some scenarios (terminates far >> too much) for CL/SM ; works OK (slightly slower than above) for MFT >> * Preferentially drop pkts not ExM: breaks completely in some >> > scenarios > >> (terminates all flows) for CL/SM ; best for MFT (much faster than >> above) >> >> Michael, i beleive this is what's shown by the paper of yours you >> pointed me at in your email http://www.ietf.org/mail- >> archive/web/pcn/current/msg01841.html >> ie Fig 9 in http://www3.informatik.uni- >> wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-MFT.pdf >> >> we should also bear in mind the pros and cons of CL/SM & MFT: >> * CL/SM: Can terminate fast ('1 shot') >> * MFT: Simpler (don't measure rates), but accept trade-off that won't >> terminate so fast >> See also more details in http://www.ietf.org/mail- >> archive/web/pcn/current/msg01449.html >> >> so the result of all the discussions at/after Philadelphia was the >> consensus decision to go for preferentially drop pkts that are already >> excess-traffic-marked, but as a SHOULD (rather than as a MUST) >> >> The latest proposal >> =================== >> The proposal from Michael & Georgios is that the preferential dropping >> behaviour is an Option. >> >> >> Summary of discussion in Minneapolis about proposal >> ======================================= >> Pros: All edge behaviours can choose their optimal preferential >> dropping behaviour >> Cons: Extra complexity to standardise, implement & operate (configure, >> manage etc) >> >> Quite a few people made comments at the mike. my impression was that >> the general feeling is that we should think very hard before having an >> Option - "have one choice" >> >> Another question is what a Std with such options would actually say. >> eg is one of them the default (MUST) and the other(s) a MAY? >> - making pref. drop the default MUST and 'random' dropping the MAY >> would be rather empty, since existing routers do tail drop, so you >> would be saying you MAY do something that the router does anyway! >> - marking 'random' dropping the default would therefore seem more >> likely But this then means that the default is something that we know >> is broken for CL/SM in scenarios that are easy to devise (basically if >> the link is greatly overloaded, say 5*, then you might over-terminate >> by 4*). which seems quite scay. >> - making them both MUSTs to implement (option which is used). this is >> actually tougher on vendors than what the current draft says (SHOULD >> for pref. drop - since the 'random dropping' is what the router does >> today, so it's trivial to offer it if that's demanded. >> >> So the conclusion of this discussion was that a SHOULD actually >> captures quite well what we want to say, ie this is the new behaviour, >> and this is the thing that means CL/SM can work, whilst MFT can also >> work OK. >> We also thought it would be worth adding a brief explanation why it's >> not a MUST (the Informative Appendix B would be the right place). so >> > we > >> could say something like: >> - you might instead want to do tail drop, as this is what today's >> routers do, so lowers the implementation step for PCN. But beware it >> has these trade-offs for CL/SM Edge behaviour >> - you might instead want to preferentially drop pkts that arent excess >> traffic marked, becuase this gives the best overall behaviour for MFT >> (ie if you know that this is your edge behaviour) >> >> Minneappers - Hopefully this captures OK our disussion, please >> add/correct if it doesnt. >> >> Michael, Gegorios, what do you think? >> >> thanks, >> 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 Wed Nov 19 14:32: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 02C4F3A6AE9; Wed, 19 Nov 2008 14:32:34 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0F513A6A8B for ; Wed, 19 Nov 2008 14:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.633, 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 AR8gPJQKMckF for ; Wed, 19 Nov 2008 14:32:30 -0800 (PST) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 595083A6A84 for ; Wed, 19 Nov 2008 14:32:30 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Nov 2008 22:09:52 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 22:07:32 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04440EB6@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Dropping preference as a configuration option Thread-Index: AclJ7Zf0x+lK08dATZq7YIEA6TblJQAACTdEABB0SdAAGOq0fw== References: <4A916DBC72536E419A0BD955EDECEDEC04440EA1@E03MVB1-UKBR.domain1.systemhost.net> <4A916DBC72536E419A0BD955EDECEDEC04440EA3@E03MVB1-UKBR.domain1.systemhost.net> <001601c94a30$22768c90$810c5982@dynamic.ewi.utwente.nl> From: To: , X-OriginalArrivalTime: 19 Nov 2008 22:09:52.0132 (UTC) FILETIME=[8BB51C40:01C94A93] Subject: Re: [PCN] Dropping preference as a configuration option X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Georgios excellent, thanks. i'll try and work a proposal for some text for the Appendix (probably next week). i agree it needs careful writing and that this may take some bashing to get right. phil ________________________________ From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] Sent: Wed 19/11/2008 10:18 To: Eardley,PL,Philip,CXR9 R; pcn@ietf.org Subject: RE: [PCN] Dropping preference as a configuration option Hi Phil I think that the conclusions, of the discussions, regarding SHOULD for dropping, see below, are reasonable to me. However, regarding the text that will be given in Appendix A should be carefully written! > > So the conclusion of this discussion was that a SHOULD > actually captures quite well what we want to say, ie this is > the new behaviour, and this is the thing that means CL/SM can > work, whilst MFT can also work OK. > We also thought it would be worth adding a brief explanation > why it's not a MUST (the Informative Appendix B would be the > right place). so we could say something like: > - you might instead want to do tail drop, as this is what > today's routers do, so lowers the implementation step for > PCN. But beware it has these trade-offs for CL/SM Edge behaviour > - you might instead want to preferentially drop pkts that > arent excess traffic marked, becuase this gives the best > overall behaviour for MFT (ie if you know that this is your > edge behaviour) Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of philip.eardley@bt.com > Sent: woensdag 19 november 2008 4:27 > To: pcn@ietf.org > Subject: [PCN] Dropping preference as a configuration option > > Michael and Georgios have raised this issue recently, and > we've discussed it here in Minneapolis - both in a 'corridor' > meeting and in the WG meeting. > so i wanted to summarised the issue and the discussions so > far. Especially as neither of you could make it here. clearly > this means we need to discuss and reach consensus on this on > the mailing list. i'd really like to do this as quickly as > poss, since i believe it's the only current discussion issue > for the marking behaviour draft (plus perhaps the satoh draft). > > The issue is about if there are 2 bottlenecks on the path, > the first one is pre-congested & excess-traffic-marking pkts > and the second one is even more overloaded and is actually > dropping pkts. the question is whether the second node should > preferentially drop pkts that have already been marked or do > something else instead. > > History of issue: > ================== > In Philadelphia we discussed the choice between: > * MUST preferentially drop pkts that are already > excess-traffic-marked OR > * MUST drop independent of marking > * a logical thid option that we didn't discuss: > preferentially drop pkts that are not excess-traffic-marked) > There was a consensus for option 1, as a SHOULD There was > also a discussion afterwards on the mailing list (one of > Steve's "Questions") which confirmed this consensus. > > I believe a fair summary of the thinking was as follows: > (CL/SM = edge behaviour where egress measures rate of pkts > that are not ExM (from an ingress), ingress measures rate of > pkts (sent to that egress) (MFT = edge behaviour where egress > terminates a flow (with some probability) when it sees a > marked pkt on that flow > > * Preferentially drop ExM pkts: works Best for CL/SM ; Works > ok for MFT > * 'random' drop: breaks completely in some scenarios > (terminates far too much) for CL/SM ; works OK (slightly > slower than above) for MFT > * Preferentially drop pkts not ExM: breaks completely in some > scenarios (terminates all flows) for CL/SM ; best for MFT > (much faster than above) > > Michael, i beleive this is what's shown by the paper of yours > you pointed me at in your email > http://www.ietf.org/mail-archive/web/pcn/current/msg01841.html > ie Fig 9 in > http://www3.informatik.uni-wuerzburg.de/staff/menth/Publicatio ns/papers/Menth08-PCN-MFT.pdf > > we should also bear in mind the pros and cons of CL/SM & MFT: > * CL/SM: Can terminate fast ('1 shot') > * MFT: Simpler (don't measure rates), but accept trade-off > that won't terminate so fast See also more details in > http://www.ietf.org/mail-archive/web/pcn/current/msg01449.html > > so the result of all the discussions at/after Philadelphia > was the consensus decision to go for preferentially drop pkts > that are already excess-traffic-marked, but as a SHOULD > (rather than as a MUST) > > The latest proposal > =================== > The proposal from Michael & Georgios is that the preferential > dropping behaviour is an Option. > > > Summary of discussion in Minneapolis about proposal > ======================================= > Pros: All edge behaviours can choose their optimal > preferential dropping behaviour > Cons: Extra complexity to standardise, implement & operate > (configure, manage etc) > > Quite a few people made comments at the mike. my impression > was that the general feeling is that we should think very > hard before having an Option - "have one choice" > > Another question is what a Std with such options would actually say. > eg is one of them the default (MUST) and the other(s) a MAY? > - making pref. drop the default MUST and 'random' dropping > the MAY would be rather empty, since existing routers do tail > drop, so you would be saying you MAY do something that the > router does anyway! > - marking 'random' dropping the default would therefore seem > more likely But this then means that the default is something > that we know is broken for CL/SM in scenarios that are easy > to devise (basically if the link is greatly overloaded, say > 5*, then you might over-terminate by 4*). which seems quite scay. > - making them both MUSTs to implement (option which is used). > this is actually tougher on vendors than what the current > draft says (SHOULD for pref. drop - since the 'random > dropping' is what the router does today, so it's trivial to > offer it if that's demanded. > > So the conclusion of this discussion was that a SHOULD > actually captures quite well what we want to say, ie this is > the new behaviour, and this is the thing that means CL/SM can > work, whilst MFT can also work OK. > We also thought it would be worth adding a brief explanation > why it's not a MUST (the Informative Appendix B would be the > right place). so we could say something like: > - you might instead want to do tail drop, as this is what > today's routers do, so lowers the implementation step for > PCN. But beware it has these trade-offs for CL/SM Edge behaviour > - you might instead want to preferentially drop pkts that > arent excess traffic marked, becuase this gives the best > overall behaviour for MFT (ie if you know that this is your > edge behaviour) > > Minneappers - Hopefully this captures OK our disussion, > please add/correct if it doesnt. > > Michael, Gegorios, what do you think? > > thanks, > 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 Wed Nov 19 14:34: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 3518C3A6AED; Wed, 19 Nov 2008 14:34:15 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4673C3A6A84 for ; Wed, 19 Nov 2008 14:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.824 X-Spam-Level: X-Spam-Status: No, score=-2.824 tagged_above=-999 required=5 tests=[AWL=0.775, 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 OAbonJKQKTi3 for ; Wed, 19 Nov 2008 14:34:13 -0800 (PST) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 3CFE43A6AED for ; Wed, 19 Nov 2008 14:34:12 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Nov 2008 22:34:11 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 22:34:10 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04440EB7@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PCN Corridor meeting on Boundary node behaviours: 3.15pm Thurs Thread-Index: AclKk7Kl1vzL778jTPSLUL/ctjFu+Q== From: To: X-OriginalArrivalTime: 19 Nov 2008 22:34:11.0004 (UTC) FILETIME=[F1434FC0:01C94A96] Subject: [PCN] PCN Corridor meeting on Boundary node behaviours: 3.15pm Thurs 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 As i said in the WG meeting, Anna and I are meeting in the Thurs afternoon session II, to talk about Boundary node behaviours. very welcome to join us. i guess we meet near the registration desk and then find an empty meeting room to chat. the basic reason is that the WG has Charter milestones to produce one or more boundary node behaviours. we thought that we'd think about what things such docs should cover and what a good structure should be (it would be nice if all such docs followed the same format). also other issues like, should a doc describe options or a single choice (ie each option in a separate doc). is there a list of questions that any doc needs to answer? also to seek volunteers to edit such documents (and to let you know that i can't edit any). best wishes phil _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Nov 19 14:41: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 0F6613A692D; Wed, 19 Nov 2008 14:41:30 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA4C43A692D for ; Wed, 19 Nov 2008 14:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.911 X-Spam-Level: X-Spam-Status: No, score=0.911 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCOh1HN4BjMu for ; Wed, 19 Nov 2008 14:41:27 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id CD1183A6807 for ; Wed, 19 Nov 2008 14:41:26 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 0AF62A068A; Wed, 19 Nov 2008 23:41:24 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id F2A01A0689; Wed, 19 Nov 2008 23:41:23 +0100 (CET) Received: from [92.229.212.244] (g229212244.adsl.alicedsl.de [92.229.212.244]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 8EFCEA0685; Wed, 19 Nov 2008 23:41:23 +0100 (CET) Message-ID: <49249613.6040502@informatik.uni-wuerzburg.de> Date: Wed, 19 Nov 2008 23:41:23 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: philip.eardley@bt.com References: <4A916DBC72536E419A0BD955EDECEDEC04440EA1@E03MVB1-UKBR.domain1.systemhost.net> <4A916DBC72536E419A0BD955EDECEDEC04440EA3@E03MVB1-UKBR.domain1.systemhost.net> <4923E408.3040807@informatik.uni-wuerzburg.de> <4A916DBC72536E419A0BD955EDECEDEC04440EB4@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC04440EB4@E03MVB1-UKBR.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Dropping preference as a configuration option 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 schrieb: > Michael > > firstly, i don't beleive it "highly" depends. marked flow termination still works with preferential dropping of exces-traffic-marked pkts, eg your paper showed that this was nearly as good as 'random' dropping for MFT (i remember 3.5secs vs 3secs). please see discussion below and pointers to other emails. > Yes MFT is rather robust. I'm not so much talking about MFT but about direct measured rate termination. Just see next email! > > secondly, independently of the above, any proposal needs to be phrased in standards language, since the Marking behaviour is a Stds doc. please see the paragrpah below that starts "Another question is what a Std with such options would actually say." > Yes, see next email, too. Regards, Michael > > thanks > phil > > ________________________________ > > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: Wed 19/11/2008 10:01 > To: Moncaster,T,Toby,CXR9 R > Cc: Eardley,PL,Philip,CXR9 R; pcn@ietf.org > Subject: Re: [PCN] Dropping preference as a configuration option > > > > Hi Toby and all, > > the issue of drop preferences highly depends on the edge behavior. E.g. > direct measured rate termination or marked flow termination benefit from > preferentially dropping unmarked packets while indirect measured rate > termination requires preferential dropping of marked packets. Therefore, > it makes most sense to demand a certain drop preference when defining > the edge behavior (aka deployment model). Defining drop preferences > independently of the deployment models is like erasing some of them. > This could be done more directly just by saying, we want only this or > that deployment model and others not (and not even for later in case the > chosen one turns out to be too complex!). If this is not the strategy, > the deployment model is the right place for the definition of drop > preferences. > > Fact is that we discovered that drop preferences are an important issue. > Therefore, it makes sense to require in general two options in the > marking or architecture draft: dropping marked or unmarked packets. The > deployment model indicates what's needed. > > Regards, > > Michael > > toby.moncaster@bt.com schrieb: > >> So outcome of discussion is that we stick with a SHOULD for preferential >> drop, but include some proper explanation of the trade-offs that a >> vendor might consider when deciding if they can ignore it? >> >> This seems to be a very good compromise. Perhaps it could be phrased >> something like: >> >> "nodes SHOULD preferentially drop excess-traffic-marked packets. >> Alternatively they MAY choose to drop randomly but for many deployment >> scenarios this is NOT RECOMMENDED (see appendix n for explanation)." >> >> Toby >> >> >> >>> -----Original Message----- >>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >>> philip.eardley@bt.com >>> Sent: 19 November 2008 03:27 >>> To: pcn@ietf.org >>> Subject: [PCN] Dropping preference as a configuration option >>> >>> Michael and Georgios have raised this issue recently, and we've >>> discussed it here in Minneapolis - both in a 'corridor' meeting and in >>> the WG meeting. >>> so i wanted to summarised the issue and the discussions so far. >>> Especially as neither of you could make it here. clearly this means we >>> need to discuss and reach consensus on this on the mailing list. i'd >>> really like to do this as quickly as poss, since i believe it's the >>> only current discussion issue for the marking behaviour draft (plus >>> perhaps the satoh draft). >>> >>> The issue is about if there are 2 bottlenecks on the path, the first >>> one is pre-congested & excess-traffic-marking pkts and the second one >>> is even more overloaded and is actually dropping pkts. the question is >>> whether the second node should preferentially drop pkts that have >>> already been marked or do something else instead. >>> >>> History of issue: >>> ================== >>> In Philadelphia we discussed the choice between: >>> * MUST preferentially drop pkts that are already excess-traffic-marked >>> OR >>> * MUST drop independent of marking >>> * a logical thid option that we didn't discuss: preferentially drop >>> pkts that are not excess-traffic-marked) >>> There was a consensus for option 1, as a SHOULD >>> There was also a discussion afterwards on the mailing list (one of >>> Steve's "Questions") which confirmed this consensus. >>> >>> I believe a fair summary of the thinking was as follows: >>> (CL/SM = edge behaviour where egress measures rate of pkts that are >>> >>> >> not >> >> >>> ExM (from an ingress), ingress measures rate of pkts (sent to that >>> egress) >>> (MFT = edge behaviour where egress terminates a flow (with some >>> probability) when it sees a marked pkt on that flow >>> >>> * Preferentially drop ExM pkts: works Best for CL/SM ; Works ok for >>> >>> >> MFT >> >> >>> * 'random' drop: breaks completely in some scenarios (terminates far >>> too much) for CL/SM ; works OK (slightly slower than above) for MFT >>> * Preferentially drop pkts not ExM: breaks completely in some >>> >>> >> scenarios >> >> >>> (terminates all flows) for CL/SM ; best for MFT (much faster than >>> above) >>> >>> Michael, i beleive this is what's shown by the paper of yours you >>> pointed me at in your email http://www.ietf.org/mail- >>> archive/web/pcn/current/msg01841.html >>> ie Fig 9 in http://www3.informatik.uni- >>> wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-MFT.pdf >>> >>> we should also bear in mind the pros and cons of CL/SM & MFT: >>> * CL/SM: Can terminate fast ('1 shot') >>> * MFT: Simpler (don't measure rates), but accept trade-off that won't >>> terminate so fast >>> See also more details in http://www.ietf.org/mail- >>> archive/web/pcn/current/msg01449.html >>> >>> so the result of all the discussions at/after Philadelphia was the >>> consensus decision to go for preferentially drop pkts that are already >>> excess-traffic-marked, but as a SHOULD (rather than as a MUST) >>> >>> The latest proposal >>> =================== >>> The proposal from Michael & Georgios is that the preferential dropping >>> behaviour is an Option. >>> >>> >>> Summary of discussion in Minneapolis about proposal >>> ======================================= >>> Pros: All edge behaviours can choose their optimal preferential >>> dropping behaviour >>> Cons: Extra complexity to standardise, implement & operate (configure, >>> manage etc) >>> >>> Quite a few people made comments at the mike. my impression was that >>> the general feeling is that we should think very hard before having an >>> Option - "have one choice" >>> >>> Another question is what a Std with such options would actually say. >>> eg is one of them the default (MUST) and the other(s) a MAY? >>> - making pref. drop the default MUST and 'random' dropping the MAY >>> would be rather empty, since existing routers do tail drop, so you >>> would be saying you MAY do something that the router does anyway! >>> - marking 'random' dropping the default would therefore seem more >>> likely But this then means that the default is something that we know >>> is broken for CL/SM in scenarios that are easy to devise (basically if >>> the link is greatly overloaded, say 5*, then you might over-terminate >>> by 4*). which seems quite scay. >>> - making them both MUSTs to implement (option which is used). this is >>> actually tougher on vendors than what the current draft says (SHOULD >>> for pref. drop - since the 'random dropping' is what the router does >>> today, so it's trivial to offer it if that's demanded. >>> >>> So the conclusion of this discussion was that a SHOULD actually >>> captures quite well what we want to say, ie this is the new behaviour, >>> and this is the thing that means CL/SM can work, whilst MFT can also >>> work OK. >>> We also thought it would be worth adding a brief explanation why it's >>> not a MUST (the Informative Appendix B would be the right place). so >>> >>> >> we >> >> >>> could say something like: >>> - you might instead want to do tail drop, as this is what today's >>> routers do, so lowers the implementation step for PCN. But beware it >>> has these trade-offs for CL/SM Edge behaviour >>> - you might instead want to preferentially drop pkts that arent excess >>> traffic marked, becuase this gives the best overall behaviour for MFT >>> (ie if you know that this is your edge behaviour) >>> >>> Minneappers - Hopefully this captures OK our disussion, please >>> add/correct if it doesnt. >>> >>> Michael, Gegorios, what do you think? >>> >>> thanks, >>> 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 > > > -- 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 Nov 19 14: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 359C23A692D; Wed, 19 Nov 2008 14:42:20 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 109AE3A692D for ; Wed, 19 Nov 2008 14:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.311 X-Spam-Level: X-Spam-Status: No, score=0.311 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_BL_SPAMCOP_NET=1.96] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqiXysIN3IZN for ; Wed, 19 Nov 2008 14:42:18 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 9A0423A6807 for ; Wed, 19 Nov 2008 14:42:17 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 6B91BA0689; Wed, 19 Nov 2008 23:42:16 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 5FFBCA0685; Wed, 19 Nov 2008 23:42:16 +0100 (CET) Received: from [92.229.212.244] (g229212244.adsl.alicedsl.de [92.229.212.244]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 140A4198E38; Wed, 19 Nov 2008 23:42:16 +0100 (CET) Message-ID: <49249648.7010101@informatik.uni-wuerzburg.de> Date: Wed, 19 Nov 2008 23:42:16 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: philip.eardley@bt.com References: <4A916DBC72536E419A0BD955EDECEDEC04440EA1@E03MVB1-UKBR.domain1.systemhost.net> <4A916DBC72536E419A0BD955EDECEDEC04440EA3@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC04440EA3@E03MVB1-UKBR.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Dropping preference as a configuration option 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, thanks for this very good summary! philip.eardley@bt.com schrieb: > Michael and Georgios have raised this issue recently, and we've discussed it here in Minneapolis - both in a 'corridor' meeting and in the WG meeting. > so i wanted to summarised the issue and the discussions so far. Especially as neither of you could make it here. clearly this means we need to discuss and reach consensus on this on the mailing list. i'd really like to do this as quickly as poss, since i believe it's the only current discussion issue for the marking behaviour draft (plus perhaps the satoh draft). > > The issue is about if there are 2 bottlenecks on the path, the first one is pre-congested & excess-traffic-marking pkts and the second one is even more overloaded and is actually dropping pkts. the question is whether the second node should preferentially drop pkts that have already been marked or do something else instead. > > History of issue: > ================== > In Philadelphia we discussed the choice between: > * MUST preferentially drop pkts that are already excess-traffic-marked OR > * MUST drop independent of marking > * a logical thid option that we didn't discuss: preferentially drop pkts that are not excess-traffic-marked) > There was a consensus for option 1, as a SHOULD > There was also a discussion afterwards on the mailing list (one of Steve's "Questions") which confirmed this consensus. > > I believe a fair summary of the thinking was as follows: > (CL/SM = edge behaviour where egress measures rate of pkts that are not ExM (from an ingress), ingress measures rate of pkts (sent to that egress) > (MFT = edge behaviour where egress terminates a flow (with some probability) when it sees a marked pkt on that flow > > * Preferentially drop ExM pkts: works Best for CL/SM ; Works ok for MFT > * 'random' drop: breaks completely in some scenarios (terminates far too much) for CL/SM ; works OK (slightly slower than above) for MFT > * Preferentially drop pkts not ExM: breaks completely in some scenarios (terminates all flows) for CL/SM ; best for MFT (much faster than above) > > Michael, i beleive this is what's shown by the paper of yours you pointed me at in your email http://www.ietf.org/mail-archive/web/pcn/current/msg01841.html > ie Fig 9 in http://www3.informatik.uni-wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-MFT.pdf > Yes. > > we should also bear in mind the pros and cons of CL/SM & MFT: > * CL/SM: Can terminate fast ('1 shot') > * MFT: Simpler (don't measure rates), but accept trade-off that won't terminate so fast > See also more details in http://www.ietf.org/mail-archive/web/pcn/current/msg01449.html > The issue is not only between CL/SM (indirect measured rate termination, IMRT) and marked flow termination (MFT). For me it is not clear whether indirect measured rate termination is better than direct measured rate termination (DMRT) which are very similar and could be used as an alternative in CL/SM. DMRT also requires dropping of unmarked packets. We studied this in http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth08-Sub-9.pdf We showed in IV.C that IMRT can suffer from biased measurement intervals and lead to overtermination. IMRT: reduce SR-overload always within two measurement intervals (one at the egress and another at the ingress plus anoter MI at the ingress for another termination step), but is prone to overtermination in case of biased measurement intervals. DMRT: reduce SR-overload also within a very few measurement intervals (one measurement interval at the egress + RTT for signalling to ingress + one inter-termination time (=2 measurement intervals+2RTT) for two termination steps). It terminates slower than IMRT only if there is a significant amount of PCN packet loss. However, DMRT is not prone to overtermination. I believe that this issue was not discussed and understood enough, yet. > > so the result of all the discussions at/after Philadelphia was the consensus decision to go for preferentially drop pkts that are already excess-traffic-marked, but as a SHOULD (rather than as a MUST) > > The latest proposal > =================== > The proposal from Michael & Georgios is that the preferential dropping behaviour is an Option. > > > Summary of discussion in Minneapolis about proposal > ======================================= > Pros: All edge behaviours can choose their optimal preferential dropping behaviour > Cons: Extra complexity to standardise, implement & operate (configure, manage etc) > > Quite a few people made comments at the mike. my impression was that the general feeling is that we should think very hard before having an Option - "have one choice" > > Another question is what a Std with such options would actually say. > eg is one of them the default (MUST) and the other(s) a MAY? > - making pref. drop the default MUST and 'random' dropping the MAY would be rather empty, since existing routers do tail drop, so you would be saying you MAY do something that the router does anyway! > - marking 'random' dropping the default would therefore seem more likely But this then means that the default is something that we know is broken for CL/SM in scenarios that are easy to devise (basically if the link is greatly overloaded, say 5*, then you might over-terminate by 4*). which seems quite scay. > - making them both MUSTs to implement (option which is used). this is actually tougher on vendors than what the current draft says (SHOULD for pref. drop - since the 'random dropping' is what the router does today, so it's trivial to offer it if that's demanded. > > So the conclusion of this discussion was that a SHOULD actually captures quite well what we want to say, ie this is the new behaviour, and this is the thing that means CL/SM can work, whilst MFT can also work OK. > We also thought it would be worth adding a brief explanation why it's not a MUST (the Informative Appendix B would be the right place). so we could say something like: > - you might instead want to do tail drop, as this is what today's routers do, so lowers the implementation step for PCN. But beware it has these trade-offs for CL/SM Edge behaviour > - you might instead want to preferentially drop pkts that arent excess traffic marked, becuase this gives the best overall behaviour for MFT (ie if you know that this is your edge behaviour) > > Minneappers - Hopefully this captures OK our disussion, please add/correct if it doesnt. > > Michael, Gegorios, what do you think? > I believe that make one option a MUST and another as SHOULD is not helpful as one cannot rely on the implementation. If there is evidence that IMRT is fine forever, we can live with dropping marked packets as the only option. But keeping the door open for DMRT means making preferential dropping of unmarked packets a MUST. BTW, I do not understand why preferential dropping must be fixed in the marking draft, deployment models seem a better place to me. Regards, Michael > > thanks, > phil > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Nov 19 15: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 8594A3A68AF; Wed, 19 Nov 2008 15:37:48 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBA863A68AF for ; Wed, 19 Nov 2008 15:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.979 X-Spam-Level: X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[AWL=0.620, 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 KwezGAE9Rre8 for ; Wed, 19 Nov 2008 15:37:47 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id BBCD33A686C for ; Wed, 19 Nov 2008 15:37:46 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Nov 2008 23:37:44 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 23:37:38 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04440EBB@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-satoh-pcn-ST-marking-00.txt Thread-Index: AclKn85qv/qc1vuoTbCB1TbEEI5zzg== From: To: X-OriginalArrivalTime: 19 Nov 2008 23:37:44.0432 (UTC) FILETIME=[D23E3F00:01C94A9F] Subject: [PCN] Comments on draft-satoh-pcn-ST-marking-00.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 Daisuke, your draft is very interesting, and good discussion over the last couple of days! here are some questions & comments on your draft, http://www.ietf.org/mail-archive/web/pcn/current/msg01868.html i tried to briefly summarise the points i remembered from the WG meeting, as we didn't have time to get to the bottom of them all yesterday. 1. Only threshold marking or only excess marking With the current draft, if you only have 1 encoding state for PCN-marking, then you have 3 possibilities: - just do threshold marking for accurate adm ctrl - just do excess marking for accurate flow termination - do excess marking (at PCN-admissible-rate) for both admission control (somewhat inaccurately) and flow termination How easy would be to do this with your proposal? or are you basically committed to the third bullet? 2. Forward Migration The current marking behaviour is written so that: - if you have only one encoding state you can do both admission control (somewhat inaccurately) and flow termination (or you can just do adm ctrl (accurately) or just do flow termination); - but if you later have two encoding states, then you simply mark pkts with both encoding states - no changes needed to the marking behaviour. With your draft, what happens if you later have two encoding states? do you need to upgrade your routers with new marking behaviour? or can you do something as simple as with the current WG draft? the other 3 issues definitely need more explanation than is below, just trying to quickly capture them (will leave it to others to write properly about them) 3. worry about admission control accuracy eg slide 7 of http://www.ietf.org/proceedings/08nov/slides/pcn-8.pdf the marking rate vs pkt rate seems to make assumptions about the traffic arriving. eg if it was very smooth traffic (CBR flows, or smoothed by nw) then the graph wouldnt look like this. 4. distinguishing admission and termination although there is only one type of PCN-marking, basically the egress interprets occasional PCN-marks as meaning "adm ctrl" and a series of pkts that are all consecutively marked as "flow termination". an issue might be if the link is actually doing admission marking, ie PCN-marking 1/N pkts, but somehow all the marks happen to the same egress - which therefore interprets them as flow termination. seems like this could happen if the flows are synchronised (eg they're all CBR flows) 5. flow termination slide 15 shows that you only terminate "y%" at a time, ie at least a round trip time (+measurement intervals) between each batch of "y%" that you terminate. but it's tricky to know what to set "y" to, eg make it big and you can terminate fast, but this also means that you risk over-terminating by a significant amount. thanks phil _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Nov 19 15:49: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 9DA123A6B87; Wed, 19 Nov 2008 15:49:59 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E11C3A6B94 for ; Wed, 19 Nov 2008 15:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 gIxOoQQNwEON for ; Wed, 19 Nov 2008 15:49:56 -0800 (PST) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 528EF3A6B87 for ; Wed, 19 Nov 2008 15:49:56 -0800 (PST) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Nov 2008 23:49:54 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Nov 2008 23:49:54 -0000 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04440EBD@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Dropping preference as a configuration option Thread-Index: AclKmCklmKcy64JdSDWo/PP9bor/0AACDha1 References: <4A916DBC72536E419A0BD955EDECEDEC04440EA1@E03MVB1-UKBR.domain1.systemhost.net> <4A916DBC72536E419A0BD955EDECEDEC04440EA3@E03MVB1-UKBR.domain1.systemhost.net> <4923E408.3040807@informatik.uni-wuerzburg.de> <4A916DBC72536E419A0BD955EDECEDEC04440EB4@E03MVB1-UKBR.domain1.systemhost.net> <49249613.6040502@informatik.uni-wuerzburg.de> From: To: X-OriginalArrivalTime: 19 Nov 2008 23:49:54.0341 (UTC) FILETIME=[854D8550:01C94AA1] Cc: pcn@ietf.org Subject: Re: [PCN] Dropping preference as a configuration option X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org ah, right - direct measured rate termination had slipped to back of mind. i think i'd not be too worried about this type of edge behaviour being compromised - if you're prepared to measure rates at egress (needed by direct measured rate termination) then seems ok to measure rate at ingress as well (ie CL/SM edge behaviour) phil ________________________________ From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] Sent: Wed 19/11/2008 22:41 To: Eardley,PL,Philip,CXR9 R Cc: Moncaster,T,Toby,CXR9 R; pcn@ietf.org Subject: Re: [PCN] Dropping preference as a configuration option Hi Phil, philip.eardley@bt.com schrieb: > Michael > > firstly, i don't beleive it "highly" depends. marked flow termination still works with preferential dropping of exces-traffic-marked pkts, eg your paper showed that this was nearly as good as 'random' dropping for MFT (i remember 3.5secs vs 3secs). please see discussion below and pointers to other emails. > Yes MFT is rather robust. I'm not so much talking about MFT but about direct measured rate termination. Just see next email! > > secondly, independently of the above, any proposal needs to be phrased in standards language, since the Marking behaviour is a Stds doc. please see the paragrpah below that starts "Another question is what a Std with such options would actually say." > Yes, see next email, too. Regards, Michael > > thanks > phil > > ________________________________ > > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: Wed 19/11/2008 10:01 > To: Moncaster,T,Toby,CXR9 R > Cc: Eardley,PL,Philip,CXR9 R; pcn@ietf.org > Subject: Re: [PCN] Dropping preference as a configuration option > > > > Hi Toby and all, > > the issue of drop preferences highly depends on the edge behavior. E.g. > direct measured rate termination or marked flow termination benefit from > preferentially dropping unmarked packets while indirect measured rate > termination requires preferential dropping of marked packets. Therefore, > it makes most sense to demand a certain drop preference when defining > the edge behavior (aka deployment model). Defining drop preferences > independently of the deployment models is like erasing some of them. > This could be done more directly just by saying, we want only this or > that deployment model and others not (and not even for later in case the > chosen one turns out to be too complex!). If this is not the strategy, > the deployment model is the right place for the definition of drop > preferences. > > Fact is that we discovered that drop preferences are an important issue. > Therefore, it makes sense to require in general two options in the > marking or architecture draft: dropping marked or unmarked packets. The > deployment model indicates what's needed. > > Regards, > > Michael > > toby.moncaster@bt.com schrieb: > >> So outcome of discussion is that we stick with a SHOULD for preferential >> drop, but include some proper explanation of the trade-offs that a >> vendor might consider when deciding if they can ignore it? >> >> This seems to be a very good compromise. Perhaps it could be phrased >> something like: >> >> "nodes SHOULD preferentially drop excess-traffic-marked packets. >> Alternatively they MAY choose to drop randomly but for many deployment >> scenarios this is NOT RECOMMENDED (see appendix n for explanation)." >> >> Toby >> >> >> >>> -----Original Message----- >>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >>> philip.eardley@bt.com >>> Sent: 19 November 2008 03:27 >>> To: pcn@ietf.org >>> Subject: [PCN] Dropping preference as a configuration option >>> >>> Michael and Georgios have raised this issue recently, and we've >>> discussed it here in Minneapolis - both in a 'corridor' meeting and in >>> the WG meeting. >>> so i wanted to summarised the issue and the discussions so far. >>> Especially as neither of you could make it here. clearly this means we >>> need to discuss and reach consensus on this on the mailing list. i'd >>> really like to do this as quickly as poss, since i believe it's the >>> only current discussion issue for the marking behaviour draft (plus >>> perhaps the satoh draft). >>> >>> The issue is about if there are 2 bottlenecks on the path, the first >>> one is pre-congested & excess-traffic-marking pkts and the second one >>> is even more overloaded and is actually dropping pkts. the question is >>> whether the second node should preferentially drop pkts that have >>> already been marked or do something else instead. >>> >>> History of issue: >>> ================== >>> In Philadelphia we discussed the choice between: >>> * MUST preferentially drop pkts that are already excess-traffic-marked >>> OR >>> * MUST drop independent of marking >>> * a logical thid option that we didn't discuss: preferentially drop >>> pkts that are not excess-traffic-marked) >>> There was a consensus for option 1, as a SHOULD >>> There was also a discussion afterwards on the mailing list (one of >>> Steve's "Questions") which confirmed this consensus. >>> >>> I believe a fair summary of the thinking was as follows: >>> (CL/SM = edge behaviour where egress measures rate of pkts that are >>> >>> >> not >> >> >>> ExM (from an ingress), ingress measures rate of pkts (sent to that >>> egress) >>> (MFT = edge behaviour where egress terminates a flow (with some >>> probability) when it sees a marked pkt on that flow >>> >>> * Preferentially drop ExM pkts: works Best for CL/SM ; Works ok for >>> >>> >> MFT >> >> >>> * 'random' drop: breaks completely in some scenarios (terminates far >>> too much) for CL/SM ; works OK (slightly slower than above) for MFT >>> * Preferentially drop pkts not ExM: breaks completely in some >>> >>> >> scenarios >> >> >>> (terminates all flows) for CL/SM ; best for MFT (much faster than >>> above) >>> >>> Michael, i beleive this is what's shown by the paper of yours you >>> pointed me at in your email http://www.ietf.org/mail- >>> archive/web/pcn/current/msg01841.html >>> ie Fig 9 in http://www3.informatik.uni- >>> wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-MFT.pdf >>> >>> we should also bear in mind the pros and cons of CL/SM & MFT: >>> * CL/SM: Can terminate fast ('1 shot') >>> * MFT: Simpler (don't measure rates), but accept trade-off that won't >>> terminate so fast >>> See also more details in http://www.ietf.org/mail- >>> archive/web/pcn/current/msg01449.html >>> >>> so the result of all the discussions at/after Philadelphia was the >>> consensus decision to go for preferentially drop pkts that are already >>> excess-traffic-marked, but as a SHOULD (rather than as a MUST) >>> >>> The latest proposal >>> =================== >>> The proposal from Michael & Georgios is that the preferential dropping >>> behaviour is an Option. >>> >>> >>> Summary of discussion in Minneapolis about proposal >>> ======================================= >>> Pros: All edge behaviours can choose their optimal preferential >>> dropping behaviour >>> Cons: Extra complexity to standardise, implement & operate (configure, >>> manage etc) >>> >>> Quite a few people made comments at the mike. my impression was that >>> the general feeling is that we should think very hard before having an >>> Option - "have one choice" >>> >>> Another question is what a Std with such options would actually say. >>> eg is one of them the default (MUST) and the other(s) a MAY? >>> - making pref. drop the default MUST and 'random' dropping the MAY >>> would be rather empty, since existing routers do tail drop, so you >>> would be saying you MAY do something that the router does anyway! >>> - marking 'random' dropping the default would therefore seem more >>> likely But this then means that the default is something that we know >>> is broken for CL/SM in scenarios that are easy to devise (basically if >>> the link is greatly overloaded, say 5*, then you might over-terminate >>> by 4*). which seems quite scay. >>> - making them both MUSTs to implement (option which is used). this is >>> actually tougher on vendors than what the current draft says (SHOULD >>> for pref. drop - since the 'random dropping' is what the router does >>> today, so it's trivial to offer it if that's demanded. >>> >>> So the conclusion of this discussion was that a SHOULD actually >>> captures quite well what we want to say, ie this is the new behaviour, >>> and this is the thing that means CL/SM can work, whilst MFT can also >>> work OK. >>> We also thought it would be worth adding a brief explanation why it's >>> not a MUST (the Informative Appendix B would be the right place). so >>> >>> >> we >> >> >>> could say something like: >>> - you might instead want to do tail drop, as this is what today's >>> routers do, so lowers the implementation step for PCN. But beware it >>> has these trade-offs for CL/SM Edge behaviour >>> - you might instead want to preferentially drop pkts that arent excess >>> traffic marked, becuase this gives the best overall behaviour for MFT >>> (ie if you know that this is your edge behaviour) >>> >>> Minneappers - Hopefully this captures OK our disussion, please >>> add/correct if it doesnt. >>> >>> Michael, Gegorios, what do you think? >>> >>> thanks, >>> 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 > > > -- 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 Nov 19 19:44: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 7C4BC3A67A5; Wed, 19 Nov 2008 19:44:20 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBFAF3A67A5 for ; Wed, 19 Nov 2008 19:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjtC8OIsTJnY for ; Wed, 19 Nov 2008 19:44:19 -0800 (PST) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id BD3C63A67A1 for ; Wed, 19 Nov 2008 19:44:18 -0800 (PST) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KAM00CXB51JTL@szxga01-in.huawei.com> for pcn@ietf.org; Thu, 20 Nov 2008 11:44:07 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KAM002W051JMQ@szxga01-in.huawei.com> for pcn@ietf.org; Thu, 20 Nov 2008 11:44:07 +0800 (CST) Received: from [192.168.0.103] (64.198.35.121.broad.sz.gd.dynamic.163data.com.cn [121.35.198.64]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KAM0073T51HNV@szxml01-in.huawei.com>; Thu, 20 Nov 2008 11:44:07 +0800 (CST) Date: Thu, 20 Nov 2008 11:44:05 +0800 From: Tina TSOU In-reply-to: <4A916DBC72536E419A0BD955EDECEDEC04440EB7@E03MVB1-UKBR.domain1.systemhost.net> To: philip.eardley@bt.com Message-id: <39297ADA-CECD-4FA5-ADAD-BBFC5574CEFF@huawei.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.929.2) References: <4A916DBC72536E419A0BD955EDECEDEC04440EB7@E03MVB1-UKBR.domain1.systemhost.net> Cc: pcn@ietf.org Subject: Re: [PCN] PCN Corridor meeting on Boundary node behaviours: 3.15pm Thurs 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="===============0471670022==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org --===============0471670022== Content-type: multipart/alternative; boundary="Boundary_(ID_mZA7sJSsgIT5DGD2yL1Z3A)" --Boundary_(ID_mZA7sJSsgIT5DGD2yL1Z3A) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT Hi Phil et al, In my mind, EWMA (Exponential Weighted Moving Average) and Policy Enforcement are needed to be described in some edge node behavior document. B. R. Tina Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com +86-755-28971872 (Office) +86-13922884380(Mobile) On Nov 20, 2008, at 6:34 AM, philip.eardley@bt.com wrote: > As i said in the WG meeting, Anna and I are meeting in the Thurs > afternoon session II, to talk about Boundary node behaviours. very > welcome to join us. i guess we meet near the registration desk and > then find an empty meeting room to chat. > > the basic reason is that the WG has Charter milestones to produce > one or more boundary node behaviours. we thought that we'd think > about what things such docs should cover and what a good structure > should be (it would be nice if all such docs followed the same > format). also other issues like, should a doc describe options or a > single choice (ie each option in a separate doc). is there a list of > questions that any doc needs to answer? also to seek volunteers to > edit such documents (and to let you know that i can't edit any). > > best wishes > phil > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn --Boundary_(ID_mZA7sJSsgIT5DGD2yL1Z3A) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: 7BIT
Hi Phil et al,
In my mind, EWMA (Exponential Weighted Moving Average) and Policy Enforcement are needed to be described in some edge node behavior document.

B. R.
Tina

Messengers:

MSN: tinatsou6@hotmail.com   Yahoo: tina_tsou    Skype: tinaTSOU    Jabber: tina@jabber.org    Google talk: tinatsou6@gmail.com

+86-755-28971872 (Office)    +86-13922884380(Mobile)




On No a href="mailto:philip.eardley@bt.com">philip.eardley@bt.com wrote:

As i said in the WG meeting, Anna and I are meeting in the Thurs afternoon session II, to talk about Boundary node behaviours. very welcome to join us. i guess we meet near the registration desk and then find an empty meeting room to chat.

the basic reason is that the WG has Charter milestones to produce one or more boundary node behaviours. we thought that we'd think about what things such docs should cover and what a good structure should be (it would be nice if all such docs followed the same format). also other issues like, should a doc describe options or a single choice (ie each option in a separate doc). is there a list of questions that any doc needs to answer? also to seek volunteers to edit such documents (and to let you know that i can't edit any).

best wishes
phil
_______________________________________ ________ a href="mailto:PCN@ietf.org">PCN@ietf.org
https://www.ietf.org/mailman/listinfo/pcn

--Boundary_(ID_mZA7sJSsgIT5DGD2yL1Z3A)-- --===============0471670022== 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 --===============0471670022==-- From pcn-bounces@ietf.org Thu Nov 20 00:19: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 A16A728C105; Thu, 20 Nov 2008 00:19:03 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 764A228C105 for ; Thu, 20 Nov 2008 00:19:02 -0800 (PST) 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_72=0.6, J_CHICKENPOX_91=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 ADcF7zcPfUw7 for ; Thu, 20 Nov 2008 00:19:00 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 6500C3A69E8 for ; Thu, 20 Nov 2008 00:19:00 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id E9887A069E; Thu, 20 Nov 2008 09:18:58 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id DD0CDA0699; Thu, 20 Nov 2008 09:18:58 +0100 (CET) Received: from [78.51.65.66] (f051065066.adsl.alicedsl.de [78.51.65.66]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 5B318A0692; Thu, 20 Nov 2008 09:18:58 +0100 (CET) Message-ID: <49251D72.1020109@informatik.uni-wuerzburg.de> Date: Thu, 20 Nov 2008 09:18:58 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: philip.eardley@bt.com References: <4A916DBC72536E419A0BD955EDECEDEC04440EA1@E03MVB1-UKBR.domain1.systemhost.net> <4A916DBC72536E419A0BD955EDECEDEC04440EA3@E03MVB1-UKBR.domain1.systemhost.net> <4923E408.3040807@informatik.uni-wuerzburg.de> <4A916DBC72536E419A0BD955EDECEDEC04440EB4@E03MVB1-UKBR.domain1.systemhost.net> <49249613.6040502@informatik.uni-wuerzburg.de> <4A916DBC72536E419A0BD955EDECEDEC04440EBD@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC04440EBD@E03MVB1-UKBR.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Dropping preference as a configuration option 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 schrieb: > ah, right - direct measured rate termination had slipped to back of mind. i think i'd not be too worried about this type of edge behaviour being compromised - if you're prepared to measure rates at egress (needed by direct measured rate termination) then seems ok to measure rate at ingress as well (ie CL/SM edge behaviour) > phil > This is not the point. I'm not talking about overhead or the feasibility of measurements. I'm talking about problems that may occur when measurement intervals at ingress and egress are not synchronized. This issue has always been ignored. We explained it in IV.C of http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth08-Sub-9.pdf Regards, Michael > ________________________________ > > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: Wed 19/11/2008 22:41 > To: Eardley,PL,Philip,CXR9 R > Cc: Moncaster,T,Toby,CXR9 R; pcn@ietf.org > Subject: Re: [PCN] Dropping preference as a configuration option > > > > Hi Phil, > > philip.eardley@bt.com schrieb: > >> Michael >> >> firstly, i don't beleive it "highly" depends. marked flow termination still works with preferential dropping of exces-traffic-marked pkts, eg your paper showed that this was nearly as good as 'random' dropping for MFT (i remember 3.5secs vs 3secs). please see discussion below and pointers to other emails. >> >> > Yes MFT is rather robust. I'm not so much talking about MFT but about > direct measured rate termination. Just see next email! > > >> secondly, independently of the above, any proposal needs to be phrased in standards language, since the Marking behaviour is a Stds doc. please see the paragrpah below that starts "Another question is what a Std with such options would actually say." >> >> > Yes, see next email, too. > > Regards, > > Michael > >> thanks >> phil >> >> ________________________________ >> >> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >> Sent: Wed 19/11/2008 10:01 >> To: Moncaster,T,Toby,CXR9 R >> Cc: Eardley,PL,Philip,CXR9 R; pcn@ietf.org >> Subject: Re: [PCN] Dropping preference as a configuration option >> >> >> >> Hi Toby and all, >> >> the issue of drop preferences highly depends on the edge behavior. E.g. >> direct measured rate termination or marked flow termination benefit from >> preferentially dropping unmarked packets while indirect measured rate >> termination requires preferential dropping of marked packets. Therefore, >> it makes most sense to demand a certain drop preference when defining >> the edge behavior (aka deployment model). Defining drop preferences >> independently of the deployment models is like erasing some of them. >> This could be done more directly just by saying, we want only this or >> that deployment model and others not (and not even for later in case the >> chosen one turns out to be too complex!). If this is not the strategy, >> the deployment model is the right place for the definition of drop >> preferences. >> >> Fact is that we discovered that drop preferences are an important issue. >> Therefore, it makes sense to require in general two options in the >> marking or architecture draft: dropping marked or unmarked packets. The >> deployment model indicates what's needed. >> >> Regards, >> >> Michael >> >> toby.moncaster@bt.com schrieb: >> >> >>> So outcome of discussion is that we stick with a SHOULD for preferential >>> drop, but include some proper explanation of the trade-offs that a >>> vendor might consider when deciding if they can ignore it? >>> >>> This seems to be a very good compromise. Perhaps it could be phrased >>> something like: >>> >>> "nodes SHOULD preferentially drop excess-traffic-marked packets. >>> Alternatively they MAY choose to drop randomly but for many deployment >>> scenarios this is NOT RECOMMENDED (see appendix n for explanation)." >>> >>> Toby >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >>>> philip.eardley@bt.com >>>> Sent: 19 November 2008 03:27 >>>> To: pcn@ietf.org >>>> Subject: [PCN] Dropping preference as a configuration option >>>> >>>> Michael and Georgios have raised this issue recently, and we've >>>> discussed it here in Minneapolis - both in a 'corridor' meeting and in >>>> the WG meeting. >>>> so i wanted to summarised the issue and the discussions so far. >>>> Especially as neither of you could make it here. clearly this means we >>>> need to discuss and reach consensus on this on the mailing list. i'd >>>> really like to do this as quickly as poss, since i believe it's the >>>> only current discussion issue for the marking behaviour draft (plus >>>> perhaps the satoh draft). >>>> >>>> The issue is about if there are 2 bottlenecks on the path, the first >>>> one is pre-congested & excess-traffic-marking pkts and the second one >>>> is even more overloaded and is actually dropping pkts. the question is >>>> whether the second node should preferentially drop pkts that have >>>> already been marked or do something else instead. >>>> >>>> History of issue: >>>> ================== >>>> In Philadelphia we discussed the choice between: >>>> * MUST preferentially drop pkts that are already excess-traffic-marked >>>> OR >>>> * MUST drop independent of marking >>>> * a logical thid option that we didn't discuss: preferentially drop >>>> pkts that are not excess-traffic-marked) >>>> There was a consensus for option 1, as a SHOULD >>>> There was also a discussion afterwards on the mailing list (one of >>>> Steve's "Questions") which confirmed this consensus. >>>> >>>> I believe a fair summary of the thinking was as follows: >>>> (CL/SM = edge behaviour where egress measures rate of pkts that are >>>> >>>> >>>> >>> not >>> >>> >>> >>>> ExM (from an ingress), ingress measures rate of pkts (sent to that >>>> egress) >>>> (MFT = edge behaviour where egress terminates a flow (with some >>>> probability) when it sees a marked pkt on that flow >>>> >>>> * Preferentially drop ExM pkts: works Best for CL/SM ; Works ok for >>>> >>>> >>>> >>> MFT >>> >>> >>> >>>> * 'random' drop: breaks completely in some scenarios (terminates far >>>> too much) for CL/SM ; works OK (slightly slower than above) for MFT >>>> * Preferentially drop pkts not ExM: breaks completely in some >>>> >>>> >>>> >>> scenarios >>> >>> >>> >>>> (terminates all flows) for CL/SM ; best for MFT (much faster than >>>> above) >>>> >>>> Michael, i beleive this is what's shown by the paper of yours you >>>> pointed me at in your email http://www.ietf.org/mail- >>>> archive/web/pcn/current/msg01841.html >>>> ie Fig 9 in http://www3.informatik.uni- >>>> wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-MFT.pdf >>>> >>>> we should also bear in mind the pros and cons of CL/SM & MFT: >>>> * CL/SM: Can terminate fast ('1 shot') >>>> * MFT: Simpler (don't measure rates), but accept trade-off that won't >>>> terminate so fast >>>> See also more details in http://www.ietf.org/mail- >>>> archive/web/pcn/current/msg01449.html >>>> >>>> so the result of all the discussions at/after Philadelphia was the >>>> consensus decision to go for preferentially drop pkts that are already >>>> excess-traffic-marked, but as a SHOULD (rather than as a MUST) >>>> >>>> The latest proposal >>>> =================== >>>> The proposal from Michael & Georgios is that the preferential dropping >>>> behaviour is an Option. >>>> >>>> >>>> Summary of discussion in Minneapolis about proposal >>>> ======================================= >>>> Pros: All edge behaviours can choose their optimal preferential >>>> dropping behaviour >>>> Cons: Extra complexity to standardise, implement & operate (configure, >>>> manage etc) >>>> >>>> Quite a few people made comments at the mike. my impression was that >>>> the general feeling is that we should think very hard before having an >>>> Option - "have one choice" >>>> >>>> Another question is what a Std with such options would actually say. >>>> eg is one of them the default (MUST) and the other(s) a MAY? >>>> - making pref. drop the default MUST and 'random' dropping the MAY >>>> would be rather empty, since existing routers do tail drop, so you >>>> would be saying you MAY do something that the router does anyway! >>>> - marking 'random' dropping the default would therefore seem more >>>> likely But this then means that the default is something that we know >>>> is broken for CL/SM in scenarios that are easy to devise (basically if >>>> the link is greatly overloaded, say 5*, then you might over-terminate >>>> by 4*). which seems quite scay. >>>> - making them both MUSTs to implement (option which is used). this is >>>> actually tougher on vendors than what the current draft says (SHOULD >>>> for pref. drop - since the 'random dropping' is what the router does >>>> today, so it's trivial to offer it if that's demanded. >>>> >>>> So the conclusion of this discussion was that a SHOULD actually >>>> captures quite well what we want to say, ie this is the new behaviour, >>>> and this is the thing that means CL/SM can work, whilst MFT can also >>>> work OK. >>>> We also thought it would be worth adding a brief explanation why it's >>>> not a MUST (the Informative Appendix B would be the right place). so >>>> >>>> >>>> >>> we >>> >>> >>> >>>> could say something like: >>>> - you might instead want to do tail drop, as this is what today's >>>> routers do, so lowers the implementation step for PCN. But beware it >>>> has these trade-offs for CL/SM Edge behaviour >>>> - you might instead want to preferentially drop pkts that arent excess >>>> traffic marked, becuase this gives the best overall behaviour for MFT >>>> (ie if you know that this is your edge behaviour) >>>> >>>> Minneappers - Hopefully this captures OK our disussion, please >>>> add/correct if it doesnt. >>>> >>>> Michael, Gegorios, what do you think? >>>> >>>> thanks, >>>> 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 >> >> >> >> > > -- > Dr. Michael Menth, Assistant Professor > University of Wuerzburg, Institute of Computer Science > Am Hubland, D-97074 Wuerzburg, Germany, room B206 > phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 > mailto:menth@informatik.uni-wuerzburg.de > http://www3.informatik.uni-wuerzburg.de/research/ngn > > > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Nov 20 00:26: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 CE20D3A69E7; Thu, 20 Nov 2008 00:26:09 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 061BC3A682D for ; Thu, 20 Nov 2008 00:26:08 -0800 (PST) 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 3LMKGhzdZde5 for ; Thu, 20 Nov 2008 00:26:07 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id D63603A63D2 for ; Thu, 20 Nov 2008 00:26:06 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 403DBA069F; Thu, 20 Nov 2008 09:26:04 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 3247DA069E; Thu, 20 Nov 2008 09:26:04 +0100 (CET) Received: from [78.51.65.66] (f051065066.adsl.alicedsl.de [78.51.65.66]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id DFCA0A0699; Thu, 20 Nov 2008 09:26:03 +0100 (CET) Message-ID: <49251F1C.1030405@informatik.uni-wuerzburg.de> Date: Thu, 20 Nov 2008 09:26:04 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: philip.eardley@bt.com References: <4A916DBC72536E419A0BD955EDECEDEC04440EBB@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC04440EBB@E03MVB1-UKBR.domain1.systemhost.net> X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Comments on draft-satoh-pcn-ST-marking-00.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 and others, philip.eardley@bt.com schrieb: > Hi Daisuke, > your draft is very interesting, and good discussion over the last couple of days! > > here are some questions & comments on your draft, http://www.ietf.org/mail-archive/web/pcn/current/msg01868.html > i tried to briefly summarise the points i remembered from the WG meeting, as we didn't have time to get to the bottom of them all yesterday. > > 1. Only threshold marking or only excess marking > With the current draft, if you only have 1 encoding state for PCN-marking, then you have 3 possibilities: > - just do threshold marking for accurate adm ctrl > - just do excess marking for accurate flow termination > - do excess marking (at PCN-admissible-rate) for both admission control (somewhat inaccurately) and flow termination > How easy would be to do this with your proposal? or are you basically committed to the third bullet? > > 2. Forward Migration > The current marking behaviour is written so that: > - if you have only one encoding state you can do both admission control (somewhat inaccurately) and flow termination (or you can just do adm ctrl (accurately) or just do flow termination); > - but if you later have two encoding states, then you simply mark pkts with both encoding states - no changes needed to the marking behaviour. > With your draft, what happens if you later have two encoding states? do you need to upgrade your routers with new marking behaviour? or can you do something as simple as with the current WG draft? > > > the other 3 issues definitely need more explanation than is below, just trying to quickly capture them (will leave it to others to write properly about them) > > 3. worry about admission control accuracy > eg slide 7 of http://www.ietf.org/proceedings/08nov/slides/pcn-8.pdf > the marking rate vs pkt rate seems to make assumptions about the traffic arriving. eg if it was very smooth traffic (CBR flows, or smoothed by nw) then the graph wouldnt look like this. > > 4. distinguishing admission and termination > although there is only one type of PCN-marking, basically the egress interprets occasional PCN-marks as meaning "adm ctrl" and a series of pkts that are all consecutively marked as "flow termination". an issue might be if the link is actually doing admission marking, ie PCN-marking 1/N pkts, but somehow all the marks happen to the same egress - which therefore interprets them as flow termination. seems like this could happen if the flows are synchronised (eg they're all CBR flows) > The same phenomenon occurs when flow termination is based on excess marking based on the admissible rate. See IV.F of http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth08-Sub-9.pdf > > 5. flow termination > slide 15 shows that you only terminate "y%" at a time, ie at least a round trip time (+measurement intervals) between each batch of "y%" that you terminate. but it's tricky to know what to set "y" to, eg make it big and you can terminate fast, but this also means that you risk over-terminating by a significant amount. > Terminating y% of the PCN excess traffic rate is rather unproblematic as this leads to an exponential decay of the PCN excess traffic rate. However, here y% of the overall PCN rate is terminated and, therefore, it is basically impossible to avoid overtermination. Regards, Michael > > thanks > phil > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Nov 20 11:33: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 8A7C33A6906; Thu, 20 Nov 2008 11:33:24 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEB033A6906 for ; Thu, 20 Nov 2008 11:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.31 X-Spam-Level: **** X-Spam-Status: No, score=4.31 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, J_CHICKENPOX_57=0.6, J_CHICKENPOX_62=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 wIV43-MCofXz for ; Thu, 20 Nov 2008 11:33:22 -0800 (PST) Received: from sg.ntt-at.co.jp (roma.ntt-at.co.jp [202.253.160.19]) by core3.amsl.com (Postfix) with SMTP id 7258F3A677D for ; Thu, 20 Nov 2008 11:33:22 -0800 (PST) Received: (qmail 93419 invoked by alias); 20 Nov 2008 19:33:20 -0000 Received: from suez.bb.ntt-at.co.jp (192.168.2.9) by subgate.bb.ntt-at.co.jp with SMTP; 20 Nov 2008 19:33:20 -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 mAKJXJOM029686 for ; Fri, 21 Nov 2008 04:33:19 +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 mAKJXJad009638 for ; Fri, 21 Nov 2008 04:33:19 +0900 (JST) (envelope-from daisuke.satoh@ntt-at.co.jp) Received: from [192.168.250.61] (apuser61.bb.ntt-at.co.jp [192.168.250.61]) by mercury.tec.ntt-at.co.jp (Postfix) with ESMTP id A0DD553F61; Fri, 21 Nov 2008 04:33:18 +0900 (JST) Date: Fri, 21 Nov 2008 04:33:19 +0900 From: =?ISO-2022-JP?B?GyRCOjRGIyEhQmdKZRsoQg==?= To: pcn@ietf.org Message-Id: <20081121042743.DBC2.26AD349@ntt-at.co.jp> MIME-Version: 1.0 X-Mailer: Becky! ver. 2.47 [ja] Subject: Re: [PCN] Comments on draft-satoh-pcn-ST-marking-00.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 and Michael, > > Hi Daisuke, > your draft is very interesting, and good discussion over the last couple of days! > > here are some questions & comments on your draft, http://www.ietf.org/mail-archive/web/pcn/current/msg01868.html > i tried to briefly summarise the points i remembered from the WG meeting, as we didn't have time to get to the bottom of them all yesterday. > > 1. Only threshold marking or only excess marking > With the current draft, if you only have 1 encoding state for PCN-marking, then you have 3 possibilities: > - just do threshold marking for accurate adm ctrl > - just do excess marking for accurate flow termination > - do excess marking (at PCN-admissible-rate) for both admission control (somewhat inaccurately) and flow termination > How easy would be to do this with your proposal? or are you basically committed to the third bullet? > -just do threshold marking for both admission control and flow termination. However, TBthreshold.threshold of our algorithm is set to token bucket size minus the metered packet size. PCN-threshold-rate is equal to Supportable rate(Termination rate). Furthremore, one-Nth marking is required when PCN traffic is between Admissible rate and Supportable rate. > 2. Forward Migration > The current marking behaviour is written so that: > - if you have only one encoding state you can do both admission control (somewhat inaccurately) and flow termination (or you can just do adm ctrl (accurately) or just do flow termination); > - but if you later have two encoding states, then you simply mark pkts with both encoding states - no changes needed to the marking behaviour. > With your draft, what happens if you later have two encoding states? do you need to upgrade your routers with new marking behaviour? or can you do something as simple as with the current WG draft? > I cannot answer it immediately because our algorithm is made on condition that only one encoding state is available. If two encoding is available, I guess we do not have to use ratio of marking to distinguish three congestion states. Please give me time to think. > > the other 3 issues definitely need more explanation than is below, just trying to quickly capture them (will leave it to others to write properly about them) > > 3. worry about admission control accuracy > eg slide 7 of http://www.ietf.org/proceedings/08nov/slides/pcn-8.pdf > the marking rate vs pkt rate seems to make assumptions about the traffic arriving. eg if it was very smooth traffic (CBR flows, or smoothed by nw) then the graph wouldnt look like this. > If we measure time average of vacant ratio of server(no packet is in queue and there is no processing packet), Little's law guarantees this slide for G/G/1, that is any arrival process and any service time. Furethremore, due to PASTA(Poisson arrival see time average), if the arrival process is Poisson process, we can measure time average of the vacant ratio of server. The number of superposition is increased, any renewal process approaches to Poisson process. Although I know these above, some of non-renewal processes must approach to Poisson process when the number of superpositions approaches to infinity. I believe most process approaches to Poisson procee when the superposition approaches to infinity. Michael, do you know other things? > 4. distinguishing admission and termination > although there is only one type of PCN-marking, basically the egress interprets occasional PCN-marks as meaning "adm ctrl" and a series of pkts that are all consecutively marked as "flow termination". an issue might be if the link is actually doing admission marking, ie PCN-marking 1/N pkts, but somehow all the marks happen to the same egress - which therefore interprets them as flow termination. seems like this could happen if the flows are synchronised (eg they're all CBR flows) > I answer it supposing that Egress measure CLE and L-sequential marked packet per Ingress. I understand your question is if "adm ctrl" is mis-interpreted as "termination" when there are multi-bottleneck links. The answer is No if operator choose appropriate N and L depending the maximum number of links (or maximum number of multi-bottleneck links) between Ingress and Egress. > 5. flow termination > slide 15 shows that you only terminate "y%" at a time, ie at least a round trip time (+measurement intervals) between each batch of "y%" that you terminate. but it's tricky to know what to set "y" to, eg make it big and you can terminate fast, but this also means that you risk over-terminating by a significant amount. If PCN traffic is a small quantity over Supportable rate(e.g., PCN traffic rate is 101% of supportable rate) and Y is chosen as a big value, it is true over-termination happens but this termination leads to an exponential decay of the PCN excess traffic rate as Michael pointed out. Best regards, Daisuke _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Nov 21 18:42: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 7F6FF3A69B1; Fri, 21 Nov 2008 18:42:44 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 680C23A69BF for ; Fri, 21 Nov 2008 18:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.714 X-Spam-Level: X-Spam-Status: No, score=-5.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, 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 o1OFg1BzfMNy for ; Fri, 21 Nov 2008 18:42:42 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id DFEBD3A67B6 for ; Fri, 21 Nov 2008 18:42:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,648,1220227200"; d="scan'208,217";a="28693983" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 22 Nov 2008 02:42:40 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id mAM2gem9007322; Fri, 21 Nov 2008 21:42:40 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id mAM2geAB025749; Sat, 22 Nov 2008 02:42:40 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Nov 2008 21:42:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Nov 2008 21:33:56 -0500 Message-ID: In-Reply-To: <39297ADA-CECD-4FA5-ADAD-BBFC5574CEFF@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN Corridor meeting on Boundary node behaviours: 3.15pm Thurs Thread-Index: AclKwkqTh0nELA0HQWqULdWDibYZNwAnvV7g References: <4A916DBC72536E419A0BD955EDECEDEC04440EB7@E03MVB1-UKBR.domain1.systemhost.net> <39297ADA-CECD-4FA5-ADAD-BBFC5574CEFF@huawei.com> From: "Anna Charny (acharny)" To: "Tina TSOU" , X-OriginalArrivalTime: 22 Nov 2008 02:42:39.0860 (UTC) FILETIME=[FC75B340:01C94C4B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13057; t=1227321760; x=1228185760; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20(acharny)=22=20 |Subject:=20RE=3A=20[PCN]=20PCN=20Corridor=20meeting=20on=2 0Boundary=20node=20behaviours=3A=203.15pm=20Thurs |Sender:=20 |To:=20=22Tina=20TSOU=22=20,=20; bh=15psZuytRkjxnyXigas4Di8GztFbEeVHGujNLxa37TY=; b=bLYRpKn9GfxHuslyckEPCNH2N9B8bSNW+rZBVuzS38VeWAmmbneV/buHeq WAE3vAGLtQutsJawQ8WY6EaC497RS/p9M69tiUxHM62cTw6TWIJ3mlCZ3Qw9 a8iNi3m7xz; Authentication-Results: rtp-dkim-2; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: pcn@ietf.org Subject: Re: [PCN] PCN Corridor meeting on Boundary node behaviours: 3.15pm Thurs 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="===============1378897703==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1378897703== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C94C4A.C44B217F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C94C4A.C44B217F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Tina, =20 I agree EWMA should be mentioned in the edge behavior where applicable (although the concept of EWMA is quite well known). However I would argue that Policy Enforcement is a separate issue the description of which is outside of the scope of PCN edge behavior.=20 =20 Anna=20 ________________________________ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Tina TSOU Sent: Wednesday, November 19, 2008 9:44 PM To: philip.eardley@bt.com Cc: pcn@ietf.org Subject: Re: [PCN] PCN Corridor meeting on Boundary node behaviours: 3.15pm Thurs =09 =09 =09 Hi Phil et al, In my mind, EWMA (Exponential Weighted Moving Average) and Policy Enforcement are needed to be described in some edge node behavior document.=20 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 =09 B. R. Tina Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com +86-755-28971872 (Office) +86-13922884380(Mobile) On No a href=3D"mailto:philip.eardley@bt.com">philip.eardley@bt.com wrote: As i said in the WG meeting, Anna and I are meeting in the Thurs afternoon session II, to talk about Boundary node behaviours. very welcome to join us. i guess we meet near the registration desk and then find an empty meeting room to chat.=20 =09 the basic reason is that the WG has Charter milestones to produce one or more boundary node behaviours. we thought that we'd think about what things such docs should cover and what a good structure should be (it would be nice if all such docs followed the same format). also other issues like, should a doc describe options or a single choice (ie each option in a separate doc). is there a list of questions that any doc needs to answer? also to seek volunteers to edit such documents (and to let you know that i can't edit any). =09 best wishes phil _______________________________________ ________ a href=3D"mailto:PCN@ietf.org">PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn =09 ------_=_NextPart_001_01C94C4A.C44B217F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello Tina,
 
I agree EWMA should be mentioned in the edge = behavior where=20 applicable (although the concept of EWMA is quite well known).  = However=20 I would argue that Policy Enforcement is a separate issue the=20 description of which is outside of the scope of PCN edge behavior.=20
 
Anna=20

From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of Tina = TSOU
Sent:=20 Wednesday, November 19, 2008 9:44 PM
To:=20 philip.eardley@bt.com
Cc: pcn@ietf.org
Subject: = Re: [PCN]=20 PCN Corridor meeting on Boundary node behaviours: 3.15pm=20 Thurs

Hi Phil et al,
In my mind, EWMA (Exponential Weighted Moving = Average) and Policy Enforcement are needed to be described in some = edge node=20 behavior document.

B. R.
Tina

Messengers:

MSN: tinatsou6@hotmail.com &nbs= p;=20 Yahoo: tina_tsou    Skype: tinaTSOU    = Jabber:=20 tina@jabber.org    = Google=20 talk: tinatsou6@gmail.com

+86-755-28971872 (Office)   =20 = +86-13922884380(Mobile)



On No a=20 href=3D"mailto:philip.eardley@bt.com">philip.eardley@bt.com=20 wrote:

As i said in the WG meeting, Anna and I are meeting in the = Thurs=20 afternoon session II, to talk about Boundary node behaviours. very = welcome=20 to join us. i guess we meet near the registration desk and then find = an=20 empty meeting room to chat.

the basic reason is that the WG = has=20 Charter milestones to produce one or more boundary node behaviours. = we=20 thought that we'd think about what things such docs should cover and = what a=20 good structure should be (it would be nice if all such docs followed = the=20 same format). also other issues like, should a doc describe options = or a=20 single choice (ie each option in a separate doc). is there a list of = questions that any doc needs to answer? also to seek volunteers to = edit such=20 documents (and to let you know that i can't edit any).

best=20 wishes
phil
_______________________________________ ________ a = = href=3D"mailto:PCN@ietf.org">PCN@ietf.org
https://www.ietf.org/= mailman/listinfo/pcn

------_=_NextPart_001_01C94C4A.C44B217F-- --===============1378897703== 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 --===============1378897703==-- From pcn-bounces@ietf.org Fri Nov 21 18:42: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 A00E228B56A; Fri, 21 Nov 2008 18:42:46 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 337DC3A67B6 for ; Fri, 21 Nov 2008 18:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.556 X-Spam-Level: X-Spam-Status: No, score=-5.556 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=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 wDRLenKRdsCp for ; Fri, 21 Nov 2008 18:42:42 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 1C4EF3A69B1 for ; Fri, 21 Nov 2008 18:42:42 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.33,648,1220227200"; d="scan'208";a="28726788" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 22 Nov 2008 02:42:40 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mAM2geWV019795; Fri, 21 Nov 2008 21:42:40 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mAM2ger7021724; Sat, 22 Nov 2008 02:42:40 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Nov 2008 21:42:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Nov 2008 21:33:56 -0500 Message-ID: In-Reply-To: <49251D72.1020109@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Dropping preference as a configuration option Thread-Index: AclK6KicWOTX6fQhSgakt3yYBQfZWwAeUVNg References: <4A916DBC72536E419A0BD955EDECEDEC04440EA1@E03MVB1-UKBR.domain1.systemhost.net> <4A916DBC72536E419A0BD955EDECEDEC04440EA3@E03MVB1-UKBR.domain1.systemhost.net><4923E408.3040807@informatik.uni-wuerzburg.de><4A916DBC72536E419A0BD955EDECEDEC04440EB4@E03MVB1-UKBR.domain1.systemhost.net><49249613.6040502@informatik.uni-wuerzburg.de><4A916DBC72536E419A0BD955EDECEDEC04440EBD@E03MVB1-UKBR.domain1.systemhost.net> <49251D72.1020109@informatik.uni-wuerzburg.de> From: "Anna Charny (acharny)" To: , X-OriginalArrivalTime: 22 Nov 2008 02:42:40.0063 (UTC) FILETIME=[FC94ACF0:01C94C4B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=14015; t=1227321760; x=1228185760; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=acharny@cisco.com; z=From:=20=22Anna=20Charny=20(acharny)=22=20 |Subject:=20RE=3A=20[PCN]=20Dropping=20preference=20as=20a= 20configuration=20option |Sender:=20 |To:=20,=20; bh=HmLd/pbAR9kOjmvrhooRE7sTfUr0YhPtetAo+yDV8W0=; b=luoKDTj+yn+R5T9YnM7H9HGz78iayfKCIjOc1k2hzZxrnIqOLjp2iA9X+e q7qlmh6YrsHXXr8NdAMMWiwmBRePuI8OoaLeVXVlD4YvcfKToidoMZVuwjG0 h1TrGA/TFN; Authentication-Results: rtp-dkim-1; header.From=acharny@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: pcn@ietf.org Subject: Re: [PCN] Dropping preference as a configuration option X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Hi Michael, Just a quick note below: > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Michael Menth > Sent: Thursday, November 20, 2008 2:19 AM > To: philip.eardley@bt.com > Cc: pcn@ietf.org > Subject: Re: [PCN] Dropping preference as a configuration option > > Hi Phil, > > philip.eardley@bt.com schrieb: > > ah, right - direct measured rate termination had slipped to back of > > mind. i think i'd not be too worried about this type of > edge behaviour > > being compromised - if you're prepared to measure rates at egress > > (needed by direct measured rate termination) then seems ok > to measure > > rate at ingress as well (ie CL/SM edge behaviour) phil > > > This is not the point. I'm not talking about overhead or the > feasibility of measurements. I'm talking about problems that > may occur when measurement intervals at ingress and egress > are not synchronized. This issue has always been ignored. We > explained it in IV.C of > http://www3.informatik.uni-wuerzburg.de/~menth/Publications/pa pers/Menth08-Sub-9.pdf I just wanted to point out that we did not really see any evidence of issues related to desynchronized measurement intervals neither for CL nor for SM in any of the CL or SM simulations we ran and reported (which did not rely on synchronized intervals at all). Best, Anna > > Regards, > > Michael > > > > ________________________________ > > > > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > > Sent: Wed 19/11/2008 22:41 > > To: Eardley,PL,Philip,CXR9 R > > Cc: Moncaster,T,Toby,CXR9 R; pcn@ietf.org > > Subject: Re: [PCN] Dropping preference as a configuration option > > > > > > > > Hi Phil, > > > > philip.eardley@bt.com schrieb: > > > >> Michael > >> > >> firstly, i don't beleive it "highly" depends. marked flow > termination still works with preferential dropping of > exces-traffic-marked pkts, eg your paper showed that this was > nearly as good as 'random' dropping for MFT (i remember > 3.5secs vs 3secs). please see discussion below and pointers > to other emails. > >> > >> > > Yes MFT is rather robust. I'm not so much talking about MFT > but about > > direct measured rate termination. Just see next email! > > > > > >> secondly, independently of the above, any proposal needs > to be phrased in standards language, since the Marking > behaviour is a Stds doc. please see the paragrpah below that > starts "Another question is what a Std with such options > would actually say." > >> > >> > > Yes, see next email, too. > > > > Regards, > > > > Michael > > > >> thanks > >> phil > >> > >> ________________________________ > >> > >> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > >> Sent: Wed 19/11/2008 10:01 > >> To: Moncaster,T,Toby,CXR9 R > >> Cc: Eardley,PL,Philip,CXR9 R; pcn@ietf.org > >> Subject: Re: [PCN] Dropping preference as a configuration option > >> > >> > >> > >> Hi Toby and all, > >> > >> the issue of drop preferences highly depends on the edge > behavior. E.g. > >> direct measured rate termination or marked flow > termination benefit > >> from preferentially dropping unmarked packets while > indirect measured > >> rate termination requires preferential dropping of marked packets. > >> Therefore, it makes most sense to demand a certain drop preference > >> when defining the edge behavior (aka deployment model). Defining > >> drop preferences independently of the deployment models is > like erasing some of them. > >> This could be done more directly just by saying, we want > only this or > >> that deployment model and others not (and not even for > later in case > >> the chosen one turns out to be too complex!). If this is not the > >> strategy, the deployment model is the right place for the > definition > >> of drop preferences. > >> > >> Fact is that we discovered that drop preferences are an > important issue. > >> Therefore, it makes sense to require in general two options in the > >> marking or architecture draft: dropping marked or unmarked > packets. > >> The deployment model indicates what's needed. > >> > >> Regards, > >> > >> Michael > >> > >> toby.moncaster@bt.com schrieb: > >> > >> > >>> So outcome of discussion is that we stick with a SHOULD for > >>> preferential drop, but include some proper explanation of the > >>> trade-offs that a vendor might consider when deciding if > they can ignore it? > >>> > >>> This seems to be a very good compromise. Perhaps it could > be phrased > >>> something like: > >>> > >>> "nodes SHOULD preferentially drop excess-traffic-marked packets. > >>> Alternatively they MAY choose to drop randomly but for many > >>> deployment scenarios this is NOT RECOMMENDED (see > appendix n for explanation)." > >>> > >>> Toby > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] > On Behalf > >>>> Of philip.eardley@bt.com > >>>> Sent: 19 November 2008 03:27 > >>>> To: pcn@ietf.org > >>>> Subject: [PCN] Dropping preference as a configuration option > >>>> > >>>> Michael and Georgios have raised this issue recently, and we've > >>>> discussed it here in Minneapolis - both in a 'corridor' > meeting and > >>>> in the WG meeting. > >>>> so i wanted to summarised the issue and the discussions so far. > >>>> Especially as neither of you could make it here. clearly > this means > >>>> we need to discuss and reach consensus on this on the > mailing list. > >>>> i'd really like to do this as quickly as poss, since i > believe it's > >>>> the only current discussion issue for the marking > behaviour draft > >>>> (plus perhaps the satoh draft). > >>>> > >>>> The issue is about if there are 2 bottlenecks on the path, the > >>>> first one is pre-congested & excess-traffic-marking pkts and the > >>>> second one is even more overloaded and is actually > dropping pkts. > >>>> the question is whether the second node should > preferentially drop > >>>> pkts that have already been marked or do something else instead. > >>>> > >>>> History of issue: > >>>> ================== > >>>> In Philadelphia we discussed the choice between: > >>>> * MUST preferentially drop pkts that are already > >>>> excess-traffic-marked OR > >>>> * MUST drop independent of marking > >>>> * a logical thid option that we didn't discuss: > preferentially drop > >>>> pkts that are not excess-traffic-marked) There was a > consensus for > >>>> option 1, as a SHOULD There was also a discussion > afterwards on the > >>>> mailing list (one of Steve's "Questions") which confirmed this > >>>> consensus. > >>>> > >>>> I believe a fair summary of the thinking was as follows: > >>>> (CL/SM = edge behaviour where egress measures rate of > pkts that are > >>>> > >>>> > >>>> > >>> not > >>> > >>> > >>> > >>>> ExM (from an ingress), ingress measures rate of pkts > (sent to that > >>>> egress) > >>>> (MFT = edge behaviour where egress terminates a flow (with some > >>>> probability) when it sees a marked pkt on that flow > >>>> > >>>> * Preferentially drop ExM pkts: works Best for CL/SM ; > Works ok for > >>>> > >>>> > >>>> > >>> MFT > >>> > >>> > >>> > >>>> * 'random' drop: breaks completely in some scenarios (terminates > >>>> far too much) for CL/SM ; works OK (slightly slower than > above) for > >>>> MFT > >>>> * Preferentially drop pkts not ExM: breaks completely in some > >>>> > >>>> > >>>> > >>> scenarios > >>> > >>> > >>> > >>>> (terminates all flows) for CL/SM ; best for MFT (much > faster than > >>>> above) > >>>> > >>>> Michael, i beleive this is what's shown by the paper of > yours you > >>>> pointed me at in your email http://www.ietf.org/mail- > >>>> archive/web/pcn/current/msg01841.html > >>>> ie Fig 9 in http://www3.informatik.uni- > >>>> > >>>> wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-MFT.pdf > >>>> > >>>> we should also bear in mind the pros and cons of CL/SM & MFT: > >>>> * CL/SM: Can terminate fast ('1 shot') > >>>> * MFT: Simpler (don't measure rates), but accept trade-off that > >>>> won't terminate so fast See also more details in > >>>> http://www.ietf.org/mail- archive/web/pcn/current/msg01449.html > >>>> > >>>> so the result of all the discussions at/after > Philadelphia was the > >>>> consensus decision to go for preferentially drop pkts that are > >>>> already excess-traffic-marked, but as a SHOULD (rather than as a > >>>> MUST) > >>>> > >>>> The latest proposal > >>>> =================== > >>>> The proposal from Michael & Georgios is that the preferential > >>>> dropping behaviour is an Option. > >>>> > >>>> > >>>> Summary of discussion in Minneapolis about proposal > >>>> ======================================= > >>>> Pros: All edge behaviours can choose their optimal preferential > >>>> dropping behaviour > >>>> Cons: Extra complexity to standardise, implement & operate > >>>> (configure, manage etc) > >>>> > >>>> Quite a few people made comments at the mike. my impression was > >>>> that the general feeling is that we should think very > hard before > >>>> having an Option - "have one choice" > >>>> > >>>> Another question is what a Std with such options would > actually say. > >>>> eg is one of them the default (MUST) and the other(s) a MAY? > >>>> - making pref. drop the default MUST and 'random' > dropping the MAY > >>>> would be rather empty, since existing routers do tail > drop, so you > >>>> would be saying you MAY do something that the router does anyway! > >>>> - marking 'random' dropping the default would therefore > seem more > >>>> likely But this then means that the default is something that we > >>>> know is broken for CL/SM in scenarios that are easy to devise > >>>> (basically if the link is greatly overloaded, say 5*, then you > >>>> might over-terminate by 4*). which seems quite scay. > >>>> - making them both MUSTs to implement (option which is > used). this > >>>> is actually tougher on vendors than what the current draft says > >>>> (SHOULD for pref. drop - since the 'random dropping' is what the > >>>> router does today, so it's trivial to offer it if that's > demanded. > >>>> > >>>> So the conclusion of this discussion was that a SHOULD actually > >>>> captures quite well what we want to say, ie this is the new > >>>> behaviour, and this is the thing that means CL/SM can > work, whilst > >>>> MFT can also work OK. > >>>> We also thought it would be worth adding a brief explanation why > >>>> it's not a MUST (the Informative Appendix B would be the right > >>>> place). so > >>>> > >>>> > >>>> > >>> we > >>> > >>> > >>> > >>>> could say something like: > >>>> - you might instead want to do tail drop, as this is > what today's > >>>> routers do, so lowers the implementation step for PCN. > But beware > >>>> it has these trade-offs for CL/SM Edge behaviour > >>>> - you might instead want to preferentially drop pkts that arent > >>>> excess traffic marked, becuase this gives the best overall > >>>> behaviour for MFT (ie if you know that this is your edge > behaviour) > >>>> > >>>> Minneappers - Hopefully this captures OK our disussion, please > >>>> add/correct if it doesnt. > >>>> > >>>> Michael, Gegorios, what do you think? > >>>> > >>>> thanks, > >>>> 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 > >> > >> > >> > >> > > > > -- > > 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 Sat Nov 22 01:10: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 170133A692B; Sat, 22 Nov 2008 01:10:24 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43D333A692B for ; Sat, 22 Nov 2008 01:10:22 -0800 (PST) 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_72=0.6, J_CHICKENPOX_91=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 xyiHaJQnTC5f for ; Sat, 22 Nov 2008 01:10:19 -0800 (PST) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 207553A68E4 for ; Sat, 22 Nov 2008 01:10:18 -0800 (PST) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 0EFEEA073E; Sat, 22 Nov 2008 10:10:14 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 02A6BA06D8; Sat, 22 Nov 2008 10:10:14 +0100 (CET) Received: from [92.226.138.86] (g226138086.adsl.alicedsl.de [92.226.138.86]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 7D4F6198F16; Sat, 22 Nov 2008 10:10:13 +0100 (CET) Message-ID: <4927CC77.8060504@informatik.uni-wuerzburg.de> Date: Sat, 22 Nov 2008 10:10:15 +0100 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "Anna Charny (acharny)" References: <4A916DBC72536E419A0BD955EDECEDEC04440EA1@E03MVB1-UKBR.domain1.systemhost.net> <4A916DBC72536E419A0BD955EDECEDEC04440EA3@E03MVB1-UKBR.domain1.systemhost.net><4923E408.3040807@informatik.uni-wuerzburg.de><4A916DBC72536E419A0BD955EDECEDEC04440EB4@E03MVB1-UKBR.domain1.systemhost.net><49249613.6040502@informatik.uni-wuerzburg.de><4A916DBC72536E419A0BD955EDECEDEC04440EBD@E03MVB1-UKBR.domain1.systemhost.net> <49251D72.1020109@informatik.uni-wuerzburg.de> In-Reply-To: X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Dropping preference as a configuration option 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 Anna, Anna Charny (acharny) schrieb: > Hi Michael, > > Just a quick note below: > > >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On >> Behalf Of Michael Menth >> Sent: Thursday, November 20, 2008 2:19 AM >> To: philip.eardley@bt.com >> Cc: pcn@ietf.org >> Subject: Re: [PCN] Dropping preference as a configuration option >> >> Hi Phil, >> >> philip.eardley@bt.com schrieb: >> >>> ah, right - direct measured rate termination had slipped to back of >>> mind. i think i'd not be too worried about this type of >>> >> edge behaviour >> >>> being compromised - if you're prepared to measure rates at egress >>> (needed by direct measured rate termination) then seems ok >>> >> to measure >> >>> rate at ingress as well (ie CL/SM edge behaviour) phil >>> >>> >> This is not the point. I'm not talking about overhead or the >> feasibility of measurements. I'm talking about problems that >> may occur when measurement intervals at ingress and egress >> are not synchronized. This issue has always been ignored. We >> explained it in IV.C of >> http://www3.informatik.uni-wuerzburg.de/~menth/Publications/pa >> > pers/Menth08-Sub-9.pdf > > I just wanted to point out that we did not really see any evidence of > issues related to desynchronized measurement intervals neither for CL > nor for SM in any of the CL or SM simulations we ran and reported (which > did not rely on synchronized intervals at all). > In simulations you can easily have synchronization effects that can have positive or negative impact on the results. Our example shows that overtermination through desynchronized measurement intervals is possible. So this problem does exist. The question is how big is its probability and impact in real systems. To that end, it's important to use explicitly desynchronized measurement intervals in simulations and changing traffic. You can see this phenomenon in simulations only if you make sure that the settings allow the problem I've described. Regards, Michael > Best, > Anna > > > > > > >> Regards, >> >> Michael >> >> >> >>> ________________________________ >>> >>> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >>> Sent: Wed 19/11/2008 22:41 >>> To: Eardley,PL,Philip,CXR9 R >>> Cc: Moncaster,T,Toby,CXR9 R; pcn@ietf.org >>> Subject: Re: [PCN] Dropping preference as a configuration option >>> >>> >>> >>> Hi Phil, >>> >>> philip.eardley@bt.com schrieb: >>> >>> >>>> Michael >>>> >>>> firstly, i don't beleive it "highly" depends. marked flow >>>> >> termination still works with preferential dropping of >> exces-traffic-marked pkts, eg your paper showed that this was >> nearly as good as 'random' dropping for MFT (i remember >> 3.5secs vs 3secs). please see discussion below and pointers >> to other emails. >> >>>> >>>> >>>> >>> Yes MFT is rather robust. I'm not so much talking about MFT >>> >> but about >> >>> direct measured rate termination. Just see next email! >>> >>> >>> >>>> secondly, independently of the above, any proposal needs >>>> >> to be phrased in standards language, since the Marking >> behaviour is a Stds doc. please see the paragrpah below that >> starts "Another question is what a Std with such options >> would actually say." >> >>>> >>>> >>>> >>> Yes, see next email, too. >>> >>> Regards, >>> >>> Michael >>> >>> >>>> thanks >>>> phil >>>> >>>> ________________________________ >>>> >>>> From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] >>>> Sent: Wed 19/11/2008 10:01 >>>> To: Moncaster,T,Toby,CXR9 R >>>> Cc: Eardley,PL,Philip,CXR9 R; pcn@ietf.org >>>> Subject: Re: [PCN] Dropping preference as a configuration option >>>> >>>> >>>> >>>> Hi Toby and all, >>>> >>>> the issue of drop preferences highly depends on the edge >>>> >> behavior. E.g. >> >>>> direct measured rate termination or marked flow >>>> >> termination benefit >> >>>> from preferentially dropping unmarked packets while >>>> >> indirect measured >> >>>> rate termination requires preferential dropping of marked packets. >>>> Therefore, it makes most sense to demand a certain drop preference >>>> when defining the edge behavior (aka deployment model). Defining >>>> drop preferences independently of the deployment models is >>>> >> like erasing some of them. >> >>>> This could be done more directly just by saying, we want >>>> >> only this or >> >>>> that deployment model and others not (and not even for >>>> >> later in case >> >>>> the chosen one turns out to be too complex!). If this is not the >>>> strategy, the deployment model is the right place for the >>>> >> definition >> >>>> of drop preferences. >>>> >>>> Fact is that we discovered that drop preferences are an >>>> >> important issue. >> >>>> Therefore, it makes sense to require in general two options in the >>>> marking or architecture draft: dropping marked or unmarked >>>> >> packets. >> >>>> The deployment model indicates what's needed. >>>> >>>> Regards, >>>> >>>> Michael >>>> >>>> toby.moncaster@bt.com schrieb: >>>> >>>> >>>> >>>>> So outcome of discussion is that we stick with a SHOULD for >>>>> preferential drop, but include some proper explanation of the >>>>> trade-offs that a vendor might consider when deciding if >>>>> >> they can ignore it? >> >>>>> This seems to be a very good compromise. Perhaps it could >>>>> >> be phrased >> >>>>> something like: >>>>> >>>>> "nodes SHOULD preferentially drop excess-traffic-marked packets. >>>>> Alternatively they MAY choose to drop randomly but for many >>>>> deployment scenarios this is NOT RECOMMENDED (see >>>>> >> appendix n for explanation)." >> >>>>> Toby >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] >>>>>> >> On Behalf >> >>>>>> Of philip.eardley@bt.com >>>>>> Sent: 19 November 2008 03:27 >>>>>> To: pcn@ietf.org >>>>>> Subject: [PCN] Dropping preference as a configuration option >>>>>> >>>>>> Michael and Georgios have raised this issue recently, and we've >>>>>> discussed it here in Minneapolis - both in a 'corridor' >>>>>> >> meeting and >> >>>>>> in the WG meeting. >>>>>> so i wanted to summarised the issue and the discussions so far. >>>>>> Especially as neither of you could make it here. clearly >>>>>> >> this means >> >>>>>> we need to discuss and reach consensus on this on the >>>>>> >> mailing list. >> >>>>>> i'd really like to do this as quickly as poss, since i >>>>>> >> believe it's >> >>>>>> the only current discussion issue for the marking >>>>>> >> behaviour draft >> >>>>>> (plus perhaps the satoh draft). >>>>>> >>>>>> The issue is about if there are 2 bottlenecks on the path, the >>>>>> first one is pre-congested & excess-traffic-marking pkts and the >>>>>> second one is even more overloaded and is actually >>>>>> >> dropping pkts. >> >>>>>> the question is whether the second node should >>>>>> >> preferentially drop >> >>>>>> pkts that have already been marked or do something else instead. >>>>>> >>>>>> History of issue: >>>>>> ================== >>>>>> In Philadelphia we discussed the choice between: >>>>>> * MUST preferentially drop pkts that are already >>>>>> excess-traffic-marked OR >>>>>> * MUST drop independent of marking >>>>>> * a logical thid option that we didn't discuss: >>>>>> >> preferentially drop >> >>>>>> pkts that are not excess-traffic-marked) There was a >>>>>> >> consensus for >> >>>>>> option 1, as a SHOULD There was also a discussion >>>>>> >> afterwards on the >> >>>>>> mailing list (one of Steve's "Questions") which confirmed this >>>>>> consensus. >>>>>> >>>>>> I believe a fair summary of the thinking was as follows: >>>>>> (CL/SM = edge behaviour where egress measures rate of >>>>>> >> pkts that are >> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> not >>>>> >>>>> >>>>> >>>>> >>>>>> ExM (from an ingress), ingress measures rate of pkts >>>>>> >> (sent to that >> >>>>>> egress) >>>>>> (MFT = edge behaviour where egress terminates a flow (with some >>>>>> probability) when it sees a marked pkt on that flow >>>>>> >>>>>> * Preferentially drop ExM pkts: works Best for CL/SM ; >>>>>> >> Works ok for >> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> MFT >>>>> >>>>> >>>>> >>>>> >>>>>> * 'random' drop: breaks completely in some scenarios (terminates >>>>>> far too much) for CL/SM ; works OK (slightly slower than >>>>>> >> above) for >> >>>>>> MFT >>>>>> * Preferentially drop pkts not ExM: breaks completely in some >>>>>> >>>>>> >>>>>> >>>>>> >>>>> scenarios >>>>> >>>>> >>>>> >>>>> >>>>>> (terminates all flows) for CL/SM ; best for MFT (much >>>>>> >> faster than >> >>>>>> above) >>>>>> >>>>>> Michael, i beleive this is what's shown by the paper of >>>>>> >> yours you >> >>>>>> pointed me at in your email http://www.ietf.org/mail- >>>>>> archive/web/pcn/current/msg01841.html >>>>>> ie Fig 9 in http://www3.informatik.uni- >>>>>> >>>>>> wuerzburg.de/staff/menth/Publications/papers/Menth08-PCN-MFT.pdf >>>>>> >>>>>> we should also bear in mind the pros and cons of CL/SM & MFT: >>>>>> * CL/SM: Can terminate fast ('1 shot') >>>>>> * MFT: Simpler (don't measure rates), but accept trade-off that >>>>>> won't terminate so fast See also more details in >>>>>> http://www.ietf.org/mail- archive/web/pcn/current/msg01449.html >>>>>> >>>>>> so the result of all the discussions at/after >>>>>> >> Philadelphia was the >> >>>>>> consensus decision to go for preferentially drop pkts that are >>>>>> already excess-traffic-marked, but as a SHOULD (rather than as a >>>>>> MUST) >>>>>> >>>>>> The latest proposal >>>>>> =================== >>>>>> The proposal from Michael & Georgios is that the preferential >>>>>> dropping behaviour is an Option. >>>>>> >>>>>> >>>>>> Summary of discussion in Minneapolis about proposal >>>>>> ======================================= >>>>>> Pros: All edge behaviours can choose their optimal preferential >>>>>> dropping behaviour >>>>>> Cons: Extra complexity to standardise, implement & operate >>>>>> (configure, manage etc) >>>>>> >>>>>> Quite a few people made comments at the mike. my impression was >>>>>> that the general feeling is that we should think very >>>>>> >> hard before >> >>>>>> having an Option - "have one choice" >>>>>> >>>>>> Another question is what a Std with such options would >>>>>> >> actually say. >> >>>>>> eg is one of them the default (MUST) and the other(s) a MAY? >>>>>> - making pref. drop the default MUST and 'random' >>>>>> >> dropping the MAY >> >>>>>> would be rather empty, since existing routers do tail >>>>>> >> drop, so you >> >>>>>> would be saying you MAY do something that the router does anyway! >>>>>> - marking 'random' dropping the default would therefore >>>>>> >> seem more >> >>>>>> likely But this then means that the default is something that we >>>>>> know is broken for CL/SM in scenarios that are easy to devise >>>>>> (basically if the link is greatly overloaded, say 5*, then you >>>>>> might over-terminate by 4*). which seems quite scay. >>>>>> - making them both MUSTs to implement (option which is >>>>>> >> used). this >> >>>>>> is actually tougher on vendors than what the current draft says >>>>>> (SHOULD for pref. drop - since the 'random dropping' is what the >>>>>> router does today, so it's trivial to offer it if that's >>>>>> >> demanded. >> >>>>>> So the conclusion of this discussion was that a SHOULD actually >>>>>> captures quite well what we want to say, ie this is the new >>>>>> behaviour, and this is the thing that means CL/SM can >>>>>> >> work, whilst >> >>>>>> MFT can also work OK. >>>>>> We also thought it would be worth adding a brief explanation why >>>>>> it's not a MUST (the Informative Appendix B would be the right >>>>>> place). so >>>>>> >>>>>> >>>>>> >>>>>> >>>>> we >>>>> >>>>> >>>>> >>>>> >>>>>> could say something like: >>>>>> - you might instead want to do tail drop, as this is >>>>>> >> what today's >> >>>>>> routers do, so lowers the implementation step for PCN. >>>>>> >> But beware >> >>>>>> it has these trade-offs for CL/SM Edge behaviour >>>>>> - you might instead want to preferentially drop pkts that arent >>>>>> excess traffic marked, becuase this gives the best overall >>>>>> behaviour for MFT (ie if you know that this is your edge >>>>>> >> behaviour) >> >>>>>> Minneappers - Hopefully this captures OK our disussion, please >>>>>> add/correct if it doesnt. >>>>>> >>>>>> Michael, Gegorios, what do you think? >>>>>> >>>>>> thanks, >>>>>> 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 >>>> >>>> >>>> >>>> >>>> >>> -- >>> 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 >> >> -- 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 Nov 24 00:09: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 77AE73A6B93; Mon, 24 Nov 2008 00:09:24 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4046B3A6B92 for ; Mon, 24 Nov 2008 00:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.807 X-Spam-Level: X-Spam-Status: No, score=-2.807 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, 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 4V1wmp2SJar2 for ; Mon, 24 Nov 2008 00:09:22 -0800 (PST) Received: from tcmail12.telekom.de (tcmail12.telekom.de [217.5.214.82]) by core3.amsl.com (Postfix) with ESMTP id 869D43A6B93 for ; Mon, 24 Nov 2008 00:09:21 -0800 (PST) Received: from S4DE8PSAANQ.mitte.t-com.de (S4DE8PSAANQ.mitte.t-com.de [10.151.180.166]) by tcmail11.telekom.de with ESMTP; Mon, 24 Nov 2008 09:09:18 +0100 Received: from S4DE8PSAANK.mitte.t-com.de ([10.151.229.10]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 24 Nov 2008 09:09:17 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 24 Nov 2008 09:09:16 +0100 Message-Id: <1B6169C658325341A3B8066E23919E1C020B5DAC@S4DE8PSAANK.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [PCN] PCN Corridor meeting on Boundary node behaviours: 3.15pmThurs thread-index: AclKwkqTh0nELA0HQWqULdWDibYZNwAnvV7gAKm100A= References: <4A916DBC72536E419A0BD955EDECEDEC04440EB7@E03MVB1-UKBR.domain1.systemhost.net><39297ADA-CECD-4FA5-ADAD-BBFC5574CEFF@huawei.com> From: "Geib, Ruediger" To: , X-OriginalArrivalTime: 24 Nov 2008 08:09:17.0838 (UTC) FILETIME=[F29752E0:01C94E0B] Cc: pcn@ietf.org Subject: Re: [PCN] PCN Corridor meeting on Boundary node behaviours: 3.15pmThurs 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="===============0404338717==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============0404338717== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C94E0B.F20B5C81" This is a multi-part message in MIME format. ------_=_NextPart_001_01C94E0B.F20B5C81 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Anna, hello Tina, =20 I agree on including the description of EWMA in the edge node behaviour. =20 What exactly is meant by "Policy Enforcement"? To me, the PCN WG should = for now focus on bulk traffic treatment. So policy enforcement dealing = with bulk traffic may be a relevant issue (if applicable). I don't think = that layer 4 signaling session related policy enforcement or the policy = enforcement for layer 4 signaling session related transport streams = should be specified by PCN. The PCN WG may however specify ways to = support the latter activities and define a kind of interface to higher = layers (may be a kind of PCN edge node API to layer 4 signaling and = transport stream related policy enforcement).=20 =20 Regards, =20 Ruediger _____ =20 From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Anna Charny (acharny) Sent: Saturday, November 22, 2008 3:34 AM To: Tina TSOU; philip.eardley@bt.com Cc: pcn@ietf.org Subject: Re: [PCN] PCN Corridor meeting on Boundary node behaviours: = 3.15pmThurs Hello Tina, =20 I agree EWMA should be mentioned in the edge behavior where applicable = (although the concept of EWMA is quite well known). However I would = argue that Policy Enforcement is a separate issue the description of = which is outside of the scope of PCN edge behavior.=20 =20 Anna=20 _____ =20 From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Tina TSOU Sent: Wednesday, November 19, 2008 9:44 PM To: philip.eardley@bt.com Cc: pcn@ietf.org Subject: Re: [PCN] PCN Corridor meeting on Boundary node behaviours: = 3.15pm Thurs Hi Phil et al, In my mind, EWMA (Exponential Weighted Moving Average) and Policy = Enforcement are needed to be described in some edge node behavior = document.=20 B. R. Tina Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU = Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com +86-755-28971872 (Office) +86-13922884380(Mobile) On No a href=3D"mailto:philip.eardley@bt.com">philip.eardley@bt.com = wrote: As i said in the WG meeting, Anna and I are meeting in the Thurs = afternoon session II, to talk about Boundary node behaviours. very = welcome to join us. i guess we meet near the registration desk and then = find an empty meeting room to chat.=20 the basic reason is that the WG has Charter milestones to produce one or = more boundary node behaviours. we thought that we'd think about what = things such docs should cover and what a good structure should be (it = would be nice if all such docs followed the same format). also other = issues like, should a doc describe options or a single choice (ie each = option in a separate doc). is there a list of questions that any doc = needs to answer? also to seek volunteers to edit such documents (and to = let you know that i can't edit any). best wishes phil _______________________________________ ________ a = href=3D"mailto:PCN@ietf.org">PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn ------_=_NextPart_001_01C94E0B.F20B5C81 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello Anna, = hello Tina,
 
I agree on including the description of EWMA = in the=20 edge node behaviour.
 
What exactly is meant by "Policy = Enforcement"? To me,=20 the PCN WG should for now focus on bulk traffic treatment. So policy = enforcement=20 dealing with bulk traffic may be a relevant issue (if applicable). = I don't=20 think that layer 4 signaling session related policy = enforcement or the=20 policy enforcement for layer 4 signaling session related transport = streams=20 should be specified by PCN. The PCN WG may however specify ways to = support the=20 latter activities and define a kind of interface to higher layers (may = be a=20 kind of PCN edge node API to layer 4 signaling and transport stream = related=20 policy enforcement).
 
Regards,
 
Ruediger

From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of Anna Charny=20 (acharny)
Sent: Saturday, November 22, 2008 3:34 = AM
To: Tina=20 TSOU; philip.eardley@bt.com
Cc: = pcn@ietf.org
Subject: Re:=20 [PCN] PCN Corridor meeting on Boundary node behaviours:=20 3.15pmThurs

Hello Tina,
 
I agree EWMA should be mentioned in the edge = behavior where=20 applicable (although the concept of EWMA is quite well known).  = However=20 I would argue that Policy Enforcement is a separate issue the=20 description of which is outside of the scope of PCN edge behavior.=20
 
Anna=20

From: pcn-bounces@ietf.org=20 [mailto:pcn-bounces@ietf.org] On Behalf Of Tina = TSOU
Sent:=20 Wednesday, November 19, 2008 9:44 PM
To:=20 philip.eardley@bt.com
Cc: pcn@ietf.org
Subject: = Re: [PCN]=20 PCN Corridor meeting on Boundary node behaviours: 3.15pm=20 Thurs

Hi Phil et al,
In my mind, EWMA (Exponential Weighted Moving = Average) and Policy Enforcement are needed to be described in some = edge node=20 behavior document.=20

B. R.
Tina

Messengers:

MSN: tinatsou6@hotmail.com &nbs= p;=20 Yahoo: tina_tsou    Skype: tinaTSOU    = Jabber:=20 tina@jabber.org    = Google=20 talk: tinatsou6@gmail.com

+86-755-28971872 (Office)   =20 = +86-13922884380(Mobile)



On No a=20 href=3D"mailto:philip.eardley@bt.com">philip.eardley@bt.com=20 wrote:

As i said in the WG meeting, Anna and I are meeting in the = Thurs=20 afternoon session II, to talk about Boundary node behaviours. very = welcome=20 to join us. i guess we meet near the registration desk and then find = an=20 empty meeting room to chat.

the basic reason is that the WG = has=20 Charter milestones to produce one or more boundary node behaviours. = we=20 thought that we'd think about what things such docs should cover and = what a=20 good structure should be (it would be nice if all such docs followed = the=20 same format). also other issues like, should a doc describe options = or a=20 single choice (ie each option in a separate doc). is there a list of = questions that any doc needs to answer? also to seek volunteers to = edit such=20 documents (and to let you know that i can't edit any).

best=20 wishes
phil
_______________________________________ ________ a = = href=3D"mailto:PCN@ietf.org">PCN@ietf.org
https://www.ietf.org/= mailman/listinfo/pcn

------_=_NextPart_001_01C94E0B.F20B5C81-- --===============0404338717== 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 --===============0404338717==-- From pcn-bounces@ietf.org Mon Nov 24 02:31: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 54A7A3A683A; Mon, 24 Nov 2008 02:31:51 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1657C3A67F7 for ; Mon, 24 Nov 2008 02:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 UMZ9Un-Fos21 for ; Mon, 24 Nov 2008 02:31:48 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 6B8A33A67B3 for ; Mon, 24 Nov 2008 02:31:48 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KAU003PW2KX1X@szxga04-in.huawei.com> for pcn@ietf.org; Mon, 24 Nov 2008 18:31:45 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KAU001N32KWYF@szxga04-in.huawei.com> for pcn@ietf.org; Mon, 24 Nov 2008 18:31:44 +0800 (CST) Received: from [192.168.0.103] ([116.24.132.196]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KAU002WS2KUI1@szxml02-in.huawei.com>; Mon, 24 Nov 2008 18:31:44 +0800 (CST) Date: Mon, 24 Nov 2008 18:31:42 +0800 From: Tina TSOU In-reply-to: <1B6169C658325341A3B8066E23919E1C020B5DAC@S4DE8PSAANK.mitte.t-com.de> To: "Geib, Ruediger" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.929.2) References: <4A916DBC72536E419A0BD955EDECEDEC04440EB7@E03MVB1-UKBR.domain1.systemhost.net> <39297ADA-CECD-4FA5-ADAD-BBFC5574CEFF@huawei.com> <1B6169C658325341A3B8066E23919E1C020B5DAC@S4DE8PSAANK.mitte.t-com.de> Cc: pcn@ietf.org Subject: Re: [PCN] PCN Corridor meeting on Boundary node behaviours: 3.15pmThurs 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="===============2133818286==" Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org --===============2133818286== Content-type: multipart/alternative; boundary="Boundary_(ID_szNA8t7Tq+iTshayZvJ5fQ)" --Boundary_(ID_szNA8t7Tq+iTshayZvJ5fQ) Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-transfer-encoding: 7BIT Hi Ruediger, Thank you for your reply. Comment in line. B. R. Tina Messengers: MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com +86-755-28971872 (Office) +86-13922884380(Mobile) On Nov 24, 2008, at 4:09 PM, Geib, Ruediger wrote: > Hello Anna, hello Tina, > > I agree on including the description of EWMA in the edge node > behaviour. > > What exactly is meant by "Policy Enforcement"? To me, the PCN WG > should for now focus on bulk traffic treatment. So policy > enforcement dealing with bulk traffic may be a relevant issue (if > applicable). I don't think that layer 4 signaling session related > policy enforcement or the policy enforcement for layer 4 signaling > session related transport streams should be specified by PCN. The > PCN WG may however specify ways to support the latter activities and > define a kind of interface to higher layers (may be a kind of PCN > edge node API to layer 4 signaling and transport stream related > policy enforcement). > [Tina: Any policy enforcement which enforces traffic policy control > which is useful for operators. It's mainly L2/L3. My mind was not in > layer 4 so high:)] > Regards, > > Ruediger > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf > Of Anna Charny (acharny) > Sent: Saturday, November 22, 2008 3:34 AM > To: Tina TSOU; philip.eardley@bt.com > Cc: pcn@ietf.org > Subject: Re: [PCN] PCN Corridor meeting on Boundary node behaviours: > 3.15pmThurs > > Hello Tina, > > I agree EWMA should be mentioned in the edge behavior where > applicable (although the concept of EWMA is quite well known). > However I would argue that Policy Enforcement is a separate issue > the description of which is outside of the scope of PCN edge behavior. > > Anna > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf > Of Tina TSOU > Sent: Wednesday, November 19, 2008 9:44 PM > To: philip.eardley@bt.com > Cc: pcn@ietf.org > Subject: Re: [PCN] PCN Corridor meeting on Boundary node behaviours: > 3.15pm Thurs > > Hi Phil et al, > In my mind, EWMA (Exponential Weighted Moving Average) and Policy > Enforcement are needed to be described in some edge node behavior > document. > > B. R. > Tina > > Messengers: > > MSN: tinatsou6@hotmail.com Yahoo: tina_tsou Skype: tinaTSOU > Jabber: tina@jabber.org Google talk: tinatsou6@gmail.com > > +86-755-28971872 (Office) +86-13922884380(Mobile) > > > > > On No a href="mailto:philip.eardley@bt.com">philip.eardley@bt.com > wrote: > >> As i said in the WG meeting, Anna and I are meeting in the Thurs >> afternoon session II, to talk about Boundary node behaviours. very >> welcome to join us. i guess we meet near the registration desk and >> then find an empty meeting room to chat. >> >> the basic reason is that the WG has Charter milestones to produce >> one or more boundary node behaviours. we thought that we'd think >> about what things such docs should cover and what a good structure >> should be (it would be nice if all such docs followed the same >> format). also other issues like, should a doc describe options or a >> single choice (ie each option in a separate doc). is there a list >> of questions that any doc needs to answer? also to seek volunteers >> to edit such documents (and to let you know that i can't edit any). >> >> best wishes >> phil >> _______________________________________ ________ a href="mailto:PCN@ietf.org >> ">PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn > --Boundary_(ID_szNA8t7Tq+iTshayZvJ5fQ) Content-type: text/html; charset=US-ASCII Content-transfer-encoding: quoted-printable
Hi = Ruediger,
Thank you for your reply.
Comment in = line.

B. = R.
Tina

Messengers:

MSN: tinatsou6@hotmail.com  = ; Yahoo: tina_tsou    Skype: tinaTSOU    = Jabber: tina@jabber.org    = Google talk: tinatsou6@gmail.com

+86-755-28971872 (Office)    = +86-13922884380(Mobile)





On Nov 24, 2008, at 4:09 PM, Geib, Ruediger = wrote:

Hello Anna, = hello Tina,
 
I agree on including the description of = EWMA in the edge node behaviour.
 
What exactly is meant by "Policy = Enforcement"? To me, the PCN WG should for now focus on bulk traffic = treatment. So policy enforcement dealing with bulk traffic may be a = relevant issue (if applicable). I don't think that layer 4 = signaling session related policy enforcement or the policy = enforcement for layer 4 signaling session related transport streams = should be specified by PCN. The PCN WG may however specify ways to = support the latter activities and define a kind of interface to higher = layers (may be a kind of PCN edge node API to layer 4 signaling and = transport stream related policy enforcement).
[Tina: Any policy enforcement which enforces traffic policy = control which is useful for operators. It's mainly L2/L3. My mind was = not in layer 4 so = high:)]

Regards,
 
Ruediger

=
From: = pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] = On Behalf Of Anna Charny (acharny)
Sent: Saturday, = November 22, 2008 3:34 AM
To: Tina TSOU; philip.eardley@bt.com
Cc:<= /b> pcn@ietf.org
Subject: = Re: [PCN] PCN Corridor meeting on Boundary node behaviours: = 3.15pmThurs

Hello Tina,
 
=
I agree EWMA should be = mentioned in the edge behavior where applicable (although the concept of = EWMA is quite well known).  However I would argue = that Policy Enforcement is a separate issue the description of = which is outside of the scope of PCN edge behavior.
=
 
Anna

From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] = On Behalf Of Tina TSOU
Sent: Wednesday, November 19, = 2008 9:44 PM
To: philip.eardley@bt.com
Cc:<= /b> pcn@ietf.org
Subject: = Re: [PCN] PCN Corridor meeting on Boundary node behaviours: 3.15pm = Thurs

Hi Phil = et al,
In my mind, EWMA (Exponential Weighted Moving Average) and = Policy Enforcement are needed to be described in some edge node = behavior document.

=
=
B. R.
=
Tina

Messengers:

MSN: tinatsou6@hotmail.com  = ; Yahoo: tina_tsou    Skype: tinaTSOU    = Jabber: tina@jabber.org    = Google talk: tinatsou6@gmail.com

+86-755-= 28971872 (Office)    = +86-13922884380(Mobile)




On No a = href=3D"mailto:philip.eardley@bt.com">philip.eardley@bt.com = wrote:

As i said in the WG meeting, Anna and I are = meeting in the Thurs afternoon session II, to talk about Boundary = node behaviours. very welcome to join us. i guess we meet near the = registration desk and then find an empty meeting room to chat. =

the basic reason is that the WG has Charter milestones to = produce one or more boundary node behaviours. we thought that we'd = think about what things such docs should cover and what a good = structure should be (it would be nice if all such docs followed the = same format). also other issues like, should a doc describe options or a = single choice (ie each option in a separate doc). is there a list of = questions that any doc needs to answer? also to seek volunteers to = edit such documents (and to let you know that i can't edit = any).

best = wishes
phil
_______________________________________ ________ a = href=3D"mailto:PCN@ietf.org">PCN@ietf.org
https://www.ietf.org/ma= ilman/listinfo/pcn

=

= --Boundary_(ID_szNA8t7Tq+iTshayZvJ5fQ)-- --===============2133818286== 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 --===============2133818286==-- From pcn-bounces@ietf.org Mon Nov 24 09:35: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 05C633A6BAE; Mon, 24 Nov 2008 09:35:37 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86A273A6BAB for ; Mon, 24 Nov 2008 09:35:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.38 X-Spam-Level: X-Spam-Status: No, score=-0.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaX70cxa5LdH for ; Mon, 24 Nov 2008 09:35:34 -0800 (PST) Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p2.extremenetworks.com [207.179.9.62]) by core3.amsl.com (Postfix) with ESMTP id EAA563A6A46 for ; Mon, 24 Nov 2008 09:35:34 -0800 (PST) Received: from [10.5.2.103] (10.5.2.103) by ussc-casht-p1.corp.extremenetworks.com (10.0.4.73) with Microsoft SMTP Server id 8.1.291.1; Mon, 24 Nov 2008 09:35:32 -0800 From: Steven Blake To: Organization: Extreme Networks Date: Mon, 24 Nov 2008 12:35:31 -0500 Message-ID: <1227548131.4165.13.camel@ecliptic.corp.extremenetworks.com> MIME-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Subject: [PCN] Testing X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: pcn-bounces@ietf.org Errors-To: pcn-bounces@ietf.org Please ignore ///////////////////////////////////////////// Steven Blake sblake@extremenetworks.com Extreme Networks +1 919-884-3211 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Nov 24 21:28: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 646583A691A; Mon, 24 Nov 2008 21:28:59 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B003D3A691A for ; Mon, 24 Nov 2008 21:28:57 -0800 (PST) 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 Jl+o20Hc6prv for ; Mon, 24 Nov 2008 21:28:56 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 0586E3A680F for ; Mon, 24 Nov 2008 21:28:56 -0800 (PST) Received: from localhost ([127.0.0.1] helo=petri-meat.com) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1L4qTh-0004PT-KH for pcn@ietf.org; Tue, 25 Nov 2008 00:28:49 -0500 MIME-Version: 1.0 Date: Tue, 25 Nov 2008 00:28:49 -0500 From: To: pcn@ietf.org Message-ID: <794e2263a060f550541ba6aa649af0a5@petri-meat.com> X-Sender: slblake@petri-meat.com User-Agent: RoundCube Webmail/0.1 Content-Type: multipart/mixed; boundary="=_0981d5bca524478ea7db3c3bdc8a8e2d" 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 73 **DRAFT** working group 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 --=_0981d5bca524478ea7db3c3bdc8a8e2d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit I have uploaded the draft working group minutes from the Minneapolis PCN meeting to: http://www.ietf.org/proceedings/08nov/minutes/pcn.txt They are also attached. Please send comments/corrections to the list this week. Regards, // Steve --=_0981d5bca524478ea7db3c3bdc8a8e2d Content-Transfer-Encoding: base64 Content-Type: text/plain; name="minutes.draft.txt"; charset="UTF-8" Content-Disposition: attachment; filename="minutes.draft.txt" Q29uZ2VzdGlvbiBhbmQgUHJlLUNvbmdlc3Rpb24gTm90aWZpY2F0aW9uIFdHIChwY24pCklFVEY3 MyAqKkRSQUZUKiogTWVldGluZyBNaW51dGVzCgpDSEFJUnM6IFNjb3R0IEJyYWRuZXIgPHNvYkBo YXJ2YXJkLmVkdT4KICAgICAgICBTdGV2ZW4gQmxha2UgIDxzYmxha2VAZXh0cmVtZW5ldHdvcmtz LmNvbT4KCk1pbnV0ZSB0YWtlcjogVG9tIFRheWxvcgoKClRVRVNEQVksIE5vdmVtYmVyIDE4LCAy MDA4IAowOTAwLTExMzAgTW9ybmluZyBTZXNzaW9uIEkgClNhbG9uIEUKPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09CgpBR0VOREE6CgpvIEFkbWluaXN0cml2aWEKClN0ZXZlbiBC bGFrZSBwcmVzZW50ZWQgdGhlIGFnZW5kYSBzbGlkZXM6CgogIGh0dHA6Ly93d3czLmlldGYub3Jn L3Byb2NlZWRpbmdzLzA4bm92L3NsaWRlcy9wY24tMC5wZGYKCkhlIHJldmlld2VkIHRoZSBzdGF0 dXMgb2YgdGhlIGNoYXJ0ZXIgbWlsZXN0b25lcy4gIFRoZSBhcmNoaXRlY3R1cmUgCmRvY3VtZW50 IGlzIGdyZWVuLCBtb3N0IG9mIHRoZSByZXF1aXJlZCBkb2N1bWVudHMgYXJlIHllbGxvdywgd2hp bGUKdGhlIHNpZ25hbGluZyByZXF1aXJlbWVudHMgZG9jdW1lbnQgaXMgcmVkLgoKCi0tLS0tLS0t LS0tLS0tLS0tLQpvIFBDTiBBcmNoaXRlY3R1cmUgCiAgZHJhZnQtaWV0Zi1wY24tYXJjaGl0ZWN0 dXJlLTA4CgpQaGlsaXAgRWFyZGxleSBkaXNjdXNzZWQgdGhlIHN0YXR1cyBvZiB0aGUgUENOIGFy Y2hpdGVjdHVyZSBkcmFmdC4KClNsaWRlczogaHR0cDovL3d3dzMuaWV0Zi5vcmcvcHJvY2VlZGlu Z3MvMDhub3Yvc2xpZGVzL3Bjbi0xLnBkZiAKClRoZSBkcmFmdCBoYXMgYmVlbiB0aHJvdWdoIHR3 byB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbHMuICBDdXJyZW50bHkgd2FpdGluZwpvbiBBZCBkaXJl Y3Rpb24gYmVmb3JlIHN1Ym1pdHRpbmcgdGhlIGRyYWZ0IGZvciBJRVNHIGFwcHJvdmFsIChhbmQg SUVURgpMYXN0IENhbGwsIGFjY29yZGluZyB0byBMYXJzIEVnZ2VydCkuICBIZSBtZW50aW9uZWQg dGhhdCB2b2x1bnRlZXJzIHdlcmUKbmVlZGVkIHRvIHdyaXRlIGVkZ2Ugbm9kZSBiZWhhdmlvciBk cmFmdHMuICBUaGVyZSB3aWxsIGJlIGEgY29ycmlkb3IgbWVldGluZwpvbiBUaHVyc2RheSB0byB3 b3JrIG9uIGEgdGVtcGxhdGUgZm9yIHRoZXNlIGRyYWZ0cy4KCgotLS0tLS0tLS0tLS0tLS0tLS0K byBNYXJraW5nIEJlaGF2aW9yIAogIGRyYWZ0LWlldGYtcGNuLW1hcmtpbmctYmVoYXZpb3ItMDEK ClBoaWxpcCBFYXJkbGV5IGRpc2N1c3NlZCB0aGUgc3RhdHVzIG9mIHRoZSBQQ04gTWFya2luZyBC ZWhhdmlvciBkcmFmdC4gIAoKU2xpZGVzOiBodHRwOi8vd3d3My5pZXRmLm9yZy9wcm9jZWVkaW5n cy8wOG5vdi9zbGlkZXMvcGNuLTIucGRmCgpQaGlsYWRlbHBoaWEgY29uc2Vuc3VzIG9uIG1hcmtp bmcgYmVoYXZpb3Igd2FzIGNvbmZpcm1lZCBpbiBEdWJsaW4sIGFuZApkb2N1bWVudGVkIGhlcmUu ICBUcmFmZmljIGNvbmRpdGlvbmluZyBzZWN0aW9uIHdhcyByZXdyaXR0ZW4uICBUaGVyZSBpcyBu byAKbm9ybWF0aXZlIGFkdmljZSBvbiB0aGUgcHJpb3JpdGl6YXRpb24gb2YgY29tcGV0aW5nIG5v bi1QQ04gcGFja2V0cy4gIFBoaWxpcApjb25zaWRlcnMgdGhlIGRyYWZ0IHJlYWR5IGZvciB3b3Jr aW5nIGdyb3VwIGxhc3QgY2FsbC4KCkNoYWlyIGFza2VkIGhvdyBtYW55IGluIHJvb20gaGFkIHJl YWQgZG9jdW1lbnQsIHN0YXRlZCB0aGF0IHRoZSBudW1iZXIgaGFkIHRvCmluY3JlYXNlLCBhbmQg ZW5jb3VyYWdlZCBwYXJ0aWNpcGFudHMgdG8gcmVhZCB0aGUgZHJhZnQgYW5kIGNvbW1lbnQgb24g dGhlCmxpc3QuCgpQaGlsaXAgbWVudGlvbmVkIGEgbnVtYmVyIG9mIHBvaW50cyB3aGljaCBoYXZl IGhhZCBsaXN0IGRpc2N1c3Npb246CgpvIFNhdG9oIGRyYWZ0IChkcmFmdC1zYXRvaC1wY24tU1Qt bWFya2luZy0wMC50eHQpCgpvIDEvTiBtYXJraW5nIC0tIE1pY2hhZWwgTWVudGggc2hvd2VkIGVx dWl2YWxlbnQgYmVoYXZpb3IgY291bGQgYmUgYWNoaWV2ZWQgYnkKICBwZXJmb3JtaW5nIDEvTiBy ZWR1Y3Rpb24gaW4gZWRnZSB0ZXJtaW5hdGlvbi4KCm8gTWFrZSBwcmVmZXJlbnRpYWwgZHJvcHBp bmcgb3B0aW9uYWwgcmF0aGVyIHRoYW4gU0hPVUxEOyBhZGQgb3B0aW9uIGZvciAKICByYW5kb20g ZHJvcHBpbmcgKGUuZy4gdGFpbCBkcm9wKQoKUGhpbGlwIHJldmlld2VkIHNsaWRlcyBvZiBkaWZm ZXJlbnQgZHJvcHBpbmcgcG9saWNpZXMuIFRoZSBlZmZlY3Qgb2YgZWFjaCAKZGVwZW5kcyBvbiB0 aGUgbWFya2luZyBiZWhhdmlvdXIuICBNaWNoYWVsIE1lbnRoIGhhZCBzdWdnZXN0ZWQgdG8gbWFr ZSAKZHJvcHBpbmcgYmVoYXZpb3VyIGEgY29uZmlndXJhYmxlIG9wdGlvbi4gIFRoaXMgY2hvaWNl IGhhcyBwcm9zIGFuZCBjb25zLiAKUHJvYmxlbSBvZiB3aGF0IHRvIHNheSBpbiBhIHN0YW5kYXJk cyBkb2N1bWVudC4gIFN1Z2dlc3RzIGtlZXBpbmcgdGhlIFNIT1VMRApvbiBwcmVmZXJlbnRpYWwg ZHJvcHBpbmcgb2YgbWFya2VkIHBhY2tldHMsIGJ1dCBhZGQgZXhwbGFuYXRpb24gb2Ygd2hlbiBp dCAKd291bGQgYmUgcmVhc29uYWJsZSB0byB1c2UgYW5vdGhlciBiZWhhdmlvdXIgKHRoaXMgd2Fz IHRoZSBvdXRjb21lIG9mIGEgZ3JvdXAKZGlzY3Vzc2lvbiB5ZXN0ZXJkYXkpCgo+IFJ1ZWRpZ2Vy IEdlaWI6IHRvbyBtYW55IG9wdGlvbnMgLSBndXQgZmVlbGluZwoKPiBHbGVuIFpvcm46IElFVEYg c2hvdWxkIG5vdCBzdGFuZGFyZGl6ZSBjb25maWd1cmF0aW9uLiAgQW5kIHRoaXMgZG9lc24ndAog IGFmZmVjdCB0aGUgcHJvdG9jb2wsIHNvIHdoeSBtZW50aW9uIGl0PyAKICAKPiBTY290dCBCcmFk bmVyOiBkb2VzIGhhdmUgb3BlcmF0aW9uYWwgc2lnbmlmaWNhbmNlLiBEb2VzIGNoYW5nZSBiZWhh dmlvdXI7IAogIGhhdmUgdG8gZW5zdXJlIGludGVyb3BlcmFiaWxpdHkuCgo+IFN0ZXZlbiBCbGFr ZTogY291bGQgc2V0IHVwIHRvIHJlcXVpcmUgY29uZmlndXJhYmlsaXR5LiAgU2ltcGxlc3Qgd2F5 IGlzIHRvIAogIGxlYXZlIGl0IHVwIHRvIG9wZXJhdG9yIHRvIHR1cm4gb24gYSBwb2xpY2VyLCB0 dXJuIG9uIGEgbWFya2VyLiAgU2hvdWxkIHRha2UKICBkaXNjdXNzaW9uIHRvIGxpc3QuCgo+IChV bmtub3duKTogQmFkIGlkZWEgdG8gYWRkIGNvbmZpZ3VyYXRpb24gb3B0aW9uLgoKPiAoVW5rbm93 bik6IE5lZWQgdG8gdGhpbmsgY2FyZWZ1bGx5IGFib3V0IGRlc2NyaWJpbmcgYmVoYXZpb3VyIHRo YXQgaXMgbm90IAogIG5vcm1hdGl2ZS4gIFNIT1VMRHMgc2hvdWxkIGxlYWQgdG8gaW50ZXJvcGVy YWJpbGl0eS4KCj4gU3R1IEdvbGRtYW46IFRvbyBtYW55IG9wdGlvbnMgaXMgbm90IGEgc3RhbmRh cmQuCgpQaGlsaXAncyBjbG9zaW5nIHJlbWFyayAtLSAxMDAlIGNvbnNlbnN1cyBpcyBub3QgYWNo aWV2YWJsZS4gIENoYWlycyBhZ3JlZSwgCndvcmtpbmcgZ3JvdXAgaXMgYWltaW5nIGZvciByb3Vn aCBjb25zZW5zdXMuICBUaGUgZHJhZnQgbmVlZHMgYW5vdGhlciByb3VuZCBvbgp0aGUgbWFpbGlu ZyBsaXN0IHRvIGNsb3NlIGRpc2N1c3Npb24gcG9pbnRzLCBiZWZvcmUgaW5pdGlhdGluZyBhIHdv cmtpbmcgZ3JvdXAKbGFzdCBjYWxsLgoKCi0tLS0tLS0tLS0tLS0tLS0tLS0KbyBCYXNlbGluZSBF bmNvZGluZwogIGRyYWZ0LWlldGYtcGNuLWJhc2VsaW5lLWVuY29kaW5nLTAxCgpCb2IgQnJpc2Nv ZSBkaXNjdXNzZWQgdGhlIHN0YXR1cyBvZiB0aGUgQmFzZWxpbmUgRW5jb2RpbmcgZHJhZnQuCgpT bGlkZXM6IGh0dHA6Ly93d3czLmlldGYub3JnL3Byb2NlZWRpbmdzLzA4bm92L3NsaWRlcy9wY24t My5wZGYgCgpUaGUgZHJhZnQgaGFzIGJlZW4gdXBkYXRlZCB0d2ljZSBzaW5jZSB0aGUgRHVibGlu IG1lZXRpbmcsIGFuZCBpcyBub3cgYQp3b3JraW5nIGdyb3VwIGRyYWZ0LiAgTWFpbiBjaGFuZ2Ug dG8gZW5jb2RpbmcgaXMgdG8gc3BlY2lmeSB0aGF0IEVDTj0nMDEnIAplbmNvZGluZyBpcyBmb3Ig RXhwZXJpbWVudGFsIChub3QgbG9jYWwpIHVzZS4gIEFkZGVkIGEgc2VjdGlvbiBvbiByZXN0cmlj dGlvbnMKZm9yIGV4dGVuc2lvbiBlbmNvZGluZyB0byBlbnN1cmUgYmFja3dhcmQgY29tcGF0aWJp bGl0eS4gIE5vZGUgYmVoYXZpb3VycyAKbW92ZWQgdG8gYW4gYXBwZW5kaXguICBBZGRlZCBjaGFu Z2Ugb2YgdGVybWlub2xvZ3kgdG8gJ1BDTi1jb21wYXRpYmxlIERTQ1AnLAonUENOLWVuYWJsZWQg cGFja2V0Jy4KClN1bW1hcnkgc2xpZGUgYXQgZW5kIHNob3dzIHdoeSB0aGUgYmFzZWxpbmUgZW5j b2RpbmcgaXMgdGhlIGJlc3QgY2hvaWNlIGZvcgpleHRlbnNpYmlsaXR5LiAgCk9wZW4gaXNzdWU6 IHdoZXJlIHRvIHB1dCB0ZXh0IG9uIHZhbGlkIGFuZCBpbnZhbGlkIGNvZGVwb2ludCB0cmFuc2l0 aW9ucz8KT3RoZXIgdGhhbiB0aGlzLCBCb2IgY29uc2lkZXJzIHRoZSBkcmFmdCByZWFkeSBmb3Ig d29ya2luZyBncm91cCBsYXN0IGNhbGwuCgpDaGFpciBhc2tlZCB3aG8gaGFkIHJlYWQgdGhpcyBk cmFmdCAoZmV3ZXIgdGhhbiBmb3IgdGhlIG1hcmtpbmcgYmVoYXZpb3VyCmRyYWZ0KS4gIEhlIGVu Y291cmFnZWQgcGFydGljaXBhbnRzIHRvIHJlYWQgaXQgYW5kIGNvbW1lbnQgb24gdGhlIG1haWxp bmcKbGlzdC4KCj4gUGhpbGlwIEVhcmRsZXk6IHBlb3BsZSBzaG91bGQgZXNwZWNpYWxseSByZXZp ZXcgdGhlIHNlY3Rpb24gb24gcmVzdHJpY3Rpb25zCiAgZm9yIGZ1dHVyZSBleHRlbnNpb25zLgoK PiBMYXJzIEVnZ2VydCAoQUQpOiBJbmZvcm1hdGlvbmFsIGRvY3VtZW50cyBkb24ndCBub3JtYWxs eSBnbyB0aHJvdWdoIElFVEYgCiAgTGFzdCBDYWxsLCBidXQgbGF0ZWx5IGFyY2hpdGVjdHVyZSBh bmQgcmVxdWlyZW1lbnRzIGRvY3VtZW50cyBkby4gCiAgQXBwcm92YWwgb2YgdGhlIGFyY2hpdGVj dHVyZSBkcmFmdCB3aWxsIGJlIG5lZWRlZCBiZWZvcmUgb3RoZXIgUENOIGRyYWZ0cyAKICBjYW4g cHJvZ3Jlc3MuICAKICAKQ2hhaXJzIGFncmVlZCB0aGF0IGEgcmVxdWVzdCBmb3IgcHVibGljYXRp b24gb2YgdGhlIGFyY2hpdGVjdHVyZSBkcmFmdAp3aWxsIGJlIHN1Ym1pdHRlZCBzaG9ydGx5IChT Y290dCBCcmFkbmVyIHdpbGwgYmUgZG9jdW1lbnQgc2hlcGhhcmQpLiAgQUQgCnJldmlldyB3aWxs IGJlIHNob3J0IGJlY2F1c2UgTGFycyBoYXMgYWxyZWFkeSByZWFkIHRoZSBkcmFmdC4KCgotLS0t LS0tLS0tLS0tLS0tLS0tLS0KbyAzLWluLTEgUENOIEVuY29kaW5nCiAgZHJhZnQtYnJpc2NvZS1w Y24tMy1pbi0xLWVuY29kaW5nLTAwCgpCb2IgQnJpc2NvZSBkaXNjdXNzZWQgdGhlIHN0YXR1cyBv ZiBoaXMgMy1pbi0xIFBDTiBFbmNvZGluZyBkcmFmdC4KClNsaWRlczogaHR0cDovL3d3dzMuaWV0 Zi5vcmcvcHJvY2VlZGluZ3MvMDhub3Yvc2xpZGVzL3Bjbi00LnBkZgoKSGUgaXMgbG9va2luZyB0 byBkZXZlbG9wbWVudHMgZWxzZXdoZXJlIHRvIGVuYWJsZSB0aGlzIG9wdGlvbi4KRXhwZWN0ZWQg ZGlzcG9zaXRpb24sIGFsbCBnb2luZyB3ZWxsLCBpcyB0aGF0IGl0IGJlY29tZSBhbiBFeHBlcmlt ZW50YWwgUkZDLgpOZWVkIG1vcmUgcGVvcGxlIHRvIHJlYWQgYW5kIGNvbW1lbnQgb24gdGhlIFBD TiBtYWlsaW5nIGxpc3QuCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0KbyBQU0RNIEVkZ2UgQmVoYXZp b3IKICBkcmFmdC1tZW50aC1wY24tcHNkbS1kZXBsb3ltZW50LTAwCgpQaGlsaXAgRWFyZGxleSBk aXNjdXNzZWQgdGhlIHN0YXR1cyBvZiB0aGUgTWljaGFlbCBNZW50aCdzIFBTRE0gRWRnZSBCZWhh dmlvcgpkcmFmdC4KClNsaWRlczogaHR0cDovL3d3dzMuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvMDhu b3Yvc2xpZGVzL3Bjbi01LnBkZgoKVHdvIGFzcGVjdHMgdG8gdGhlIGRyYWZ0OiBlbmNvZGluZyAo ZXhwZXJpbWVudGFsIGV4dGVuc2lvbiBvZiBiYXNlbGluZSksIHBsdXMKYSBkZXBsb3ltZW50IG1v ZGVsLiAgQ2hhaXIgYXNrZWQgaWYgdGhlIGVuY29kaW5nIHVzZWQgaW4gdGhpcyBkcmFmdCBpcwpj b21wYXRpYmxlIHdpdGggd29yayBCb2IgQnJpc2NvZSBpcyBkb2luZywgYW5zd2VyIGlzIHllcy4K ClRoZSBzbGlkZXMgcmV2aWV3IGhvdyBQU0RNIHdvcmtzLiAgRGF0YSBhbmQgcHJvYmUgcGFja2V0 cyBhcmUgbWFya2VkIApkaWZmZXJlbnRseS4gIEFkbWlzc2lvbiBjb250cm9sIGlzIHBlcmZvcm1l ZCBvbiBwcm9iZSBwYWNrZXRzOyBmbG93IAp0ZXJtaW5hdGlvbiBpcyBwZXJmb3JtZWQgb24gZGF0 YSBwYWNrZXRzLiAgQW4gZXhhbXBsZSBzaG93cyBSU1ZQIFBBVEggbWVzc2FnZQphcyBhbiBpbXBs aWNpdCBwcm9iZS4gIEEgc2Vjb25kIGV4YW1wbGUgaGFzIGV4cGxpY2l0IHByb2JlIHBhY2tldHMs IHJlZ3VsYXIgCnByb2JpbmcsIHN0YXRlIHRyYW5zaXRpb25zIGJldHdlZW4gYWRtaXQgZmxvd3Ms IGFuZCBkbyBub3QgYWRtaXQgZmxvd3MuCgpTbGlkZSBvbiBiZW5lZml0cy4gTm90ZTogdGhlIHNj aGVtZSB3b3JrcyB3aXRoIG11bHRpcGF0aCBhbmQgc21hbGwgCmluZ3Jlc3MtZWdyZXNzIGFnZ3Jl Z2F0ZXMuCgo+IEJvYiBCcmlzY29lOiBvbmUgZG93bnNpZGUgLS0gdGhlIGZhY3QgdGhhdCB0aGUg dHlwZSBvZiBtYXJraW5nIGlzIHVuZGVyIHRoZQogIHNlbmRlcidzIGNvbnRyb2wgbWF5IG9wZW4g dXAgYW4gb3Bwb3J0dW5pdHkgZm9yIGFidXNlIGluIHRoZSBpbnRlci1kb21haW4gCiAgY2FzZS4K CgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tCm8gU2luZ2xlIFBDTi1UaHJlc2hvbGQtTWFya2luZyBVc2luZyBQQ04gQmFzZWxpbmUgRW5j b2RpbmcKICBkcmFmdC1zYXRvaC1wY24tU1QtbWFya2luZy0wMAoKRGFpc3VrZSBTYXRvaCBkaXNj dXNzZWQgaGlzIGRyYWZ0IG9uIFBDTiBzaW5nbGUgdGhyZXNob2xkIG1hcmtpbmcuCgpTbGlkZXM6 IGh0dHA6Ly93d3czLmlldGYub3JnL3Byb2NlZWRpbmdzLzA4bm92L3NsaWRlcy9wY24tNi5wZGYK ClRoZSBzY2hlbWUgdXNlcyB0aGUgYmFzZWxpbmUgZW5jb2RpbmcsIGFuZCBwcm92aWRlcyBleHBs aWNpdCBkZXRlY3Rpb24gb2YgCmZsb3dzIGV4Y2VlZGluZyB0aGUgYWRtaXNzaW9uIHRocmVzaG9s ZCBhbmQgc3VwcG9ydGFibGUgcmF0ZS4gIEl0IHVzZXMgYSAKcmF0aW8gbWFya2luZyBpbiB0aGUg c3RhdGUgYmV0d2VlbiBhZG1pc3NhYmxlIGFuZCBzdXBwb3J0YWJsZSByYXRlLiAgTWFya2luZyAK cmF0aW8gaXMgYmFzZWQgb24gdGhlIGRlZ3JlZSBvZiBmaWxsIG9mIHRoZSBtYXJraW5nIHRva2Vu IGJpY2tldC4gIE5vdGUgdGhhdCAKdGhlIG1hcmtpbmcgcmF0aW8gaXMgY3VtdWxhdGl2ZSBvdmVy IHRoZSBzdWNjZXNzaXZlIGxpbmtzIGluIHRoZSBwYXRoIC0tIApsb25nZXIgcGF0aHMgaW1wbHkg aGlnaGVyIG1hcmtpbmcgcmF0ZXMsIGFsbCBlbHNlIGJlaW5nIGVxdWFsLgoKVXNlIG9mIGEgc2Vj b25kIHRocmVzaG9sZCBhZGRzIGEgYnJlYWsgaW4gdGhlIGdyYXBoIG9mIG1hcmtpbmcgcmF0ZSB2 cy4gCmFycml2YWwgcmF0ZS4gIE1hcmtpbmcgb24vb2ZmIGJlaGF2aW91ciBhZGRzIGEgc2Vjb25k IGJyZWFrLgoKU2F0b2ggYWxzbyBkaXNjdXNzZWQgdGhlIGVkZ2UgYmVoYXZpb3VyIGZvciBmbG93 IHRlcm1pbmF0aW9uLgoKPiBCb2IgQnJpc2NvZTogYXNzdW1wdGlvbiB0aGF0IGFsbCBtYXJraW5n Z3MgZnJvbSBvbmUgcXVldWUgYXJlIGFzc29jaWF0ZWQgdG8KICB0aGUgc2FtZSBpbmdyZXNzLiAK ICAKU2F0b2ggYXNzdXJlZCB0aGF0IGFsbCBwYWNrZXRzIGFyZSBtYXJrZWQgaW4gZmxvdyB0ZXJt aW5hdGlvbiBzdGF0ZS4KQ29uY2x1ZGVkIHRoYXQgdGhlcmUgaXMgbm8gaXNzdWUuCgpUaGUgdGVy bWluYXRpb24gYWxnb3JpdGhtIHVzZXMgYW4gYWRkaXRpb25hbCB0ZXJtIHdpdGggZmFjdG9yIHkg dG8gZW5zdXJlIHRoYXQKdGVybWluYXRpb24gaXMgYnJvdWdodCBkb3duIHRvIHRoZSBzdXBwb3J0 YWJsZSByYXRlLCBub3QganVzdCBsaW5rIGNhcGFjaXR5LgoKPiBBbm5hIENoYXJueTogYXMgYWdy ZWVkIGluIGRpc2N1c3Npb24gTW9uZGF5LCBhZG1pc3Npb24gd2lsbCBiZSB0ZXJtaW5hdGVkCiAg ZXZlbiB3aGVuIG9wZXJhdGluZyBiZWxvdyBhZG1pc3Npb24gdGhyZXNob2xkIGlmIGZsb3dzIGFy ZSBidXJzdHkuICBTdWdnZXN0cwogIHRoYXQgdGhlIHRpbWUgaXQgdGFrZXMgdG8gdGVybWluYXRl IHNob3VsZCBiZSBhIGNyaXRlcmlvbiBmb3IgYXNzZXNzbWVudCBvZgogIHRoZSBhbGdvcml0aG0u ICBDaG9pY2Ugb2YgeSB0byBiYWxhbmNlIGJldHdlZW4gb3Zlci10ZXJtaW5hdGlvbiBhbmQgb3Zl ci0KICBzbG93IHRlcm1pbmF0aW9uIGlzIGRpZmZpY3VsdC4KCj4gQm9iIEJyaXNjb2U6IHF1ZXN0 aW9uIG9uIG1vdGl2YXRpb24uICBBcmUgeW91IG1vdGl2YXRlZCBieSBsYWNrIG9mCiAgY29kZXBv aW50cywgb3IgaXMgdGhlIHNjaGVtZSBzZWVuIGFzIHZhbHVhYmxlIG9uIGl0cyBvd24gbWVyaXRz PyAKICAKPiBQaGlsaXAgRWFyZGxleTogcmVwaHJhc2luZyB0aGUgcXVlc3Rpb24gLS0gd2l0aCBh ZGRpdGlvbmFsIGNvZGVwb2ludHMsIHRoZQogIHNjaGVtZSBjb3VsZCBzZWUgc2lnbmlmaWNhbnQg Y2hhbmdlLiAgCiAgClNhdG9oIGhhcyBubyB2aWV3IGF0IG1vbWVudCBvZiB3aGF0IGl0IHdvdWxk IGxvb2sgbGlrZSBpZiB0aGUgY29kaW5nIHNjaGVtZQphbGxvd2VkIGRlY291cGxpbmcgb2YgYWRt aXNzaW9uIGFuZCB0ZXJtaW5hdGlvbiBiZWhhdmlvdXJzLgoKPiBCb2IgQnJpc2NvZTogbW9yZSBp bnRlcmVzdGVkIGluIHdoZXRoZXIgdGhleSB3b3VsZCB1c2Ugc2luZ2xlIG1hcmtpbmcgYXQgYWxs CiAgaWYgbW9yZSBjb2RlcG9pbnRzIGF2YWlsYWJsZS4gCiAgCj4gQW5uYSBDaGFybnk6IGRpc2Fn cmVlIHdpdGggdGhpcyBmb3JtdWxhdGlvbi4gCgpTYXRvaCBhZ3JlZWQgdGhhdCBwZXJmb3JtYW5j ZSB3b3VsZCBpbXByb3ZlIHdpdGggMy1zdGF0ZSBlbmNvZGluZy4gIAoKPiBCb2IgQnJpc2NvZTog d2lsbCB0aGUgYWxnb3JpdGhtIHdvdWxkIGJlIHNpbXBsaWZpZWQ/IAoKPiBBbm5hIENoYXJueTog dGhlIGFsZ29yaXRobSBtaWdodCBzdGlsbCBzdGFuZCBvbiBpdHMgb3duIG1lcml0czsgc2hvdWxk IAogIGF1dG9tYXRpY2FsbHkgYXNzdW1lIHNpbmdsZSBtYXJraW5nLXR5cGUgYWxnb3JpdGhtcyBh cmUgbGVzcyBkZXNpcmFibGUgYW5kCiAgc2hvdWxkIGJlIHNldCBhc2lkZSBpZiBjb2RlcG9pbnRz IGFsbG93IGFsdGVybmF0aXZlcy4KCkNoYWlyIHJlcXVlc3RlZCBmdXJ0aGVyIGRpc2N1c3Npb24g b2YgdGhpcyBwb2ludCBvbiBsaXN0LgoKPiBQaGlsaXAgRWFyZGxleTogaXMgZnVydGhlciBiZWhh dmlvdXIgcmVxdWlyZWQ/IAoKPiBTdGV2ZW4gQmxha2U6IGJlbGlldmUgdGhhdCB0aGlzIGlzIHRo ZSB3aG9sZSBwYWNrYWdlLgoKPiBCb2IgQnJpc2NvZTogY2FuIGdldCBzeW5jaHJvbml6YXRpb24g YmVoYXZpb3VyIGluIGJ1Y2tldCB3aGVyZSB0aGUgc2FtZSAKICBwYWNrZXRzIGZvciB0aGUgc2Ft ZSBmbG93IHRlbmQgdG8gYXJyaXZlIHdoZW4gdGhlIGJ1Y2tldCBpcyBpbiB0aGUgc2FtZQogIHN0 YXRlLiAgR2V0IGJpYXNlZCBoYW5kbGluZyBvZiBmbG93cyBhcyBhIHJlc3VsdC4gIAogIAo+IE1h dHQgTWF0dGhpczogY2xhcmlmaWVkLCBwaWNrZWQtdXBvbiBmbG93cyBoYXZlIHRvIGdvIHRvIHRo ZSBzYW1lIGVncmVzcy4KClNhdG9oIG1lbnRpb25lZCB0aGF0IHRoZXJlIGlzIGFuIGVsZW1lbnQg b2YgcmFuZG9taXphdGlvbi4gCgo+IEJvYiBCcmlzY29lOiBidXQgdGhpcyBhc3N1bWVzIHJhbmRv bSB0cmFmZmljIC0tIG5vIHJhbmRvbWl6YXRpb24gaW4gCiAgYWxnb3JpdGhtLiAKICAKPiBNYXR0 IE1hdGhpczogaW4gZXh0cmVtZSBjYXNlLCB0aGUgc2FtZSBmbG93IHdvdWxkIGFsd2F5cyBiZSB0 aGUgb25lIG1hcmtlZC4KCj4gQW5uYSBDaGFybnk6IGlzIGEgbW9yZSBkZXRhaWxlZCBldmFsdWF0 aW9uIGF2YWlsYWJsZT8gCgpTYXRvaCBzYWlkIHllcyBmb3IgYWRtaXNzaW9uIGJlaGF2aW9yLCBu b3QgeWV0IGZvciB0ZXJtaW5hdGlvbiBiZWhhdmlvci4gCgo+IEFubmEgQ2hhcm55OiBzdW1taW5n IHVwIC0tIGEgbnVtYmVyIG9mIHBlcmZvbWFuY2UgY29uY2VybnMsIG5lZWQgbW9yZSBpbmZvCiAg YmVmb3JlIGNoYW5naW5nIHdoYXQgd2UgaGF2ZSBkb25lIHNvIGZhci4KCkNoYWlyIHJlcXVlc3Rl ZCBmdXRoZXIgZGlzY3Vzc2lvbiBvbiB0aGUgUENOIG1haWxpbmcgbGlzdC4KCgotLS0tLS0tLS0t LS0tLS0KbyBFQ04gVHVubmVsaW5nICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgQnJpc2NvZSAgMTAgbWluCiAgZHJhZnQtaWV0Zi10c3Z3Zy1lY24tdHVubmVs LTAxCgpCb2IgQnJpc2NvZSBwcmVzZW50ZWQgaGlzIFRTVldHIGRyYWZ0ICdMYXllcmVkIGVuY2Fw c3VsYXRpb24gb2YgY29uZ2VzdGlvbiAKbm90aWZpY2F0aW9uJy4KClNsaWRlczogaHR0cDovL3d3 dzMuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvMDhub3Yvc2xpZGVzL3Bjbi03LnBkZgoKVGhpcyBkcmFm dCBwcm9wb3NlcyBhIGNoYW5nZSBvZiBiZWhhdmlvdXIgb2YgYWxsIEVDTiB0dW5uZWxpbmcuICBO b3cgYSBUU1ZXRyAKZHJhZnQgaW4gVFNWV0cuIFF1ZXN0aW9uIHRvIHRoZSBQQ04gV0cgaXMgd2hl dGhlciB0byBhZGQgdG8gb3VyIHNjb3BlLiAgRHJhZnQKY3VycmVudGx5IGJyaW5ncyBub24tSVBz ZWMgdHVubmVsaW5nIGJlaGF2aW91ciBpbnRvIGxpbmUgd2l0aCBJUHNlYyBiZWhhdmlvdXIuClBy b3Bvc2VkIGZ1cnRoZXIgY2hhbmdlIG9mIGJlaGF2aW91ciBhdCBlZ3Jlc3MgaXMgY3VycmVudGx5 IGluIGFuIGFwcGVuZGl4LgpEbyB3ZSBuZWVkIHRvIG1ha2UgdGhpcyBub3JtYXRpdmU/ICBEbyB3 ZSBkbyBpdCBpbiB0aGUgc2FtZSBkcmFmdD8KCj4gTWF0dCBNYXRoaXM6IGFyZSB0aGVyZSBjb25z aWRlcmF0aW9ucyBvZiBkZXBsb3ltZW50IGNvc3RzPyAKCj4gQm9iIEJyaXNjb2U6IGNhbid0IHRo aW5rIG9mIGFueS4gIENhbiBtYWtlIG11Y2ggc2hvcnRlciBhcmd1bWVudCBiYXNlZCBvbiAKICBn b29kIHBvaW50cyBvZiB1bmNvbmRpdGlvbmFsIGJlaGF2aW91ci4gIEJhc2ljIHByaW5jaXBsZSBv ZiBwcm9wb3NlZCBlZ3Jlc3MKICBiZWhhdmlvdXI6IHByaW9yaXR5IHRvIHRoZSBoaWdoZXN0IHNl dmVyaXR5IG9mIG1hcmtpbmcuCiAKVGhlIGRyYWZ0IHNob3VsZCBiZSBkaXNjdXNzZWQgb24gdGhl IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0LgoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0K byBSZXRoaW5raW5nIFRDUC1mcmllbmRseQoKTWF0dCBNYXRoaXMgZGlzY3Vzc2VkIGEgcHJlc2Vu dGF0aW9uIGhlIHBsYW5zIHRvIG1ha2UgaW4gdGhlIFRTVkFSRUEgbWVldGluZwpsYXRlciB0aGlz IHdlZWsgKG5vIHNsaWRlcykuICBUaGUgb2JqZWN0aXZlIG9mIHRoZSBwcmVzZW50YXRpb24gdGhl cmUgaXMgCmFkdm9jYXRlIGZvciBtb3ZpbmcgcmVzcG9uc2liaWxpdHkgZm9yIGZhaXJuZXNzIGlu dG8gdGhlIG5ldHdvcmsuICBXaGF0IGlzIAp0aGUgb3ZlcmxhcCB3aXRoIFBDTiBpbnRlcmVzdHM/ Cgo+IEJvYiBCcmlzY29lOiBvbmUgb2YgdGhlIHJlc2VhcmNoIGFjdGl2aXRpZXMgaXMgZGVmaW5p bmcgd2hhdCBjb25nZXN0aW9uIAogIHNob3VsZCBiZS4KCgpNZWV0aW5nIGFkam91cm5lZCBhdCAx MTowMCBhbS4K --=_0981d5bca524478ea7db3c3bdc8a8e2d 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 --=_0981d5bca524478ea7db3c3bdc8a8e2d-- From pcn-bounces@ietf.org Mon Nov 24 21:57: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 DD1FA3A69BF; Mon, 24 Nov 2008 21:57:52 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B5DC3A69BF for ; Mon, 24 Nov 2008 21:57:51 -0800 (PST) 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 Le4hd7iD63ej for ; Mon, 24 Nov 2008 21:57:50 -0800 (PST) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 723213A6881 for ; Mon, 24 Nov 2008 21:57:50 -0800 (PST) Received: from cpe-071-077-048-187.nc.res.rr.com ([71.77.48.187]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1L4qvg-0001gH-EM for pcn@ietf.org; Tue, 25 Nov 2008 00:57:44 -0500 From: Steven Blake To: pcn@ietf.org In-Reply-To: <794e2263a060f550541ba6aa649af0a5@petri-meat.com> References: <794e2263a060f550541ba6aa649af0a5@petri-meat.com> Date: Tue, 25 Nov 2008 00:57:46 -0500 Message-Id: <1227592666.2126.0.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] IETF 73 **DRAFT** working group 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-11-25 at 00:28 -0500, slblake@petri-meat.com wrote: > I have uploaded the draft working group minutes from the Minneapolis PCN > meeting to: > > http://www.ietf.org/proceedings/08nov/minutes/pcn.txt > > They are also attached. Please send comments/corrections to the list this > week. And thanks to Tom Taylor for volunteering to take the meeting minutes! // Steve _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Nov 25 01:52: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 38A723A6AAD; Tue, 25 Nov 2008 01:52:34 -0800 (PST) X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13B293A6AAD for ; Tue, 25 Nov 2008 01:52:33 -0800 (PST) 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 TAUEPjuQqfbW for ; Tue, 25 Nov 2008 01:52:32 -0800 (PST) Received: from smtp126.rog.mail.re2.yahoo.com (smtp126.rog.mail.re2.yahoo.com [206.190.53.31]) by core3.amsl.com (Postfix) with SMTP id 243993A6B03 for ; Tue, 25 Nov 2008 01:52:31 -0800 (PST) Received: (qmail 21222 invoked from network); 25 Nov 2008 09:52:29 -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=atKSLYDPNUnwac0cYXwB67yMDiObaDLk2eyFzhoVxCqVGTGCnhB4UESNYCfWLVJAD1/TKRsk6Ch/0cfoe0LUWB3igt68PwGaF6OVs+Jszwm9oZzmkqaRq/LzpPVIgMTMOTQ9m2LGQc8kdWJqMpmyeRlurKeoZtVFKH5qku8Itlk= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@72.140.46.24 with plain) by smtp126.rog.mail.re2.yahoo.com with SMTP; 25 Nov 2008 09:52:29 -0000 X-YMail-OSG: 5QZlo54VM1mym3YbLqMFNmtHSdboXqs7FrRz5WJps5k4U3X14mhhj.2MIWCA1Fa5iw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <492BCAE0.9040907@rogers.com> Date: Tue, 25 Nov 2008 04:52:32 -0500 From: Tom Taylor User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) MIME-Version: 1.0 To: slblake@petri-meat.com References: <794e2263a060f550541ba6aa649af0a5@petri-meat.com> In-Reply-To: <794e2263a060f550541ba6aa649af0a5@petri-meat.com> Cc: pcn@ietf.org Subject: Re: [PCN] IETF 73 **DRAFT** working group 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 I can see one essential correction (apologies to Anna for missing some characters). Down in the discussion of the Satoh draft here is a quotation from Anna: > Anna Charny: the algorithm might still stand on its own merits; should automatically assume single marking-type algorithms are less desirable and should be set aside if codepoints allow alternatives. I expect that "should" on the first line should be a "shouldn't". _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn