From toby.moncaster@bt.com Wed Jul 1 01:11:47 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ECC93A6AE6 for ; Wed, 1 Jul 2009 01:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.115 X-Spam-Level: X-Spam-Status: No, score=-3.115 tagged_above=-999 required=5 tests=[AWL=0.484, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9H3uuvXyy7sC for ; Wed, 1 Jul 2009 01:11:46 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 7F1483A6A09 for ; Wed, 1 Jul 2009 01:11:46 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Jul 2009 09:12:07 +0100 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 Date: Wed, 1 Jul 2009 09:12:05 +0100 Message-ID: In-Reply-To: <4A4AAEC7.8060900@rogers.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Editorial note on baseline encoding document Thread-Index: Acn548UDaGjLiqjkRduWqDNtRoN+6wAP4pyg References: <4A4AAEC7.8060900@rogers.com> From: To: , X-OriginalArrivalTime: 01 Jul 2009 08:12:07.0251 (UTC) FILETIME=[A008F230:01C9FA23] Subject: Re: [PCN] Editorial note on baseline encoding document X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 08:11:47 -0000 Well spotted Tom, Thanks.=20 Current sentence reads: "If an operator it is essential that any operator wishing to allow ECN = to exist end-to-end ensures there are no tunnel end-points within the = PCN-domain." Should read: "If an operator wishes to allow ECN to exist end-to-end they must ensure = there are no tunnel end-points within the PCN-domain." Toby ____________________________________________________________________=20 Toby Moncaster, Networks Research Centre, BT=20 B54/70 Adastral Park, Ipswich, IP53RE, UK.=A0 +44 7918 901170=20 > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Tom Taylor > Sent: 01 July 2009 01:33 > To: pcn > Subject: [PCN] Editorial note on baseline encoding document >=20 > This is a quick editorial note which has been causing me some > uncertainty. The > last sentence of section 6 of draft-ietf-pcn-baseline-encoding-04 > is a bit garbled. I'm assuming the sentence was begun then rebegun. >=20 > Tom > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From root@core3.amsl.com Wed Jul 1 06:45:01 2009 Return-Path: X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3D73E3A6F26; Wed, 1 Jul 2009 06:45:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090701134501.3D73E3A6F26@core3.amsl.com> Date: Wed, 1 Jul 2009 06:45:01 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-3-in-1-encoding-00.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 13:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF. Title : PCN 3-State Encoding Extension in a single DSCP Author(s) : B. Briscoe, T. Moncaster Filename : draft-ietf-pcn-3-in-1-encoding-00.txt Pages : 8 Date : 2009-07-01 The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. The overall rate of the PCN-traffic is metered on every link in the PCN-domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. The level of marking allows the boundary nodes to make decisions about whether to admit or block a new flow request, and (in abnormal circumstances) whether to terminate some of the existing flows, thereby protecting the QoS of previously admitted flows. This document specifies how such marks are to be encoded into the IP header by re-using the Explicit Congestion Notification (ECN) codepoints within this controlled domain. This encoding builds on the baseline encoding and provides for three PCN encoding states: Not-marked, Threshold-marked and Excess-traffic-marked. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-in-1-encoding-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcn-3-in-1-encoding-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-01063258.I-D@ietf.org> --NextPart-- From Black_David@emc.com Wed Jul 1 09:12:28 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3072F3A6862; Wed, 1 Jul 2009 09:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.122 X-Spam-Level: X-Spam-Status: No, score=-5.122 tagged_above=-999 required=5 tests=[AWL=-0.823, BAYES_00=-2.599, MANGLED_LIST=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id um4ziM2O6Ctn; Wed, 1 Jul 2009 09:12:26 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id E90013A692D; Wed, 1 Jul 2009 09:11:41 -0700 (PDT) Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com [10.254.111.23]) by mexforward.lss.emc.com (Switch-3.3.2/Switch-3.1.7) with ESMTP id n61GAdtt004667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jul 2009 12:10:39 -0400 Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.15]) by hop04-l1d11-si03.isus.emc.com (Tablus Interceptor); Wed, 1 Jul 2009 12:10:33 -0400 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.3.2mp/Switch-3.3.2mp) with ESMTP id n61GATYO025608; Wed, 1 Jul 2009 12:10:32 -0400 Received: from CORPUSMX80A.corp.emc.com ([10.254.89.202]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Jul 2009 12:10:30 -0400 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 Date: Wed, 1 Jul 2009 12:10:29 -0400 Message-ID: <9FA859626025B64FBC2AF149D97C944A03210F1F@CORPUSMX80A.corp.emc.com> In-Reply-To: <9FA859626025B64FBC2AF149D97C944A02FE0ACB@CORPUSMX80A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Gen-ART review of draft-ietf-pcn-marking-behaviour-03.txt Thread-Index: AcietuD6zRiwq9zOTSK6y1+D8tbCgVRffacwAow9RlA= References: <9FA859626025B64FBC2AF149D97C944A02FE0ACB@CORPUSMX80A.corp.emc.com> From: To: , , X-OriginalArrivalTime: 01 Jul 2009 16:10:30.0450 (UTC) FILETIME=[74798920:01C9FA66] X-EMM-EM: Active Cc: pcn@ietf.org Subject: Re: [PCN] Gen-ART review of draft-ietf-pcn-marking-behaviour-03.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 16:12:28 -0000 The -04 version of this draft resolves all of my comments from the Gen-ART review of the -03 version. While it would be better to change the term "PCN-excess-rate" to something else in a perfect world, the world is not perfect - since that is now the established term for the concept of a PCN configured rate above which all traffic is excess, it should be left as is. Thanks, --David =20 > -----Original Message----- > From: Black, David=20 > Sent: Thursday, June 18, 2009 3:32 PM > To: philip.eardley@bt.com; Gen Art > Cc: Black, David; Scott Bradner; Steven Blake; Lars Eggert;=20 > pcn@ietf.org > Subject: Gen-ART review of draft-ietf-pcn-marking-behaviour-03.txt >=20 > I have been selected as the General Area Review Team (Gen-ART)=20 > reviewer for this draft (for background on Gen-ART, please see=20 > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). >=20 > Please resolve these comments along with any other Last Call > comments you may receive.=20 >=20 > Document: draft-ietf-pcn-marking-behaviour-03.txt > Reviewer: David L. Black > Review Date: 18 June 2008 > IETF LC End Date: 18 June 2008 >=20 > Summary:=20 > This draft is basically ready for publication, but has nits that > should be fixed before publication. >=20 > Comments: >=20 > This draft specified requirements on how the diffserv components > in a PCN node need to behave in order to support PCN. In addition > to specifying the requirements, an example algorithm (Appendix > A) and extensive implementation notes (Appendix B) are provided. > The implementation notes are very useful - the WG should be > commended for working through the practical implementation > considerations for this functionality up front as opposed to > leaving them to implementers to puzzle out. >=20 > All of my comments are on relatively minor points: >=20 > "PCN-excess-rate" strikes me as a bad name for a configured > throughput rate - I suggest choosing another term. Intuitively, > I would expect PCN-excess-rate to refer to traffic that is in > excess of a PCN configured rate. >=20 > Section 2.1, 1st paragraph and Section B.3 need to cite a > reference for how the DSCP and ECN field values are used to > decide whether a packet is PCN or not. >=20 > In Section 2.2, first bullet, what is "scheduling rate"? Please > supply a definition. >=20 > Section 2.4 - the second bullet also applies to competing non-PCN > traffic (if that traffic is metered). The text needs to be adjusted > to allow for this. Try: >=20 > A packet SHOULD NOT be metered ... >=20 > o If the PCN-packet is already .... >=20 > o If this PCN-node drops the packet. >=20 > Section 2.5 could use a reminder that while competing non-PCN packets > may be metered, they MUST NOT be marked. This may have implications > for the marking behavior that are probably most usefully discussed > in Appendix B. >=20 > Nits: > - At the end of the first paragraph in B.1 > "there needs to be" --> "there should be" > The "should" is lower case. >=20 > - idnits 2.11.11 noted that there is now a -04 version of the > pcn-baseline-encoding draft, as was noted in the draft > shepherd's writeup. >=20 > Thanks, > --David > ---------------------------------------------------- > David L. Black, Distinguished Engineer > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- >=20 >=20 From slblake@petri-meat.com Wed Jul 1 12:28:31 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E78D3A6839 for ; Wed, 1 Jul 2009 12:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ktq1exAsDfzE for ; Wed, 1 Jul 2009 12:28:30 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 6E17F3A696A for ; Wed, 1 Jul 2009 12:28:30 -0700 (PDT) Received: from cpe-066-057-118-226.nc.res.rr.com ([66.57.118.226]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1MM5Tn-0000nb-3B; Wed, 01 Jul 2009 15:28:27 -0400 From: Steven Blake To: "Black_David@emc.com" In-Reply-To: <9FA859626025B64FBC2AF149D97C944A03210F1F@CORPUSMX80A.corp.emc.com> References: <9FA859626025B64FBC2AF149D97C944A02FE0ACB@CORPUSMX80A.corp.emc.com> <9FA859626025B64FBC2AF149D97C944A03210F1F@CORPUSMX80A.corp.emc.com> Content-Type: text/plain Date: Wed, 01 Jul 2009 15:28:27 -0400 Message-Id: <1246476508.2990.7.camel@tachyon> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Cc: pcn@ietf.org Subject: Re: [PCN] Gen-ART review of draft-ietf-pcn-marking-behaviour-03.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 19:28:31 -0000 On Wed, 2009-07-01 at 09:10 -0700, Black_David@emc.com wrote: > The -04 version of this draft resolves all of my comments > from the Gen-ART review of the -03 version. > > While it would be better to change the term "PCN-excess-rate" > to something else in a perfect world, the world is not > perfect - since that is now the established term for the > concept of a PCN configured rate above which all traffic is > excess, it should be left as is. Thanks David. // Steve From root@core3.amsl.com Thu Jul 2 05:00:01 2009 Return-Path: X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 67D8528C1A9; Thu, 2 Jul 2009 05:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090702120001.67D8528C1A9@core3.amsl.com> Date: Thu, 2 Jul 2009 05:00:01 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-psdm-encoding-00.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 12:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF. Title : PCN Encoding for Packet-Specific Dual Marking (PSDM) Author(s) : M. Menth, et al. Filename : draft-ietf-pcn-psdm-encoding-00.txt Pages : 10 Date : 2009-06-26 This document proposes how PCN marks can be encoded into the IP header. The presented encoding reuses the ECN field of the Voice- Admit DSCP in a single PCN domain. The encoding of unmarked PCN packets indicates whether they are subject to either excess- or exhaustive-marking. This is useful, e.g., when data and probe packets require different marking mechanisms. Status This memo is posted as an Internet-Draft with an intent to eventually be published as an experimental RFC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-psdm-encoding-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcn-psdm-encoding-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-02045720.I-D@ietf.org> --NextPart-- From menth@informatik.uni-wuerzburg.de Thu Jul 2 08:37:03 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB3B728C10B for ; Thu, 2 Jul 2009 08:37:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.294 X-Spam-Level: X-Spam-Status: No, score=-1.294 tagged_above=-999 required=5 tests=[AWL=0.955, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgEQ8QXo7LkQ for ; Thu, 2 Jul 2009 08:37:02 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id C46533A6DCA for ; Thu, 2 Jul 2009 08:37:01 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id C2B3CA0898 for ; Thu, 2 Jul 2009 17:37:23 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id B740FA0892 for ; Thu, 2 Jul 2009 17:37:23 +0200 (CEST) Received: from [132.187.12.151] (win3151.informatik.uni-wuerzburg.de [132.187.12.151]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 9E3AAA0882 for ; Thu, 2 Jul 2009 17:37:23 +0200 (CEST) Message-ID: <4A4CD435.2080106@informatik.uni-wuerzburg.de> Date: Thu, 02 Jul 2009 17:37:25 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: pcn@ietf.org References: <20090702120001.67D8528C1A9@core3.amsl.com> In-Reply-To: <20090702120001.67D8528C1A9@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Subject: Re: [PCN] I-D Action:draft-ietf-pcn-psdm-encoding-00.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 15:37:03 -0000 Hi, this is the unchanged version of the individual submission. Comments are welcome for further improvement. The proposal has been published at http://www.future-network09.org/ and a preprint is accessible at http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth09f.pdf Regards, Michael Internet-Drafts@ietf.org schrieb: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF. > > > Title : PCN Encoding for Packet-Specific Dual Marking (PSDM) > Author(s) : M. Menth, et al. > Filename : draft-ietf-pcn-psdm-encoding-00.txt > Pages : 10 > Date : 2009-06-26 > > This document proposes how PCN marks can be encoded into the IP > header. The presented encoding reuses the ECN field of the Voice- > Admit DSCP in a single PCN domain. The encoding of unmarked PCN > packets indicates whether they are subject to either excess- or > exhaustive-marking. This is useful, e.g., when data and probe > packets require different marking mechanisms. > > Status > > This memo is posted as an Internet-Draft with an intent to eventually > be published as an experimental RFC. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pcn-psdm-encoding-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From toby.moncaster@bt.com Thu Jul 2 09:06:33 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78AAA3A677D for ; Thu, 2 Jul 2009 09:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.212 X-Spam-Level: X-Spam-Status: No, score=-3.212 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mR9admwptot3 for ; Thu, 2 Jul 2009 09:06:31 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 6F48D3A6A2C for ; Thu, 2 Jul 2009 09:06:31 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 17:06:53 +0100 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 Date: Thu, 2 Jul 2009 17:06:52 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Editorial note on baseline encoding document Thread-Index: Acn548UDaGjLiqjkRduWqDNtRoN+6wAP4pygAELWBKA= References: <4A4AAEC7.8060900@rogers.com> From: To: , , X-OriginalArrivalTime: 02 Jul 2009 16:06:53.0419 (UTC) FILETIME=[1D86FBB0:01C9FB2F] Subject: Re: [PCN] Editorial note on baseline encoding document X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 16:06:33 -0000 One final quick question about imperatives in this document... Currently I have the condition: "The 00 codepoint in the ECN field SHALL = indicate not-PCN and MUST NOT be changed to any other codepoint within a = PCN-domain. Therefore an ingress node wishing to disable PCN marking for = a packet within a PCN-compatible Diffserv Codepoint MUST set the ECN = field to 00." Gorry was a little uneasy about mixing SHALLs and MUSTs (both have same = level of imperative). My argument was this was sounded clearer than the = alternative: "The 00 codepoint in the ECN field MUST indicate not-PCN and MUST NOT be = changed to any other=20 codepoint within a PCN-domain. Therefore an ingress node wishing to = disable PCN marking for a=20 packet within a PCN-compatible Diffserv Codepoint MUST set the ECN field = to 00." However I am now not so sure if this is true... Any thoughts? Toby ____________________________________________________________________=20 Toby Moncaster, Networks Research Centre, BT=20 B54/70 Adastral Park, Ipswich, IP53RE, UK.=A0 +44 1206 332805=20 > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > toby.moncaster@bt.com > Sent: 01 July 2009 09:12 > To: tom.taylor@rogers.com; pcn@ietf.org > Subject: Re: [PCN] Editorial note on baseline encoding document >=20 > Well spotted Tom, Thanks. >=20 > Current sentence reads: > "If an operator it is essential that any operator wishing to allow ECN > to exist end-to-end ensures there are no tunnel end-points within the > PCN-domain." >=20 > Should read: > "If an operator wishes to allow ECN to exist end-to-end they must > ensure there are no tunnel end-points within the PCN-domain." >=20 > Toby >=20 > ____________________________________________________________________ > Toby Moncaster, Networks Research Centre, BT > B54/70 Adastral Park, Ipswich, IP53RE, UK.=A0 +44 7918 901170 >=20 >=20 >=20 > > -----Original Message----- > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf = Of > > Tom Taylor > > Sent: 01 July 2009 01:33 > > To: pcn > > Subject: [PCN] Editorial note on baseline encoding document > > > > This is a quick editorial note which has been causing me some > > uncertainty. The > > last sentence of section 6 of draft-ietf-pcn-baseline-encoding-04 > > is a bit garbled. I'm assuming the sentence was begun then rebegun. > > > > Tom > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From philip.eardley@bt.com Thu Jul 2 09:11:49 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C079E3A677D for ; Thu, 2 Jul 2009 09:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wlyDUCCcZCj for ; Thu, 2 Jul 2009 09:11:48 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 9D71F3A6BDB for ; Thu, 2 Jul 2009 09:11:08 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 17:11:30 +0100 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 Date: Thu, 2 Jul 2009 17:11:30 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD7D71@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Editorial note on baseline encoding document Thread-Index: Acn548UDaGjLiqjkRduWqDNtRoN+6wAP4pygAELWBKAAADvDYA== From: To: , , , X-OriginalArrivalTime: 02 Jul 2009 16:11:30.0430 (UTC) FILETIME=[C2A381E0:01C9FB2F] Subject: Re: [PCN] Editorial note on baseline encoding document X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 16:11:49 -0000 I'd prefer to stick with the MUSTS (then i don't have to re-boot brain = about what a SHALL means). It's standards speak, not prose! { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { toby.moncaster@bt.com { Sent: 02 July 2009 17:07 { To: Moncaster,T,Toby,DER3 R; tom.taylor@rogers.com; pcn@ietf.org { Subject: Re: [PCN] Editorial note on baseline encoding document {=20 { One final quick question about imperatives in this document... {=20 { Currently I have the condition: "The 00 codepoint in the ECN field = SHALL { indicate not-PCN and MUST NOT be changed to any other codepoint within = a { PCN-domain. Therefore an ingress node wishing to disable PCN marking = for a { packet within a PCN-compatible Diffserv Codepoint MUST set the ECN = field { to 00." {=20 { Gorry was a little uneasy about mixing SHALLs and MUSTs (both have = same { level of imperative). My argument was this was sounded clearer than = the { alternative: {=20 { "The 00 codepoint in the ECN field MUST indicate not-PCN and MUST NOT = be { changed to any other { codepoint within a PCN-domain. Therefore an ingress node wishing to { disable PCN marking for a { packet within a PCN-compatible Diffserv Codepoint MUST set the ECN = field { to 00." {=20 { However I am now not so sure if this is true... Any thoughts? {=20 { Toby {=20 {=20 { ____________________________________________________________________ { Toby Moncaster, Networks Research Centre, BT { B54/70 Adastral Park, Ipswich, IP53RE, UK.=A0 +44 1206 332805 {=20 {=20 {=20 { > -----Original Message----- { > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf = Of { > toby.moncaster@bt.com { > Sent: 01 July 2009 09:12 { > To: tom.taylor@rogers.com; pcn@ietf.org { > Subject: Re: [PCN] Editorial note on baseline encoding document { > { > Well spotted Tom, Thanks. { > { > Current sentence reads: { > "If an operator it is essential that any operator wishing to allow = ECN { > to exist end-to-end ensures there are no tunnel end-points within = the { > PCN-domain." { > { > Should read: { > "If an operator wishes to allow ECN to exist end-to-end they must { > ensure there are no tunnel end-points within the PCN-domain." { > { > Toby { > { > ____________________________________________________________________ { > Toby Moncaster, Networks Research Centre, BT { > B54/70 Adastral Park, Ipswich, IP53RE, UK.=A0 +44 7918 901170 { > { > { > { > > -----Original Message----- { > > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf = Of { > > Tom Taylor { > > Sent: 01 July 2009 01:33 { > > To: pcn { > > Subject: [PCN] Editorial note on baseline encoding document { > > { > > This is a quick editorial note which has been causing me some { > > uncertainty. The { > > last sentence of section 6 of draft-ietf-pcn-baseline-encoding-04 { > > is a bit garbled. I'm assuming the sentence was begun then = rebegun. { > > { > > Tom { > > _______________________________________________ { > > PCN mailing list { > > PCN@ietf.org { > > https://www.ietf.org/mailman/listinfo/pcn { > _______________________________________________ { > PCN mailing list { > PCN@ietf.org { > https://www.ietf.org/mailman/listinfo/pcn { _______________________________________________ { PCN mailing list { PCN@ietf.org { https://www.ietf.org/mailman/listinfo/pcn From tom.taylor@rogers.com Thu Jul 2 12:36:02 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34F5F3A6D84 for ; Thu, 2 Jul 2009 12:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12+iqCZWt+9L for ; Thu, 2 Jul 2009 12:36:01 -0700 (PDT) Received: from smtp122.rog.mail.re2.yahoo.com (smtp122.rog.mail.re2.yahoo.com [206.190.53.27]) by core3.amsl.com (Postfix) with SMTP id 92DAB28C268 for ; Thu, 2 Jul 2009 12:35:40 -0700 (PDT) Received: (qmail 47056 invoked from network); 2 Jul 2009 19:36:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Dn4lQSN42Lft3OSNoYl/lr5ssrIwGmCPfGde1Uv8CWuNzlSdJZtuKmp3S1YzVN6z7LEfDfR+vMANo3Pm8X65YuYPXI7oOWL0KvpP+dxvCZ+KGnzpDaVpIheGWQHaDLPTbofMS7Cz4xzYzcFoRVbsVK3FpyRpYaLhUYNVuc6mxUo= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp122.rog.mail.re2.yahoo.com with SMTP; 2 Jul 2009 19:36:01 -0000 X-YMail-OSG: UIGGEnsVM1ksKI_PWtPbHpq2fZhLjCC_4iHQ0ozsLDeaM_aV7tmo2jcGqqkgpgG7uw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A4D0C1F.8020003@rogers.com> Date: Thu, 02 Jul 2009 15:35:59 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: toby.moncaster@bt.com References: <4A4AAEC7.8060900@rogers.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn@ietf.org Subject: Re: [PCN] Editorial note on baseline encoding document X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 19:36:02 -0000 I'm a little uneasy about: "The 00 codepoint in the ECN field MUST indicate not-PCN." Perhaps the first sentence should say: ""Interior nodes in the PCN domain MUST interpret the 00 codepoint in the ECN field as 'not-PCN' and MUST NOT change it to another value." toby.moncaster@bt.com wrote: > One final quick question about imperatives in this document... > > Currently I have the condition: "The 00 codepoint in the ECN field SHALL > indicate not-PCN and MUST NOT be changed to any other codepoint within a > PCN-domain. Therefore an ingress node wishing to disable PCN marking for a > packet within a PCN-compatible Diffserv Codepoint MUST set the ECN field to > 00." > > Gorry was a little uneasy about mixing SHALLs and MUSTs (both have same level > of imperative). My argument was this was sounded clearer than the > alternative: > > "The 00 codepoint in the ECN field MUST indicate not-PCN and MUST NOT be > changed to any other codepoint within a PCN-domain. Therefore an ingress node > wishing to disable PCN marking for a packet within a PCN-compatible Diffserv > Codepoint MUST set the ECN field to 00." > > However I am now not so sure if this is true... Any thoughts? > > Toby > > > ____________________________________________________________________ Toby > Moncaster, Networks Research Centre, BT B54/70 > Adastral Park, Ipswich, IP53RE, UK. +44 1206 332805 > > > >> -----Original Message----- From: pcn-bounces@ietf.org >> [mailto:pcn-bounces@ietf.org] On Behalf Of toby.moncaster@bt.com Sent: 01 >> July 2009 09:12 To: tom.taylor@rogers.com; pcn@ietf.org Subject: Re: [PCN] >> Editorial note on baseline encoding document >> >> Well spotted Tom, Thanks. >> >> Current sentence reads: "If an operator it is essential that any operator >> wishing to allow ECN to exist end-to-end ensures there are no tunnel >> end-points within the PCN-domain." >> >> Should read: "If an operator wishes to allow ECN to exist end-to-end they >> must ensure there are no tunnel end-points within the PCN-domain." >> >> Toby >> >> ____________________________________________________________________ Toby >> Moncaster, Networks Research Centre, BT B54/70 >> Adastral Park, Ipswich, IP53RE, UK. +44 7918 901170 >> >> >> >>> -----Original Message----- From: pcn-bounces@ietf.org >>> [mailto:pcn-bounces@ietf.org] On Behalf Of Tom Taylor Sent: 01 July 2009 >>> 01:33 To: pcn Subject: [PCN] Editorial note on baseline encoding document >>> >>> >>> This is a quick editorial note which has been causing me some >>> uncertainty. The last sentence of section 6 of >>> draft-ietf-pcn-baseline-encoding-04 is a bit garbled. I'm assuming the >>> sentence was begun then rebegun. >>> >>> Tom _______________________________________________ PCN mailing list >>> PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn >> _______________________________________________ PCN mailing list >> PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn > From toby.moncaster@bt.com Fri Jul 3 01:10:20 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E2B53A6DBB for ; Fri, 3 Jul 2009 01:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3su04ZrEJ7ME for ; Fri, 3 Jul 2009 01:10:19 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id CF1063A6D9D for ; Fri, 3 Jul 2009 01:10:18 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Jul 2009 09:10:02 +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 Date: Fri, 3 Jul 2009 09:09:59 +0100 Message-ID: In-Reply-To: <4A4D0C1F.8020003@rogers.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Editorial note on baseline encoding document Thread-Index: Acn7TFgA4djiWZvGSC6mK0zrw2gSAgAaQ7Og References: <4A4AAEC7.8060900@rogers.com> <4A4D0C1F.8020003@rogers.com> From: To: X-OriginalArrivalTime: 03 Jul 2009 08:10:02.0760 (UTC) FILETIME=[AAA8A080:01C9FBB5] Cc: pcn@ietf.org Subject: Re: [PCN] Editorial note on baseline encoding document X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 08:10:20 -0000 I think I am more or less OK with your suggestion with one additional word: "All Interior-nodes within a PCN-domain MUST interpret the 00 codepoint in the ECN field as 'not-PCN' and MUST NOT change it to another value." > -----Original Message----- > From: Tom Taylor [mailto:tom.taylor@rogers.com] > Sent: 02 July 2009 20:36 > To: Moncaster,T,Toby,DER3 R > Cc: pcn@ietf.org > Subject: Re: [PCN] Editorial note on baseline encoding document >=20 > I'm a little uneasy about: "The 00 codepoint in the ECN field MUST > indicate > not-PCN." Perhaps the first sentence should say: ""Interior nodes in > the PCN > domain MUST interpret the 00 codepoint in the ECN field as 'not-PCN' > and MUST > NOT change it to another value." >=20 > toby.moncaster@bt.com wrote: > > One final quick question about imperatives in this document... > > > > Currently I have the condition: "The 00 codepoint in the ECN field > SHALL > > indicate not-PCN and MUST NOT be changed to any other codepoint > within a > > PCN-domain. Therefore an ingress node wishing to disable PCN marking > for a > > packet within a PCN-compatible Diffserv Codepoint MUST set the ECN > field to > > 00." > > > > Gorry was a little uneasy about mixing SHALLs and MUSTs (both have > same level > > of imperative). My argument was this was sounded clearer than the > > alternative: > > > > "The 00 codepoint in the ECN field MUST indicate not-PCN and MUST NOT > be > > changed to any other codepoint within a PCN-domain. Therefore an > ingress node > > wishing to disable PCN marking for a packet within a PCN-compatible > Diffserv > > Codepoint MUST set the ECN field to 00." > > > > However I am now not so sure if this is true... Any thoughts? > > > > Toby > > > > > > ____________________________________________________________________ > Toby > > Moncaster, Networks Research Centre, BT > B54/70 > > Adastral Park, Ipswich, IP53RE, UK. +44 1206 332805 > > > > > > > >> -----Original Message----- From: pcn-bounces@ietf.org > >> [mailto:pcn-bounces@ietf.org] On Behalf Of toby.moncaster@bt.com > Sent: 01 > >> July 2009 09:12 To: tom.taylor@rogers.com; pcn@ietf.org Subject: Re: > [PCN] > >> Editorial note on baseline encoding document > >> > >> Well spotted Tom, Thanks. > >> > >> Current sentence reads: "If an operator it is essential that any > operator > >> wishing to allow ECN to exist end-to-end ensures there are no tunnel > >> end-points within the PCN-domain." > >> > >> Should read: "If an operator wishes to allow ECN to exist end-to-end > they > >> must ensure there are no tunnel end-points within the PCN-domain." > >> > >> Toby > >> > >> ____________________________________________________________________ > Toby > >> Moncaster, Networks Research Centre, BT > B54/70 > >> Adastral Park, Ipswich, IP53RE, UK. +44 7918 901170 > >> > >> > >> > >>> -----Original Message----- From: pcn-bounces@ietf.org > >>> [mailto:pcn-bounces@ietf.org] On Behalf Of Tom Taylor Sent: 01 July > 2009 > >>> 01:33 To: pcn Subject: [PCN] Editorial note on baseline encoding > document > >>> > >>> > >>> This is a quick editorial note which has been causing me some > >>> uncertainty. The last sentence of section 6 of > >>> draft-ietf-pcn-baseline-encoding-04 is a bit garbled. I'm assuming > the > >>> sentence was begun then rebegun. > >>> > >>> Tom _______________________________________________ PCN mailing > list > >>> PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn > >> _______________________________________________ PCN mailing list > >> PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn > > From tom.taylor@rogers.com Fri Jul 3 05:25:35 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92FD028C2A5 for ; Fri, 3 Jul 2009 05:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, J_CHICKENPOX_91=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqH3Gqf4DFEw for ; Fri, 3 Jul 2009 05:25:34 -0700 (PDT) Received: from smtp110.rog.mail.re2.yahoo.com (smtp110.rog.mail.re2.yahoo.com [206.190.37.120]) by core3.amsl.com (Postfix) with SMTP id 576CE3A6DE7 for ; Fri, 3 Jul 2009 05:25:34 -0700 (PDT) Received: (qmail 63589 invoked from network); 3 Jul 2009 12:25:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=i5zxrY3UEzr0um8zLeQiYLeMInncULadJ+STCecT85t07MiJZl+A0NuAPN71bvtfp07FJIqtBk1xiUJjUE3lItceRiA2WELn+S+PMgj7ZdA7UnIB4HsbMXznMV8fw8c6A9O9gjZp50P70Z7xJqRDA3npBjTuBgTnYcXAliZxY4c= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp110.rog.mail.re2.yahoo.com with SMTP; 3 Jul 2009 12:25:54 -0000 X-YMail-OSG: JaJZpNgVM1lEndQLsC0MEWd7RwnqXyLhvjY.jh4PrdlyDigiyFJi9D8ivOFb44QtBQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A4DF8CF.5020604@rogers.com> Date: Fri, 03 Jul 2009 08:25:51 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: toby.moncaster@bt.com References: <4A4AAEC7.8060900@rogers.com> <4A4D0C1F.8020003@rogers.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn@ietf.org Subject: Re: [PCN] Editorial note on baseline encoding document X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2009 12:25:35 -0000 OK toby.moncaster@bt.com wrote: > I think I am more or less OK with your suggestion with one additional > word: > > "All Interior-nodes within a PCN-domain MUST interpret the 00 codepoint > in the ECN field as 'not-PCN' and MUST NOT change it to another value." > >> -----Original Message----- >> From: Tom Taylor [mailto:tom.taylor@rogers.com] >> Sent: 02 July 2009 20:36 >> To: Moncaster,T,Toby,DER3 R >> Cc: pcn@ietf.org >> Subject: Re: [PCN] Editorial note on baseline encoding document >> >> I'm a little uneasy about: "The 00 codepoint in the ECN field MUST >> indicate >> not-PCN." Perhaps the first sentence should say: ""Interior nodes in >> the PCN >> domain MUST interpret the 00 codepoint in the ECN field as 'not-PCN' >> and MUST >> NOT change it to another value." >> ... From tom.taylor@rogers.com Mon Jul 6 16:41:30 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 964E128C2F7 for ; Mon, 6 Jul 2009 16:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxAzC7eCfUHA for ; Mon, 6 Jul 2009 16:41:29 -0700 (PDT) Received: from smtp111.rog.mail.re2.yahoo.com (smtp111.rog.mail.re2.yahoo.com [206.190.37.1]) by core3.amsl.com (Postfix) with SMTP id 909233A6853 for ; Mon, 6 Jul 2009 16:41:29 -0700 (PDT) Received: (qmail 13972 invoked from network); 6 Jul 2009 23:41:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=W764pa6VOFGJ21lChQXxvLWxLdj1IgLElSbOiXkSNWAZxWKerdJ4G835ooOcZ2/rBVHnZ6WXgv8xICYCxsbjvdWasn585t/sHPYcwjAYJaKptAI4KpnccLLRDl3fpXCL2JRVJ2L3mnIZjqa5dcYAUStpX/y1qCKZK5wX1B+cmRk= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@174.115.211.243 with plain) by smtp111.rog.mail.re2.yahoo.com with SMTP; 6 Jul 2009 23:41:06 -0000 X-YMail-OSG: O2VTc9gVM1kB4WCJ5EuaLPtuHCEV_9lejl728O3eWQBhNCaZlhZ1qo7peHXGQ0DEPg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A528B91.9090400@rogers.com> Date: Mon, 06 Jul 2009 19:41:05 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: pcn Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [PCN] CL and SM Edge Behaviour Drafts X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 23:41:30 -0000 I have submitted CL and SM edge behaviour drafts. The CL draft went through three major iterations. My thanks to the design team, especially Michael, for their comments. However, any deficiencies are mine, since no one had time to comment on the final version. I knocked together the SM in an hour or so based on the CL draft and Anna's old text. This has not been reviewed by anyone else, and I take full responsibility for its deficiencies too. However, I thought it worthwhile to have a document on the table for discussion and improvement. I apologize to Joy Zhang because somehow she did not show up on the list of authors even though she was there in XML. Tom From root@core3.amsl.com Mon Jul 6 16:45:01 2009 Return-Path: X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 34EA13A6CF1; Mon, 6 Jul 2009 16:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090706234501.34EA13A6CF1@core3.amsl.com> Date: Mon, 6 Jul 2009 16:45:01 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-encoding-comparison-00.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 23:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF. Title : Pre-Congestion Notification Encoding Comparison Author(s) : K. Chan, et al. Filename : draft-ietf-pcn-encoding-comparison-00.txt Pages : 34 Date : 2009-07-06 A number of mechanisms have been proposed to support differential Qualiy of Service for packets in the Internet. DiffServ is an example of such a mechanism. However, the level of assurance that can be provided with DiffServ without substantial over-provisioning is limited. Pre-Congestion Notification (PCN) uses path congestion information across a PCN region to enable 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 termination mechanism is necessary to cope with extreme events (e.g. route changes due to link or node failure). In order to allow the PCN mechanisms to work it is necessary for IP packets to be able to carry the pre-congestion information to the PCN egress nodes. This document collects the lessons learned as we explores the different ways in which this information can be encoded into IP packets. This document does not choose the encoding but provide information on trade offs with the encoding choices, providing guidance based on different criteria. This document provides a historical trace of the consideration on different encoding alternatives for Pre-Congestion Notification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-encoding-comparison-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcn-encoding-comparison-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-06163035.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 6 16:45:01 2009 Return-Path: X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 413A83A6C08; Mon, 6 Jul 2009 16:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090706234501.413A83A6C08@core3.amsl.com> Date: Mon, 6 Jul 2009 16:45:01 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-cl-edge-behaviour-00.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 23:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF. Title : PCN Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation Author(s) : A. Charny, et al. Filename : draft-ietf-pcn-cl-edge-behaviour-00.txt Pages : 13 Date : 2009-07-06 Precongestion notification (PCN) is a means for protecting quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary node behaviours for a PCN domain. The behaviour described here is that for three-state measurement-based load control, known informally as Controlled Load (CL). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-cl-edge-behaviour-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcn-cl-edge-behaviour-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-06163434.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Jul 6 16:45:01 2009 Return-Path: X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 58C4B3A6DB9; Mon, 6 Jul 2009 16:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090706234501.58C4B3A6DB9@core3.amsl.com> Date: Mon, 6 Jul 2009 16:45:01 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-sm-edge-behaviour-00.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 23:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF. Title : PCN Boundary Node Behaviour for the Single Marking (SM) Mode of Operation Author(s) : A. Charny, et al. Filename : draft-ietf-pcn-sm-edge-behaviour-00.txt Pages : 12 Date : 2009-07-06 Precongestion notification (PCN) is a means for protecting quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary node behaviours for a PCN domain. The behaviour described here is that for two-state measurement-based load control, known informally as Single Marking (SM). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-sm-edge-behaviour-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcn-sm-edge-behaviour-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-06163646.I-D@ietf.org> --NextPart-- From Ruediger.Geib@telekom.de Wed Jul 8 06:19:39 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E13BB3A6945 for ; Wed, 8 Jul 2009 06:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.104 X-Spam-Level: X-Spam-Status: No, score=-3.104 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rv0HBcjkrfLJ for ; Wed, 8 Jul 2009 06:19:39 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 759E23A69D4 for ; Wed, 8 Jul 2009 06:19:38 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 08 Jul 2009 15:19:35 +0200 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jul 2009 15:19:35 +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 Date: Wed, 8 Jul 2009 15:19:28 +0200 Message-ID: <151C164FE2E066418D8D44D0801543A50198554A@S4DE8PSAAQA.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] SM Edge Behaviour Draft Thread-Index: Acn/zrf8dVHS//o4SZqOe3Gyoje1MQ== From: To: X-OriginalArrivalTime: 08 Jul 2009 13:19:35.0542 (UTC) FILETIME=[BCF70160:01C9FFCE] Cc: pcn@ietf.org Subject: [PCN] SM Edge Behaviour Draft X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 13:19:40 -0000 Tom, thanks for your work. The draft is clearer than the first version. I=20 still miss details how to measure an IEA. That the "howto" is an=20 issue isn't even mentioned in the draft. Regards, Ruediger Some comments: 1.1 terminology and following cahpters A new PCN node called "Policy Decision Point" is added to the = architecture.=20 The document does not explain where it is located and by which = interfaces=20 and priotocols it communicates. The draft text however seems to make = this PDP mandatory in some instances. My personal take: remove the "Policy Decision Point" and all references = to it from this draft and write an experimental architecture draft = explaining the concept. ----------------- 3.1 Overview 2nd section: ..."measured rate of flow of unmarked..."=20 replace by "..measured rate of unmarked.."=20 ----------------- 3.2.1 PCN Egress Node Role in flow admission new_CLE is the value of old_CLE during the next iteration, but the text=20 doesn't state that. As you never know what an implementor understands=20 from this text, the formula may be changed or text added. "k" should be from 0 < k < 1. The text should state that. Typo: Replace old-CLE/new-CLE by old_CLE/new_CLE ------------------ 3.4 Possible Extensions to the basic algorithm End of first section: "....is low (< 50 flows). " If this holds independent of the flow size, leave as is. If it makes a=20 difference whether these are voice calls or HD video streams, please=20 explain "50 flows" in sufficient detail. ------------------- 4.7 Environmental Concerns Please change the 2nd sentence If the mechanism flow termination can't be enabled, signaling the=20 corresponding state may be used to reduce traffic by other means=20 like codec adaptation or the drop of low priority video frames. This is however out of scope of the PCN WG. ------------------- 4.8 and 5. Security Considerations Delete one section. From Ruediger.Geib@telekom.de Wed Jul 8 07:07:12 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD4153A6F2E for ; Wed, 8 Jul 2009 07:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.14 X-Spam-Level: X-Spam-Status: No, score=-3.14 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZ-kcP9tSKeK for ; Wed, 8 Jul 2009 07:07:11 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 495DC3A6B9B for ; Wed, 8 Jul 2009 07:07:11 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 08 Jul 2009 16:00:13 +0200 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jul 2009 16:00:13 +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 Date: Wed, 8 Jul 2009 16:00:17 +0200 Message-ID: <151C164FE2E066418D8D44D0801543A5019855EE@S4DE8PSAAQA.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] CL Edge Behaviour Draft Thread-Index: Acn/zrf8dVHS//o4SZqOe3Gyoje1MQ== From: To: X-OriginalArrivalTime: 08 Jul 2009 14:00:13.0448 (UTC) FILETIME=[6A11F080:01C9FFD4] Cc: pcn@ietf.org Subject: [PCN] CL Edge Behaviour Draft X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 14:07:12 -0000 Tom, a second set of comments, on the CL draft. Thanks for your work. The draft is clearer than the first version. I=20 still miss details how to measure an IEA. That the "howto" is an=20 issue isn't even mentioned in the draft. Regards, Ruediger Some comments: 1.1 terminology and following chapters A new PCN node called "Policy Decision Point" is added to the = architecture.=20 The document does not explain where it is located and by which = interfaces=20 and priotocols it communicates. The draft text however seems to make = this PDP mandatory in some instances. My personal take: remove the "Policy Decision Point" and all references = to it from this draft and write an experimental architecture draft = explaining the concept. ----------------- 3.1 Overview Last section: "..supplies a list of excess-traffic-marked flows .."=20 This is an IntServ concept rather than a DiffServ one. While recognising = that dealing with ECMP is an issue, I don't like the idea of any per = flow=20 functionality on a backbone node. If you assume to be deployed in an=20 application gateway operating PCN per flow identification, please = mention=20 that. ----------------- 3.2.1 PCN Egress Node Role in flow admission new_CLE is the value of old_CLE during the next iteration, but the text=20 doesn't state that. As you never know what an implementor understands=20 from this text, the formula may be changed or text added. "k" should be from 0 < k < 1. The text should state that. ------------------ 3.2.2 PCN Egress Node Role in flow termination 1st section "...it immediately resets NM-count and ThM-count.." In this case, two measurement intervals have to pass to get an accurate=20 value of "old_CLE", is that correct? If not, the text should state this. 3rd section=20 "..to record flow identifiers.." As mentioned I don't like the concept. If maintained despite my concerns, please specify what a "flow=20 identifier" is. Formula/definition: "...ratio: R =3D ThM-count..." Here a new definition is applied for R while the ratio itself isn't=20 evaluated. Is it harmful to stick with the section 2.2.1 definition=20 of R while termination state is detected? Or asking differently,=20 could any error arise after termination state has ended and the ETM packets aren't accounted for the old_CLE values? I don't think so. ------------------- 3.3.2 PCN-Ingress-Node role in Flow Termination 1st section: "... It immediately begins to measure the rate.." This incurs more delay. ------------------- 4.5 Assumptions "Recovery from overloads should happen within 1-3 seconds." Collecting two CLE values at the egress is at minimum 200 ms. Informing the Ingress another 20 ms, say, which then starts to=20 measure, taking at least another 100 ms. In your draft, the=20 ingress must contact a PDP, that'll take another 50 ms (RTT). That's approximately 400 ms with processing and minimum=20 evaluation configurations. Isn't 1 second fairly optimistic=20 for a recovery from overload?=20 ------------------- 4.7 Environmental Concerns Please change the 2nd sentence If the mechanism flow termination can't be enabled, signaling the=20 corresponding state may be used to reduce traffic by other means=20 like codec adaptation or the drop of low priority video frames. This is however out of scope of the PCN WG. ------------------- 4.8 and 5. Security Considerations Delete one section. From Ruediger.Geib@telekom.de Wed Jul 8 07:14:44 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FF853A6889 for ; Wed, 8 Jul 2009 07:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.162 X-Spam-Level: X-Spam-Status: No, score=-3.162 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOmMuTe3xC4X for ; Wed, 8 Jul 2009 07:14:42 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 070483A680E for ; Wed, 8 Jul 2009 07:14:41 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 08 Jul 2009 16:07:24 +0200 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jul 2009 16:07:24 +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 Date: Wed, 8 Jul 2009 16:07:25 +0200 Message-ID: <151C164FE2E066418D8D44D0801543A501985609@S4DE8PSAAQA.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] A general concern on ECMP and IEA measurements Thread-Index: Acn/zrf8dVHS//o4SZqOe3Gyoje1MQ== From: To: X-OriginalArrivalTime: 08 Jul 2009 14:07:24.0756 (UTC) FILETIME=[6B265140:01C9FFD5] Cc: pcn@ietf.org Subject: [PCN] A general concern on ECMP and IEA measurements X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 14:14:44 -0000 Tom, while I read your drafts I noticed that a scenario with two (parallel) ECMP links passed by the same IEA may be an issue under the following=20 condition: - link 1 is in termination state - link 2 is in stop admission state Is an egress node able to determine which traffic to account for which=20 link? Regards, Ruediger Deutsche Telekom Netzproduktion GmbH=20 Zentrum Technik Einf=FChrung=20 Technik Internet Backbone, TE142-19 R=FCdiger Geib Heinrich Hertz Str. 3-7 64297 Darmstadt Tel.: 06151/6282747 Fax: 0251/7985109 Deutsche Telekom Netzproduktion (DT NP) GmbH Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr.: DE 814645262 From menth@informatik.uni-wuerzburg.de Thu Jul 9 14:56:37 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0372A28C277 for ; Thu, 9 Jul 2009 14:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XixmFvQr9upe for ; Thu, 9 Jul 2009 14:56:36 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id E0F4E28C216 for ; Thu, 9 Jul 2009 14:56:35 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 90F1A1991B0; Thu, 9 Jul 2009 23:56:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 833741991A5; Thu, 9 Jul 2009 23:56:56 +0200 (CEST) Received: from [192.168.1.2] (f051157049.adsl.alicedsl.de [78.51.157.49]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 4930C1991A2; Thu, 9 Jul 2009 23:56:56 +0200 (CEST) Message-ID: <4A5667A9.5090702@informatik.uni-wuerzburg.de> Date: Thu, 09 Jul 2009 23:56:57 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Ruediger.Geib@telekom.de References: <151C164FE2E066418D8D44D0801543A501985609@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <151C164FE2E066418D8D44D0801543A501985609@S4DE8PSAAQA.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] A general concern on ECMP and IEA measurements X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 21:56:37 -0000 Hi Ruediger, Ruediger.Geib@telekom.de schrieb: > Tom, > > while I read your drafts I noticed that a scenario with two (parallel) > ECMP links passed by the same IEA may be an issue under the following > condition: > > - link 1 is in termination state > - link 2 is in stop admission state > > Is an egress node able to determine which traffic to account for which > link? > From my perspective this is not possible. Nevertheless, CL does the termination right when the termination process takes into account which flows were marked, otherwise CL leads to overtermination as traffic on the AR-precongested link is also terminated. With SM this is worse since it is not always possible to detect SR-overload and if detected, the termination process leads to over- and undertermination on the two links. An extensive analyis of this issue can be found in Section 4.7 of http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth08-Sub-9b.pdf Regards, Michael > Regards, > > Ruediger > > > > Deutsche Telekom Netzproduktion GmbH > Zentrum Technik Einführung > Technik Internet Backbone, TE142-19 > Rüdiger Geib > Heinrich Hertz Str. 3-7 > 64297 Darmstadt > Tel.: 06151/6282747 > Fax: 0251/7985109 > > > Deutsche Telekom Netzproduktion (DT NP) GmbH > Aufsichtsrat: Timotheus Höttges (Vorsitzender) > Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren > Handelsregister: Amtsgericht Bonn HRB 14190 > Sitz der Gesellschaft: Bonn > USt-IdNr.: DE 814645262 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From slblake@petri-meat.com Mon Jul 13 11:32:13 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BA3428C560 for ; Mon, 13 Jul 2009 11:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95T2YmHpOkww for ; Mon, 13 Jul 2009 11:32:12 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 2E3FB3A69D3 for ; Mon, 13 Jul 2009 11:31:27 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=petri-meat.com) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1MQQJc-0003ic-0u for pcn@ietf.org; Mon, 13 Jul 2009 14:31:52 -0400 MIME-Version: 1.0 Date: Mon, 13 Jul 2009 14:31:51 -0400 From: To: pcn@ietf.org Message-ID: X-Sender: slblake@petri-meat.com User-Agent: RoundCube Webmail/0.2 Content-Type: multipart/mixed; boundary="=_a9e0f692714f542dbb688d9caaaadb27" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Subject: [PCN] Draft WG agenda for Stockholm X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 18:32:13 -0000 --=_a9e0f692714f542dbb688d9caaaadb27 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Greetings, Here is the draft agenda for PCN in Stockholm, based on the presentation requests. My personal email archives prior to July 1 are offline at the moment, so if you sent a request privately to me or Scott, please resend. Note that the secretariat changed the meeting time from Thursday to Monday (sorry Michael!). I "volunteered" some folks to present; please send corrections. I specifically need a presenter for the PSDM Encoding draft. The agenda is not tightly packed, so there is room to expand some slots if needed. Regards, // Steve --=_a9e0f692714f542dbb688d9caaaadb27 Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="UTF-8"; name="pcn-ietf75-agenda.txt"; Content-Disposition: attachment; filename="pcn-ietf75-agenda.txt"; Q29uZ2VzdGlvbiBhbmQgUHJlLUNvbmdlc3Rpb24gTm90aWZpY2F0aW9uIFdHIChwY24pCklFVEYg NzUgTWVldGluZyBBZ2VuZGEKCkNIQUlSczogU2NvdHQgQnJhZG5lciA8c29iQGhhcnZhcmQuZWR1 PgogICAgICAgIFN0ZXZlbiBCbGFrZSAgPHNibGFrZUBleHRyZW1lbmV0d29ya3MuY29tPgoKCk1P TkRBWSwgSnVseSAyNywgMjAwOQowOTAwLTExMzAgTW9ybmluZyBTZXNzaW9uIEkKUm9vbSAzMDAK PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09CgpBR0VOREE6CgpvIEFkbWluaXN0 cml2aWEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2hh aXJzICAxMCBtaW4KICAtIEJsdWUgc2hlZXRzCiAgLSBTY3JpYmUKICAtIEFnZW5kYSBiYXNoCiAg LSBNaWxlc3RvbmVzIHN0YXR1cwoKCm8gMyBTdGF0ZSBFbmNvZGluZyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBNb25jYXN0ZXIgIDE1IG1pbgogIGRyYWZ0LWlldGYt cGNuLTMtc3RhdGUtZW5jb2RpbmctMDAKCm8gMy1pbi0xIEVuY29kaW5nICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNb25jYXN0ZXIgIDE1IG1pbgogIGRyYWZ0LWll dGYtcGNuLTMtaW4tMS1lbmNvZGluZy0wMAoKbyBQU0RNIEVuY29kaW5nICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgID8/PyAgMTUgbWluCiAgZHJhZnQt aWV0Zi1wY24tcHNkbS1lbmNvZGluZy0wMAoKbyBFbmNvZGluZyBDb21wYXJpc29uICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ2hhbiAgMTAgbWluCiAgZHJhZnQt aWV0Zi1wY24tZW5jb2RpbmctY29tcGFyaXNvbi0wMAoKbyBDb250cm9sbGVkIExvYWQgRWRnZSBC ZWhhdmlvdXIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRheWxvciAgMTUgbWluCiAg ZHJhZnQtaWV0Zi1wY24tY2wtZWRnZS1iZWhhdmlvdXItMDAKCm8gU2luZ2xlIE1hcmtpbmcgRWRn ZSBCZWhhdmlvdXIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUYXlsb3IgIDE1IG1p bgogIGRyYWZ0LWlldGYtcGNuLXNtLWVkZ2UtYmVoYXZpb3VyLTAwCgpvIE5leHQgc3RlcHMgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY2hhaXJzICA0 NSBtaW4K --=_a9e0f692714f542dbb688d9caaaadb27-- From toby.moncaster@bt.com Tue Jul 14 01:34:20 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 339DC3A69F2 for ; Tue, 14 Jul 2009 01:34:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MLH_Stock1=0.87] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atd28axAmc+y for ; Tue, 14 Jul 2009 01:34:19 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 195333A6A6F for ; Tue, 14 Jul 2009 01:33:54 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.63]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 09:19:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 14 Jul 2009 09:19:45 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Draft WG agenda for Stockholm Thread-Index: AcoD6dWumvdJkH1XQzWvzCi5vmQYQQAcTN6Q References: From: To: , X-OriginalArrivalTime: 14 Jul 2009 08:19:46.0774 (UTC) FILETIME=[D94D5760:01CA045B] Subject: Re: [PCN] Draft WG agenda for Stockholm X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2009 08:34:20 -0000 SSdtIG5vdCBnb2luZyB0byBTdG9ja2hvbG0gc28gY2FuJ3QgcHJlc2VudCBhdCBhbGwuIEkgdGhp bmsgUGhpbCB3aWxsIHRha2UgbXkgcHJlc2VudGF0aW9uIHNsb3RzIGZvciBtZS4uLiBJIHdvdWxk IHN1Z2dlc3Qgcm9sbGluZyB0aGUgcHJlc2VudGF0aW9ucyBmb3IgdGhlIDMgZXhwZXJpbWVudGFs IGVuY29kaW5ncyAoMy1pbi0xLCAzLXN0YXRlIGFuZCBQU0RNKSBpbnRvIDEgc2Vzc2lvbiB0aGF0 IHdpbGwgcHJvYmFibHkgb25seSBuZWVkIDIwIG1pbnMgc2luY2UgdGhlcmUgaGF2ZSBiZWVuIHJl bGF0aXZlbHkgbWlub3IgY2hhbmdlcyB0byBhbGwgb2YgdGhlbSBzaW5jZSBsYXN0IHRpbWUuLi4N Cg0KVGhhdCB3b3VsZCBsZWF2ZSBhIDI1IG1pbiBzbG90IHRvIGhhdmUgYSBwcm9wZXIgZGlzY3Vz c2lvbiBvZiBob3cgd2UgdGhpbmsgdGhlIGV4cGVyaW1lbnRzIG1pZ2h0IGJlIHJ1biwgd2hhdCB3 b3VsZCBiZSB0aGUgY3JpdGVyaWEgdG8ganVkZ2UgdGhlaXIgc3VjY2Vzcywgd291bGQgdGhlcmUg bmVlZCB0byBiZSBhIGZvcm1hbCBkb2N1bWVudCB0byBleHBsYWluIHRoZSBwcm9jZXNzLCB3aGF0 IHdvdWxkIGJlIHRoZSBydWxlcyBhYm91dCByZWdpc3RlcmluZyBEU0NQcyBmb3IgZXhwZXJpbWVu dHMuIFRoaXMgd291bGRuJ3QganVzdCBiZSBsb29raW5nIGF0IHRoZSAzIGV4cGVyaW1lbnRhbCBl bmNvZGluZ3MgYnV0IHdvdWxkIGFsc28gY292ZXIgc3R1ZmYgbGlrZSB1c2luZyB0aGUgYmFzZWxp bmUgZW5jb2RpbmcgdG8gcnVuIGV4cGVyaW1lbnRzIGludG8gRGFpc3VrZSdzIG5ldyB2YXJpYW50 IG9mIHNpbmdsZSBtYXJraW5nLg0KDQpUb2J5DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogcGNuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpwY24tYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mDQo+IHNsYmxha2VAcGV0cmktbWVhdC5jb20NCj4gU2VudDogMTMg SnVseSAyMDA5IDE5OjMyDQo+IFRvOiBwY25AaWV0Zi5vcmcNCj4gU3ViamVjdDogW1BDTl0gRHJh ZnQgV0cgYWdlbmRhIGZvciBTdG9ja2hvbG0NCj4gDQo+IEdyZWV0aW5ncywNCj4gDQo+IEhlcmUg aXMgdGhlIGRyYWZ0IGFnZW5kYSBmb3IgUENOIGluIFN0b2NraG9sbSwgYmFzZWQgb24gdGhlDQo+ IHByZXNlbnRhdGlvbiByZXF1ZXN0cy4gIE15IHBlcnNvbmFsIGVtYWlsIGFyY2hpdmVzIHByaW9y IHRvIEp1bHkgMSBhcmUNCj4gb2ZmbGluZSBhdCB0aGUgbW9tZW50LCBzbyBpZiB5b3Ugc2VudCBh IHJlcXVlc3QgcHJpdmF0ZWx5IHRvIG1lIG9yDQo+IFNjb3R0LCBwbGVhc2UgcmVzZW5kLg0KPiAN Cj4gTm90ZSB0aGF0IHRoZSBzZWNyZXRhcmlhdCBjaGFuZ2VkIHRoZSBtZWV0aW5nIHRpbWUgZnJv bSBUaHVyc2RheSB0bw0KPiBNb25kYXkgKHNvcnJ5IE1pY2hhZWwhKS4gIEkgInZvbHVudGVlcmVk IiBzb21lIGZvbGtzIHRvIHByZXNlbnQ7IHBsZWFzZQ0KPiBzZW5kIGNvcnJlY3Rpb25zLiAgSSBz cGVjaWZpY2FsbHkgbmVlZCBhIHByZXNlbnRlciBmb3IgdGhlIFBTRE0NCj4gRW5jb2RpbmcgZHJh ZnQuDQo+IA0KPiBUaGUgYWdlbmRhIGlzIG5vdCB0aWdodGx5IHBhY2tlZCwgc28gdGhlcmUgaXMg cm9vbSB0byBleHBhbmQgc29tZSBzbG90cw0KPiBpZiBuZWVkZWQuDQo+IA0KPiANCj4gUmVnYXJk cywNCj4gDQo+IC8vIFN0ZXZlDQo= From rbriscoe@jungle.bt.co.uk Mon Jul 20 03:15:36 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 805A528C0CF for ; Mon, 20 Jul 2009 03:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.458 X-Spam-Level: X-Spam-Status: No, score=-0.458 tagged_above=-999 required=5 tests=[AWL=-1.659, BAYES_20=-0.74, DNS_FROM_RFC_BOGUSMX=1.482, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8ZdU5Wg7Zq2 for ; Mon, 20 Jul 2009 03:15:28 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 939E73A6B5D for ; Mon, 20 Jul 2009 03:13:45 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 11:09:19 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 11:09:19 +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 124808455867; Mon, 20 Jul 2009 11:09:18 +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 n6KA8U3E004790; Mon, 20 Jul 2009 11:08:31 +0100 Message-Id: <200907201008.n6KA8U3E004790@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 20 Jul 2009 11:07:13 +0100 To: "MONCASTER, Toby" From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 20 Jul 2009 10:09:19.0131 (UTC) FILETIME=[2535EEB0:01CA0922] Cc: PCN IETF list Subject: [PCN] pcn-3-in-1-encoding & IPv4 header checksum recalculation X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 10:15:36 -0000 Toby,

In pcn-3-in-1-encoding we should add a parenthesis reminding the implementer:

"
(The IPv4 header checksum changes when the ECN field changes.)
"
RFC3168 said how to update the checksum when ECT(0) -> CE
For ECT(1) -> CE it just said "it can be done similarly"

In 3-in-1 we also have ECT(0) - > ECT(1) and ECT(1) to CE transitions.

I don't think we need to say how the checksum should be updated in each case - an implementer can work this out. We just need to remind them to do it.


Bob


________________________________________________________________
Bob Briscoe,               Networks Research Centre, BT Research From rbriscoe@jungle.bt.co.uk Tue Jul 21 10:35:49 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E9523A6A81 for ; Tue, 21 Jul 2009 10:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-O80asAlLTv for ; Tue, 21 Jul 2009 10:35:42 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 195153A697B for ; Tue, 21 Jul 2009 10:35:41 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 18:35:27 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 18:35:27 +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 1248197727155; Tue, 21 Jul 2009 18:35:27 +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 n6LHZNq9009754; Tue, 21 Jul 2009 18:35:23 +0100 Message-Id: <200907211735.n6LHZNq9009754@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 21 Jul 2009 18:35:22 +0100 To: "tsvwg IETF list" , "PCN IETF list" From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 21 Jul 2009 17:35:27.0482 (UTC) FILETIME=[A2CDE5A0:01CA0A29] Subject: [PCN] draft-ietf-tsvwg-ecn-tunnel-03 update pending I-D queue X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 17:35:49 -0000 tsvwg & pcn folks, I've revised draft-ietf-tsvwg-ecn-tunnel to -03 after extensive review comments. Thanks for the deep reviews from Gorry Fairhurst, Michael Menth, Ingemar Johansson, Toby Moncaster and David Black. I didn't upload it in time for the draft deadline (sorry), but I've uploaded -03 to my personal Web site, while we wait for the queue to re-open: I shall be presenting the draft in the Security Area Advisory Group next week, as well as in tsvwg. As you may have noticed, there are still open discussions on the list, but I wanted to put the new revision up there, as it's had a major bashing. A summary of the changes is below... Bob =========================================================================== Tunnelling of Explicit Congestion Notification draft-ietf-tsvwg-ecn-tunnel-03 Abstract This document redefines how the explicit congestion notification (ECN) field of the IP header should be constructed on entry to and exit from any IP in IP tunnel. On encapsulation it updates RFC3168 to bring all IP in IP tunnels (v4 or v6) into line with RFC4301 IPsec ECN processing. On decapsulation it updates both RFC3168 and RFC4301 to add new behaviours for previously unused combinations of inner and outer header. The new rules propagate the ECN field whether it is used to signal one or two severity levels of congestion, whereas before they propagated only one. Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field (backward compatible). Nonetheless, operators wanting to support two severity levels (e.g. for pre-congestion notification--PCN) can require compliance with this new specification. A thorough analysis of the reasoning for these changes and the implications is included. From ietf-02 to ietf-03 (current): * Functional changes: + Corrected errors in recap of previous RFCs, which wrongly stated the different decapsulation behaviours of RFC3168 & RFC4301 with a Not-ECT inner header. This also required corrections to the "Changes from Earlier RFCs" and the Motivations for these changes. + Mandated that any future standards action SHOULD NOT use the ECT(0) codepoint as an indication of congestion, without giving strong reasons. + Added optional alarm when decapsulating ECT(1) outer, ECT(0), but noted it would need to be disabled for 2-severity level congestion (e.g. PCN). * Structural changes: + Removed Document Roadmap which merely repeated the Contents (previously Section 1.2). + Moved "Changes from Earlier RFCs" (Section 5) before Section 6 on Backward Compatibility and internally organised both by RFC, rather than by ingress then egress. + Moved motivation for changing existing RFCs (Section 5.3) to after the changes are specified. + Moved informative "Design Principles for Future Non-Default Schemes" after all the normative sections. + Added Appendix A on early history of ECN tunnelling RFCs. + Removed specialist appendix on "Relative Placement of Tunnelling and In-Path Load Regulation" (Appendix D in the -02 draft) + Moved and updated specialist text on "Compromise on Decap with ECT(1) Inner and ECT(0) Outer" from Security Considerations to Appendix F * Textual changes: + Simplified vocabulary for non-native-english speakers + Simplified Introduction and defined regularly used terms in an expanded Terminology section. + More clearly distinguished statically configured tunnels from dynamic tunnel endpoint discovery, before explaining operating modes. + Simplified, cut-down and clarified throughout + Updated references. ________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research From rbriscoe@jungle.bt.co.uk Wed Jul 22 03:26:27 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ACFA28C36D for ; Wed, 22 Jul 2009 03:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.746 X-Spam-Level: X-Spam-Status: No, score=-1.746 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3XpO79Dh8R8p for ; Wed, 22 Jul 2009 03:26:19 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 246EA28C1EE for ; Wed, 22 Jul 2009 03:26:18 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 11:25:22 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 11:25:22 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1248258321488; Wed, 22 Jul 2009 11:25:21 +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 n6MAPHrh028644; Wed, 22 Jul 2009 11:25:17 +0100 Message-Id: <200907221025.n6MAPHrh028644@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 22 Jul 2009 11:25:20 +0100 To: menth@informatik.uni-wuerzburg.de From: Bob Briscoe Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 22 Jul 2009 10:25:22.0249 (UTC) FILETIME=[B8199390:01CA0AB6] Cc: PCN IETF list Subject: Re: [PCN] draft-ietf-tsvwg-ecn-tunnel-03 and tunnelling PCN X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 10:26:27 -0000 Michael, I've added the PCN list to the distr as agreed. [PCN folks, this is an off-list thread that we=20 agreed would be useful on-list. I think the=20 context can be understood by starting at the=20 bottom - I've digested it a bit to help.] At 21:52 21/07/2009, Michael Menth wrote: >Hi Bob, > >thanks for your feedback. Yes, that makes sense=20 >to me. I summarized what I have understood from=20 >your Section 7 in my own words. It's a bit more=20 >general as it does not just apply do load=20 >regulation. Maybe this text shows you some=20 >alternative view of the same thing ;-) No, this isn't an alternative view, it's different. I'm trying to avoid needing specially coded=20 PCN-specific tunnel endpoints. I want to be able=20 to use off-the-shelf ecn-tunnel-compliant=20 encapsulator (E) and decapsulator (D) _functions_=20 that aren't specially coded to know about PCN. -------E--------------------------------D-------> \ / \PI---------->-------------PE/ ECN:=3DECT(0) ECN:=3DNot-ECT Then you can have an arrangement like the above.=20 The PCN ingress (PI) sets or resets the ECN field=20 to ECT(0) and the PCN egress (PE) zeroes it to Not-ECT. More inline... >Regards, > >Michael > > >Design Principles for Tunnelling Schemes over Segments with Local >Reuse of the ECN-Field The aim is that PCN does _not_ require an=20 alternate ECN _tunnelling_ scheme, it just=20 requires alternate ECN _marking_ semantics on=20 interior nodes. The "Don't" advice about=20 alternate ECN tunnelling in ecn-tunnel applies to PCN too. >ECN is an end-to-end protocol, but the ECN field can be reused for >local purposes under certain conditions. To preserve the >End-to-endness of ECN, tunnels may be used to bridge a segment >with alternative ECN semantics in order to protect the original >ECN field. This can be done using the [compatibility mode] which >sets the ECN field in the outer header to `00' upon encapsulation Why? As you say below, we want it eventually set=20 to a non-zero value, typically ECT(0), at the PCN ingress. >and ignores the ECN field in the outer header upon decapsulation. Note: an off-the-shelf egress compliant with=20 ecn-tunnel doesn't have modes. If you want an=20 ecn-tunnel egress (or any legacy egress for that=20 matter) to ignore the outer, it's safest to clear=20 the outer to 00 just before the decapsulator,=20 then the decapsulation rules will behave as if=20 the egress is ignoring the outer. >Additional rules regarding the outer ECN field may applied to >support its local reuse. For instance, directly after >encapsulation the ingress tunnel router may re-mark the `00' >codepoint to a typical ingress value and the egress tunnel router >may reset the locally reused ECN field to the neutral `00' just >before decapsulation. This avoids potential alarms. This is correct, but we didn't need compatibility=20 mode for PCN traffic to do this. We just needed=20 any tunnel, so I'd rather it was in normal mode,=20 then it will correctly support ECN-capable traffic, whether PCN-enabled or= not. One idea (drawn above) is to use normal mode for=20 the encapsulator _function_ for _all_ traffic,=20 without having to configure it to know what is=20 PCN traffic and what isn't. Otherwise the=20 encapsulation function has to be in compatibility=20 mode for PCN-enabled traffic and normal mode for non-PCN-enabled traffic. Alternatively (and better), a PCN ingress could=20 encapsulate (in the software sense, not the=20 tunnelling sense) off-the-shelf encapsulation=20 code (drawn below). This would be the only way to=20 avoid tunnelling non-PCN-enabled traffic=20 unnecessarily. I actually prefer this, as a PCN=20 ingress will always need to know the address of=20 the egress for PCN-enabled traffic, but it=20 shouldn't have to for non-PCN-enabled traffic,=20 which doesn't need to be tunnelled. +--------------------->---------------------+ ..........|.............. not tunnelled | : PCN- N : | :enabled?/\ :tunnelled | -:-------- -Y----E-------------->-----------------D---+----> : \/ \ : / : \------------>-------------PE/ : ECN:=3DECT(0): ECN:=3DNot-ECT :.......................: PCN-ingress (PI) The first alternative makes sense if you're=20 already tunnelling everything across the domain=20 (e.g. probably using MPLS or Ethernet but it=20 could be IP). The second alternative makes sense=20 if only PCN needs to determine the egress address to tunnel to. The text that explained all this was taken out of=20 the ecn-tunnel draft because I probably=20 over-generalised it (talking about in-path=20 load-regulators) when it primarily applied to PCN=20 (although it could apply to pseudo-wires too).=20 This fell between two stools (English idiom for=20 not hitting either of two alternate targets). The=20 scenario was too PCN-specific and the text was=20 too abstract. I can't think of a better place to=20 put an explanation like that, but it ought to be somewhere. Bob >Regards, > >Michael > > >Bob Briscoe schrieb: >>Michael, >> >>Thank you very much for you extensive review. I=20 >>hope the revised draft (see link in mail to pcn=20 >>copied below) is much more understandable. I=20 >>took all your suggestions into account, and=20 >>wherever you didn't understand it I tried hard=20 >>to think why and make amends. You were right in every case. >> >>One of your points needs a specific response.=20 >>Here's my text, your comment and my comment on=20 >>your comment (pasted from your Word file), then=20 >>the new text (pasted from the new draft): >> >>" RFC3168 also provided a Limited Functionality mode that turns off ECN >>processing over the scope of the tunnel. This is necessary if the >>ingress does not know whether the tunnel egress supports propagation >>of ECN markings.[LfII2] [RJB3] >> >>[LfII2] It=92s also useful for tunneling ECN=20 >>marks in PCN domains. This tunneling rule should remain as a useful= option. >> >>[RJB3] The new compatibility mode provides the=20 >>same per-packet behaviour as RFC3168 limited=20 >>functionality mode. However, it is not a mode=20 >>of the tunnel, only of the ingress, so I gave it a new name. >> >>PCN's tunnelling of ECN marks is another case=20 >>again. It doesn't set Not-ECT in the outer=20 >>header. It resets the ECN field in the outer header to ECT(0). >> >>But this is not an encapsulation behaviour =AD it=20 >>is a PCN-specific behaviour independent of=20 >>tunnelling. PCN resets the ECN field whether or=20 >>not there is a tunnel across the PCN region. If=20 >>the operator wants to preserve the e2e field,=20 >>it puts the encap function just before PCN does=20 >>the reset. This was explained in Appendix B=20 >>(which has been removed in draft-03 by popular=20 >>request). A short para about this has been put in S.7). >>" >> >>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >>7. Design Principles for Future Non-Default Schemes >>[snip] >> >> 1. If it has established that ECN will be correctly propagated, an >> encapsulator should also copy incoming congestion notification >> into the outer header. The general principle here is that the >> outer header should reflect congestion accumulated along the >> whole upstream path, not just since the tunnel ingress ( >> Appendix B.3 on management and monitoring explains). >> >> In some circumstances (e.g. pseudowires, PCN), the whole path is >> divided into segments, each with its own congestion notification >> and feedback loop. In these cases, the function that regulates >> load at the start of each segment will need to reset congestion >> notification for its segment. Often the point where congestion >> notification is reset will also be located at the start of a >> tunnel. However, the resetting function should be thought of as >> being applied to packets after the encapsulation function=ADtwo >> logically separate functions even though they might run on the >> same physical box. Then the code module doing encapsulation can >> keep to the copying rule and the load regulator module can reset >> congestion, without any code in either module being conditional on >> whether the other is there. >> >> >> >>Bob >> >>>Date: Tue, 21 Jul 2009 18:35:22 +0100 >>>To: "tsvwg IETF list" , "PCN IETF list" >>>From: Bob Briscoe >>>Subject: draft-ietf-tsvwg-ecn-tunnel-03 update pending I-D queue >>> >>>tsvwg & pcn folks, >>> >>>I've revised draft-ietf-tsvwg-ecn-tunnel to=20 >>>-03 after extensive review comments. Thanks=20 >>>for the deep reviews from Gorry Fairhurst,=20 >>>Michael Menth, Ingemar Johansson, Toby Moncaster and David Black. >>> >>>I didn't upload it in time for the draft=20 >>>deadline (sorry), but I've uploaded -03 to my=20 >>>personal Web site, while we wait for the queue to re-open: >>>< http://www.bobbriscoe.net/pubs.html#ecn-tunnel> [snip] ________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research =20 From rbriscoe@jungle.bt.co.uk Wed Jul 22 10:30:02 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2625D3A6820 for ; Wed, 22 Jul 2009 10:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n+DB6ETR-Cii for ; Wed, 22 Jul 2009 10:29:54 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id C922B3A689B for ; Wed, 22 Jul 2009 10:29:53 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 18:24:42 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 18:24:42 +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 1248283481918; Wed, 22 Jul 2009 18:24:41 +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 n6MHObMt005696; Wed, 22 Jul 2009 18:24:37 +0100 Message-Id: <200907221724.n6MHObMt005696@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 22 Jul 2009 18:24:21 +0100 To: Tom Taylor From: Bob Briscoe In-Reply-To: <20090706234501.413A83A6C08@core3.amsl.com> References: <20090706234501.413A83A6C08@core3.amsl.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 22 Jul 2009 17:24:42.0611 (UTC) FILETIME=[4CD82430:01CA0AF1] Cc: pcn@ietf.org, i-d-announce@ietf.org Subject: Re: [PCN] I-D Action:draft-ietf-pcn-cl-edge-behaviour-00.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 17:30:02 -0000 Tom and co-authors, Thanks for this draft. Here's my immediate thoughts up to start of S.3.3 on p9 (further comments will follow when I don't have to dash): 1/ The draft needs to say explicitly at the start that some things will need to be standardised to aid interworking, while some things can be left for vendors and operators to turn into their competitive advantage. Then throughout, each item should decalre which it is: - something essential for interworking, - or an example that could be improved on. As it stands, it's not clear what the purpose of describing all the pieces is. Examples: - excess-rate or threshold marking might initially trigger re-routing rather than respectively blocking or terminating flows. We can say this is possible, but we've not chosen to describe it here because it doesn't impact interworking. - Smoothing algorithms could be an area for innovation - Ditto for responding to flash crowds, etc 2/ As well as S.2 "Assumed Core Network Behaviour for CL", I felt the draft lacked a similar section "Assumed External Behaviour". All the actions seem to happen suspended in a vacuum, without saying what initiates them, or what carries messages between them. For instance, in 3.2.1 there are sentences saying "the egress reports that...", without saying what the report message is sent to. We probably don't need to say signalling system X, but we could say signalling system with properties like X or Y, where X=RSVP and Y=NSIS (say). 3/ Perhaps we need to think about what the CL-edge-behaviour is not. Certainly it's different from single marking. But why? Certainly it's different from a RACF-compatible solution. But why? I think the essence of these answers is that: - it's a solution that can potentially be completely distributed; - it allows 2 threshold rates to be independently set on each interior node, so that an operator can tailor the config of different parts of the network (or have them all the same if that works) - it is a way of putting together existing IETF standards without having to change them (or at least not significantly at all). I think it could also do with a (very brief) summary in such a section of what the goal is that this PDB is contributing to - ie one domain of an e2e controlled load service. 4/ S.3.2.1. It says that that CLE is _measured_ regularly. But then it gives a value with a justification as if the value is _reported_ regularly. They may need to be _measured_ regularly, but surely they only need to be reported when there's a flow signalling that it wants to start? I thought this was one aspect of the CL scenario that was different from, say, the RACF scenario? Or have I missed something. There is a significant difference between regularly beaconed signals that have to have their own reliable delivery, and signals piggy-backed on flow signalling that already has reliable delivery (because if it doesn't arrive, the flow doesn't start). "4.7. Environmental Concerns In some markets, traffic preemption is considered to be impermissible. In such environments, flow termination would not be enabled. " [even tho I said I hadn't reviewed it this far, my eye was caught by this heading]. This could refer to a misunderstanding of the US regulations. In the US, the admission of one flow (even an emergency services flow) is not allowed to preempt another. But the operator is allowed to terminate flows when network capacity unexpectedly reduces - in order to preserve service. However, I'm not sure what the US position is regarding choosing what to terminate. This is why we changed the terminology ages ago, from preemption to termination, which is what we meant. It otherwise unnecessarily rang alarm bells with people wary of the US regulations. Nits 1. Introduction s/the overall rate of PCN traffic is metered on every link/ /the fill of a virtual queue for all PCN traffic on a link is metered/ [my point here is one I always harp on about: the threshold metering algo measures variance as much as average rate, because they are both important.] 1.1 Definition of CLE shouldn't go into such details of how it is measured (which are items of debate). s/2. Assumed Core Network Behaviour for CL/ /2. Assumed Interior Node Behaviour for CL/ 3.1. s/the PDP gives preference to this list when determining which flows to terminate/the PDP chooses flows to terminate from this list/ [preference is confusing as it implies a nice outcome for the chosen ones] 3.2.1 Altho it's generally agreed that the choice of CLE threshold value isn't sensitive, I think 0.5 is unnecessarily high - this would make the system a bit sluggish I would have thought. Would 1/8 be a better choice (to choose another arbitrary but round number in binary)? Bob At 00:45 07/07/2009, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Congestion and Pre-Congestion >Notification Working Group of the IETF. > > > Title : PCN Boundary Node Behaviour for the > Controlled Load (CL) Mode of Operation > Author(s) : A. Charny, et al. > Filename : draft-ietf-pcn-cl-edge-behaviour-00.txt > Pages : 13 > Date : 2009-07-06 > >Precongestion notification (PCN) is a means for protecting quality of >service for inelastic traffic admitted to a Diffserv domain. The >overall PCN architecture is described in RFC 5559. This memo is one >of a series describing possible boundary node behaviours for a PCN >domain. The behaviour described here is that for three-state >measurement-based load control, known informally as Controlled Load >(CL). > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-pcn-cl-edge-behaviour-00.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. > > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn ________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research From rbriscoe@jungle.bt.co.uk Wed Jul 22 10:36:30 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF0CF3A6B91 for ; Wed, 22 Jul 2009 10:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.105 X-Spam-Level: X-Spam-Status: No, score=-1.105 tagged_above=-999 required=5 tests=[AWL=-0.384, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aA8mQ6UrkKeg for ; Wed, 22 Jul 2009 10:36:23 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id AC6513A689B for ; Wed, 22 Jul 2009 10:36:22 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 18:34:52 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 18:34:52 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1248284091596; Wed, 22 Jul 2009 18:34:51 +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 n6MHYjth006145; Wed, 22 Jul 2009 18:34:45 +0100 Message-Id: <200907221734.n6MHYjth006145@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 22 Jul 2009 18:34:49 +0100 To: menth@informatik.uni-wuerzburg.de From: Bob Briscoe In-Reply-To: <4A66EB1E.4090104@informatik.uni-wuerzburg.de> References: <200907211750.n6LHoeJk010104@bagheera.jungle.bt.co.uk> <4A662A70.4000208@informatik.uni-wuerzburg.de> <200907220940.n6M9egg5027846@bagheera.jungle.bt.co.uk> <4A66EB1E.4090104@informatik.uni-wuerzburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 22 Jul 2009 17:34:52.0111 (UTC) FILETIME=[B82275F0:01CA0AF2] Cc: pcn Subject: Re: [PCN] Fwd: draft-ietf-tsvwg-ecn-tunnel-03 update pending I-D queue X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 17:36:30 -0000 Michael, At 11:34 22/07/2009, Michael Menth wrote: >Hi Bob, > >comments inline. > >Bob Briscoe schrieb: >>Michael, >>[snip] >>>Additional rules regarding the outer ECN field may applied to >>>support its local reuse. For instance, directly after >>>encapsulation the ingress tunnel router may re-mark the `00' >>>codepoint to a typical ingress value and the egress tunnel router >>>may reset the locally reused ECN field to the neutral `00' just >>>before decapsulation. This avoids potential alarms. >> >>This is correct, but we didn't need=20 >>compatibility mode for PCN traffic to do this.=20 >>We just needed any tunnel, so I'd rather it was=20 >>in normal mode, then it will correctly support=20 >>ECN-capable traffic, whether PCN-enabled or not. >Do you mean first encapsulate PCN packets using=20 >normal (or any) mode and then set the PCN-DSCP=20 >and ECT(0) by specific PCN ingress functions?=20 >That makes sense to me, but must be stated explicitly. Yes. >I believe I know what you mean and I am=20 >technically with you. So what you want is probably the following, right? > >Design Principles for Tunnelling Traffic over=20 >Segments with Alternate ECN Semantics > >ECN is an end-to-end protocol, but the ECN field=20 >can be reused for local purposes under certain=20 >conditions. To preserve the end-to-endness of=20 >ECN, tunnels may be used to bridge a segment=20 >with alternative ECN semantics in order to=20 >protect the original ECN field. This can be done=20 >using any tunneling mode at the ingress. ...as far as PCN traffic is concerned (I merely=20 say this, because non-PCN traffic may well care=20 in my first alternative scenario). >Additional rules regarding the outer ECN field=20 >may applied to support its local reuse. That means, directly after >encapsulation the ingress tunnel router may=20 >re-mark the outer ECN field to a typical ingress=20 >value and the egress tunnel router resets the=20 >locally reused ECN field to the neutral `00' just before decapsulation. Yup. Bob >Regards, > >Michael > > >> >>The text that explained all this was taken out=20 >>of the ecn-tunnel draft because I probably=20 >>over-generalised it (talking about in-path=20 >>load-regulators) when it primarily applied to=20 >>PCN (although it could apply to pseudo-wires=20 >>too). This fell between two stools (English=20 >>idiom for not hitting either of two alternate=20 >>targets). The scenario was too PCN-specific and=20 >>the text was too abstract. I can't think of a=20 >>better place to put an explanation like that, but it ought to be= somewhere. >> >> >>Bob >> >> >> >> >>>Regards, >>> >>>Michael >>> >>> >>>Bob Briscoe schrieb: >>>>Michael, >>>> >>>>Thank you very much for you extensive review.=20 >>>>I hope the revised draft (see link in mail to=20 >>>>pcn copied below) is much more=20 >>>>understandable. I took all your suggestions=20 >>>>into account, and wherever you didn't=20 >>>>understand it I tried hard to think why and=20 >>>>make amends. You were right in every case. >>>> >>>>One of your points needs a specific response.=20 >>>>Here's my text, your comment and my comment=20 >>>>on your comment (pasted from your Word file),=20 >>>>then the new text (pasted from the new draft): >>>> >>>>" RFC3168 also provided a Limited Functionality mode that turns off ECN >>>>processing over the scope of the tunnel. [LfII1] This is necessary if= the >>>>ingress does not know whether the tunnel egress supports propagation >>>>of ECN markings.[LfII2] [RJB3] >>>> >>>>[LfII2] <#_msoanchor_2>It=92s also useful for=20 >>>>tunneling ECN marks in PCN domains. This=20 >>>>tunneling rule should remain as a useful option. >>>> >>>>[RJB3] <#_msoanchor_3>The new compatibility=20 >>>>mode provides the same per-packet behaviour=20 >>>>as RFC3168 limited functionality mode.=20 >>>>However, it is not a mode of the tunnel, only=20 >>>>of the ingress, so I gave it a new name. >>>> >>>>PCN's tunnelling of ECN marks is another case=20 >>>>again. It doesn't set Not-ECT in the outer=20 >>>>header. It resets the ECN field in the outer header to ECT(0). >>>> >>>>But this is not an encapsulation behaviour =AD=20 >>>>it is a PCN-specific behaviour independent of=20 >>>>tunnelling. PCN resets the ECN field whether=20 >>>>or not there is a tunnel across the PCN=20 >>>>region. If the operator wants to preserve the=20 >>>>e2e field, it puts the encap function just=20 >>>>before PCN does the reset. This was explained=20 >>>>in Appendix B (which has been removed in=20 >>>>draft-03 by popular request). A short para about this has been put in= S.7). >>>>" >>>> >>>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=20 >>>> >>>>7. Design Principles for Future Non-Default Schemes >>>>[snip] >>>> >>>>1. If it has established that ECN will be correctly propagated, an >>>>encapsulator should also copy incoming congestion notification >>>>into the outer header. The general principle here is that the >>>>outer header should reflect congestion accumulated along the >>>>whole upstream path, not just since the tunnel ingress ( >>>>Appendix B.3 >>>> >>>>=20 >>>> >>>>on management and monitoring explains). >>>> >>>>In some circumstances (e.g. pseudowires, PCN), the whole path is >>>>divided into segments, each with its own congestion notification >>>>and feedback loop. In these cases, the function that regulates >>>>load at the start of each segment will need to reset congestion >>>>notification for its segment. Often the point where congestion >>>>notification is reset will also be located at the start of a >>>>tunnel. However, the resetting function should be thought of as >>>>being applied to packets after the encapsulation function=ADtwo >>>>logically separate functions even though they might run on the >>>>same physical box. Then the code module doing encapsulation can >>>>keep to the copying rule and the load regulator module can reset >>>>congestion, without any code in either module being conditional on >>>>whether the other is there. >>>> >>>> >>>> >>>>Bob >>>> >>>>>Date: Tue, 21 Jul 2009 18:35:22 +0100 >>>>>To: "tsvwg IETF list" , "PCN IETF list" >>>>>From: Bob Briscoe >>>>>Subject: draft-ietf-tsvwg-ecn-tunnel-03 update pending I-D queue >>>>> >>>>>tsvwg & pcn folks, >>>>> >>>>>I've revised draft-ietf-tsvwg-ecn-tunnel to=20 >>>>>-03 after extensive review comments. Thanks=20 >>>>>for the deep reviews from Gorry Fairhurst,=20 >>>>>Michael Menth, Ingemar Johansson, Toby Moncaster and David Black. >>>>> >>>>>I didn't upload it in time for the draft=20 >>>>>deadline (sorry), but I've uploaded -03 to=20 >>>>>my personal Web site, while we wait for the queue to re-open: >>>>>< http://www.bobbriscoe.net/pubs.html#ecn-tunnel> >>>>> >>>>>I shall be presenting the draft in the=20 >>>>>Security Area Advisory Group next week, as well as in tsvwg. >>>>> >>>>>As you may have noticed, there are still=20 >>>>>open discussions on the list, but I wanted=20 >>>>>to put the new revision up there, as it's=20 >>>>>had a major bashing. A summary of the changes is below... >>>>> >>>>> >>>>>Bob >>>>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=20 >>>>> >>>>> >>>>>Tunnelling of Explicit Congestion Notification >>>>>draft-ietf-tsvwg-ecn-tunnel-03 >>>>> >>>>>Abstract >>>>> >>>>>This document redefines how the explicit congestion notification >>>>>(ECN) field of the IP header should be constructed on entry to and >>>>>exit from any IP in IP tunnel. On encapsulation it updates RFC3168 >>>>>to bring all IP in IP tunnels (v4 or v6) into line with RFC4301 IPsec >>>>>ECN processing. On decapsulation it updates both RFC3168 and RFC4301 >>>>>to add new behaviours for previously unused combinations of inner and >>>>>outer header. The new rules propagate the ECN field whether it is >>>>>used to signal one or two severity levels of congestion, whereas >>>>>before they propagated only one. Tunnel endpoints can be updated in >>>>>any order without affecting pre-existing uses of the ECN field >>>>>(backward compatible). Nonetheless, operators wanting to support two >>>>>severity levels (e.g. for pre-congestion notification--PCN) can >>>>>require compliance with this new specification. A thorough analysis >>>>>of the reasoning for these changes and the implications is included. >>>>> >>>>> >>>>> From ietf-02 to ietf-03 (current): >>>>> >>>>>* Functional changes: >>>>> >>>>>+ Corrected errors in recap of previous RFCs, which wrongly >>>>>stated the different decapsulation behaviours of RFC3168 & >>>>>RFC4301 with a Not-ECT inner header. This also required >>>>>corrections to the "Changes from Earlier RFCs" and the >>>>>Motivations for these changes. >>>>> >>>>>+ Mandated that any future standards action SHOULD NOT use the >>>>>ECT(0) codepoint as an indication of congestion, without >>>>>giving strong reasons. >>>>> >>>>>+ Added optional alarm when decapsulating ECT(1) outer, >>>>>ECT(0), but noted it would need to be disabled for >>>>>2-severity level congestion (e.g. PCN). >>>>> >>>>>* Structural changes: >>>>> >>>>>+ Removed Document Roadmap which merely repeated the Contents >>>>>(previously Section 1.2). >>>>> >>>>>+ Moved "Changes from Earlier RFCs" (Section 5) before >>>>>Section 6 on Backward Compatibility and internally organised >>>>>both by RFC, rather than by ingress then egress. >>>>> >>>>>+ Moved motivation for changing existing RFCs (Section 5.3) to >>>>>after the changes are specified. >>>>> >>>>>+ Moved informative "Design Principles for Future Non-Default >>>>>Schemes" after all the normative sections. >>>>> >>>>>+ Added Appendix A on early history of ECN tunnelling RFCs. >>>>> >>>>>+ Removed specialist appendix on "Relative Placement of >>>>>Tunnelling and In-Path Load Regulation" (Appendix D in the >>>>>-02 draft) >>>>> >>>>>+ Moved and updated specialist text on "Compromise on Decap >>>>>with ECT(1) Inner and ECT(0) Outer" from Security >>>>>Considerations to Appendix F >>>>> >>>>>* Textual changes: >>>>> >>>>>+ Simplified vocabulary for non-native-english speakers >>>>> >>>>>+ Simplified Introduction and defined regularly used terms in >>>>>an expanded Terminology section. >>>>> >>>>>+ More clearly distinguished statically configured tunnels >>>>>from dynamic tunnel endpoint discovery, before explaining >>>>>operating modes. >>>>> >>>>>+ Simplified, cut-down and clarified throughout >>>>> >>>>>+ Updated references. >>>>> >>>>> >>>>> >>>>>________________________________________________________________ >>>>>Bob Briscoe, Networks Research Centre, BT Research >>>> >>>>________________________________________________________________ >>>>Bob Briscoe, Networks Research Centre, BT Research >>> >>>-- >>>Dr. Michael Menth, Assistant Professor >>>University of Wuerzburg, Institute of Computer Science >>>Am Hubland, D-97074 Wuerzburg, Germany, room B206 >>>phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632 >>>mailto:menth@informatik.uni-wuerzburg.de >>>http://www3.informatik.uni-wuerzburg.de/research/ngn >> >>________________________________________________________________ >>Bob Briscoe, Networks Research Centre, BT Research > >-- >Dr. Michael Menth, Assistant Professor >University of Wuerzburg, Institute of Computer Science >Am Hubland, D-97074 Wuerzburg, Germany, room B206 >phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632 >mailto:menth@informatik.uni-wuerzburg.de >http://www3.informatik.uni-wuerzburg.de/research/ngn ________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research=20 From menth@informatik.uni-wuerzburg.de Wed Jul 22 13:19:36 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7D5C3A6B18 for ; Wed, 22 Jul 2009 13:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QxKRpzslhpR for ; Wed, 22 Jul 2009 13:19:35 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 89CF728C0F7 for ; Wed, 22 Jul 2009 13:18:50 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 3D7E51991C1; Wed, 22 Jul 2009 12:34:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 2E6D81991C0; Wed, 22 Jul 2009 12:34:07 +0200 (CEST) Received: from [132.187.12.151] (win3151.informatik.uni-wuerzburg.de [132.187.12.151]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 07C571991BE; Wed, 22 Jul 2009 12:34:07 +0200 (CEST) Message-ID: <4A66EB1E.4090104@informatik.uni-wuerzburg.de> Date: Wed, 22 Jul 2009 12:34:06 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Bob Briscoe References: <200907211750.n6LHoeJk010104@bagheera.jungle.bt.co.uk> <4A662A70.4000208@informatik.uni-wuerzburg.de> <200907220940.n6M9egg5027846@bagheera.jungle.bt.co.uk> In-Reply-To: <200907220940.n6M9egg5027846@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn Subject: Re: [PCN] Fwd: draft-ietf-tsvwg-ecn-tunnel-03 update pending I-D queue X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2009 20:19:36 -0000 Hi Bob, comments inline. Bob Briscoe schrieb: > Michael, > > No, this isn't an alternative view, it's different. > > I'm trying to avoid needing specially coded PCN-specific tunnel > endpoints. I want to be able to use off-the-shelf ecn-tunnel-compliant > encapsulator (E) and decapsulator (D) _functions_ that aren't > specially coded to know about PCN. > > -------E--------------------------------D-------> > \ / > \PI---------->-------------PE/ > ECN:=ECT(0) ECN:=Not-ECT > > Then you can have an arrangement like the above. The PCN ingress (PI) > sets or resets the ECN field to ECT(0) and the PCN egress (PE) zeroes > it to Not-ECT. > > More inline... > > At 21:52 21/07/2009, Michael Menth wrote: >> Hi Bob, >> >> thanks for your feedback. Yes, that makes sense to me. I summarized >> what I have understood from your Section 7 in my own words. It's a >> bit more general as it does not just apply do load regulation. Maybe >> this text shows you some alternative view of the same thing ;-) >> >> Regards, >> >> Michael >> >> >> Design Principles for Tunnelling Schemes over Segments with Local >> Reuse of the ECN-Field > > The aim is that PCN does _not_ require an alternate ECN _tunnelling_ > scheme, it just requires alternate ECN _marking_ semantics on interior > nodes. The "Don't" advice about alternate ECN tunnelling in ecn-tunnel > applies to PCN too. Yes, PCN does not require its own tunneling scheme, but it needs to apply the correct marking to the packets after encapsulation. > > >> ECN is an end-to-end protocol, but the ECN field can be reused for >> local purposes under certain conditions. To preserve the >> End-to-endness of ECN, tunnels may be used to bridge a segment >> with alternative ECN semantics in order to protect the original >> ECN field. This can be done using the [compatibility mode] which >> sets the ECN field in the outer header to `00' upon encapsulation > > Why? As you say below, we want it eventually set to a non-zero value, > typically ECT(0), at the PCN ingress. > >> and ignores the ECN field in the outer header upon decapsulation. > > Note: an off-the-shelf egress compliant with ecn-tunnel doesn't have > modes. If you want an ecn-tunnel egress (or any legacy egress for that > matter) to ignore the outer, it's safest to clear the outer to 00 just > before the decapsulator, then the decapsulation rules will behave as > if the egress is ignoring the outer. That makes sense and is fine with me. > >> Additional rules regarding the outer ECN field may applied to >> support its local reuse. For instance, directly after >> encapsulation the ingress tunnel router may re-mark the `00' >> codepoint to a typical ingress value and the egress tunnel router >> may reset the locally reused ECN field to the neutral `00' just >> before decapsulation. This avoids potential alarms. > > This is correct, but we didn't need compatibility mode for PCN traffic > to do this. We just needed any tunnel, so I'd rather it was in normal > mode, then it will correctly support ECN-capable traffic, whether > PCN-enabled or not. Do you mean first encapsulate PCN packets using normal (or any) mode and then set the PCN-DSCP and ECT(0) by specific PCN ingress functions? That makes sense to me, but must be stated explicitly. > > One idea (drawn above) is to use normal mode for the encapsulator > _function_ for _all_ traffic, without having to configure it to know > what is PCN traffic and what isn't. > Otherwise the encapsulation function has to be in compatibility mode > for PCN-enabled traffic and normal mode for non-PCN-enabled traffic. > > Alternatively (and better), a PCN ingress could encapsulate (in the > software sense, not the tunnelling sense) off-the-shelf encapsulation > code (drawn below). This would be the only way to avoid tunnelling > non-PCN-enabled traffic unnecessarily. I actually prefer this, as a > PCN ingress will always need to know the address of the egress for > PCN-enabled traffic, but it shouldn't have to for non-PCN-enabled > traffic, which doesn't need to be tunnelled. > > +--------------------->---------------------+ > ..........|.............. not tunnelled | > : PCN- N : | > :enabled?/\ :tunnelled | > -:-------- -Y----E-------------->-----------------D---+----> > : \/ \ : / > : \------------>-------------PE/ > : ECN:=ECT(0): ECN:=Not-ECT > :.......................: > PCN-ingress (PI) > > The first alternative makes sense if you're already tunnelling > everything across the domain (e.g. probably using MPLS or Ethernet but > it could be IP). The second alternative makes sense if only PCN needs > to determine the egress address to tunnel to. I believe I know what you mean and I am technically with you. So what you want is probably the following, right? Design Principles for Tunnelling Traffic over Segments with Alternate ECN Semantics ECN is an end-to-end protocol, but the ECN field can be reused for local purposes under certain conditions. To preserve the end-to-endness of ECN, tunnels may be used to bridge a segment with alternative ECN semantics in order to protect the original ECN field. This can be done using any tunneling mode at the ingress. Additional rules regarding the outer ECN field may applied to support its local reuse. That means, directly after encapsulation the ingress tunnel router may re-mark the outer ECN field to a typical ingress value and the egress tunnel router resets the locally reused ECN field to the neutral `00' just before decapsulation. Regards, Michael > > The text that explained all this was taken out of the ecn-tunnel draft > because I probably over-generalised it (talking about in-path > load-regulators) when it primarily applied to PCN (although it could > apply to pseudo-wires too). This fell between two stools (English > idiom for not hitting either of two alternate targets). The scenario > was too PCN-specific and the text was too abstract. I can't think of a > better place to put an explanation like that, but it ought to be > somewhere. > > > Bob > > > > >> Regards, >> >> Michael >> >> >> Bob Briscoe schrieb: >>> Michael, >>> >>> Thank you very much for you extensive review. I hope the revised >>> draft (see link in mail to pcn copied below) is much more >>> understandable. I took all your suggestions into account, and >>> wherever you didn't understand it I tried hard to think why and make >>> amends. You were right in every case. >>> >>> One of your points needs a specific response. Here's my text, your >>> comment and my comment on your comment (pasted from your Word file), >>> then the new text (pasted from the new draft): >>> >>> " RFC3168 also provided a Limited Functionality mode that turns off ECN >>> processing over the scope of the tunnel. [LfII1] This is necessary >>> if the >>> ingress does not know whether the tunnel egress supports propagation >>> of ECN markings.[LfII2] [RJB3] >>> >>> [LfII2] <#_msoanchor_2>It’s also useful for tunneling ECN marks in >>> PCN domains. This tunneling rule should remain as a useful option. >>> >>> [RJB3] <#_msoanchor_3>The new compatibility mode provides the same >>> per-packet behaviour as RFC3168 limited functionality mode. However, >>> it is not a mode of the tunnel, only of the ingress, so I gave it a >>> new name. >>> >>> PCN's tunnelling of ECN marks is another case again. It doesn't set >>> Not-ECT in the outer header. It resets the ECN field in the outer >>> header to ECT(0). >>> >>> But this is not an encapsulation behaviour ­ it is a PCN-specific >>> behaviour independent of tunnelling. PCN resets the ECN field >>> whether or not there is a tunnel across the PCN region. If the >>> operator wants to preserve the e2e field, it puts the encap function >>> just before PCN does the reset. This was explained in Appendix B >>> (which has been removed in draft-03 by popular request). A short >>> para about this has been put in S.7). >>> " >>> >>> ============================================================================ >>> >>> 7. Design Principles for Future Non-Default Schemes >>> [snip] >>> >>> 1. If it has established that ECN will be correctly propagated, an >>> encapsulator should also copy incoming congestion notification >>> into the outer header. The general principle here is that the >>> outer header should reflect congestion accumulated along the >>> whole upstream path, not just since the tunnel ingress ( >>> Appendix B.3 >>> >>> >>> >>> on management and monitoring explains). >>> >>> In some circumstances (e.g. pseudowires, PCN), the whole path is >>> divided into segments, each with its own congestion notification >>> and feedback loop. In these cases, the function that regulates >>> load at the start of each segment will need to reset congestion >>> notification for its segment. Often the point where congestion >>> notification is reset will also be located at the start of a >>> tunnel. However, the resetting function should be thought of as >>> being applied to packets after the encapsulation function­two >>> logically separate functions even though they might run on the >>> same physical box. Then the code module doing encapsulation can >>> keep to the copying rule and the load regulator module can reset >>> congestion, without any code in either module being conditional on >>> whether the other is there. >>> >>> >>> >>> Bob >>> >>>> Date: Tue, 21 Jul 2009 18:35:22 +0100 >>>> To: "tsvwg IETF list" , "PCN IETF list" >>>> From: Bob Briscoe >>>> Subject: draft-ietf-tsvwg-ecn-tunnel-03 update pending I-D queue >>>> >>>> tsvwg & pcn folks, >>>> >>>> I've revised draft-ietf-tsvwg-ecn-tunnel to -03 after extensive >>>> review comments. Thanks for the deep reviews from Gorry Fairhurst, >>>> Michael Menth, Ingemar Johansson, Toby Moncaster and David Black. >>>> >>>> I didn't upload it in time for the draft deadline (sorry), but I've >>>> uploaded -03 to my personal Web site, while we wait for the queue >>>> to re-open: >>>> < http://www.bobbriscoe.net/pubs.html#ecn-tunnel> >>>> >>>> I shall be presenting the draft in the Security Area Advisory Group >>>> next week, as well as in tsvwg. >>>> >>>> As you may have noticed, there are still open discussions on the >>>> list, but I wanted to put the new revision up there, as it's had a >>>> major bashing. A summary of the changes is below... >>>> >>>> >>>> Bob >>>> =========================================================================== >>>> >>>> >>>> Tunnelling of Explicit Congestion Notification >>>> draft-ietf-tsvwg-ecn-tunnel-03 >>>> >>>> Abstract >>>> >>>> This document redefines how the explicit congestion notification >>>> (ECN) field of the IP header should be constructed on entry to and >>>> exit from any IP in IP tunnel. On encapsulation it updates RFC3168 >>>> to bring all IP in IP tunnels (v4 or v6) into line with RFC4301 IPsec >>>> ECN processing. On decapsulation it updates both RFC3168 and RFC4301 >>>> to add new behaviours for previously unused combinations of inner and >>>> outer header. The new rules propagate the ECN field whether it is >>>> used to signal one or two severity levels of congestion, whereas >>>> before they propagated only one. Tunnel endpoints can be updated in >>>> any order without affecting pre-existing uses of the ECN field >>>> (backward compatible). Nonetheless, operators wanting to support two >>>> severity levels (e.g. for pre-congestion notification--PCN) can >>>> require compliance with this new specification. A thorough analysis >>>> of the reasoning for these changes and the implications is included. >>>> >>>> >>>> From ietf-02 to ietf-03 (current): >>>> >>>> * Functional changes: >>>> >>>> + Corrected errors in recap of previous RFCs, which wrongly >>>> stated the different decapsulation behaviours of RFC3168 & >>>> RFC4301 with a Not-ECT inner header. This also required >>>> corrections to the "Changes from Earlier RFCs" and the >>>> Motivations for these changes. >>>> >>>> + Mandated that any future standards action SHOULD NOT use the >>>> ECT(0) codepoint as an indication of congestion, without >>>> giving strong reasons. >>>> >>>> + Added optional alarm when decapsulating ECT(1) outer, >>>> ECT(0), but noted it would need to be disabled for >>>> 2-severity level congestion (e.g. PCN). >>>> >>>> * Structural changes: >>>> >>>> + Removed Document Roadmap which merely repeated the Contents >>>> (previously Section 1.2). >>>> >>>> + Moved "Changes from Earlier RFCs" (Section 5) before >>>> Section 6 on Backward Compatibility and internally organised >>>> both by RFC, rather than by ingress then egress. >>>> >>>> + Moved motivation for changing existing RFCs (Section 5.3) to >>>> after the changes are specified. >>>> >>>> + Moved informative "Design Principles for Future Non-Default >>>> Schemes" after all the normative sections. >>>> >>>> + Added Appendix A on early history of ECN tunnelling RFCs. >>>> >>>> + Removed specialist appendix on "Relative Placement of >>>> Tunnelling and In-Path Load Regulation" (Appendix D in the >>>> -02 draft) >>>> >>>> + Moved and updated specialist text on "Compromise on Decap >>>> with ECT(1) Inner and ECT(0) Outer" from Security >>>> Considerations to Appendix F >>>> >>>> * Textual changes: >>>> >>>> + Simplified vocabulary for non-native-english speakers >>>> >>>> + Simplified Introduction and defined regularly used terms in >>>> an expanded Terminology section. >>>> >>>> + More clearly distinguished statically configured tunnels >>>> from dynamic tunnel endpoint discovery, before explaining >>>> operating modes. >>>> >>>> + Simplified, cut-down and clarified throughout >>>> >>>> + Updated references. >>>> >>>> >>>> >>>> ________________________________________________________________ >>>> Bob Briscoe, Networks Research Centre, BT Research >>> >>> ________________________________________________________________ >>> Bob Briscoe, Networks Research Centre, BT Research >> >> -- >> Dr. Michael Menth, Assistant Professor >> University of Wuerzburg, Institute of Computer Science >> Am Hubland, D-97074 Wuerzburg, Germany, room B206 >> phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632 >> mailto:menth@informatik.uni-wuerzburg.de >> http://www3.informatik.uni-wuerzburg.de/research/ngn > > ________________________________________________________________ > Bob Briscoe, Networks Research Centre, BT Research -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From menth@informatik.uni-wuerzburg.de Wed Jul 22 17:29:23 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEB683A693F; Wed, 22 Jul 2009 17:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.514 X-Spam-Level: X-Spam-Status: No, score=-1.514 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zdi1spf2NMmb; Wed, 22 Jul 2009 17:29:22 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 4EDBE3A6405; Wed, 22 Jul 2009 17:29:22 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 2A17D1992AE; Wed, 22 Jul 2009 23:48:08 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 1E5FA1992A8; Wed, 22 Jul 2009 23:48:08 +0200 (CEST) Received: from [192.168.1.2] (g228028068.adsl.alicedsl.de [92.228.28.68]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id B7330A094C; Wed, 22 Jul 2009 23:48:07 +0200 (CEST) Message-ID: <4A678916.5070406@informatik.uni-wuerzburg.de> Date: Wed, 22 Jul 2009 23:48:06 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Bob Briscoe References: <20090706234501.413A83A6C08@core3.amsl.com> <200907221724.n6MHObMt005696@bagheera.jungle.bt.co.uk> In-Reply-To: <200907221724.n6MHObMt005696@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org, i-d-announce@ietf.org Subject: Re: [PCN] I-D Action:draft-ietf-pcn-cl-edge-behaviour-00.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 00:29:24 -0000 Hi Bob, Bob Briscoe schrieb: > Tom and co-authors, > > Thanks for this draft. > > Here's my immediate thoughts up to start of S.3.3 on p9 (further > comments will follow when I don't have to dash): > > 1/ The draft needs to say explicitly at the start that some things > will need to be standardised to aid interworking, while some things > can be left for vendors and operators to turn into their competitive > advantage. Then throughout, each item should decalre which it is: > - something essential for interworking, > - or an example that could be improved on. > As it stands, it's not clear what the purpose of describing all the > pieces is. > > Examples: > - excess-rate or threshold marking might initially trigger re-routing > rather than respectively blocking or terminating flows. We can say > this is possible, but we've not chosen to describe it here because it > doesn't impact interworking. > - Smoothing algorithms could be an area for innovation That's why it is important for admission control to signal from the egress to the ingress only admission-stop or admission-continue and keep the logic local to the egress node. > - Ditto for responding to flash crowds, etc > > 2/ As well as S.2 "Assumed Core Network Behaviour for CL", I felt the > draft lacked a similar section "Assumed External Behaviour". All the > actions seem to happen suspended in a vacuum, without saying what > initiates them, or what carries messages between them. For instance, > in 3.2.1 there are sentences saying "the egress reports that...", > without saying what the report message is sent to. > > We probably don't need to say signalling system X, but we could say > signalling system with properties like X or Y, where X=RSVP and Y=NSIS > (say). > > 3/ Perhaps we need to think about what the CL-edge-behaviour is not. > Certainly it's different from single marking. But why? Certainly it's > different from a RACF-compatible solution. But why? I think the > essence of these answers is that: > - it's a solution that can potentially be completely distributed; > - it allows 2 threshold rates to be independently set on each interior > node, so that an operator can tailor the config of different parts of > the network (or have them all the same if that works) > - it is a way of putting together existing IETF standards without > having to change them (or at least not significantly at all). > > I think it could also do with a (very brief) summary in such a section > of what the goal is that this PDB is contributing to - ie one domain > of an e2e controlled load service. > > 4/ S.3.2.1. > It says that that CLE is _measured_ regularly. But then it gives a > value with a justification as if the value is _reported_ regularly. > They may need to be _measured_ regularly, but surely they only need to > be reported when there's a flow signalling that it wants to start? I > thought this was one aspect of the CL scenario that was different > from, say, the RACF scenario? Or have I missed something. > > There is a significant difference between regularly beaconed signals > that have to have their own reliable delivery, and signals > piggy-backed on flow signalling that already has reliable delivery > (because if it doesn't arrive, the flow doesn't start). > > "4.7. Environmental Concerns > > In some markets, traffic preemption is considered to be > impermissible. In such environments, flow termination would not be > enabled. > " > > [even tho I said I hadn't reviewed it this far, my eye was caught by > this heading]. > This could refer to a misunderstanding of the US regulations. In the > US, the admission of one flow (even an emergency services flow) is not > allowed to preempt another. But the operator is allowed to terminate > flows when network capacity unexpectedly reduces - in order to > preserve service. However, I'm not sure what the US position is > regarding choosing what to terminate. > > This is why we changed the terminology ages ago, from preemption to > termination, which is what we meant. It otherwise unnecessarily rang > alarm bells with people wary of the US regulations. > > > > > Nits > > 1. Introduction > > s/the overall rate of PCN traffic is metered on every link/ > /the fill of a virtual queue for all PCN traffic on a link is metered/ > > [my point here is one I always harp on about: the threshold metering > algo measures variance as much as average rate, because they are both > important.] > > 1.1 Definition of CLE shouldn't go into such details of how it is > measured (which are items of debate). > > s/2. Assumed Core Network Behaviour for CL/ > /2. Assumed Interior Node Behaviour for CL/ > > 3.1. > s/the PDP gives preference to this list when determining which flows > to terminate/the PDP chooses flows to terminate from this list/ > [preference is confusing as it implies a nice outcome for the chosen > ones] > > 3.2.1 Altho it's generally agreed that the choice of CLE threshold > value isn't sensitive, I think 0.5 is unnecessarily high - this would > make the system a bit sluggish I would have thought. Would 1/8 be a > better choice (to choose another arbitrary but round number in binary)? With CL, the exact value of the CLE is not really important since when the admissible rate on a link is exceeded, that value immediately jumps from 0 to 1. Unless you have ECMP and unmarked packets from other paths dilute the signal ... Regards, Michael > > > Bob > > At 00:45 07/07/2009, Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Congestion and Pre-Congestion >> Notification Working Group of the IETF. >> >> >> Title : PCN Boundary Node Behaviour for the >> Controlled Load (CL) Mode of Operation >> Author(s) : A. Charny, et al. >> Filename : draft-ietf-pcn-cl-edge-behaviour-00.txt >> Pages : 13 >> Date : 2009-07-06 >> >> Precongestion notification (PCN) is a means for protecting quality of >> service for inelastic traffic admitted to a Diffserv domain. The >> overall PCN architecture is described in RFC 5559. This memo is one >> of a series describing possible boundary node behaviours for a PCN >> domain. The behaviour described here is that for three-state >> measurement-based load control, known informally as Controlled Load >> (CL). >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-pcn-cl-edge-behaviour-00.txt >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> >> >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn > > ________________________________________________________________ > Bob Briscoe, Networks Research Centre, BT Research > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From rbriscoe@jungle.bt.co.uk Thu Jul 23 01:05:05 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B6023A6909 for ; Thu, 23 Jul 2009 01:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[AWL=0.366, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhUsCbV-iKlH for ; Thu, 23 Jul 2009 01:04:59 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id A0E0D3A68D5 for ; Thu, 23 Jul 2009 01:04:58 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 09:00: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.3959); Thu, 23 Jul 2009 09:00:38 +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 1248336034776; Thu, 23 Jul 2009 09:00:34 +0100 Received: from mut.jungle.bt.co.uk ([10.73.0.78]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id n6N80VtW027352; Thu, 23 Jul 2009 09:00:31 +0100 Message-Id: <200907230800.n6N80VtW027352@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 23 Jul 2009 09:00:27 +0100 To: menth@informatik.uni-wuerzburg.de From: Bob Briscoe In-Reply-To: <4A678916.5070406@informatik.uni-wuerzburg.de> References: <20090706234501.413A83A6C08@core3.amsl.com> <200907221724.n6MHObMt005696@bagheera.jungle.bt.co.uk> <4A678916.5070406@informatik.uni-wuerzburg.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 23 Jul 2009 08:00:38.0527 (UTC) FILETIME=[AA9C80F0:01CA0B6B] Cc: pcn@ietf.org Subject: Re: [PCN] I-D Action:draft-ietf-pcn-cl-edge-behaviour-00.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 08:05:05 -0000 Michael, I've reversed the order of the two points below, as one depends on the other... At 22:48 22/07/2009, Michael Menth wrote: >Bob Briscoe schrieb: >>[BB] 3.2.1 Altho it's generally agreed that the choice of CLE >>threshold value isn't sensitive, I think 0.5 is unnecessarily high >>- this would make the system a bit sluggish I would have thought. >>Would 1/8 be a better choice (to choose another arbitrary but round >>number in binary)? >[MM] With CL, the exact value of the CLE is not really important >since when the admissible rate on a link is exceeded, that value >immediately jumps from 0 to 1. Unless you have ECMP and unmarked >packets from other paths dilute the signal ... Is this true with aggregated video traffic (or video + audio)? I believe the spikes in video (e.g. every time the action jumps to a new scene) and the general lumpiness don't all get smoothed out by aggregation. I don't recall the simulation results, but I thought the goal is that PCN threshold marking isn't just a rate-measuring machine, it's a rate and variance measuring machine. Then, even if the average rate is well below the threshold rate, threshold marking can still block more admissions if the traffic variance is also high (which threatens the QoS of admitted flows). But if variance is low, the average rate can naturally be closer to the threshold rate. If CLE does always toggle from 0 to 1, life would be easy, surely. Isn't the whole reason we're debating how to do EWMAs /hysteresis etc because CLE doesn't just toggle 0/1 in all circumstances. >>- Smoothing algorithms could be an area for innovation >That's why it is important for admission control to signal from the >egress to the ingress only admission-stop or admission-continue and >keep the logic local to the egress node. This is true if one assumes that CLE will effectively either be 0 or 1. If values in between have some meaning, then the actual value of CLE might be important to the PDP. But your point is a good one; it's no good reporting the CLE unless its meaning is standardised. Alternatively, if the meaning of the CLE isn't standardised, it makes more sense not to report it's exact value, just stop/go instead. Should we standardise the meaning of CLE? Bob >Regards, > > Michael > >> >> >>Bob >> >>At 00:45 07/07/2009, Internet-Drafts@ietf.org wrote: >>>A New Internet-Draft is available from the on-line Internet-Drafts >>>directories. >>>This draft is a work item of the Congestion and Pre-Congestion >>>Notification Working Group of the IETF. >>> >>> >>> Title : PCN Boundary Node Behaviour for the >>> Controlled Load (CL) Mode of Operation >>> Author(s) : A. Charny, et al. >>> Filename : draft-ietf-pcn-cl-edge-behaviour-00.txt >>> Pages : 13 >>> Date : 2009-07-06 >>> >>>Precongestion notification (PCN) is a means for protecting quality of >>>service for inelastic traffic admitted to a Diffserv domain. The >>>overall PCN architecture is described in RFC 5559. This memo is one >>>of a series describing possible boundary node behaviours for a PCN >>>domain. The behaviour described here is that for three-state >>>measurement-based load control, known informally as Controlled Load >>>(CL). >>> >>>A URL for this Internet-Draft is: >>>http://www.ietf.org/internet-drafts/draft-ietf-pcn-cl-edge-behaviour-00.txt >>> >>>Internet-Drafts are also available by anonymous FTP at: >>>ftp://ftp.ietf.org/internet-drafts/ >>> >>>Below is the data which will enable a MIME compliant mail reader >>>implementation to automatically retrieve the ASCII version of the >>>Internet-Draft. >>> >>> >>> >>> >>>_______________________________________________ >>>PCN mailing list >>>PCN@ietf.org >>>https://www.ietf.org/mailman/listinfo/pcn >> >>________________________________________________________________ >>Bob Briscoe, Networks Research Centre, BT Research >>_______________________________________________ >>PCN mailing list >>PCN@ietf.org >>https://www.ietf.org/mailman/listinfo/pcn > >-- >Dr. Michael Menth, Assistant Professor >University of Wuerzburg, Institute of Computer Science >Am Hubland, D-97074 Wuerzburg, Germany, room B206 >phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632 >mailto:menth@informatik.uni-wuerzburg.de >http://www3.informatik.uni-wuerzburg.de/research/ngn ________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research From menth@informatik.uni-wuerzburg.de Thu Jul 23 02:02:48 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 654953A6AA7 for ; Thu, 23 Jul 2009 02:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJ9QQGlC9CMh for ; Thu, 23 Jul 2009 02:02:47 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 193CE3A6A21 for ; Thu, 23 Jul 2009 02:02:47 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 78934199331; Thu, 23 Jul 2009 11:02:12 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 6C622199330; Thu, 23 Jul 2009 11:02:12 +0200 (CEST) Received: from [132.187.12.151] (win3151.informatik.uni-wuerzburg.de [132.187.12.151]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 4F7F7A0899; Thu, 23 Jul 2009 11:02:12 +0200 (CEST) Message-ID: <4A682710.8070902@informatik.uni-wuerzburg.de> Date: Thu, 23 Jul 2009 11:02:08 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Bob Briscoe References: <20090706234501.413A83A6C08@core3.amsl.com> <200907221724.n6MHObMt005696@bagheera.jungle.bt.co.uk> <4A678916.5070406@informatik.uni-wuerzburg.de> <200907230800.n6N80VtW027352@bagheera.jungle.bt.co.uk> In-Reply-To: <200907230800.n6N80VtW027352@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] I-D Action:draft-ietf-pcn-cl-edge-behaviour-00.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 09:02:48 -0000 Bob, Bob Briscoe schrieb: > Michael, > > I've reversed the order of the two points below, as one depends on the > other... > > At 22:48 22/07/2009, Michael Menth wrote: >> Bob Briscoe schrieb: >>> [BB] 3.2.1 Altho it's generally agreed that the choice of CLE >>> threshold value isn't sensitive, I think 0.5 is unnecessarily high - >>> this would make the system a bit sluggish I would have thought. >>> Would 1/8 be a better choice (to choose another arbitrary but round >>> number in binary)? >> [MM] With CL, the exact value of the CLE is not really important >> since when the admissible rate on a link is exceeded, that value >> immediately jumps from 0 to 1. Unless you have ECMP and unmarked >> packets from other paths dilute the signal ... > > Is this true with aggregated video traffic (or video + audio)? I > believe the spikes in video (e.g. every time the action jumps to a new > scene) and the general lumpiness don't all get smoothed out by > aggregation. I don't recall the simulation results, but I thought the > goal is that PCN threshold marking isn't just a rate-measuring > machine, it's a rate and variance measuring machine. Yes, all the token buckets are rate and variance measuring machines and the question is how much variance is allowed before admission should be stopped. What's a preliminary spike and what's the begin of an overload phase? > > Then, even if the average rate is well below the threshold rate, > threshold marking can still block more admissions if the traffic > variance is also high (which threatens the QoS of admitted flows). But > if variance is low, the average rate can naturally be closer to the > threshold rate. Ok, I see what you mean. The question is what you want to do in such a situation. Admit or block. Then you can adapt the admit/block threshold accordingly. But I think all these are corner cases when the PCN traffic rate is around the threshold rate. BTW, "threshold rate" is a terrible term ... > > If CLE does always toggle from 0 to 1, life would be easy, surely. > Isn't the whole reason we're debating how to do EWMAs /hysteresis etc > because CLE doesn't just toggle 0/1 in all circumstances. The whole debate is about what to do when CLE goes up and down - not necessarily toggle 0/1. When one can live with a admit/block change within 200 ms, then it's fine to do nothing. And this demanding scenario is not the general case. We have this situation only when the system is in blocking mode which is rather seldom, but especially then it must work. > >>> - Smoothing algorithms could be an area for innovation >> That's why it is important for admission control to signal from the >> egress to the ingress only admission-stop or admission-continue and >> keep the logic local to the egress node. > > This is true if one assumes that CLE will effectively either be 0 or > 1. If values in between have some meaning, then the actual value of > CLE might be important to the PDP. > > But your point is a good one; it's no good reporting the CLE unless > its meaning is standardised. Alternatively, if the meaning of the CLE > isn't standardised, it makes more sense not to report it's exact > value, just stop/go instead. > > Should we standardise the meaning of CLE? The CLE has already a different meaning for CL and SM which cannot be unified. Regards, Michael > > > Bob > > >> Regards, >> >> Michael >> >>> >>> >>> Bob >>> >>> At 00:45 07/07/2009, Internet-Drafts@ietf.org wrote: >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the Congestion and Pre-Congestion >>>> Notification Working Group of the IETF. >>>> >>>> >>>> Title : PCN Boundary Node Behaviour for the >>>> Controlled Load (CL) Mode of Operation >>>> Author(s) : A. Charny, et al. >>>> Filename : draft-ietf-pcn-cl-edge-behaviour-00.txt >>>> Pages : 13 >>>> Date : 2009-07-06 >>>> >>>> Precongestion notification (PCN) is a means for protecting quality of >>>> service for inelastic traffic admitted to a Diffserv domain. The >>>> overall PCN architecture is described in RFC 5559. This memo is one >>>> of a series describing possible boundary node behaviours for a PCN >>>> domain. The behaviour described here is that for three-state >>>> measurement-based load control, known informally as Controlled Load >>>> (CL). >>>> >>>> A URL for this Internet-Draft is: >>>> http://www.ietf.org/internet-drafts/draft-ietf-pcn-cl-edge-behaviour-00.txt >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> Below is the data which will enable a MIME compliant mail reader >>>> implementation to automatically retrieve the ASCII version of the >>>> Internet-Draft. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> PCN mailing list >>>> PCN@ietf.org >>>> https://www.ietf.org/mailman/listinfo/pcn >>> >>> ________________________________________________________________ >>> Bob Briscoe, Networks Research Centre, BT Research >>> _______________________________________________ >>> PCN mailing list >>> PCN@ietf.org >>> https://www.ietf.org/mailman/listinfo/pcn >> >> -- >> Dr. Michael Menth, Assistant Professor >> University of Wuerzburg, Institute of Computer Science >> Am Hubland, D-97074 Wuerzburg, Germany, room B206 >> phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632 >> mailto:menth@informatik.uni-wuerzburg.de >> http://www3.informatik.uni-wuerzburg.de/research/ngn > > ________________________________________________________________ > Bob Briscoe, Networks Research Centre, BT Research -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From fqhuang@huawei.com Thu Jul 23 02:51:26 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DEA403A68C9 for ; Thu, 23 Jul 2009 02:51:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.304 X-Spam-Level: * X-Spam-Status: No, score=1.304 tagged_above=-999 required=5 tests=[AWL=1.800, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-qGaOadzpsn for ; Thu, 23 Jul 2009 02:51:26 -0700 (PDT) Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 1C7BC3A67A2 for ; Thu, 23 Jul 2009 02:51:26 -0700 (PDT) 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 <0KN800CBLBA4UX@szxga01-in.huawei.com> for pcn@ietf.org; Thu, 23 Jul 2009 17:49:17 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KN800LK8BA43I@szxga01-in.huawei.com> for pcn@ietf.org; Thu, 23 Jul 2009 17:49:16 +0800 (CST) Received: from h36145c ([10.70.39.54]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KN800381BA4WS@szxml06-in.huawei.com> for pcn@ietf.org; Thu, 23 Jul 2009 17:49:16 +0800 (CST) Date: Thu, 23 Jul 2009 17:49:16 +0800 From: Fortune HUANG In-reply-to: <4A682710.8070902@informatik.uni-wuerzburg.de> To: menth@informatik.uni-wuerzburg.de, 'Bob Briscoe' Message-id: <002f01ca0b7a$d7bc7bd0$3627460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcoLdGHlcXjYvguHRginQAJJXNKT5gAAvJ2A Cc: pcn@ietf.org Subject: Re: [PCN] I-D Action:draft-ietf-pcn-cl-edge-behaviour-00.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2009 09:51:27 -0000 Hi Michael and Bob, >From the operation and management point of view, it would be better to have the configuration of the the CLE threshold for stop or go on the PDP but not on each egress node. My first preference would be to have a unified standardized CLE for both CL and SM if this is possible with some modifications in the current drafts. If this is not possible, I prefer to have the standardized CLE for CL and SM respectively. In this case, an extra information element indicating the type (CL, SM, etc.) of CLE should be included in the report to PDP. Best regards, Fortune -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Michael Menth Sent: Thursday, July 23, 2009 5:02 PM To: Bob Briscoe Cc: pcn@ietf.org Subject: Re: [PCN] I-D Action:draft-ietf-pcn-cl-edge-behaviour-00.txt ... ... > But your point is a good one; it's no good reporting the CLE unless > its meaning is standardised. Alternatively, if the meaning of the CLE > isn't standardised, it makes more sense not to report it's exact > value, just stop/go instead. > > Should we standardise the meaning of CLE? The CLE has already a different meaning for CL and SM which cannot be unified. ... ... From slblake@petri-meat.com Fri Jul 24 11:23:24 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBA0628C1B5 for ; Fri, 24 Jul 2009 11:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiAC3MVHqkzv for ; Fri, 24 Jul 2009 11:23:24 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 27B6A28C195 for ; Fri, 24 Jul 2009 11:23:24 -0700 (PDT) Received: from localhost ([127.0.0.1]) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1MUPQN-0004YI-9x for pcn@ietf.org; Fri, 24 Jul 2009 14:23:19 -0400 Received: from 75.182.69.209 ([75.182.69.209]) by petri-meat.com (Horde MIME library) with HTTP; Fri, 24 Jul 2009 14:23:19 -0400 Message-ID: <20090724142319.0t63x3bd8oowcso4@petri-meat.com> Date: Fri, 24 Jul 2009 14:23:19 -0400 From: slblake@petri-meat.com To: pcn@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Subject: [PCN] Presentation slides X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2009 18:23:24 -0000 Please send me your presentation slides for the PCN meeting Monday morning. PDF preferred (they are going to get converted anyway, you might as well do it). Thanks, // Steve From slblake@petri-meat.com Sun Jul 26 07:57:11 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04E113A69F3 for ; Sun, 26 Jul 2009 07:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TM6HXF+8c9N4 for ; Sun, 26 Jul 2009 07:57:10 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id 65C8A3A6983 for ; Sun, 26 Jul 2009 07:57:10 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=petri-meat.com) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1MV59u-0000A0-Ii for pcn@ietf.org; Sun, 26 Jul 2009 10:57:06 -0400 MIME-Version: 1.0 Date: Sun, 26 Jul 2009 10:57:06 -0400 From: To: pcn@ietf.org Message-ID: <9aa91d15875c175a28fa054e6842f2cc@petri-meat.com> X-Sender: slblake@petri-meat.com User-Agent: RoundCube Webmail/0.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Subject: [PCN] Volunteer scribes needed X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Jul 2009 14:57:11 -0000 Please volunteer to take minutes or Jabber notes for tomorrow's meeting. Thanks, // Steve From philip.eardley@bt.com Mon Jul 27 02:43:32 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 157AE3A6C60 for ; Mon, 27 Jul 2009 02:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.605 X-Spam-Level: X-Spam-Status: No, score=-1.605 tagged_above=-999 required=5 tests=[AWL=1.994, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYW7AOwzvhrd for ; Mon, 27 Jul 2009 02:43:31 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id E627A3A6C67 for ; Mon, 27 Jul 2009 02:43:30 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.111]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 10:43:05 +0100 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 Date: Mon, 27 Jul 2009 10:43:05 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC05DF88BA@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comment on draft-ietf-pcn-encoding-comparison Thread-Index: AcoOAV2xPd9hX+omR2q+I58wnXs3mAAmbpKQ References: <9aa91d15875c175a28fa054e6842f2cc@petri-meat.com> From: To: X-OriginalArrivalTime: 27 Jul 2009 09:43:05.0590 (UTC) FILETIME=[A432E160:01CA0E9E] Subject: [PCN] comment on draft-ietf-pcn-encoding-comparison X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 09:43:32 -0000 In a perfect world this would be a nice document to have, so I'm in = favour of it if it can realistically get done.=20 =20 However, i wanted to raise the question of how realistic this is? i = think there is a lot of work to do on it (for example: the text was = written before we realised the tunnelling issue, so the rationale for = the baseline encoding isn't covered; the text was written before = agreement on the various exptl encodings). Also, the reasoning behind = the baseline is well covered in the baseline, and the extensions could = include similar text explaining their rationale (by implication this = covers the reasons for rejecting a lot of the other possible encodings). = =20 I agree ideally it would be nice to collect all this reasoning into a = single document, but the question is whether this is the best use of the = WG effort? after all, nothing has happened to this draft since the last = ietf. So my suggestion would be to ask Lars whether it's ok to drop it, = and to make sure that any exptl encoding going forward to rfc includes = reasons for the choice of encoding. =20 phil =20 =20 From toby.moncaster@bt.com Mon Jul 27 03:51:00 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F04963A6C03 for ; Mon, 27 Jul 2009 03:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxIJC1-1BkuE for ; Mon, 27 Jul 2009 03:51:00 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id EDD103A6B84 for ; Mon, 27 Jul 2009 03:50:59 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.62]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 11:51:00 +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 Date: Mon, 27 Jul 2009 11:50:58 +0100 Message-ID: In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC05DF88BA@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] comment on draft-ietf-pcn-encoding-comparison Thread-Index: AcoOAV2xPd9hX+omR2q+I58wnXs3mAAmbpKQAAMfOyA= References: <9aa91d15875c175a28fa054e6842f2cc@petri-meat.com> <4A916DBC72536E419A0BD955EDECEDEC05DF88BA@E03MVB1-UKBR.domain1.systemhost.net> From: To: , X-OriginalArrivalTime: 27 Jul 2009 10:51:00.0460 (UTC) FILETIME=[2102B2C0:01CA0EA8] Subject: Re: [PCN] comment on draft-ietf-pcn-encoding-comparison X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 10:51:01 -0000 The essential thing is to make sure that we leave enough information for posterity to ensure that future WGs don't end up wasting effort on as many dead-ends as we did as a WG. This task is significantly simplified for us because Bob's ECN tunnelling draft explains why there are tunnelling limitations and reduces those limitations to a manageable subset. So if Bob's draft becomes RFC then (in combination with the baseline encoding and some slight additional text in extension documents) all the relevant info is probably recorded. If any of that made any sense... Toby > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > philip.eardley@bt.com > Sent: 27 July 2009 10:43 > To: pcn@ietf.org > Subject: [PCN] comment on draft-ietf-pcn-encoding-comparison >=20 > In a perfect world this would be a nice document to have, so I'm in > favour of it if it can realistically get done. >=20 >=20 >=20 > However, i wanted to raise the question of how realistic this is? i > think there is a lot of work to do on it (for example: the text was > written before we realised the tunnelling issue, so the rationale for > the baseline encoding isn't covered; the text was written before > agreement on the various exptl encodings). Also, the reasoning behind > the baseline is well covered in the baseline, and the extensions could > include similar text explaining their rationale (by implication this > covers the reasons for rejecting a lot of the other possible > encodings). >=20 >=20 >=20 > I agree ideally it would be nice to collect all this reasoning into a > single document, but the question is whether this is the best use of > the WG effort? after all, nothing has happened to this draft since the > last ietf. So my suggestion would be to ask Lars whether it's ok to > drop it, and to make sure that any exptl encoding going forward to rfc > includes reasons for the choice of encoding. >=20 >=20 >=20 > phil >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From ingemar.s.johansson@ericsson.com Mon Jul 27 05:33:06 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E356628C19D; Mon, 27 Jul 2009 05:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.249 X-Spam-Level: X-Spam-Status: No, score=-5.249 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOF+9dJQqwHl; Mon, 27 Jul 2009 05:33:06 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 5B52328C19C; Mon, 27 Jul 2009 05:33:05 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9dae00000519d-02-4a6d9e81d394 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 10.CA.20893.18E9D6A4; Mon, 27 Jul 2009 14:33:05 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 14:32:20 +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 Date: Mon, 27 Jul 2009 14:32:18 +0200 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C018EC284@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECN for UDP Thread-Index: AcoOtkf1hyHX9Y5uQruG0P1f7ood3g== From: "Ingemar Johansson S" To: , , , X-OriginalArrivalTime: 27 Jul 2009 12:32:20.0175 (UTC) FILETIME=[48CD95F0:01CA0EB6] X-Brightmail-Tracker: AAAAAA== Subject: [PCN] ECN for UDP X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 12:33:07 -0000 Hi Sorry for the cross-posting but I believe this is of interest not only = to AVT people.=20 I guess it is reasonable to make the replies only to tsv-area The 3GPP contributions below are probably interesting for those who = happen to follow the progress of the "ECN for UDP" drafts posted on the = avt page=20 Discussion paper: = http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_66bis/Docs/R2-093806.zip Change request: = http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_66bis/Docs/R2-094024.zip I would believe that the first paper is the most interesting. Regards Ingemar *******************************************=20 Ingemar Johansson=20 Senior Research Engineer, IETF "nethead"=20 EAB/TVK - Multimedia Technologies=20 Ericsson Research Ericsson AB=20 Box 920 S-971 28 Lule=E5, Sweden=20 Tel: +46 (0)10 7143042=20 ECN: 852-43042=20 ECC: 852-19042 Mobile: +46 (0)730 783289=20 Visit http://labs.ericsson.com ! *******************************************=20 From philip.eardley@bt.com Mon Jul 27 05:36:06 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3DA83A6C1E for ; Mon, 27 Jul 2009 05:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=0.997, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZo9VZAFza99 for ; Mon, 27 Jul 2009 05:36:05 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 4F8133A6BFB for ; Mon, 27 Jul 2009 05:36:05 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.111]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 13:36:05 +0100 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 Date: Mon, 27 Jul 2009 13:36:05 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC05DF88BC@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-pcn-cl-edge-behaviour (& draft-ietf-pcn-sm-edge-behaviour draft) Thread-Index: AcoOAV2xPd9hX+omR2q+I58wnXs3mAAmbpKQAAa8xKM= References: <9aa91d15875c175a28fa054e6842f2cc@petri-meat.com> <4A916DBC72536E419A0BD955EDECEDEC05DF88BA@E03MVB1-UKBR.domain1.systemhost.net> From: To: X-OriginalArrivalTime: 27 Jul 2009 12:36:05.0607 (UTC) FILETIME=[CF2BC770:01CA0EB6] Subject: [PCN] Comments on draft-ietf-pcn-cl-edge-behaviour (& draft-ietf-pcn-sm-edge-behaviour draft) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 12:36:06 -0000 Comments on draft-ietf-pcn-cl-edge-behaviour=20 Most of these also apply to the draft-ietf-pcn-sm-edge-behaviour draft =20 S1 "pcn uses dscp values" - could add 'in part' Could add ref to encoding drafts =20 S1.1 PDP definition This would be clarified by saying whether we assume it's at ingress or = elsewhere (will draft cover both cases?) =20 S3.1 "Flow termination may be spread out over a period of time to avoid = over-termination" Dasiuke's results show that you need to do two things:- - if you do a second round of termination, wait for the longest = RTT of the PCN-domain before you do a second lot of termination, = otherwise there is over-termination. RTT means the reaction time - how = long after the overload on a link before the load is reduced on the = link. The reason is that otherwise IEAs with short RTT don't take = account of the fact the other IEAs (with long RTT) are in the process of = terminating some flows - when measuring the sustainable rate, measure it over a short = period of time. Reason: otherwise measurement of sustanible-rate could = be too high, because part way through your measurement there's some = termination on IEAs with a short RTT =20 so some advice could be added on these lines, if we think these effects = likely in practice (rather than things that are only significant in = unlikely scenarios] =20 "[when alerted] the PCN-ingress-node similarly performs measurements to = determine the rate at which it is admitting PCN-traffic..." One option is for the ingress node to make this measurement = continuously, ie so the result is already known if needed - thus = speeding up the termination process. would it be any significant work to = measure this continuously? =20 "the pcn egress node supplies a list of excess-traffic-marked flows" - = this isn't compulsory. It's only useful if the pcn-domain is doing ecmp. =20 3.2.1 the egress measures the CLE over a fixed period. Does this period = need to be the same over whole pcn-domain? [not sure] =20 3.2.1 new_CLE =3D k*R + (1-k)*old_CLE I dont really see the gain of this. I think the draft should just = measure the CLE over one measurement period. But it should have a = statement that the operator might want to implement something beyond = this as a local optimisation. So you could do what you suggest or indeed = do a packet by packet EWMA (as in the old Briscoe-cl draft) =20 "in the absence of one of these two threshold crossing events the egress = issues no report" - this assumes the centralised PDP case, not true for = the rsvp etc case. I also assume that you'd also report periodically (to = confirm still in admit state etc and not crashed) - it also sets a = reliability requirement on the signalling =20 threshold-crossing is reported - this assumes centralised PDP, not true = for on-path signlling (where piggyback on return RSVP msg say I'd also add a recommendation that if there's no traffic currently on = the IEA, then (1) in the rsvp-style case, then look to see if the rsvp = request msg is pcn-marked (admit if it isn't); (2) in the centralised = case, then admit the new flow =20 3.2.2 & 3.3.2 The admission and termination are tied together in several ways. I don't = think this is a good idea. An operator may want to implement just = admission or just termination, and this should be easy. Also, from a = technical point of view I don't see why measurement of sustainable-rate = and CLE should be over same measurement period. The only link is that when you're doing termination on an IEA then you = shouldn't admit into that IEA =20 3.3.2 "when the pcn egress node detects an excess marked pkt, it transitions = to the excess traffic regime" - I'm not sure transiting when you see a = single marked pkt is best - perhaps you should wait to see more than = one. Also, if the operator knows that the network is using some lower = layer protection mechanism (eg switch in a new optical path), then you = may want to wait to give a chance for this mechanism to solve the = problem before you terminate any traffic. I think exactly when you = transit can be an implementation optimisation. =20 Should the egress report the CLE or should it report 'admit' or 'block'? I don't see a whole lot of difference. It's 8 bits versus 1 bit. There's = a slight advantage to reporting the CLE, in that there might be policy = to admit some flows ("important") if CLE is below one threshold and some = flows ("normal") only if CLE is below a lower threshold. [such policy = won't be known at the egress] In the on-path signalling case, then you don't have to signal CLE, you = could just use the existing RSVP msg (ie it just gets rejected if CLE is = too high) =20 S5 Security "No new security considerations" - Prevent a false termination msg would = be one security consideration? =20 S7 Acks "appendices" are referred to, but don't exist? From sblake@extremenetworks.com Mon Jul 27 17:14:47 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC02A3A698E for ; Mon, 27 Jul 2009 17:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.034 X-Spam-Level: ** X-Spam-Status: No, score=2.034 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LRn3Kz+1R2m for ; Mon, 27 Jul 2009 17:14:47 -0700 (PDT) Received: from ussc-casht-p1.extremenetworks.com (ussc-casht-p2.extremenetworks.com [207.179.9.62]) by core3.amsl.com (Postfix) with ESMTP id 2C84D3A68D9 for ; Mon, 27 Jul 2009 17:14:47 -0700 (PDT) Received: from [10.35.16.2] (10.35.16.2) by ussc-casht-p1.corp.extremenetworks.com (10.0.4.73) with Microsoft SMTP Server id 8.1.291.1; Mon, 27 Jul 2009 17:14:48 -0700 From: Steven Blake To: pcn Content-Type: text/plain Organization: Extreme Networks Date: Tue, 28 Jul 2009 00:14:22 +0000 Message-ID: <1248740062.3015.52.camel@ecliptic> MIME-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: 7bit Subject: [PCN] Testing X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2009 00:14:47 -0000 please ignore ///////////////////////////////////////////// Steven Blake sblake@extremenetworks.com Extreme Networks +1 919-884-3211 From karagian@cs.utwente.nl Wed Jul 29 09:24:16 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1913C3A6830 for ; Wed, 29 Jul 2009 09:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.892 X-Spam-Level: X-Spam-Status: No, score=0.892 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v+rRzObd3PmF for ; Wed, 29 Jul 2009 09:24:15 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 10EEE3A6774 for ; Wed, 29 Jul 2009 09:24:14 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id n6TGODBi025289; Wed, 29 Jul 2009 18:24:13 +0200 (MEST) Received: from 130.129.19.193 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Wed, 29 Jul 2009 16:24:17 +0000 To: "philip.eardley@bt.com" , "pcn@ietf.org" Date: Wed, 29 Jul 2009 16:24:16 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC05DF88BA@E03MVB1-UKBR.domain1.systemhost.net> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Wed, 29 Jul 2009 18:24:15 +0200 (MEST) Subject: Re: [PCN] comment on draft-ietf-pcn-encoding-comparison X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 16:24:16 -0000 Hi Phil Please see in line! On 7/27/2009, "philip.eardley@bt.com" wrote: >In a perfect world this would be a nice document to have, so I'm in favour o= f it if it can realistically get done. Georgios: I think that it can be done! my proposal is to provide the survey and comparison that have been done until the baseline encoding scheme has been chosen. I do not think that we need to include comparisons that are related to choices on the upcoming encoding proposals. This will actually satisfy the charter item and at the same time the draft can be completely very soon. Kwok and I are willing to spend time on completing this draft. > > > >However, i wanted to raise the question of how realistic this is? i think th= ere is a lot of work to do on it (for example: the text was written before we= realised the tunnelling issue, so the rationale for the baseline encoding is= n't covered; the text was written before agreement on the various exptl encod= ings). Also, the reasoning behind the baseline is well covered in the baselin= e, and the extensions could include similar text explaining their rationale (= by implication this covers the reasons for rejecting a lot of the other possi= ble encodings). Georgios: We should focus on the survey and comparison that was needed to select the baseline encoding document. This is already included in the curent version of the draft. if his goal is followed then we just need to do some refinements and editorials before completing the draft. > > > >I agree ideally it would be nice to collect all this reasoning into a single= document, but the question is whether this is the best use of the WG effort?= after all, nothing has happened to this draft since the last ietf. So my sug= gestion would be to ask Lars whether it's ok to drop it, and to make sure tha= t any exptl encoding going forward to rfc includes reasons for the choice of = encoding. Georgios: Please see my comments above! best regards, Georgios > > > >phil > > > > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn From menth@informatik.uni-wuerzburg.de Wed Jul 29 15:45:06 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF16D28C0F8 for ; Wed, 29 Jul 2009 15:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjxG2JjOnMs1 for ; Wed, 29 Jul 2009 15:45:05 -0700 (PDT) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by core3.amsl.com (Postfix) with ESMTP id 5C7C83A702D for ; Wed, 29 Jul 2009 15:45:05 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 257E0A07EB; Thu, 30 Jul 2009 00:45:04 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 18266A07DF; Thu, 30 Jul 2009 00:45:04 +0200 (CEST) Received: from [78.64.88.12] (host-78-64-88-12.homerun.telia.com [78.64.88.12]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id CAD721990E7; Thu, 30 Jul 2009 00:45:03 +0200 (CEST) Message-ID: <4A70D0F0.1030506@informatik.uni-wuerzburg.de> Date: Thu, 30 Jul 2009 00:45:04 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: philip.eardley@bt.com References: <9aa91d15875c175a28fa054e6842f2cc@petri-meat.com> <4A916DBC72536E419A0BD955EDECEDEC05DF88BA@E03MVB1-UKBR.domain1.systemhost.net> <4A916DBC72536E419A0BD955EDECEDEC05DF88BC@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC05DF88BC@E03MVB1-UKBR.domain1.systemhost.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: pcn@ietf.org Subject: Re: [PCN] Comments on draft-ietf-pcn-cl-edge-behaviour (& draft-ietf-pcn-sm-edge-behaviour draft) X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: menth@informatik.uni-wuerzburg.de List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2009 22:45:06 -0000 Hi all, philip.eardley@bt.com schrieb: > Comments on draft-ietf-pcn-cl-edge-behaviour > > Most of these also apply to the draft-ietf-pcn-sm-edge-behaviour draft > > > > S1 > > "pcn uses dscp values" - could add 'in part' > > Could add ref to encoding drafts > > > > S1.1 > > PDP definition > > This would be clarified by saying whether we assume it's at ingress or elsewhere (will draft cover both cases?) > > > > S3.1 > > "Flow termination may be spread out over a period of time to avoid over-termination" > > Dasiuke's results show that you need to do two things:- > > - if you do a second round of termination, wait for the longest RTT of the PCN-domain before you do a second lot of termination, otherwise there is over-termination. RTT means the reaction time - how long after the overload on a link before the load is reduced on the link. The reason is that otherwise IEAs with short RTT don't take account of the fact the other IEAs (with long RTT) are in the process of terminating some flows > > - when measuring the sustainable rate, measure it over a short period of time. Reason: otherwise measurement of sustanible-rate could be too high, because part way through your measurement there's some termination on IEAs with a short RTT > > > > so some advice could be added on these lines, if we think these effects likely in practice (rather than things that are only significant in unlikely scenarios] > > > > "[when alerted] the PCN-ingress-node similarly performs measurements to determine the rate at which it is admitting PCN-traffic..." > > One option is for the ingress node to make this measurement continuously, ie so the result is already known if needed - thus speeding up the termination process. would it be any significant work to measure this continuously? > > > > "the pcn egress node supplies a list of excess-traffic-marked flows" - this isn't compulsory. It's only useful if the pcn-domain is doing ecmp. > > > > 3.2.1 the egress measures the CLE over a fixed period. Does this period need to be the same over whole pcn-domain? [not sure] > > > > 3.2.1 new_CLE = k*R + (1-k)*old_CLE > > I dont really see the gain of this. I think the draft should just measure the CLE over one measurement period. But it should have a statement that the operator might want to implement something beyond this as a local optimisation. So you could do what you suggest or indeed do a packet by packet EWMA (as in the old Briscoe-cl draft) > > > > "in the absence of one of these two threshold crossing events the egress issues no report" - this assumes the centralised PDP case, not true for the rsvp etc case. I also assume that you'd also report periodically (to confirm still in admit state etc and not crashed) - it also sets a reliability requirement on the signalling > > > > threshold-crossing is reported - this assumes centralised PDP, not true for on-path signlling (where piggyback on return RSVP msg say > This piggybacking is not very clean: a property of the IEA is reported in a packet belonging to one of its subflows. It's a hack and I do not see its value. Is it to save bandwidth or the definition of an extra signalling protocol? The RSVP process needs to be modified to handle such information correctly, right? > > > I'd also add a recommendation that if there's no traffic currently on the IEA, then (1) in the rsvp-style case, then look to see if the rsvp request msg is pcn-marked (admit if it isn't); (2) in the centralised case, then admit the new flow > Hm, if this is acceptable, we have almost lightweight probing as needed for PSDM. But don't we need to change RSVP then? Indeed, probing solves the problem of empty IEAs. > > > 3.2.2 & 3.3.2 > > The admission and termination are tied together in several ways. I don't think this is a good idea. An operator may want to implement just admission or just termination, and this should be easy. Also, from a technical point of view I don't see why measurement of sustainable-rate and CLE should be over same measurement period. > > The only link is that when you're doing termination on an IEA then you shouldn't admit into that IEA > True. I also had this feeling. > > > 3.3.2 > > "when the pcn egress node detects an excess marked pkt, it transitions to the excess traffic regime" - I'm not sure transiting when you see a single marked pkt is best - perhaps you should wait to see more than one. Also, if the operator knows that the network is using some lower layer protection mechanism (eg switch in a new optical path), then you may want to wait to give a chance for this mechanism to solve the problem before you terminate any traffic. I think exactly when you transit can be an implementation optimisation. > > > > Should the egress report the CLE or should it report 'admit' or 'block'? > > I don't see a whole lot of difference. It's 8 bits versus 1 bit. There's a slight advantage to reporting the CLE, in that there might be policy to admit some flows ("important") if CLE is below one threshold and some flows ("normal") only if CLE is below a lower threshold. [such policy won't be known at the egress] > When using only admit/block there is more "optimization potential" at the egress regarding when to admit/block. For instance, observation-based AC can be implemented which does not need to wait until the end of a measurement interval. > In the on-path signalling case, then you don't have to signal CLE, you could just use the existing RSVP msg (ie it just gets rejected if CLE is too high) > > > > S5 Security > > "No new security considerations" - Prevent a false termination msg would be one security consideration? > > > > S7 Acks > > "appendices" are referred to, but don't exist? > Regards, Michael > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From tom.taylor@rogers.com Wed Jul 29 23:57:07 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C4AA3A6BE9 for ; Wed, 29 Jul 2009 23:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AAopq8mgXP-A for ; Wed, 29 Jul 2009 23:57:06 -0700 (PDT) Received: from smtp120.rog.mail.re2.yahoo.com (smtp120.rog.mail.re2.yahoo.com [68.142.224.75]) by core3.amsl.com (Postfix) with SMTP id 4BA343A6BC7 for ; Wed, 29 Jul 2009 23:57:05 -0700 (PDT) Received: (qmail 65002 invoked from network); 30 Jul 2009 06:57:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=N8zRgqIa6x5iFvqJoAZR4aazQKUEUBjBshnMW2++zx2giJZBpyGdDI2MYlEjmosN+LCfCK6hCp3Vqlo9+bUtBfha6qUKo8/GgtpjgQjqHGfwncwhVSkkWyflifB9CjlcDYosJf4T+d9K+X1LpPTd5/64ggTzPOP+UKEd7DTSeOo= ; Received: from unknown (HELO ?130.129.22.181?) (tom.taylor@130.129.22.181 with plain) by smtp120.rog.mail.re2.yahoo.com with SMTP; 30 Jul 2009 06:57:05 -0000 X-YMail-OSG: OscsnyIVM1neo0.tU.DnBql3Z.v.2S5nP3.S_0kDjAptk_TTfp4N68BNB3hMihZ2ww-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4A714440.1000309@rogers.com> Date: Thu, 30 Jul 2009 08:57:04 +0200 From: Tom Taylor User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: pcn Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [PCN] Reporting from the trailing edge X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 06:57:07 -0000 Phil, Anna and I were discussing the whole question of what the egress node reports the other day. Anna made it clearer for me why she was concerned with the existing state of the drafts. Because SM cannot decide on the need for termination without the help of the ingress node, the egress node has to send reports back to the ingress node whenever the admission state is "block". At the same time, when you are operating a system at design load, CL will be sending back threshold crossing reports very frequently, perhaps at the end of most measurement periods. We concluded that it made more sense to go back to the previous idea of shipping reports out at the end of every measurement period. In the PCN WG meeting we agreed that we should explore three signalling cases: - reports piggy-backed on resource signalling; - reports using asynchronous messaging over RSVP or GIST; These two I would call "on-path" signalling. The third possibility would be reports sent over a direct connection between the egress and ingress nodes (or PDP) using reliable transport such as TCP or SCTP. (No, Bob, we don't have to invent our own transport.) I call this alternative "direct signalling". Michael has questioned piggy-backing, and I'll let that discussion go on. In the meantime, please consider the proposal to report data every measurement period as in the pre-IETF drafts. Tom From karagian@cs.utwente.nl Thu Jul 30 01:21:15 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4A9328C202 for ; Thu, 30 Jul 2009 01:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.892 X-Spam-Level: X-Spam-Status: No, score=0.892 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeH2jK3mjzUr for ; Thu, 30 Jul 2009 01:21:15 -0700 (PDT) Received: from rotterdam.ewi.utwente.nl (rotterdam.ewi.utwente.nl [130.89.10.5]) by core3.amsl.com (Postfix) with ESMTP id 0843828C226 for ; Thu, 30 Jul 2009 01:19:56 -0700 (PDT) Received: from webmail.cs.utwente.nl (janus.ewi.utwente.nl [130.89.10.26]) by rotterdam.ewi.utwente.nl (8.13.6/8.13.6) with SMTP id n6U8JsIb002530; Thu, 30 Jul 2009 10:19:54 +0200 (MEST) Received: from 130.129.19.193 (auth. user karagian@imap1.ewi.utwente.nl) by webmail.cs.utwente.nl with HTTP; Thu, 30 Jul 2009 08:19:57 +0000 To: "Tom Taylor" , "pcn" Date: Thu, 30 Jul 2009 08:19:57 +0000 X-Mailer: IlohaMail/0.8.13 (On: webmail.cs.utwente.nl) Message-ID: In-Reply-To: <4A714440.1000309@rogers.com> From: "Georgios Karagiannis" Bounce-To: "Georgios Karagiannis" Errors-To: "Georgios Karagiannis" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.52 on 130.89.10.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (rotterdam.ewi.utwente.nl [130.89.10.5]); Thu, 30 Jul 2009 10:19:58 +0200 (MEST) Subject: Re: [PCN] Reporting from the trailing edge X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 08:21:15 -0000 Hi Tom I agree with the proposal of using the three classes of signaling requirements that edge behaviours have to support. The next step is to identify the content that has to be signaled and which of the requirements should be common for all edge behaviours, i.e., mandatory, and which of them should be optional that will only be needed by some edge behaviour drafts. I think that we could also use the above described classification for the signaling requirements draft. Best regards, Georgios On 7/30/2009, "Tom Taylor" wrote: >Phil, Anna and I were discussing the whole question of what the egress node >reports the other day. Anna made it clearer for me why she was concerned wit= h >the existing state of the drafts. Because SM cannot decide on the need for >termination without the help of the ingress node, the egress node has to sen= d >reports back to the ingress node whenever the admission state is "block". > >At the same time, when you are operating a system at design load, CL will be >sending back threshold crossing reports very frequently, perhaps at the end = of >most measurement periods. > >We concluded that it made more sense to go back to the previous idea of ship= ping >reports out at the end of every measurement period. > >In the PCN WG meeting we agreed that we should explore three signalling case= s: > > - reports piggy-backed on resource signalling; > - reports using asynchronous messaging over RSVP or GIST; >These two I would call "on-path" signalling. > >The third possibility would be reports sent over a direct connection between= the >egress and ingress nodes (or PDP) using reliable transport such as TCP or SC= TP. >(No, Bob, we don't have to invent our own transport.) I call this alternativ= e >"direct signalling". > >Michael has questioned piggy-backing, and I'll let that discussion go on. In= the >meantime, please consider the proposal to report data every measurement peri= od >as in the pre-IETF drafts. > >Tom >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn From philip.eardley@bt.com Thu Jul 30 04:32:46 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0353A28C200 for ; Thu, 30 Jul 2009 04:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3Due938YOPi for ; Thu, 30 Jul 2009 04:32:45 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id D62B728C1F1 for ; Thu, 30 Jul 2009 04:32:44 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.111]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 12:32:45 +0100 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 Date: Thu, 30 Jul 2009 12:28:51 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC05DF88E2@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] comment on draft-ietf-pcn-encoding-comparison Thread-Index: AcoQaQUY8zRT9QFeQyiOs+CaMw1puwAn+TWl References: From: To: , X-OriginalArrivalTime: 30 Jul 2009 11:32:45.0921 (UTC) FILETIME=[759EF510:01CA1109] Subject: Re: [PCN] comment on draft-ietf-pcn-encoding-comparison X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 11:32:46 -0000 =20 ________________________________ From: Georgios Karagiannis [mailto:karagian@cs.utwente.nl] Sent: Wed 29/07/2009 17:24 To: Eardley,PL,Philip,DER3 R; pcn@ietf.org Subject: Re: [PCN] comment on draft-ietf-pcn-encoding-comparison Hi Phil Please see in line! On 7/27/2009, "philip.eardley@bt.com" wrote: >In a perfect world this would be a nice document to have, so I'm in = favour of it if it can realistically get done. Georgios: I think that it can be done! my proposal is to provide the survey and comparison that have been done until the baseline encoding scheme has been chosen. I do not think that we need to include comparisons that are related to choices on the upcoming encoding proposals. This will actually satisfy the charter item and at the same time the draft can be completely very soon. Kwok and I are willing to spend time on completing this draft. [phil] that doesnt work. quite a few of the words and reasoning in the = draft is wrong, ie we learnt more since this draft was written quite = some time ago. the reason for selecting the baseline encoding isnt fully mentioned in = this draft [the tunnelling issue was realised subsequently] but is = covered in the baseline doc. the reasoning is simple & short:- - only one dscp [to save dscps] - non-pcn traffic can go in same sdcp [ditto] - cope with ecn tunnel egress re-setting non-11 codepoint=20 phil > > > >However, i wanted to raise the question of how realistic this is? i = think there is a lot of work to do on it (for example: the text was = written before we realised the tunnelling issue, so the rationale for = the baseline encoding isn't covered; the text was written before = agreement on the various exptl encodings). Also, the reasoning behind = the baseline is well covered in the baseline, and the extensions could = include similar text explaining their rationale (by implication this = covers the reasons for rejecting a lot of the other possible encodings). Georgios: We should focus on the survey and comparison that was needed = to select the baseline encoding document. This is already included in the curent version of the draft. if his goal is followed then we just need to do some refinements and editorials before completing the draft. > > > >I agree ideally it would be nice to collect all this reasoning into a = single document, but the question is whether this is the best use of the = WG effort? after all, nothing has happened to this draft since the last = ietf. So my suggestion would be to ask Lars whether it's ok to drop it, = and to make sure that any exptl encoding going forward to rfc includes = reasons for the choice of encoding. Georgios: Please see my comments above! best regards, Georgios > > > >phil > > > > > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn