From pcn-bounces@ietf.org Fri Jun 08 17:27:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwlzn-0006VI-Mt; Fri, 08 Jun 2007 17:27:47 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Hwlzm-0006VC-IU for pcn-confirm+ok@megatron.ietf.org; Fri, 08 Jun 2007 17:27:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hwlzl-0006V4-Qg for pcn@ietf.org; Fri, 08 Jun 2007 17:27:45 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hwlzk-0005o7-GP for pcn@ietf.org; Fri, 08 Jun 2007 17:27:45 -0400 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l58LUJO6001173 for ; Fri, 8 Jun 2007 16:30:19 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 16:27:43 -0500 Received: from [147.117.169.165] ([147.117.169.165]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Jun 2007 16:27:43 -0500 From: Steven Blake To: pcn Content-Type: text/plain Organization: Ericsson IP Infrastructure Date: Fri, 08 Jun 2007 17:27:43 -0400 Message-Id: <1181338063.3854.16.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2007 21:27:43.0696 (UTC) FILETIME=[D9B4E500:01C7AA13] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [PCN] Drafts for Chicago X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Another reminder: the I-D cut-off for -00 drafts for discussion at the Chicago IETF is July 2. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jun 12 10:28:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy7Lr-0003vH-5U; Tue, 12 Jun 2007 10:28:07 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Hy7Lq-0003tg-3X for pcn-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 10:28:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy7Lp-0003s5-Pn for pcn@ietf.org; Tue, 12 Jun 2007 10:28:05 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy7Lo-0007oO-FS for pcn@ietf.org; Tue, 12 Jun 2007 10:28:05 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 94FA57723 for ; Tue, 12 Jun 2007 16:28:01 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 8790178F2 for ; Tue, 12 Jun 2007 16:28:01 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 6AB607723 for ; Tue, 12 Jun 2007 16:28:01 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id l5CES1k12499 for ; Tue, 12 Jun 2007 16:28:01 +0200 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 42BB66F58E for ; Tue, 12 Jun 2007 16:22:51 +0200 (CEST) Message-ID: <466EAD50.20806@informatik.uni-wuerzburg.de> Date: Tue, 12 Jun 2007 16:27:28 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: pcn@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [PCN] rate measurement capabilities of today's routers X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi all, some proposals for a PCN architecture require the measurement of the rate of marked packets per ingeress-egress-aggregates at the egress nodes. Is that currently feasible in today's routers? If so, what is the minimum measurement interval (before EWMA smoothing is performed)? Kind regards, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jun 12 11:27:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy8He-0000jl-Rg; Tue, 12 Jun 2007 11:27:50 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Hy8Hd-0000jf-VE for pcn-confirm+ok@megatron.ietf.org; Tue, 12 Jun 2007 11:27:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hy8Hd-0000jX-Ln for pcn@ietf.org; Tue, 12 Jun 2007 11:27:49 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hy8Hc-0007NX-Ad for pcn@ietf.org; Tue, 12 Jun 2007 11:27:49 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 12 Jun 2007 08:27:47 -0700 X-IronPort-AV: i="4.16,412,1175497200"; d="scan'208"; a="163232366:sNHT2792521638" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5CFRk5Z007712; Tue, 12 Jun 2007 08:27:46 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5CFReai002549; Tue, 12 Jun 2007 15:27:46 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 08:27:36 -0700 Received: from [128.107.100.164] ([128.107.100.164]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jun 2007 08:27:36 -0700 In-Reply-To: <466EAD50.20806@informatik.uni-wuerzburg.de> References: <466EAD50.20806@informatik.uni-wuerzburg.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0E1903A0-7217-4B3C-90FF-0CFA24ABE82C@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [PCN] rate measurement capabilities of today's routers Date: Tue, 12 Jun 2007 08:27:35 -0700 To: menth@informatik.uni-wuerzburg.de X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Jun 2007 15:27:36.0503 (UTC) FILETIME=[3477E470:01C7AD06] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=476; t=1181662067; x=1182526067; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[PCN]=20rate=20measurement=20capabilities=20of=20toda y's=20routers |Sender:=20; bh=0xDabsSFLBoGXPXEuLlsYH7s2gRcCtUf2Grn+x/FEWw=; b=1Rvvp4HrofEuhJETfgUjUprHL6I74Dox64NGIeRjlvETWZmoKdY/IV5PfkzroOK82ssplvHP e9YYgz9wm1Zv7aG5qeKTFEu1duQBbXx4e2wqdwPxZx+96BPPbVNT2E/l; Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org On Jun 12, 2007, at 7:27 AM, Michael Menth wrote: > some proposals for a PCN architecture require the measurement of > the rate of marked packets per ingeress-egress-aggregates at the > egress nodes. Is that currently feasible in today's routers? If so, > what is the minimum measurement interval (before EWMA smoothing is > performed)? We have been doing it for a number of years. I'd suggest you look on www.cisco.com for our product specifications. _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Jun 14 03:14:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyjXe-0003cv-Jb; Thu, 14 Jun 2007 03:14:50 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1HyjXd-0003cn-Q2 for pcn-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 03:14:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyjXb-0003cO-VL for pcn@ietf.org; Thu, 14 Jun 2007 03:14:47 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HyjXa-0001Xt-72 for pcn@ietf.org; Thu, 14 Jun 2007 03:14:47 -0400 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 <0JJM00H7Z6RENG@szxga01-in.huawei.com> for pcn@ietf.org; Thu, 14 Jun 2007 15:14:02 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJM00IL36RDH5@szxga01-in.huawei.com> for pcn@ietf.org; Thu, 14 Jun 2007 15:14:02 +0800 (CST) Received: from y49667 ([10.111.12.75]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JJM00B7Q6RAOA@szxml03-in.huawei.com> for pcn@ietf.org; Thu, 14 Jun 2007 15:14:01 +0800 (CST) Date: Thu, 14 Jun 2007 15:13:57 +0800 From: Delei Yu Subject: RE: [PCN] rate measurement capabilities of today's routers In-reply-to: <0E1903A0-7217-4B3C-90FF-0CFA24ABE82C@cisco.com> To: 'Fred Baker' Message-id: <000001c7ae53$938209c0$4b0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcetBj5NFB6r8swwT/uvD90FW27SGgBSt2Ig X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org I have a question. At the Egress node of PCN domain, ingress-egress-aggregates traffic rate shall be measured. So an Egress node has to know which part of the traffic to the Egress is from a particular Ingress node. I mean, there is a mapping relation at the Egress node: Ingress Traffic A Traffic 1 Traffic 2 Traffic 3 B Traffic 4 Traffic 5 How to get this mapping relation? Configured by NMS? Using RSVP? > sender: Fred Baker [mailto:fred@cisco.com] > Re: [PCN] rate measurement capabilities of today's routers > > > On Jun 12, 2007, at 7:27 AM, Michael Menth wrote: > > > some proposals for a PCN architecture require the measurement of > > the rate of marked packets per ingeress-egress-aggregates at the > > egress nodes. Is that currently feasible in today's routers? If so, > > what is the minimum measurement interval (before EWMA smoothing is > > performed)? > > We have been doing it for a number of years. I'd suggest you look on > www.cisco.com for our product specifications. > > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Jun 14 09:11:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyp6O-0000dm-S4; Thu, 14 Jun 2007 09:11:04 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Hyp6M-0000dd-Pn for pcn-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 09:11:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hyp6M-0000dU-GJ for pcn@ietf.org; Thu, 14 Jun 2007 09:11:02 -0400 Received: from smtp4.smtp.bt.com ([217.32.164.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hyp6J-0005uQ-RP for pcn@ietf.org; Thu, 14 Jun 2007 09:11:02 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 14:10:59 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 14:10:58 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1181826658131; Thu, 14 Jun 2007 14:10:58 +0100 Received: from mut.jungle.bt.co.uk ([10.86.0.156]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l5EDApe7006481; Thu, 14 Jun 2007 14:10:54 +0100 Message-Id: <5.2.1.1.2.20070614134557.04246b00@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Thu, 14 Jun 2007 14:10:55 +0100 To: Steven Blake From: Bob Briscoe Subject: Re: [PCN] Drafts for Chicago In-Reply-To: <1181338063.3854.16.camel@neutrino> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -3.732 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 14 Jun 2007 13:10:58.0785 (UTC) FILETIME=[7312E510:01C7AE85] X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: "TAY, June" , pcn X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Steven, I've written/co-written three drafts motivated by PCN, but with more general applicability. So we're discussing them in tsvwg (one is already a WG draft) and we've asked to present all three in TSVWG at Chicago. Summary of each is pasted below - with brief explanation of the relevance to PCN. I'll try to always remember to cross-post if relevant to PCN. If you would like them presented in PCN too at Chicago, just say. I could do a 3-slide summary of all three in 5mins, and people could visit tsvwg if they wanted more. >1a/ "Layered Encapsulation of Congestion Notification" >Presenter: Bob Briscoe [in tsvwg] >draft-briscoe-tsvwg-ecn-tunnel-00 >New initial I-D (tba shortly) >2mins in PCN? [10mins reqested in tsvwg] This one specifies the default ECN encapsulation/decapsulation behaviour for any Diffserv per-hop behaviour (PHB), because RFC3168 tunnelling got broken by the new IPsec architecture (RFC4301). But it also gives general principles to guide the design of alternate congestion marking behaviours for specific PHBs (with PCN specifically in mind) and for lower layer congestion notification schemes (with PCN over MPLS/ethernet etc in mind). >1b/ "Explicit Congestion Marking in MPLS" >Presenter: Bruce Davie [in tsvwg] >draft-ietf-tsvwg-ecn-mpls-01.txt >Approaching WG last call >1min in PCN? [10mins req'd in tsvwg] Includes how to make room for PCN marking in the MPLS EXP field, and the rules for push and pop behaviour. >2/ "Byte and Packet Congestion Notification" >Presenter: Bob Briscoe [in tsvwg] >draft-briscoe-tsvwg-byte-pkt-mark-00 >New initial I-D (tba shortly) >2mins in PCN? [10mins req'd in tsvwg] This one proposes rules for how to handle different packet sizes when congestion marking, with PCN marking specifically in mind (in brief: allow for packet size in the transport/edge gateways, not in the network layer marking algo). Bob At 22:27 08/06/2007, Steven Blake wrote: >Another reminder: the I-D cut-off for -00 drafts for discussion at the >Chicago IETF is July 2. ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Jun 14 10:42:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyqWT-0002MK-QI; Thu, 14 Jun 2007 10:42:05 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1HyqWS-0002Ds-0d for pcn-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 10:42:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HyqWR-0002BP-La for pcn@ietf.org; Thu, 14 Jun 2007 10:42:03 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HyqWP-0001tR-VG for pcn@ietf.org; Thu, 14 Jun 2007 10:42:03 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 14 Jun 2007 07:42:01 -0700 X-IronPort-AV: i="4.16,421,1175497200"; d="scan'208"; a="379520557:sNHT55789404" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l5EEg1IE023292; Thu, 14 Jun 2007 07:42:01 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l5EEg120017917; Thu, 14 Jun 2007 14:42:01 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 07:42:00 -0700 Received: from [10.32.244.221] ([10.32.244.221]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jun 2007 07:42:00 -0700 In-Reply-To: <000001c7ae53$938209c0$4b0c6f0a@china.huawei.com> References: <000001c7ae53$938209c0$4b0c6f0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [PCN] rate measurement capabilities of today's routers Date: Thu, 14 Jun 2007 07:41:59 -0700 To: Delei Yu X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 14 Jun 2007 14:42:00.0536 (UTC) FILETIME=[2A87F580:01C7AE92] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1730; t=1181832121; x=1182696121; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[PCN]=20rate=20measurement=20capabilities=20of=20toda y's=20routers |Sender:=20; bh=hIe2jbayvOIOe4giZO58wbMQdHHCGr12r7+UgwSMYw4=; b=psuy1b9XRZKsxx7rT09Pcxs15MFcOcBBGNMKT+pOwCL5U+BtVCwgws7sqBkkarnvGwo7myCt OJhiQX3JmCFbL4nbSvqeHGaqVPaR8OFq+daVgwyNMBTD8NJ0e/kb3S54; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org I believe that PCN is intended to not use a signaling protocol. I don't see an obvious was to identify that actual ingress at the egress apart from the use of some form of tunnel (MPLS etc) from the ingress, which in the case would be "the other end of the tunnel". We don't mark traffic at ISP ingress (although we probably should, IMHO), and in a transit situation the traffic may have entered the network in a variety of places. On Jun 14, 2007, at 12:13 AM, Delei Yu wrote: > I have a question. > At the Egress node of PCN domain, ingress-egress-aggregates traffic > rate > shall be measured. So an Egress node has to know which part of the > traffic > to the Egress is from a particular Ingress node. I mean, there is a > mapping > relation at the Egress node: > Ingress Traffic > A Traffic 1 > Traffic 2 > Traffic 3 > B Traffic 4 > Traffic 5 > How to get this mapping relation? Configured by NMS? Using RSVP? > > >> sender: Fred Baker [mailto:fred@cisco.com] >> Re: [PCN] rate measurement capabilities of today's routers >> >> >> On Jun 12, 2007, at 7:27 AM, Michael Menth wrote: >> >>> some proposals for a PCN architecture require the measurement of >>> the rate of marked packets per ingeress-egress-aggregates at the >>> egress nodes. Is that currently feasible in today's routers? If so, >>> what is the minimum measurement interval (before EWMA smoothing is >>> performed)? >> >> We have been doing it for a number of years. I'd suggest you look on >> www.cisco.com for our product specifications. >> >> >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Jun 14 21:52:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz0zd-0005Gn-GU; Thu, 14 Jun 2007 21:52:53 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Hz0zb-0005Gf-C8 for pcn-confirm+ok@megatron.ietf.org; Thu, 14 Jun 2007 21:52:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hz0za-0005GU-Kq for pcn@ietf.org; Thu, 14 Jun 2007 21:52:50 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hz0zM-0008S4-As for pcn@ietf.org; Thu, 14 Jun 2007 21:52:50 -0400 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 <0JJN005AFMI23W@szxga01-in.huawei.com> for pcn@ietf.org; Fri, 15 Jun 2007 09:51:38 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JJN005Y2MI2BO@szxga01-in.huawei.com> for pcn@ietf.org; Fri, 15 Jun 2007 09:51:38 +0800 (CST) Received: from y49667 ([10.111.12.75]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JJN00GBFMHTR3@szxml04-in.huawei.com> for pcn@ietf.org; Fri, 15 Jun 2007 09:51:38 +0800 (CST) Date: Fri, 15 Jun 2007 09:51:29 +0800 From: Delei Yu Subject: RE: [PCN] rate measurement capabilities of today's routers In-reply-to: To: 'Fred Baker' Message-id: <001e01c7aeef$b45bf290$4b0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AceukitnpRv7nGhsRMeUxswMT2+Y4wAW+YQg X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org > I believe that PCN is intended to not use a signaling protocol. [Delei] I'm not sure about it. > I don't see an obvious was to identify that actual ingress at the > egress apart from the use of some form of tunnel (MPLS etc) from the > ingress, which in the case would be "the other end of the tunnel". We > don't mark traffic at ISP ingress (although we probably should, > IMHO), and in a transit situation the traffic may have entered the > network in a variety of places. [Delei] Tunnel is good solution for this problem. But what about in a non-tunnel scenario? In a route domain, How does egress node know a flow is come from ingress node A or B? Original information: > I have a question. > At the Egress node of PCN domain, ingress-egress-aggregates traffic > rate shall be measured. So an Egress node has to know which part of > the traffic to the Egress is from a particular Ingress node. I mean, > there is a mapping relation at the Egress node: > Ingress Traffic > A Traffic 1 > Traffic 2 > Traffic 3 > B Traffic 4 > Traffic 5 > How to get this mapping relation? Configured by NMS? Using RSVP? > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Jun 15 07:45:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzAEk-0003hR-GB; Fri, 15 Jun 2007 07:45:06 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1HzAEi-0003NT-Is for pcn-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 07:45:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzAEd-0002mN-Ih for pcn@ietf.org; Fri, 15 Jun 2007 07:44:59 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzAEc-0004NA-9H for pcn@ietf.org; Fri, 15 Jun 2007 07:44:59 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 15 Jun 2007 04:44:58 -0700 X-IronPort-AV: i="4.16,424,1175497200"; d="scan'208"; a="165764982:sNHT43847136" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l5FBivxt022878; Fri, 15 Jun 2007 04:44:57 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l5FBiv06029483; Fri, 15 Jun 2007 11:44:57 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 04:44:57 -0700 Received: from [10.32.244.221] ([10.32.244.221]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jun 2007 04:44:57 -0700 In-Reply-To: <001e01c7aeef$b45bf290$4b0c6f0a@china.huawei.com> References: <001e01c7aeef$b45bf290$4b0c6f0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [PCN] rate measurement capabilities of today's routers Date: Fri, 15 Jun 2007 04:44:47 -0700 To: Delei Yu X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 15 Jun 2007 11:44:57.0307 (UTC) FILETIME=[99019AB0:01C7AF42] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1330; t=1181907897; x=1182771897; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[PCN]=20rate=20measurement=20capabilities=20of=20toda y's=20routers |Sender:=20; bh=fWNVB4MCHVspb0xmx8jTeG9YM/oO0dx8zixglnmSyx8=; b=G84rXJbiTP/lf0MsOysyY1Rio7A2NqSFNm9pcbqyBdLdVSXvOymFfhp/AfT7QZl3InvCOq1s GVfExvXAzC0IiIYQXmPbkuLU6QBZZnSzqoN5raJnFYpNmzeucjqX8Akd; Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org As I said, in a network that doesn't connect ingress to egress, that can be hard to know. On Jun 14, 2007, at 6:51 PM, Delei Yu wrote: >> I believe that PCN is intended to not use a signaling protocol. > [Delei] I'm not sure about it. >> I don't see an obvious was to identify that actual ingress at the >> egress apart from the use of some form of tunnel (MPLS etc) from the >> ingress, which in the case would be "the other end of the tunnel". We >> don't mark traffic at ISP ingress (although we probably should, >> IMHO), and in a transit situation the traffic may have entered the >> network in a variety of places. > [Delei] Tunnel is good solution for this problem. But what about in a > non-tunnel scenario? In a route domain, How does egress node know a > flow is > come from ingress node A or B? > > Original information: >> I have a question. >> At the Egress node of PCN domain, ingress-egress-aggregates traffic >> rate shall be measured. So an Egress node has to know which part of >> the traffic to the Egress is from a particular Ingress node. I mean, >> there is a mapping relation at the Egress node: >> Ingress Traffic >> A Traffic 1 >> Traffic 2 >> Traffic 3 >> B Traffic 4 >> Traffic 5 >> How to get this mapping relation? Configured by NMS? Using RSVP? >> _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Fri Jun 15 08:00:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzATR-000495-Od; Fri, 15 Jun 2007 08:00:17 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1HzATQ-00048v-V2 for pcn-confirm+ok@megatron.ietf.org; Fri, 15 Jun 2007 08:00:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HzATQ-00048e-KX for pcn@ietf.org; Fri, 15 Jun 2007 08:00:16 -0400 Received: from smtp104.rog.mail.re2.yahoo.com ([206.190.36.82]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HzATP-0007Gk-Bx for pcn@ietf.org; Fri, 15 Jun 2007 08:00:16 -0400 Received: (qmail 34640 invoked from network); 15 Jun 2007 12:00:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=D5aXWQFNWdkPyw4CFu1G8aYmMWZ/GjoyqhyWtuMYj9IK7E+5SN43Sib1Bb+r9kScmO7nErzVk55m5pcPZns5gjk/33MqqxVqdb1Rf2LouWzSXUXzUH8OltJ/Q+5REozW4uXBhJDC3ugluhHSPZmrZk+d6Rf5DpRKaPfK5WEQoE8= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@rogers.com@74.105.35.229 with plain) by smtp104.rog.mail.re2.yahoo.com with SMTP; 15 Jun 2007 12:00:14 -0000 X-YMail-OSG: 4cxdzgEVM1k7kTOPlCfb2A8lmshdjx0f..hCci2UJ19gWGhGe9VZOUPQpgTs5rPhng-- Message-ID: <46727F4B.2040602@rogers.com> Date: Fri, 15 Jun 2007 08:00:11 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Fred Baker Subject: Re: [PCN] rate measurement capabilities of today's routers References: <000001c7ae53$938209c0$4b0c6f0a@china.huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org There may be some wiggle room in the charter -- the WG is allowed to provide requirements to other WGs. Fred Baker wrote: > I believe that PCN is intended to not use a signaling protocol. > > I don't see an obvious was to identify that actual ingress at the egress > apart from the use of some form of tunnel (MPLS etc) from the ingress, > which in the case would be "the other end of the tunnel". We don't mark > traffic at ISP ingress (although we probably should, IMHO), and in a > transit situation the traffic may have entered the network in a variety > of places. > ... _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sat Jun 16 14:19:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzcrk-000161-D8; Sat, 16 Jun 2007 14:19:16 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Hzcrj-00015v-Ho for pcn-confirm+ok@megatron.ietf.org; Sat, 16 Jun 2007 14:19:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hzcrj-00015n-8I for pcn@ietf.org; Sat, 16 Jun 2007 14:19:15 -0400 Received: from smtp3.smtp.bt.com ([217.32.164.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HzcrO-0004sI-Nt for pcn@ietf.org; Sat, 16 Jun 2007 14:19:15 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Jun 2007 19:18:54 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 16 Jun 2007 19:18:53 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1182017931810; Sat, 16 Jun 2007 19:18:51 +0100 Received: from mut.jungle.bt.co.uk ([10.86.0.10]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l5GIIiEj018126; Sat, 16 Jun 2007 19:18:48 +0100 Message-Id: <5.2.1.1.2.20070616185907.04431a48@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Sat, 16 Jun 2007 19:18:47 +0100 To: Steven Blake From: Bob Briscoe Subject: PCN for multidomain (was: [PCN] Drafts for Chicago) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.648 () ALL_TRUSTED,AWL,BAYES_00,MIME_QP_LONG_LINE X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 16 Jun 2007 18:18:53.0316 (UTC) FILETIME=[CB941C40:01C7B042] X-Spam-Score: 0.1 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: pcn X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Steven, I forgot, there's a 4th PCN-related draft I plan to update before Chicago=20 (link below). It's outside the scope of the current charter, being about interconnection= =20 of multiple PCN domains. But as that subject is explicitly down to "keep strongly in mind" for next= =20 rechartering, I assume it's OK to at least bring it to the w-g's attention. This doc is designed to help in discussions about mark encoding. So I'm=20 willing to present it within the PCN w-g whenever we get to that point in=20 the discussions. A number of people have suggested we should have an unofficial side mtg in= =20 Chicago about PCN for multi-domain. Would that be useful? Or do you (the=20 co-chairs) want to keep this within the w-g session? Whatever, so I get an idea of numbers, would anyone interested in=20 multidomain (other than those who already met in Prague or sent apologies)= =20 pls contact me (I'm away from mail for a week so don't expect an immediate= =20 reply). ------- The current version recently expired, but you can get it from my pubs page. "Emulating Border Flow Policing using Re-ECN on Bulk Data" draft-briscoe-tsvwg-re-ecn-border-cheat-01 If I get it done before the -00 deadline I'll change its name to draft-briscoe-re-pcn-border-cheat-00 Bob >Date: Thu, 14 Jun 2007 14:10:55 +0100 >To: Steven Blake >From: Bob Briscoe >Subject: Re: [PCN] Drafts for Chicago >Cc: pcn , "DAVIE, Bruce" , "TAY, June"=20 > >Bcc: =83\Charging\design\PCN > >Steven, > >I've written/co-written three drafts motivated by PCN, but with more=20 >general applicability. So we're discussing them in tsvwg (one is already a= =20 >WG draft) and we've asked to present all three in TSVWG at Chicago. > >Summary of each is pasted below - with brief explanation of the relevance= =20 >to PCN. > >I'll try to always remember to cross-post if relevant to PCN. > >If you would like them presented in PCN too at Chicago, just say. I could= =20 >do a 3-slide summary of all three in 5mins, and people could visit tsvwg=20 >if they wanted more. > >>1a/ "Layered Encapsulation of Congestion Notification" >>Presenter: Bob Briscoe [in tsvwg] >>draft-briscoe-tsvwg-ecn-tunnel-00 >>New initial I-D (tba shortly) >>2mins in PCN? [10mins reqested in tsvwg] > >This one specifies the default ECN encapsulation/decapsulation behaviour=20 >for any Diffserv per-hop behaviour (PHB), because RFC3168 tunnelling got=20 >broken by the new IPsec architecture (RFC4301). But it also gives general= =20 >principles to guide the design of alternate congestion marking behaviours= =20 >for specific PHBs (with PCN specifically in mind) and for lower layer=20 >congestion notification schemes (with PCN over MPLS/ethernet etc in mind). > >>1b/ "Explicit Congestion Marking in MPLS" >>Presenter: Bruce Davie [in tsvwg] >>draft-ietf-tsvwg-ecn-mpls-01.txt >>Approaching WG last call >>1min in PCN? [10mins req'd in tsvwg] > >Includes how to make room for PCN marking in the MPLS EXP field, and the=20 >rules for push and pop behaviour. > >>2/ "Byte and Packet Congestion Notification" >>Presenter: Bob Briscoe [in tsvwg] >>draft-briscoe-tsvwg-byte-pkt-mark-00 >>New initial I-D (tba shortly) >>2mins in PCN? [10mins req'd in tsvwg] > >This one proposes rules for how to handle different packet sizes when=20 >congestion marking, with PCN marking specifically in mind (in brief: allow= =20 >for packet size in the transport/edge gateways, not in the network layer=20 >marking algo). > > >Bob > >At 22:27 08/06/2007, Steven Blake wrote: >>Another reminder: the I-D cut-off for -00 drafts for discussion at the >>Chicago IETF is July 2. > >___________________________________________________________________________= _ >Notice: This contribution is the personal view of the author and does not= =20 >necessarily reflect the technical nor commercial direction of BT plc. >___________________________________________________________________________= _ >Bob Briscoe, Networks Research Centre, BT= Research >B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473= 645196 ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196= =20 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Sun Jun 17 23:49:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I08FP-0000f3-EP; Sun, 17 Jun 2007 23:49:47 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1I08FO-0000eu-6T for pcn-confirm+ok@megatron.ietf.org; Sun, 17 Jun 2007 23:49:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I08FN-0000el-T3 for pcn@ietf.org; Sun, 17 Jun 2007 23:49:45 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I08FL-0001Uv-I1 for pcn@ietf.org; Sun, 17 Jun 2007 23:49:45 -0400 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5I3nZI02283; Mon, 18 Jun 2007 03:49:36 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] rate measurement capabilities of today's routers Date: Sun, 17 Jun 2007 23:49:35 -0400 Message-ID: <9671A92C3C8B5744BC97F855F7CB646510D11AAC@zcarhxm1.corp.nortel.com> In-Reply-To: <001e01c7aeef$b45bf290$4b0c6f0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] rate measurement capabilities of today's routers Thread-Index: AceukitnpRv7nGhsRMeUxswMT2+Y4wAW+YQgAJlXAzA= From: "Jozef Babiarz" To: "Delei Yu" , "Fred Baker" X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org I'm not sure if I understand the question, but here goes. There are several different scenarios for PCN. Currently the charter focus on defining the metering and marking approach and its use in single domain, network edge to network edge deployment. PCN requires that the marking information observed at the egress network node somehow gets back to the correct ingress network node. For non-tunnel flows, one approach is to use signalling between ingress and egress nodes to establish and exchange flow information. My understanding is that it is in scope of the PCN charter for the WG to define signalling requirements for PCN. As well there are deployment models where ingress edge network node is the IP source and egress is the destination. After re-chartering, hopefully the WG will work on solution for end-to-end admission control using PCN. Regards, Joe email:babiarz@nortel.com Telephone:613-763-6098 -----Original Message----- From: Delei Yu [mailto:yudelei@huawei.com]=20 Sent: June 14, 2007 9:51 PM To: 'Fred Baker' Cc: pcn@ietf.org Subject: RE: [PCN] rate measurement capabilities of today's routers > I believe that PCN is intended to not use a signaling protocol. [Delei] I'm not sure about it. > I don't see an obvious was to identify that actual ingress at the=20 > egress apart from the use of some form of tunnel (MPLS etc) from the=20 > ingress, which in the case would be "the other end of the tunnel". We=20 > don't mark traffic at ISP ingress (although we probably should, IMHO), > and in a transit situation the traffic may have entered the network in > a variety of places. [Delei] Tunnel is good solution for this problem. But what about in a non-tunnel scenario? In a route domain, How does egress node know a flow is come from ingress node A or B? Original information: > I have a question. > At the Egress node of PCN domain, ingress-egress-aggregates traffic=20 > rate shall be measured. So an Egress node has to know which part of=20 > the traffic to the Egress is from a particular Ingress node. I mean,=20 > there is a mapping relation at the Egress node: > Ingress Traffic > A Traffic 1 > Traffic 2 > Traffic 3 > B Traffic 4 > Traffic 5 > How to get this mapping relation? Configured by NMS? Using RSVP? > _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jun 19 17:10:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ky1-0005wn-1b; Tue, 19 Jun 2007 17:10:25 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1I0ky0-0005vt-69 for pcn-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 17:10:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0kxz-0005oI-4r for pcn@ietf.org; Tue, 19 Jun 2007 17:10:23 -0400 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0kxx-0003ld-Or for pcn@ietf.org; Tue, 19 Jun 2007 17:10:23 -0400 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id l5JLBrwj014218; Tue, 19 Jun 2007 16:11:53 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 16:10:20 -0500 Received: from [147.117.169.165] ([147.117.169.165]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 16:10:20 -0500 Subject: Re: [PCN] rate measurement capabilities of today's routers From: Steven Blake To: Fred Baker In-Reply-To: References: <000001c7ae53$938209c0$4b0c6f0a@china.huawei.com> Content-Type: text/plain Organization: Ericsson IP Infrastructure Date: Tue, 19 Jun 2007 17:10:12 -0400 Message-Id: <1182287412.3856.45.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jun 2007 21:10:20.0347 (UTC) FILETIME=[3E5DB8B0:01C7B2B6] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org On Thu, 2007-06-14 at 09:41 -0500, Fred Baker wrote: > I believe that PCN is intended to not use a signaling protocol. The PCN charter is (intentionally?) vague here: = Description of Working Group: = = The Congestion and Pre-Congestion Notification (PCN) working group = develops mechanisms to protect the quality-of-service of established = inelastic flows within a DiffServ domain when congestion is imminent = or existing. These mechanisms operate at the domain boundary, based = on aggregated congestion and pre-congestion information from within = the domain. I note that the "S" word is never used in the charter, except to identify the following milestone: = Mar 2008 Submit "Requirements for Signaling of (Pre-)Congestion = Information from Egress to Ingress in a DiffServ Domain" = to the IESG for consideration as a Informational RFC > I don't see an obvious was to identify that actual ingress at the > egress apart from the use of some form of tunnel (MPLS etc) from the > ingress, which in the case would be "the other end of the tunnel". We > don't mark traffic at ISP ingress (although we probably should, > IMHO), and in a transit situation the traffic may have entered the > network in a variety of places. Agreed. Absent signaled microflows, or some form of ingress->egress tunneling, then it seems that ACLs on the egress would have to be used. Not fun. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Tue Jun 19 17:19:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0l7B-0008QW-OO; Tue, 19 Jun 2007 17:19:53 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1I0l7A-0008Q1-PF for pcn-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 17:19:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0l7A-0008Pr-Fg for pcn@ietf.org; Tue, 19 Jun 2007 17:19:52 -0400 Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0l79-0005yI-2T for pcn@ietf.org; Tue, 19 Jun 2007 17:19:52 -0400 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id l5JLMtQa008131; Tue, 19 Jun 2007 16:22:55 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 16:19:49 -0500 Received: from [147.117.169.165] ([147.117.169.165]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Jun 2007 16:19:49 -0500 Subject: Re: PCN for multidomain (was: [PCN] Drafts for Chicago) From: Steven Blake To: Bob Briscoe In-Reply-To: <5.2.1.1.2.20070616185907.04431a48@pop3.jungle.bt.co.uk> References: <5.2.1.1.2.20070616185907.04431a48@pop3.jungle.bt.co.uk> Content-Type: text/plain Organization: Ericsson IP Infrastructure Date: Tue, 19 Jun 2007 17:19:48 -0400 Message-Id: <1182287988.3856.54.camel@neutrino> Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jun 2007 21:19:49.0213 (UTC) FILETIME=[916FC8D0:01C7B2B7] X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: pcn X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org On Sat, 2007-06-16 at 19:18 +0100, Bob Briscoe wrote: > Steven, > > I forgot, there's a 4th PCN-related draft I plan to update before Chicago > (link below). > > It's outside the scope of the current charter, being about interconnection > of multiple PCN domains. > > But as that subject is explicitly down to "keep strongly in mind" for next > rechartering, I assume it's OK to at least bring it to the w-g's attention. > > This doc is designed to help in discussions about mark encoding. So I'm > willing to present it within the PCN w-g whenever we get to that point in > the discussions. > > A number of people have suggested we should have an unofficial side mtg in > Chicago about PCN for multi-domain. Would that be useful? Or do you (the > co-chairs) want to keep this within the w-g session? > > Whatever, so I get an idea of numbers, would anyone interested in > multidomain (other than those who already met in Prague or sent apologies) > pls contact me (I'm away from mail for a week so don't expect an immediate > reply). > > ------- > The current version recently expired, but you can get it from my pubs page. > > "Emulating Border Flow Policing using Re-ECN on Bulk Data" > > draft-briscoe-tsvwg-re-ecn-border-cheat-01 > > If I get it done before the -00 deadline I'll change its name to > draft-briscoe-re-pcn-border-cheat-00 > > > > Bob I'm sorry to be blunt, but people who are worried about what PCN is going to work on after it gets rechartered need to refocus on achieving PCN's existing milestones under the current charter. Progress on this front, as gauged by what has been published or discussed on the list since Prague, is not encouraging. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven Blake Ericsson/Redback Networks +1 919-472-9913 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jun 20 02:40:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0trp-0002eu-A4; Wed, 20 Jun 2007 02:40:37 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1I0trn-0002eR-3m for pcn-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 02:40:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0trm-0002eJ-EE for pcn@ietf.org; Wed, 20 Jun 2007 02:40:34 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0trl-0000Ha-SE for pcn@ietf.org; Wed, 20 Jun 2007 02:40:34 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E881220830 for ; Wed, 20 Jun 2007 08:40:32 +0200 (CEST) X-AuditID: c1b4fb3c-b1681bb0000007e1-50-4678cbe0f81b Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id CD3212082E for ; Wed, 20 Jun 2007 08:40:32 +0200 (CEST) Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 08:40:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Egress state options [Was: RE: [PCN] rate measurement capabilities of today's routers] Date: Wed, 20 Jun 2007 08:40:31 +0200 Message-ID: <63A23507A6F0C344BE6D60303E9441D901F9A324@esealmw114.eemea.ericsson.se> In-Reply-To: <1182287412.3856.45.camel@neutrino> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Egress state options [Was: RE: [PCN] rate measurement capabilities of today's routers] Thread-Index: AceytkRBJL5gdyMuQnyewArLw2JYrgAS3QmQ References: <000001c7ae53$938209c0$4b0c6f0a@china.huawei.com> <1182287412.3856.45.camel@neutrino> From: =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r_=28IJ/ETH=29?= To: X-OriginalArrivalTime: 20 Jun 2007 06:40:32.0581 (UTC) FILETIME=[E6725750:01C7B305] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org >> I don't see an obvious was to identify that actual ingress at the >> egress apart from the use of some form of tunnel (MPLS etc) from the >> ingress, which in the case would be "the other end of the tunnel". We >> don't mark traffic at ISP ingress (although we probably should, >> IMHO), and in a transit situation the traffic may have entered the >> network in a variety of places. >=20 > Agreed. Absent signaled microflows, or some form of ingress->egress > tunneling, then it seems that ACLs on the egress would have to be > used. =20 > Not fun. We seem to have the following "options" at the moment: 1) Egress infers ingress from routing and packet header: generally = cannot be done. ;-) 2) Some form of signalling. In this case, care must be taken with = re-routing situations affecting the egress router itself. In some cases, = the egress router itself may change, in which case the ingress router = should have some very quick(*) means to update the states in the egress = routers! (Preferably before the egress finished measuring the marked = packet rate...) Otherwise, the non-re-routed flows will be notified as = the egress has no ingress ID for the re-routed flows. 3) Some form of ingress-egress tunnelling. This elliminates the previous = problem. Has the disadvantage of tunnell interface/addressing = configuration potentially between each pair of edge routers. Unless, = some automatic tunnelling mechanism is proposed. 4) ACLs. Has the disadvantage of a lot of configuration. Also, preparing = for a change of egress node due to re-routing seems unfeasible. Some automatic tunnelling essentially piggybacks the ingress ID onto = each packet. Couldn't we do it with less overhead? With some IP header = option, whatever? (*) How quick congestion notification/handling is PCN targeting? What is = the timescale? I'm asking because for some applications, users are = stopping their sessions after a few seconds of bad quality. The routing = convergence time should also be taken into account. BTW, if we are at routing, some fast re-route proposals are able to / = need to identify re-routed packets. Couldn't PCN use such extra = knowledge as well? Kind regards, Andr=E1s _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jun 20 03:07:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0uHq-0005CT-Tr; Wed, 20 Jun 2007 03:07:30 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1I0uHp-0005CL-98 for pcn-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 03:07:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0uHl-0005C7-IX for pcn@ietf.org; Wed, 20 Jun 2007 03:07:25 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0uHl-0008Kk-4R for pcn@ietf.org; Wed, 20 Jun 2007 03:07:25 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 20 Jun 2007 09:07:21 +0200 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 09:07:21 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Egress state options [Was: RE: [PCN] rate measurement capabilities oftoday's routers] Date: Wed, 20 Jun 2007 09:07:20 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED201DB978C@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <63A23507A6F0C344BE6D60303E9441D901F9A324@esealmw114.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Egress state options [Was: RE: [PCN] rate measurementcapabilities of today's routers] Thread-Index: AceytkRBJL5gdyMuQnyewArLw2JYrgAS3QmQAAEySsA= From: "Geib, Ruediger" To: X-OriginalArrivalTime: 20 Jun 2007 07:07:21.0460 (UTC) FILETIME=[A569CB40:01C7B309] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Andras, |1) Egress infers ingress from routing and packet header:=20 |generally cannot be done. ;-) Without being a routing expert I must say that Intra Domain=20 Routing results in every router to store the complete=20 topology of its own domain. Some IP reroute optimisations=20 discuss application of this topology awareness. May be a=20 closer look is useful? |2) Some form of signalling. In this case, care must be taken=20 |with re-routing situations affecting the egress router itself.=20 |In some cases, the egress router itself may change, in which=20 |case the ingress router should have some very quick(*) means=20 |to update the states in the egress routers! (Preferably before=20 |the egress finished measuring the marked packet rate...)=20 |Otherwise, the non-re-routed flows will be notified as the=20 |egress has no ingress ID for the re-routed flows. Admission Control should work in the case of rerouting.=20 Preemption may not work properly as indeed the ingress can=20 only preempt the per flow reservations whose egress nodes=20 it knows. |3) Some form of ingress-egress tunnelling. This elliminates=20 |the previous problem. Has the disadvantage of tunnell=20 |interface/addressing configuration potentially between each=20 |pair of edge routers. Unless, some automatic tunnelling=20 |mechanism is proposed. Tunnels certainly work, but I hope that PCN finds a way to=20 get around them. |4) ACLs. Has the disadvantage of a lot of configuration. Also,=20 |preparing for a change of egress node due to re-routing seems=20 |unfeasible. | |Some automatic tunnelling essentially piggybacks the ingress=20 |ID onto each packet. Couldn't we do it with less overhead?=20 |With some IP header option, whatever? | |(*) How quick congestion notification/handling is PCN=20 |targeting? What is the timescale? I'm asking because for some=20 |applications, users are stopping their sessions after a few=20 |seconds of bad quality. The routing convergence time should=20 |also be taken into account. | |BTW, if we are at routing, some fast re-route proposals are=20 |able to / need to identify re-routed packets. Couldn't PCN use=20 |such extra knowledge as well? | |Kind regards, |Andr=E1s | | |_______________________________________________ |PCN mailing list |PCN@ietf.org |https://www1.ietf.org/mailman/listinfo/pcn | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jun 20 03:30:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ue9-0007qU-Rq; Wed, 20 Jun 2007 03:30:33 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1I0ue8-0007qG-FO for pcn-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 03:30:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ue8-0007q8-2w for pcn@ietf.org; Wed, 20 Jun 2007 03:30:32 -0400 Received: from mailgw4.ericsson.se ([193.180.251.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0ue6-0007W4-DJ for pcn@ietf.org; Wed, 20 Jun 2007 03:30:32 -0400 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id A92F421171; Wed, 20 Jun 2007 09:30:29 +0200 (CEST) X-AuditID: c1b4fb3e-b0835bb0000007e1-30-4678d7957f8b Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 86EDA2009D; Wed, 20 Jun 2007 09:30:29 +0200 (CEST) Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 09:30:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Egress state options [Was: RE: [PCN] rate measurement capabilities oftoday's routers] Date: Wed, 20 Jun 2007 09:30:28 +0200 Message-ID: <63A23507A6F0C344BE6D60303E9441D901F9A421@esealmw114.eemea.ericsson.se> In-Reply-To: <6439282641581441A36F7F6F83ED2ED201DB978C@S4DE8PSAAFQ.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Egress state options [Was: RE: [PCN] rate measurement capabilities oftoday's routers] Thread-Index: AceytkRBJL5gdyMuQnyewArLw2JYrgAS3QmQAAEySsAAARprUA== References: <63A23507A6F0C344BE6D60303E9441D901F9A324@esealmw114.eemea.ericsson.se> <6439282641581441A36F7F6F83ED2ED201DB978C@S4DE8PSAAFQ.mitte.t-com.de> From: =?iso-8859-1?Q?Andr=E1s_Cs=E1sz=E1r_=28IJ/ETH=29?= To: "Geib, Ruediger" X-OriginalArrivalTime: 20 Jun 2007 07:30:29.0335 (UTC) FILETIME=[E0A6B670:01C7B30C] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi! >> 1) Egress infers ingress from routing and packet header: >> generally cannot be done. ;-) >=20 > Without being a routing expert I must say that Intra Domain Routing > results in every router to store the complete topology of its own > domain. Some IP reroute optimisations discuss application of this > topology awareness. May be a closer look is useful? In those cases, where the packet is not coming from an other AS and you = know the whole topology, this could work. I'm not so sure whether you can always infer the ingress if within the = domain there are (e.g. OSPF) areas. And if you receive the packet from another network, you cannot always = infer the incoming ingress. You can do it if you advertise the = destination prefix with BGP through only one incoming router :-) >> 2) Some form of signalling. In this case, care must be taken with >> re-routing situations affecting the egress router itself. >> In some cases, the egress router itself may change, in which case the >> ingress router should have some very quick(*) means to update the >> states in the egress routers! (Preferably before the egress finished >> measuring the marked packet rate...) Otherwise, the non-re-routed >> flows will be notified as the egress has no ingress ID for the >> re-routed flows. >=20 > Admission Control should work in the case of rerouting. > Preemption may not work properly as indeed the ingress can only > preempt the per flow reservations whose egress nodes it knows. Without per-flow states in the interior, you cannot rely on admission = control immediately after re-routing because the router cannot = (normally) differentiate re-routed flows from original flows. In my = understanding, specifically after re-routing you have to use = pre-emption. For instance, the problem statement draft writes: "Pre-Congestion Notification (PCN) investigates the use of per-flow = admission control to provide the required service guarantees for the = admitted traffic. While admission control will protect the QoS under = normal operating conditions, an additional flow pre-emption mechanism is = necessary in the times of heavy congestion (e.g. caused by route changes = due to link or node failure)." Or do I miss something? Can you elaborate on how you think admission = control can be used in case of re-routing? >> 3) Some form of ingress-egress tunnelling. This elliminates the >> previous problem. Has the disadvantage of tunnell >> interface/addressing configuration potentially between each pair of >> edge routers. Unless, some automatic tunnelling mechanism is >> proposed.=20 >=20 > Tunnels certainly work, but I hope that PCN finds a way to get around > them.=20 Me, too :-) _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jun 20 03:45:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0usj-0001v3-Ge; Wed, 20 Jun 2007 03:45:37 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1I0usi-0001up-AJ for pcn-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 03:45:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0ush-0001uh-VP for pcn@ietf.org; Wed, 20 Jun 2007 03:45:35 -0400 Received: from wrzx28.rz.uni-wuerzburg.de ([132.187.3.28] helo=mailrelay.rz.uni-wuerzburg.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0usg-0003Ta-GS for pcn@ietf.org; Wed, 20 Jun 2007 03:45:35 -0400 Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id B4F3D6FBF; Wed, 20 Jun 2007 09:45:31 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id A70EE780E; Wed, 20 Jun 2007 09:45:31 +0200 (CEST) Received: from europa.informatik.uni-wuerzburg.de (wicx01.informatik.uni-wuerzburg.de [132.187.11.1]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 70D436FBF; Wed, 20 Jun 2007 09:45:31 +0200 (CEST) Received: from nero.informatik.uni-wuerzburg.de (win3005.informatik.uni-wuerzburg.de [132.187.106.5]) by europa.informatik.uni-wuerzburg.de (8.11.3/8.11.2/SuSE Linux 8.11.1-0.5) with ESMTP id l5K7jVk19824; Wed, 20 Jun 2007 09:45:31 +0200 Received: from [127.0.0.1] (nero.informatik.uni-wuerzburg.de [132.187.106.5]) by nero.informatik.uni-wuerzburg.de (Postfix) with ESMTP id 701BE6F58E; Wed, 20 Jun 2007 09:40:13 +0200 (CEST) Message-ID: <4678DA87.1010501@informatik.uni-wuerzburg.de> Date: Wed, 20 Jun 2007 09:43:03 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: =?ISO-8859-1?Q?=22Andr=E1s_Cs=E1sz=E1r_=28IJ/ETH=29=22?= Subject: Re: Egress state options [Was: RE: [PCN] rate measurement capabilities oftoday's routers] References: <63A23507A6F0C344BE6D60303E9441D901F9A324@esealmw114.eemea.ericsson.se> <6439282641581441A36F7F6F83ED2ED201DB978C@S4DE8PSAAFQ.mitte.t-com.de> <63A23507A6F0C344BE6D60303E9441D901F9A421@esealmw114.eemea.ericsson.se> In-Reply-To: <63A23507A6F0C344BE6D60303E9441D901F9A421@esealmw114.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: pcn@ietf.org, "Geib, Ruediger" X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi, >> Admission Control should work in the case of rerouting. >> Preemption may not work properly as indeed the ingress can only >> preempt the per flow reservations whose egress nodes it knows. >> > > Without per-flow states in the interior, you cannot rely on admission control immediately after re-routing because the router cannot (normally) differentiate re-routed flows from original flows. In my understanding, specifically after re-routing you have to use pre-emption. > > For instance, the problem statement draft writes: > "Pre-Congestion Notification (PCN) investigates the use of per-flow admission control to provide the required service guarantees for the admitted traffic. While admission control will protect the QoS under normal operating conditions, an additional flow pre-emption mechanism is necessary in the times of heavy congestion (e.g. caused by route changes due to link or node failure)." > > Or do I miss something? Can you elaborate on how you think admission control can be used in case of re-routing? > The gap between the admissible rate (where admission stops) and the supportable rate (where termination starts) can be used as backup capacity such that no admitted traffic is lost in case of re-routing provided that the admissible and supporable rate thresholds of the links are properly configured. See: http://www3.informatik.uni-wuerzburg.de/~menth/Publications/Menth07i.pdf We covered the fact that traffic is rerouted within the network, but not to another egress router. However, this can also be respected. Regards, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jun 20 03:49:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0uwX-0000ml-GV; Wed, 20 Jun 2007 03:49:33 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1I0uwW-0000mf-Ui for pcn-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 03:49:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0uwW-0000mW-FT for pcn@ietf.org; Wed, 20 Jun 2007 03:49:32 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0uwW-0004yx-0x for pcn@ietf.org; Wed, 20 Jun 2007 03:49:32 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 20 Jun 2007 09:49:30 +0200 Received: from S4DE8PSAAFQ.mitte.t-com.de ([10.151.180.5]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 09:49:30 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Egress state options [Was: RE: [PCN] rate measurement capabilities oftoday's routers] Date: Wed, 20 Jun 2007 09:49:29 +0200 Message-Id: <6439282641581441A36F7F6F83ED2ED201DB9790@S4DE8PSAAFQ.mitte.t-com.de> In-Reply-To: <63A23507A6F0C344BE6D60303E9441D901F9A421@esealmw114.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Egress state options [Was: RE: [PCN] rate measurement capabilities oftoday's routers] Thread-Index: AceytkRBJL5gdyMuQnyewArLw2JYrgAS3QmQAAEySsAAARprUAAAkiKg From: "Geib, Ruediger" To: X-OriginalArrivalTime: 20 Jun 2007 07:49:30.0248 (UTC) FILETIME=[88B03880:01C7B30F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Andras, |>> 1) Egress infers ingress from routing and packet header: |>> generally cannot be done. ;-) |>=20 |> Without being a routing expert I must say that Intra Domain Routing |> results in every router to store the complete topology of its own |> domain. Some IP reroute optimisations discuss application of this |> topology awareness. May be a closer look is useful? | |In those cases, where the packet is not coming from an other=20 |AS and you know the whole topology, this could work. | |I'm not so sure whether you can always infer the ingress if=20 |within the domain there are (e.g. OSPF) areas. | |And if you receive the packet from another network, you cannot=20 |always infer the incoming ingress. You can do it if you=20 |advertise the destination prefix with BGP through only one=20 |incoming router :-) Thanks, that's a more differentiated statement than your first one. |>> 2) Some form of signalling. In this case, care must be taken with |>> re-routing situations affecting the egress router itself. |>> In some cases, the egress router itself may change, in=20 |which case the |>> ingress router should have some very quick(*) means to update the |>> states in the egress routers! (Preferably before the egress finished |>> measuring the marked packet rate...) Otherwise, the non-re-routed |>> flows will be notified as the egress has no ingress ID for the |>> re-routed flows. |>=20 |> Admission Control should work in the case of rerouting. |> Preemption may not work properly as indeed the ingress can only |> preempt the per flow reservations whose egress nodes it knows. | |Without per-flow states in the interior, you cannot rely on=20 |admission control immediately after re-routing because the=20 |router cannot (normally) differentiate re-routed flows from=20 |original flows. In my understanding, specifically after=20 |re-routing you have to use pre-emption. Sorry, I don't understand. |For instance, the problem statement draft writes: |"Pre-Congestion Notification (PCN) investigates the use of=20 |per-flow admission control to provide the required service=20 |guarantees for the admitted traffic. While admission control=20 |will protect the QoS under normal operating conditions, an=20 |additional flow pre-emption mechanism is necessary in the=20 |times of heavy congestion (e.g. caused by route changes due to=20 |link or node failure)." | |Or do I miss something? Can you elaborate on how you think=20 |admission control can be used in case of re-routing? If an egress changes, the ingress gets a correct pre-congestion=20 indication for the new egress. If RSVP or NSIS is applied, any=20 flow asking for admission will be routed to the new egress as=20 soon as routing reconverged and the pre-congestion indication=20 is available. It will take a few seconds at least until that=20 happens and during this time nothing works properly. It is possible to engineer link loads so=20 that the maximum loads caused by re-routing after single=20 link failures can be estimated fairly accurate in=20 advance. If the admission-rate is set to "normal maximum rate" and the preemption rate to "maximum estimated load after re-routing", the QoS of admitted calls doesn't decrease while=20 new calls aren't admitted after a single link loss. After a=20 catastrophic failure, all bets are off. But let's consider=20 standard operation first. |>> 3) Some form of ingress-egress tunnelling. This elliminates the |>> previous problem. Has the disadvantage of tunnell |>> interface/addressing configuration potentially between each pair of |>> edge routers. Unless, some automatic tunnelling mechanism is |>> proposed.=20 |>=20 |> Tunnels certainly work, but I hope that PCN finds a way to get around |> them.=20 | |Me, too :-) | _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Wed Jun 20 13:00:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13XE-00087a-Q8; Wed, 20 Jun 2007 13:00:00 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1I13XE-00087V-9x for pcn-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 13:00:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I13XD-00086m-Vm for pcn@ietf.org; Wed, 20 Jun 2007 12:59:59 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I13XD-0006ql-GD for pcn@ietf.org; Wed, 20 Jun 2007 12:59:59 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 20 Jun 2007 09:59:59 -0700 X-IronPort-AV: i="4.16,443,1175497200"; d="scan'208"; a="168858983:sNHT55302426" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l5KGxw0G008660; Wed, 20 Jun 2007 09:59:58 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5KGxwaK013963; Wed, 20 Jun 2007 16:59:58 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 09:59:58 -0700 Received: from [10.32.244.219] ([10.32.244.219]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 09:59:57 -0700 In-Reply-To: <63A23507A6F0C344BE6D60303E9441D901F9A324@esealmw114.eemea.ericsson.se> References: <000001c7ae53$938209c0$4b0c6f0a@china.huawei.com> <1182287412.3856.45.camel@neutrino> <63A23507A6F0C344BE6D60303E9441D901F9A324@esealmw114.eemea.ericsson.se> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Fred Baker Subject: Re: Egress state options [Was: RE: [PCN] rate measurement capabilities of today's routers] Date: Wed, 20 Jun 2007 09:59:58 -0700 To: =?ISO-8859-1?Q?Andr=E1s_Cs=E1sz=E1r_=28IJ/ETH=29?= X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 20 Jun 2007 16:59:58.0008 (UTC) FILETIME=[6EC47380:01C7B35C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5682; t=1182358798; x=1183222798; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20Egress=20state=20options=20[Was=3A=20RE=3A=20[PCN]=20 rate=20measurement=20capabilities=20of=20today's=20routers] |Sender:=20; bh=dLK5waN/QbQf0eJgA7DqqyGmU9nWgii1qw2YPMK9Vxc=; b=fQMP0wSEdNJpaOHhaMk7linLf8shiJZJmFES6fBkgq1AbDv66FNEfFp9MIM9hUn7WHwd1OkK GAepuF5Vp0eXv0/QhcHG6TLJspsGABA66ZNdjMM3p/nQFRpNmMOB7o/9EJjzECtVWhqzmSZHJz DxjmiuavhIn6MJ05uJWhJ83jk=; Authentication-Results: sj-dkim-1; header.From=fred@cisco.com; dkim=pass (si g from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: pcn@ietf.org X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org On Jun 19, 2007, at 11:40 PM, Andr=E1s Cs=E1sz=E1r (IJ/ETH) wrote: > 1) Egress infers ingress from routing and packet header: generally =20 > cannot be done. ;-) Yes. You can infer where you would expect it to come in, but not =20 where it actually came in. The canonical example is asymmetric routing in the backbone. Each AS =20 accepts some number of BGP advertisements from preceding AS's and =20 selects one or more routes to some remote prefix, and then advertises =20= the prefix on to other AS's. The AS can infer that a datagram from =20 that prefix entered its network from one of the neighboring AS's that =20= advertised it. It cannot, at its egress, say *which* of those, only =20 that those are the obvious candidates. But in the case of a spoofed source address (this is what BCP 38 is =20 all about), it might have entered from some neighboring system that =20 didn't advertise it. On sleepless nights I wonder whether there is an =20= AS in the world that originates datagrams from some prefix and sends =20 them via an AS that it doesn't advertise the prefix to. I don't know, =20= but I hope not. > 2) Some form of signalling. In this case, care must be taken with =20 > re-routing situations affecting the egress router itself. In some =20 > cases, the egress router itself may change, in which case the =20 > ingress router should have some very quick(*) means to update the =20 > states in the egress routers! (Preferably before the egress =20 > finished measuring the marked packet rate...) Otherwise, the non-re-=20= > routed flows will be notified as the egress has no ingress ID for =20 > the re-routed flows. see (1). Routing develops a spanning tree toward a prefix from all =20 possible ingresses, and it is pretty common for data from any given =20 remote prefix to be able to use several of those paths. We call that =20 "multipath routing" or "asymmetric routing" depending on whether it =20 was intentional or a by-product of differing routing policies. First =20 mention in the RFC series is in RFC 46, April 1970. > 3) Some form of ingress-egress tunnelling. This elliminates the =20 > previous problem. Has the disadvantage of tunnell interface/=20 > addressing configuration potentially between each pair of edge =20 > routers. Unless, some automatic tunnelling mechanism is proposed. however the tunnel is set up, a packet that comes out of it can be =20 inferred to have entered it at the tunnel ingress. > 4) ACLs. Has the disadvantage of a lot of configuration. Also, =20 > preparing for a change of egress node due to re-routing seems =20 > unfeasible. See comment on (1). > Some automatic tunnelling essentially piggybacks the ingress ID =20 > onto each packet. Couldn't we do it with less overhead? With some =20 > IP header option, whatever? I have in the past proposed a trailer - in a network that is 9K =20 clean, one could have the ingress router affix one if its IP =20 addresses at the tail of each packet that it handles, perhaps the =20 address of its ingress interface. It would be ignored by a receiving =20 host as it would appear to be in the noise at the end of the packet. =20 There are good reasons to not have routers affixing trailers, and =20 perhaps better reasons to not have them inserting options or optional =20= headers in datagrams that haven't left places for them to do so. But =20 this is a possibility that addresses the multipath and spoofing =20 problems. > (*) How quick congestion notification/handling is PCN targeting? =20 > What is the timescale? I'm asking because for some applications, =20 > users are stopping their sessions after a few seconds of bad =20 > quality. The routing convergence time should also be taken into =20 > account. I don't think this is about routing convergence, although routing =20 events are possible. In the general case, PCN is about sessions using =20= existing routes and adding more traffic to them than some threshold. =20 The simulations have been about "so what happens when I'm running =20 close to the line and I add a new session" or "...and a session =20 changes its characteristics in some way". On a re-route, one has to believe that one has two disjoint paths =20 with M and N sessions on them respectively, re-routing puts N+M>T =20 sessions on some portion of one of their paths, and one would really =20 like N+M-T of the traffic (either data within the sessions or =20 sessions themselves) to go away. All of the sessions will receive the =20= same signal (ECN marks or whatever). Presumably all will apply a =20 similar algorithm but with varying configuration parameters. What we =20 will probably see is a random subset of the N+M sessions go away, =20 never less that N+M-T but very possibly more. The question is what =20 the statistical distribution is and what mean it is distributed around. Time scale... I would have to believe that expected timescales are in =20= small multiples of RTTs, which on an end-to-end basis would generally =20= be in the tens to hundreds of milliseconds. It would take at least =20 one RTT to pick up a mark and report it to the sender, and probably =20 another RTT for the sender to determine whether it was a one-of event =20= or a stable state. If we're talking aobut the sender then reporting =20 something to its SIP Proxy etc, the control system executing some =20 algorithm, and then potentially replying "take down the call", =20 following which there is at least one more RTT for a SIP shutdown =20 exchange, we're looking at the equivalent of four RTTs at least.= _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Jun 21 23:38:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Zyo-0007p7-1w; Thu, 21 Jun 2007 23:38:38 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1I1Zyn-0007ox-D0 for pcn-confirm+ok@megatron.ietf.org; Thu, 21 Jun 2007 23:38:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I1Zyn-0007oj-12 for pcn@ietf.org; Thu, 21 Jun 2007 23:38:37 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I1Zym-0005AX-Il for pcn@ietf.org; Thu, 21 Jun 2007 23:38:37 -0400 Received: from zrtphxm1.corp.nortel.com (zrtphxm1.corp.nortel.com [47.140.202.50]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l5M3cYD13787 for ; Fri, 22 Jun 2007 03:38:34 GMT Received: from KCHAN-2K3.nortel.com ([47.9.16.1] RDNS failed) by zrtphxm1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 23:38:18 -0400 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 21 Jun 2007 23:38:17 -0400 To: pcn@ietf.org From: "Kwok-Ho Chan" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 22 Jun 2007 03:38:18.0899 (UTC) FILETIME=[C64A5E30:01C7B47E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Subject: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi all: Please see the attached E-Mail on the posting of the PCN Architecture draft. On behave of the editor of this draft: Phil, and the co-authors of this draft, we would like to request for reviews and comments of this draft and welcome any comments for improvements. Please send your comments/discussions of this draft on the PCN list. Thank you for your interest and review of this draft! -- Kwok on behave of the co-authors of this draft -- >To: i-d-announce@ietf.org >Cc: >From: Internet-Drafts@ietf.org >Date: Thu, 21 Jun 2007 15:50:02 -0400 >X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 >Subject: I-D ACTION:draft-eardley-pcn-architecture-00.txt >X-BeenThere: i-d-announce@ietf.org >X-Mailman-Version: 2.1.5 >Reply-To: internet-drafts@ietf.org >List-Id: i-d-announce.ietf.org >List-Unsubscribe: , > >List-Archive: >List-Post: >List-Help: >List-Subscribe: , > >X-Spam-Tests: FORGED_RCVD_HELO=0.05,MIME_BOUND_NEXTPART=0.106, > NO_REAL_NAME=0.178,TO_CC_NOT_NORTEL=1,URIBL_MANURI=4 >X-Spam-Score: 5.3 >X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ecarhea1.nortel.com >X-DNSBL-Score: -50 >X-DNSBL-Servers: bl.nortel.com >X-SMTP-HELO: megatron.ietf.org >X-SMTP-MAIL-FROM: i-d-announce-bounces@ietf.org >X-SMTP-RCPT-TO: >kboyle@nortel.com,bstucker@nortel.com,balles@nortel.com,bharrath@nortel.com,babiarz@nortel.com,audet@nortel.com,aceler@nortel.com,simmonds@nortel.com,huiwc@nortel.com,amuhanna@nortel.com,mchen@nortel.com,khchan@nortel.com >X-SMTP-PEER-INFO: odin.ietf.ORG [156.154.16.145] >X-SMTP-REASON: PASSED >X-SMTP-ID: 1182455563.14011407 >X-OriginalArrivalTime: 21 Jun 2007 19:52:44.0828 (UTC) >FILETIME=[BC4965C0:01C7B43D] > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Pre-Congestion Notification Architecture > Author(s) : P. Eardley, et al. > Filename : draft-eardley-pcn-architecture-00.txt > Pages : 27 > Date : 2007-6-21 > > The purpose of this document is to describe a general architecture > for flow admission and termination based on aggregated (pre-) > congestion information in order to protect the quality of service of > established inelastic flows within a single DiffServ domain. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-eardley-pcn-architecture-00.txt > >To remove yourself from the I-D Announcement list, send a message to >i-d-announce-request@ietf.org with the word unsubscribe in the body of >the message. >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce >to change your subscription settings. > >Internet-Drafts are also available by anonymous FTP. Login with the >username "anonymous" and a password of your e-mail address. After >logging in, type "cd internet-drafts" and then >"get draft-eardley-pcn-architecture-00.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-eardley-pcn-architecture-00.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > >Content-Type: text/plain >Content-ID: <2007-6-21120238.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-eardley-pcn-architecture-00.txt > > > >_______________________________________________ >I-D-Announce mailing list >I-D-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Mon Jun 25 07:22:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2meB-00005x-Ub; Mon, 25 Jun 2007 07:22:19 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1I2meA-00005s-Cy for pcn-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 07:22:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2meA-00005k-3X for pcn@ietf.org; Mon, 25 Jun 2007 07:22:18 -0400 Received: from mailgw3.ericsson.se ([193.180.251.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2me7-0002u3-6z for pcn@ietf.org; Mon, 25 Jun 2007 07:22:18 -0400 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 5D7462055F for ; Mon, 25 Jun 2007 13:22:10 +0200 (CEST) X-AuditID: c1b4fb3c-b1e82bb0000007e1-9c-467fa562ee50 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 419B620055 for ; Mon, 25 Jun 2007 13:22:10 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 13:22:09 +0200 Received: from ericsson.com ([147.214.26.58]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 13:22:09 +0200 Message-ID: <467FA562.2060603@ericsson.com> Date: Mon, 25 Jun 2007 13:22:10 +0200 From: Lars Westberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pcn@ietf.org X-OriginalArrivalTime: 25 Jun 2007 11:22:09.0779 (UTC) FILETIME=[1206E430:01C7B71B] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Subject: [PCN] Fwd: I-D ACTION:draft-westberg-pcn-load-control-00.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1316676152==" Errors-To: pcn-bounces@ietf.org This is a multi-part message in MIME format. --===============1316676152== Content-Type: multipart/alternative; boundary="------------070105080204080004040905" This is a multi-part message in MIME format. --------------070105080204080004040905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dear all The "LC-PCN - The Load Control PCN solution" draft can be found via: http://www.ietf.org/internet-drafts/draft-westberg-pcn-load-control-00.txt Abstract There is an increased interest of simple and scalable resource provisioning solution for Diffserv network. The Load Control PCN (LC-PCN) addresses the following issues: 1. Admission control for real time data flows in stateless Diffserv Domains 2. Flow termination: Termination of flows in case of exceptional events, such as severe congestion after re-routing. Admission control in a Diffserv stateless domain is a combination of: 1. Probing, whereby a probe packet is sent along the forwarding path in a network to determine whether a flow can be admitted based upon the current congestion state of the network 2. Admission control based on data marking, whereby in congestion situations the data packets are marked to notify the egress node that a congestion occurred on a particular ingress to egress path. The scheme provides the capability of controlling the traffic load in the network without requiring signaling or any per-flow processing in the core routers. The complexity of Load Control is kept to a minimum to make implementation simple. Kind regards, Lars --------------070105080204080004040905 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all

The "LC-PCN - The Load Control PCN solution" draft can be found via:
http://www.ietf.org/internet-drafts/draft-westberg-pcn-load-control-00.txt


Abstract

There is an increased interest of simple and scalable resource provisioning
solution for Diffserv network.
The Load Control PCN (LC-PCN) addresses the following issues:

1. Admission control for real time data flows in stateless Diffserv Domains
2. Flow termination: Termination of flows in case of exceptional events,
such as severe congestion after re-routing.
Admission control in a Diffserv stateless domain is a combination of:

  1. Probing, whereby a probe packet is
   sent along the forwarding path in a network to determine
   whether a flow can be admitted based upon the current
   congestion state of the network

  2. Admission control based on data marking, whereby in congestion
    situations the data packets are marked to notify the egress node
    that a congestion occurred on a particular ingress to egress
    path.
    The scheme provides the capability of controlling the traffic load in
    the network without requiring signaling or any per-flow processing in
    the core routers. The complexity of Load Control is kept to a minimum
    to make implementation simple.

Kind regards,

Lars
 --------------070105080204080004040905-- --===============1316676152== 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://www1.ietf.org/mailman/listinfo/pcn --===============1316676152==-- From pcn-bounces@ietf.org Mon Jun 25 09:05:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2oGH-00026t-32; Mon, 25 Jun 2007 09:05:45 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1I2oGG-00026o-G2 for pcn-confirm+ok@megatron.ietf.org; Mon, 25 Jun 2007 09:05:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I2oGG-00026b-6N for pcn@ietf.org; Mon, 25 Jun 2007 09:05:44 -0400 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I2oGE-00077n-9s for pcn@ietf.org; Mon, 25 Jun 2007 09:05:44 -0400 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 14:05:41 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 14:05:40 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt08.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1182776739703; Mon, 25 Jun 2007 14:05:39 +0100 Received: from mut.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id l5PD5aDP004973; Mon, 25 Jun 2007 14:05:37 +0100 Message-Id: <5.2.1.1.2.20070625140136.04931eb0@pop3.jungle.bt.co.uk> X-Sender: rbriscoe@pop3.jungle.bt.co.uk X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Date: Mon, 25 Jun 2007 14:05:46 +0100 To: Steven Blake From: Bob Briscoe Subject: Re: PCN for multidomain (was: [PCN] Drafts for Chicago) In-Reply-To: <1182287988.3856.54.camel@neutrino> References: <5.2.1.1.2.20070616185907.04431a48@pop3.jungle.bt.co.uk> <5.2.1.1.2.20070616185907.04431a48@pop3.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -3.75 () ALL_TRUSTED,AWL,BAYES_00 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 25 Jun 2007 13:05:41.0180 (UTC) FILETIME=[884F77C0:01C7B729] X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: pcn X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Steven, At 22:19 19/06/2007, Steven Blake wrote: >On Sat, 2007-06-16 at 19:18 +0100, Bob Briscoe wrote: > >I'm sorry to be blunt, but people who are worried about what PCN is >going to work on after it gets rechartered need to refocus on achieving >PCN's existing milestones under the current charter. Progress on this >front, as gauged by what has been published or discussed on the list >since Prague, is not encouraging. Don't worry - it should all pop out in time. Phil Eardley is working on a PCN architecture doc with multiple authors. Anything with that number of authors takes a deal of time under the covers before a perfectly formed butterfly pops out of the chrysalis :) Phil & I have split our work (within BT) so he keeps the current stuff going and I think about the next steps. Bob ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn From pcn-bounces@ietf.org Thu Jun 28 11:59:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3wPM-000194-D0; Thu, 28 Jun 2007 11:59:48 -0400 Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1I3wPL-00018y-Su for pcn-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 11:59:47 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I3wPL-00018q-HQ for pcn@ietf.org; Thu, 28 Jun 2007 11:59:47 -0400 Received: from smtp1.smtp.bt.com ([217.32.164.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I3wPK-0002JY-VN for pcn@ietf.org; Thu, 28 Jun 2007 11:59:47 -0400 Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 16:59:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt Date: Thu, 28 Jun 2007 16:59:20 +0100 Message-ID: <75A199C5D243C741BF3D3F1EBCEF9BA5019DC2D7@E03MVZ1-UKDY.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt Thread-Index: Ace0ftSujSevBAu9SV6DTpbRzdDISwFGLhrw From: To: X-OriginalArrivalTime: 28 Jun 2007 15:59:20.0976 (UTC) FILETIME=[4A3B6900:01C7B99D] X-Spam-Score: 0.2 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: pcn-bounces@ietf.org Hi all, Just a reminder that all comments on this draft would be great. It aims to describe the PCN architecture, in light of the PCN WG's Charter & its Milestone of an Info doc on 'Flow Admission and Termination Architecture within a Diffserv Domain' (due Nov 07). S1 Introduction.=20 This is quite short. If desired, it could be boosted with a general explanation of where PCN fits into the picture of QoS and how it's evolved (compare Section 1.1 of draft-chan-pcn-problem-statement-01) S2 Terminology In the "Editor's note" are 3 alternative terms that some of the authors preferred.=20 S3 Assumptions and constraints on scope These are the 4 things mentioned in the Charter, plus some explanation of them. Are they clear? Also we mention some of the ways that a future revised Charter might look at overcoming some of the constraints/assumptions; is this sub-section at the right depth? S4 High-level functional architecture We have tried to write this section (and the following ones) so that it fits all the various proposals there've been for PCN mechanisms. Does this make the section too wishy-washy or too hard to understand? Should it include some comparison of the different mechanisms proposed (PCN-interior-node marking algorithms & PCN-boundary-node reactions)? S5 Detailed Functional architecture Is this a reasonable description of the extra functionality that PCN requires on various nodes in the PCN-domain? Is it the right way to split up the description? For clarity / help reader's understanding, should there be some specific examples of how functionality might be distributed (eg "if you followed the deployment model in draft-briscoe-tsvwg-cl-architecture-04, then this measurement is made at the PCN-egress-node, communicated to the PCN-ingress-nodes which makes the admission decision; etc.") S6 Design goals and challenges This briefly describes some open issues, taken from briscoe-tsvwg-cl-architecture. Are there other ones that should be mentioned? Is the problem description at the right level of depth? Should we discuss various possible solutions to these problems? S7 Deployment scenarios Briefly describes some deployment scenarios for pcn? is this at the right level of depth? S8 Operations and Management This section was written in response to the Charter saying that the architecture document should include security, manageability and operational considerations. The draft addresses this by providing some thoughts under the FCAPS headings: OAM of Faults, Configuration, Accounting, Performance and Security? Is this the right way of structuring it - does it cover the right set of topics? Is the text at the right level? - eg should it also have a detailed set of parameters that would be available for configuration?=20 An overall question is whether the draft should have more comparison of the options (pros/cons) for various aspects. I aim to edit another version of the draft before the ietf (but maybe not before the deadline as I'm on hols next week). Thanks! Phil/=20 > -----Original Message----- > From: Kwok-Ho Chan [mailto:khchan@nortel.com] > Sent: 22 June 2007 04:38 > To: pcn@ietf.org > Subject: [PCN] Fwd: I-D ACTION:draft-eardley-pcn-architecture-00.txt >=20 > Hi all: > Please see the attached E-Mail on the posting of the PCN Architecture > draft. > On behave of the editor of this draft: Phil, and the co-authors of this > draft, > we would like to request for reviews and comments of this draft and > welcome > any comments for improvements. >=20 > Please send your comments/discussions of this draft on the PCN list. >=20 > Thank you for your interest and review of this draft! > -- Kwok on behave of the co-authors of this draft -- >=20 >=20 > >To: i-d-announce@ietf.org > >Cc: > >From: Internet-Drafts@ietf.org > >Date: Thu, 21 Jun 2007 15:50:02 -0400 > >X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 > >Subject: I-D ACTION:draft-eardley-pcn-architecture-00.txt > >X-BeenThere: i-d-announce@ietf.org > >X-Mailman-Version: 2.1.5 > >Reply-To: internet-drafts@ietf.org > >List-Id: i-d-announce.ietf.org > >List-Unsubscribe: , > > > >List-Archive: > >List-Post: > >List-Help: > >List-Subscribe: , > > > >X-Spam-Tests: FORGED_RCVD_HELO=3D0.05,MIME_BOUND_NEXTPART=3D0.106, > > NO_REAL_NAME=3D0.178,TO_CC_NOT_NORTEL=3D1,URIBL_MANURI=3D4 > >X-Spam-Score: 5.3 > >X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on > ecarhea1.nortel.com > >X-DNSBL-Score: -50 > >X-DNSBL-Servers: bl.nortel.com > >X-SMTP-HELO: megatron.ietf.org > >X-SMTP-MAIL-FROM: i-d-announce-bounces@ietf.org > >X-SMTP-RCPT-TO: > >kboyle@nortel.com,bstucker@nortel.com,balles@nortel.com,bharrath@nortel .c > om,babiarz@nortel.com,audet@nortel.com,aceler@nortel.com,simmonds@nortel .c > om,huiwc@nortel.com,amuhanna@nortel.com,mchen@nortel.com,khchan@nortel.c om > >X-SMTP-PEER-INFO: odin.ietf.ORG [156.154.16.145] > >X-SMTP-REASON: PASSED > >X-SMTP-ID: 1182455563.14011407 > >X-OriginalArrivalTime: 21 Jun 2007 19:52:44.0828 (UTC) > >FILETIME=3D[BC4965C0:01C7B43D] > > > >A New Internet-Draft is available from the on-line Internet-Drafts > >directories. > > > > > > Title : Pre-Congestion Notification Architecture > > Author(s) : P. Eardley, et al. > > Filename : draft-eardley-pcn-architecture-00.txt > > Pages : 27 > > Date : 2007-6-21 > > > > The purpose of this document is to describe a general architecture > > for flow admission and termination based on aggregated (pre-) > > congestion information in order to protect the quality of service of > > established inelastic flows within a single DiffServ domain. > > > > > >A URL for this Internet-Draft is: > >http://www.ietf.org/internet-drafts/draft-eardley-pcn-architecture-00.t xt > > > >To remove yourself from the I-D Announcement list, send a message to > >i-d-announce-request@ietf.org with the word unsubscribe in the body of > >the message. > >You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > >to change your subscription settings. > > > >Internet-Drafts are also available by anonymous FTP. Login with the > >username "anonymous" and a password of your e-mail address. After > >logging in, type "cd internet-drafts" and then > >"get draft-eardley-pcn-architecture-00.txt". > > > >A list of Internet-Drafts directories can be found in > >http://www.ietf.org/shadow.html > >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > >Internet-Drafts can also be obtained by e-mail. > > > >Send a message to: > > mailserv@ietf.org. > >In the body type: > > "FILE /internet-drafts/draft-eardley-pcn-architecture-00.txt". > > > >NOTE: The mail server at ietf.org can return the document in > > MIME-encoded form by using the "mpack" utility. To use this > > feature, insert the command "ENCODING mime" before the "FILE" > > command. To decode the response(s), you will need "munpack" or > > a MIME-compliant mail reader. Different MIME-compliant mail > readers > > exhibit different behavior, especially when dealing with > > "multipart" MIME messages (i.e. documents which have been split > > up into multiple messages), so check your local documentation on > > how to manipulate these messages. > > > >Below is the data which will enable a MIME compliant mail reader > >implementation to automatically retrieve the ASCII version of the > >Internet-Draft. > > > >Content-Type: text/plain > >Content-ID: <2007-6-21120238.I-D@ietf.org> > > > >ENCODING mime > >FILE /internet-drafts/draft-eardley-pcn-architecture-00.txt > > > > > > 00.txt> > >_______________________________________________ > >I-D-Announce mailing list > >I-D-Announce@ietf.org > >https://www1.ietf.org/mailman/listinfo/i-d-announce >=20 >=20 >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www1.ietf.org/mailman/listinfo/pcn _______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn