From sob@harvard.edu Sat Jun 19 09:12:44 2010 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 844433A68CE for ; Sat, 19 Jun 2010 09:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.324 X-Spam-Level: X-Spam-Status: No, score=-0.324 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULyCSmushGig for ; Sat, 19 Jun 2010 09:12:43 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id DF46E3A68C1 for ; Sat, 19 Jun 2010 09:12:42 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 856D81444BC; Sat, 19 Jun 2010 12:12:48 -0400 (EDT) To: pcn@ietf.org Message-Id: <20100619161248.856D81444BC@newdev.eecs.harvard.edu> Date: Sat, 19 Jun 2010 12:12:48 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: [PCN] meeting in Mastricht? X-BeenThere: pcn@ietf.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: Sat, 19 Jun 2010 16:12:45 -0000 do we have a real need to meet in Mastricht? the IETF is short of meeting slots so our AD wants to be sure Scott From menth@informatik.uni-wuerzburg.de Sun Jun 20 17:00:41 2010 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 597323A68CB for ; Sun, 20 Jun 2010 17:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 lWf1TkBb1Yvu for ; Sun, 20 Jun 2010 17:00:40 -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 291EF3A6876 for ; Sun, 20 Jun 2010 17:00:39 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 1FCF45ACA3; Mon, 21 Jun 2010 02:00:43 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 1BE8D5AC9D; Mon, 21 Jun 2010 02:00:43 +0200 (CEST) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from [132.187.246.60] (wvpn060.vpn.uni-wuerzburg.de [132.187.246.60]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTPSA id D3BDF5D031; Mon, 21 Jun 2010 02:00:42 +0200 (CEST) Message-ID: <4C1EAB7D.7020909@informatik.uni-wuerzburg.de> Date: Mon, 21 Jun 2010 01:59:57 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Scott O. Bradner" References: <20100619161248.856D81444BC@newdev.eecs.harvard.edu> In-Reply-To: <20100619161248.856D81444BC@newdev.eecs.harvard.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn@ietf.org Subject: Re: [PCN] meeting in Mastricht? 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: Mon, 21 Jun 2010 00:00:41 -0000 Hi all, I will be for the next meeting in Maastricht and would welcome if we could move forward. Maybe a meeting speeds up the process of finalizing docs? I hope some of them are already mature enough? Best wishes, Michael Scott O. Bradner schrieb: > do we have a real need to meet in Mastricht? > > the IETF is short of meeting slots so our AD wants to be sure > > Scott > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > -- PD Dr. habil. 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/31-86632 (new) mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From philip.eardley@bt.com Mon Jun 21 02:17:30 2010 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 E18153A684A for ; Mon, 21 Jun 2010 02:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwzrzAA-Fcox for ; Mon, 21 Jun 2010 02:17:29 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 7FFC13A6895 for ; Mon, 21 Jun 2010 02:17:28 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.110]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Jun 2010 10:17:34 +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, 21 Jun 2010 10:17:34 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC063641A8@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4C1EAB7D.7020909@informatik.uni-wuerzburg.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] meeting in Mastricht? Thread-Index: AcsQ1NPTkPZJqBm7Q4G0vFUMofV4lQATah3Q From: To: , X-OriginalArrivalTime: 21 Jun 2010 09:17:34.0410 (UTC) FILETIME=[95731AA0:01CB1122] Cc: pcn@ietf.org Subject: Re: [PCN] meeting in Mastricht? X-BeenThere: pcn@ietf.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, 21 Jun 2010 09:17:31 -0000 I suppose that raises the obvious question - are there any updates for the various drafts? Best wishes phil > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On=20 > Behalf Of Michael Menth > Sent: 21 June 2010 01:00 > To: Scott O. Bradner > Cc: pcn@ietf.org > Subject: Re: [PCN] meeting in Mastricht? >=20 >=20 > Hi all, >=20 > I will be for the next meeting in Maastricht and would welcome if we=20 > could move forward. Maybe a meeting speeds up the process of=20 > finalizing=20 > docs? I hope some of them are already mature enough? >=20 > Best wishes, >=20 > Michael >=20 > Scott O. Bradner schrieb: > > do we have a real need to meet in Mastricht? > > > > the IETF is short of meeting slots so our AD wants to be sure > > > > Scott > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > =20 >=20 > --=20 > PD Dr. habil. 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/31-86632=20 > (new) mailto:menth@informatik.uni-wuerzburg.de > http://www3.informatik.uni-wuerzburg.de/research/ngn >=20 > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn >=20 From tom111.taylor@bell.net Mon Jun 21 20:37:29 2010 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 322433A67FC for ; Mon, 21 Jun 2010 20:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.104 X-Spam-Level: * X-Spam-Status: No, score=1.104 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRl6dN2mS+GK for ; Mon, 21 Jun 2010 20:37:28 -0700 (PDT) Received: from blu0-omc1-s10.blu0.hotmail.com (blu0-omc1-s10.blu0.hotmail.com [65.55.116.21]) by core3.amsl.com (Postfix) with ESMTP id B966D3A659B for ; Mon, 21 Jun 2010 20:37:26 -0700 (PDT) Received: from BLU0-SMTP36 ([65.55.116.7]) by blu0-omc1-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Jun 2010 20:37:33 -0700 X-Originating-IP: [70.26.19.89] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.26.19.89]) by BLU0-SMTP36.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Jun 2010 20:37:33 -0700 Date: Mon, 21 Jun 2010 23:37:30 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: pcn Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2010 03:37:33.0529 (UTC) FILETIME=[3FFD7490:01CB11BC] Subject: [PCN] CL edge behaviour-03 posted X-BeenThere: pcn@ietf.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, 22 Jun 2010 03:37:30 -0000 I have posted draft-ietf-pcn-cl-edge-behaviour-03.txt. I should warn you that Michael Menth disagrees with the proposal to send the calculated CLE along the raw rates. Authors Fortune Huang and Georgios Karagiannis have accepted it, and Anna Charny hasn't commented. I just figured it was time to get things moving. I'll provide a similar update to the SM edge behaviour draft tomorrow and give a detailed report of the differences from the previous versions. These drafts should then be ready for WGLC unless the chairs want to achieve a consensus on the CLE issue first. Tom Taylor From root@core3.amsl.com Mon Jun 21 20:45:03 2010 Return-Path: X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A372E3A67FC; Mon, 21 Jun 2010 20:45:02 -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: <20100622034503.A372E3A67FC@core3.amsl.com> Date: Mon, 21 Jun 2010 20:45:02 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-cl-edge-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: Tue, 22 Jun 2010 03:45:04 -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-03.txt Pages : 17 Date : 2010-06-21 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 a form of measurement-based load control using three PCN marking states, not PCN-marked, threshold-marked, and excess-traffic-marked. This behaviour is known informally as the Controlled Load (CL) PCN edge behaviour. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-cl-edge-behaviour-03.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-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-21203230.I-D@ietf.org> --NextPart-- From karagian@cs.utwente.nl Mon Jun 21 23:43:15 2010 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 4A7233A679C for ; Mon, 21 Jun 2010 23:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.096 X-Spam-Level: ** X-Spam-Status: No, score=2.096 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8L5jVCfG6H68 for ; Mon, 21 Jun 2010 23:43:14 -0700 (PDT) Received: from denhaag.ewi.utwente.nl (denhaag.ewi.utwente.nl [130.89.10.11]) by core3.amsl.com (Postfix) with ESMTP id 3C7443A65A6 for ; Mon, 21 Jun 2010 23:43:14 -0700 (PDT) Received: from ewi977 (ewi977.ewi.utwente.nl [130.89.12.129]) by denhaag.ewi.utwente.nl (8.13.6/8.13.6) with ESMTP id o5M6h7gF003790 for ; Tue, 22 Jun 2010 08:43:11 +0200 (MEST) From: "Georgios Karagiannis" To: "'pcn'" References: Date: Tue, 22 Jun 2010 08:43:03 +0200 Message-ID: <000101cb11d6$2d009ec0$810c5982@dynamic.ewi.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 In-Reply-To: Thread-Index: AcsRvE8slebr5J4hRBeU5XBW0i7U+AAGNwMg X-Scanned-By: MIMEDefang 2.52 on 130.89.10.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0rc3 (denhaag.ewi.utwente.nl [130.89.10.11]); Tue, 22 Jun 2010 08:43:20 +0200 (MEST) Subject: Re: [PCN] CL edge behaviour-03 posted X-BeenThere: pcn@ietf.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, 22 Jun 2010 06:43:15 -0000 Hi all I am updating the signaling draft, but before completing it I would like to know whether the proposals given in the edge behaviour drafts regarding signaling are accepted by the working group! Best regards, Georgios > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On > Behalf Of Tom Taylor > Sent: dinsdag 22 juni 2010 5:38 > To: pcn > Subject: [PCN] CL edge behaviour-03 posted > > I have posted draft-ietf-pcn-cl-edge-behaviour-03.txt. I > should warn you that Michael Menth disagrees with the > proposal to send the calculated CLE along the raw rates. > Authors Fortune Huang and Georgios Karagiannis have accepted > it, and Anna Charny hasn't commented. I just figured it was > time to get things moving. > > I'll provide a similar update to the SM edge behaviour draft > tomorrow and give a detailed report of the differences from > the previous versions. These drafts should then be ready for > WGLC unless the chairs want to achieve a consensus on the CLE > issue first. > > Tom Taylor > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > From menth@informatik.uni-wuerzburg.de Tue Jun 22 01:57:48 2010 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 3D70C3A6781 for ; Tue, 22 Jun 2010 01:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 tsFJNPMEnjwb for ; Tue, 22 Jun 2010 01:57: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 2C9F33A685C for ; Tue, 22 Jun 2010 01:57:47 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 28EFC5AE65; Tue, 22 Jun 2010 10:57:51 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 245235ACB8; Tue, 22 Jun 2010 10:57:51 +0200 (CEST) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from [132.187.12.151] (win3151.informatik.uni-wuerzburg.de [132.187.12.151]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTPSA id 0067E5CCE6; Tue, 22 Jun 2010 10:57:50 +0200 (CEST) Message-ID: <4C207B0F.1000105@informatik.uni-wuerzburg.de> Date: Tue, 22 Jun 2010 10:57:51 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Tom Taylor References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn Subject: Re: [PCN] CL edge behaviour-03 posted 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: Tue, 22 Jun 2010 08:57:48 -0000 Hi Tom, hi all, the egress node sends to the ingress node the rates of NM-, ThM-, and ETM-traffic. The CLE is computed as CLE=(Rates of ThM+ETM-traffic)/(Rates of NM+ThM+ETM-traffic). As it can be computed from the other data in a very simple way, including the CLE in the signalling message seems redundant to me. However, I don't want to delay things and can live with this redundant data as it is only little. It does no other harm than at most an infinitesimal contribution to global warming ;-) Apart from that, I would like to point out that CLE smoothing is harmful as it leads to overadmission in case of flash crowds. See Section IV.E in our revised paper at http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth08-Sub-8.pdf The mere existence of CLE smoothing in the draft is not harmful as long as it is not mandatory. So this is neither a reason to delay things. Best wishes, Michael Tom Taylor schrieb: > I have posted draft-ietf-pcn-cl-edge-behaviour-03.txt. I should warn > you that Michael Menth disagrees with the proposal to send the > calculated CLE along the raw rates. Authors Fortune Huang and Georgios > Karagiannis have accepted it, and Anna Charny hasn't commented. I just > figured it was time to get things moving. > > I'll provide a similar update to the SM edge behaviour draft tomorrow > and give a detailed report of the differences from the previous > versions. These drafts should then be ready for WGLC unless the chairs > want to achieve a consensus on the CLE issue first. > > Tom Taylor > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn -- PD Dr. habil. 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/31-86632 (new) mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From toby@moncaster.com Tue Jun 22 02:20:41 2010 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 835603A6782 for ; Tue, 22 Jun 2010 02:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.93 X-Spam-Level: * X-Spam-Status: No, score=1.93 tagged_above=-999 required=5 tests=[AWL=1.579, BAYES_50=0.001, 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 BXfxaPzS1MrD for ; Tue, 22 Jun 2010 02:20:36 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id 8A62B3A659A for ; Tue, 22 Jun 2010 02:20:36 -0700 (PDT) Received: from TobysHP (host86-170-50-165.range86-170.btcentralplus.com [86.170.50.165]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0MGXOi-1OMe4D2L3o-00DF3J; Tue, 22 Jun 2010 11:20:37 +0200 From: "Toby Moncaster" To: , "'Tom Taylor'" References: <4C207B0F.1000105@informatik.uni-wuerzburg.de> In-Reply-To: <4C207B0F.1000105@informatik.uni-wuerzburg.de> Date: Tue, 22 Jun 2010 10:20:38 +0100 Message-ID: <000901cb11ec$2ddc7dd0$89957970$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsR6QPcW6cAGxJwRueW2FHo8aVccQAAdQZw Content-Language: en-gb X-Provags-ID: V01U2FsdGVkX1/+Vg4g5714ZyMLxfAm8Jhsqr2k7bFoOA1emmQ pL5ETh70l26G9zzjXQGUwf1zayjpIIcEbED4CjKkwVhHGRe2fE cKNULasnvp/gpRre5qw7CfOe2eOLOWG Cc: 'pcn' Subject: Re: [PCN] CL edge behaviour-03 posted X-BeenThere: pcn@ietf.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, 22 Jun 2010 09:20:41 -0000 Hi All, It's been a good few months since I looked at PCN at all. In the meantime I have left BT, hence my new email address. I will (probably) start getting sporadically involved again over the next few weeks unless I get a new job before then... On to the meat of what I wanted to say: I will admit right now I haven't actually read this draft, but reading what Michael writes below, would it be possible to have a compromise along the following lines: "The ingress node can calculate the rates of CLE etc in the following manner: {set out appropriate equations}. However this requires the ingress to perform additional calculations which might not be desirable. In that case it would be sensible to explicitly send the CLE in the signalling message from the egress. This latter approach is RECOMMENDED, but an operator COULD calculate the rate instead" I know that isn't very well written, but it seems to me we don't need to make either of these a MUST as long as there is a MUST that the ingress has to find out the CLE somehow... Although no expert on hardware, I am sure there are instances where you wouldn't want to waste effort doing extra calculations at the ingress, equally I can think of times you would want to reduce the volume of signalling traffic... Toby > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Michael Menth > Sent: 22 June 2010 09:58 > To: Tom Taylor > Cc: pcn > Subject: Re: [PCN] CL edge behaviour-03 posted > > Hi Tom, hi all, > > the egress node sends to the ingress node the rates of NM-, ThM-, and > ETM-traffic. The CLE is computed as CLE=(Rates of > ThM+ETM-traffic)/(Rates of NM+ThM+ETM-traffic). As it can be computed > from the other data in a very simple way, including the CLE in the > signalling message seems redundant to me. However, I don't want to > delay > things and can live with this redundant data as it is only little. It > does no other harm than at most an infinitesimal contribution to global > warming ;-) > > Apart from that, I would like to point out that CLE smoothing is > harmful > as it leads to overadmission in case of flash crowds. See Section IV.E > in our revised paper at > http://www3.informatik.uni- > wuerzburg.de/~menth/Publications/papers/Menth08-Sub-8.pdf > The mere existence of CLE smoothing in the draft is not harmful as long > as it is not mandatory. So this is neither a reason to delay things. > > Best wishes, > > Michael > > > Tom Taylor schrieb: > > I have posted draft-ietf-pcn-cl-edge-behaviour-03.txt. I should warn > > you that Michael Menth disagrees with the proposal to send the > > calculated CLE along the raw rates. Authors Fortune Huang and > Georgios > > Karagiannis have accepted it, and Anna Charny hasn't commented. I > just > > figured it was time to get things moving. > > > > I'll provide a similar update to the SM edge behaviour draft tomorrow > > and give a detailed report of the differences from the previous > > versions. These drafts should then be ready for WGLC unless the > chairs > > want to achieve a consensus on the CLE issue first. > > > > Tom Taylor > > _______________________________________________ > > PCN mailing list > > PCN@ietf.org > > https://www.ietf.org/mailman/listinfo/pcn > > -- > PD Dr. habil. 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/31-86632 (new) > mailto:menth@informatik.uni-wuerzburg.de > http://www3.informatik.uni-wuerzburg.de/research/ngn > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From menth@informatik.uni-wuerzburg.de Tue Jun 22 05:53:26 2010 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 9E4263A6816 for ; Tue, 22 Jun 2010 05:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 4msjtzt7Ma8b for ; Tue, 22 Jun 2010 05:53:25 -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 C35FE3A67AC for ; Tue, 22 Jun 2010 05:53:24 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id A19AA5AC67; Tue, 22 Jun 2010 14:53:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 9E24D5AC42; Tue, 22 Jun 2010 14:53:29 +0200 (CEST) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from [132.187.12.151] (win3151.informatik.uni-wuerzburg.de [132.187.12.151]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTPSA id 79CD15CCE7; Tue, 22 Jun 2010 14:53:29 +0200 (CEST) Message-ID: <4C20B24A.2080705@informatik.uni-wuerzburg.de> Date: Tue, 22 Jun 2010 14:53:30 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "tom111.taylor@bell.net" References: <20100622034503.A372E3A67FC@core3.amsl.com> In-Reply-To: <20100622034503.A372E3A67FC@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn@ietf.org Subject: Re: [PCN] I-D Action:draft-ietf-pcn-cl-edge-behaviour-03.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: Tue, 22 Jun 2010 12:53:26 -0000 Hi Tom, according to the structure of the current draft, the big difference in reporting PCN data from egress to ingress (Section 3.2.2) is whether or not the CLE is included (see 3.2.2.1 and 3.2.2.2). I think that this is only a marginal issue. A major difference is whether reports are sent at the end of every measurement interval or whether some of them are suppressed. Would it be possible to have that reflected in 3.2.2?. Here is a draft proposal. 3.2.2 Egress Reports Section 3.2.2.1 explains which data the PCN-egress-node includes in egress reports and when it sends egress reports. Section 3.2.2.2 presents an optimization option that allows to reduce signalling traffic. 3.2.2.1 Reported Data At the end of each measurement interval, the PCN-egress-node sends the following aggregate-specific data to the ingress node in an egress report: o the rate of not-marked PCN traffic (NMR) o the rate of threshold-marked PCN traffic (TMR) o the rate of excess-traffic-marked PCN traffic (EMR) In networks with multipath routing, the PCN-egress-node SHOULD record identifiers of all or only a subset of flows for which excess-traffic-marked packets have been observed. The decision point may take advantage of this information when it selects flows for termination. In addition, the ingress node MAY calculate the CLE value from these data and include it in the report. 3.2.2.2 Signalling Reduction The absence of pre-congestion is the normal operation mode of a network, and the egress node does not observe any threshold-marked or excess-traffic-marked packets. In this case, the reported rates are not of interest for the decision point. Thus, it suffices that the egress node sends reports only a) when it has observed threshold-marked or excess-traffic-marked packets and b) when it has observed only not-marked packets in the first measurement interval after a period on measurement intervals with re-marked packets. In the absence of reports, the ingress node assumes that PCN data have not changed for the corresponding aggregate since the last egress report, i.e., that the egress node has observed only not-marked packets. Egress reports may be lost and they are also a demonstration of liveness to the decision point. Therefore, egress reports MUST be sent when a report timer Treport has expired. Depending on the transport used for reporting, the operator may choose to set value for the report timer Treport to an effectively infinite value. For example, the transport may include its own keep-alive signalling at a sufficiently frequent interval that liveness is not a concern for PCN. Comments o The reported rates and the calculation of the CLE should be defined in the terminology section. I used Treport instead of Tmax as it is more expressive. o I suggest to rename the variables NM-rate, ThM-rate, ETM-rate to NMR: rate of not-marked PCN traffic in octects per second TMR: rate of theshold-marked PCN traffic in octets per second EMT: rate of excess-traffic-mared PCN traffic in octects per second Reason: ther is nothing like a "not-marked rate" and the expression does not reveal whether it's a packet or a traffic rate. o Any other difference between the proposed text and the current draft is not intended. My intent is only to have clearer text. Best wishes, 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 Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation > Author(s) : A. Charny, et al. > Filename : draft-ietf-pcn-cl-edge-behaviour-03.txt > Pages : 17 > Date : 2010-06-21 > > 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 a form of > measurement-based load control using three PCN marking states, not > PCN-marked, threshold-marked, and excess-traffic-marked. This > behaviour is known informally as the Controlled Load (CL) PCN edge > behaviour. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pcn-cl-edge-behaviour-03.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 > -- PD Dr. habil. 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/31-86632 (new) mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From tom111.taylor@bell.net Tue Jun 22 08:39:14 2010 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 189CE3A67DB for ; Tue, 22 Jun 2010 08:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.061 X-Spam-Level: * X-Spam-Status: No, score=1.061 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pj3dpJjOx5hF for ; Tue, 22 Jun 2010 08:39:13 -0700 (PDT) Received: from blu0-omc1-s36.blu0.hotmail.com (blu0-omc1-s36.blu0.hotmail.com [65.55.116.47]) by core3.amsl.com (Postfix) with ESMTP id DB7C13A67AB for ; Tue, 22 Jun 2010 08:39:12 -0700 (PDT) Received: from BLU0-SMTP38 ([65.55.116.9]) by blu0-omc1-s36.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Jun 2010 08:39:19 -0700 X-Originating-IP: [70.26.19.89] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.26.19.89]) by BLU0-SMTP38.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Jun 2010 08:39:19 -0700 Date: Tue, 22 Jun 2010 11:39:15 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: menth@informatik.uni-wuerzburg.de References: <20100622034503.A372E3A67FC@core3.amsl.com> <4C20B24A.2080705@informatik.uni-wuerzburg.de> In-Reply-To: <4C20B24A.2080705@informatik.uni-wuerzburg.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2010 15:39:19.0965 (UTC) FILETIME=[14A32CD0:01CB1221] Cc: pcn@ietf.org Subject: Re: [PCN] I-D Action:draft-ietf-pcn-cl-edge-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: Tue, 22 Jun 2010 15:39:14 -0000 The use of marked vs. not-marked traffic as the suppression criterion in place of the zero-traffic and below-threshold CLE criteria is a good compromise, particularly for the CL edge behaviour. I'll reorganize along these lines. Calculation and reporting of CLE then becomes a purely optional affair -- a configurable decision whether to calculate CLE at the egress node or at the decision point. That will be another subsection following the one on signalling reduction. I was starting to worry about the number of configurable parameters, so it's good to get rid of one of them (CLErep) at least. Michael Menth wrote: > Hi Tom, > > according to the structure of the current draft, the big difference in > reporting PCN data from egress to ingress (Section 3.2.2) is whether or > not the CLE is included (see 3.2.2.1 and 3.2.2.2). I think that this is > only a marginal issue. A major difference is whether reports are sent at > the end of every measurement interval or whether some of them are > suppressed. Would it be possible to have that reflected in 3.2.2?. Here > is a draft proposal. > > 3.2.2 Egress Reports > Section 3.2.2.1 explains which data the PCN-egress-node includes in > egress reports and when it sends egress reports. Section 3.2.2.2 > presents an optimization option that allows to reduce signalling traffic. > > 3.2.2.1 Reported Data > > At the end of each measurement interval, the PCN-egress-node sends the > following aggregate-specific data to the ingress node in an egress report: > o the rate of not-marked PCN traffic (NMR) > o the rate of threshold-marked PCN traffic (TMR) > o the rate of excess-traffic-marked PCN traffic (EMR) > > In networks with multipath routing, the PCN-egress-node SHOULD record > identifiers of all or only a subset of flows for which > excess-traffic-marked packets have been observed. The decision point > may take advantage of this information when it selects flows for > termination. In addition, the ingress node MAY calculate the CLE value > from these data and include it in the report. > > > 3.2.2.2 Signalling Reduction > > The absence of pre-congestion is the normal operation mode of a network, > and the egress node does not observe any threshold-marked or > excess-traffic-marked packets. In this case, the reported rates are not > of interest for the decision point. Thus, it suffices that the egress > node sends reports only > a) when it has observed threshold-marked or excess-traffic-marked > packets and > b) when it has observed only not-marked packets in the first measurement > interval after a period on measurement intervals with re-marked packets. > > In the absence of reports, the ingress node assumes that PCN data have > not changed for the corresponding aggregate since the last egress > report, i.e., that the egress node has observed only not-marked packets. > > Egress reports may be lost and they are also a demonstration of liveness > to the decision point. Therefore, egress reports MUST be sent when a > report timer Treport has expired. Depending on the transport used for > reporting, > the operator may choose to set value for the report timer Treport to an > effectively infinite value. For example, the transport may include its > own keep-alive signalling at a sufficiently frequent interval that > liveness is not a concern for PCN. > > Comments > o The reported rates and the calculation of the CLE should be defined in > the terminology section. > I used Treport instead of Tmax as it is more expressive. > o I suggest to rename the variables NM-rate, ThM-rate, ETM-rate to > NMR: rate of not-marked PCN traffic in octects per second > TMR: rate of theshold-marked PCN traffic in octets per second > EMT: rate of excess-traffic-mared PCN traffic in octects per second > Reason: ther is nothing like a "not-marked rate" and the expression > does not reveal whether it's a packet or a traffic rate. > o Any other difference between the proposed text and the current draft > is not intended. My intent is only to have clearer text. > > > Best wishes, > > Michael > ... From root@core3.amsl.com Tue Jun 22 11:45:03 2010 Return-Path: X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F174F3A6943; Tue, 22 Jun 2010 11:45:02 -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: <20100622184502.F174F3A6943@core3.amsl.com> Date: Tue, 22 Jun 2010 11:45:02 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-cl-edge-behaviour-04.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 18:45:03 -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-04.txt Pages : 17 Date : 2010-06-22 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 a form of measurement-based load control using three PCN marking states, not PCN-marked, threshold-marked, and excess-traffic-marked. This behaviour is known informally as the Controlled Load (CL) PCN edge behaviour. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-cl-edge-behaviour-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcn-cl-edge-behaviour-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-22114009.I-D@ietf.org> --NextPart-- From tom111.taylor@bell.net Tue Jun 22 12:16:33 2010 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 26A733A6977 for ; Tue, 22 Jun 2010 12:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.029 X-Spam-Level: * X-Spam-Status: No, score=1.029 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qAVvlWafbM5r for ; Tue, 22 Jun 2010 12:16:31 -0700 (PDT) Received: from blu0-omc1-s22.blu0.hotmail.com (blu0-omc1-s22.blu0.hotmail.com [65.55.116.33]) by core3.amsl.com (Postfix) with ESMTP id 055713A68D4 for ; Tue, 22 Jun 2010 12:16:30 -0700 (PDT) Received: from BLU0-SMTP58 ([65.55.116.7]) by blu0-omc1-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Jun 2010 12:16:38 -0700 X-Originating-IP: [70.26.19.89] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.26.19.89]) by BLU0-SMTP58.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Jun 2010 12:16:37 -0700 Date: Tue, 22 Jun 2010 15:16:34 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: pcn Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jun 2010 19:16:38.0169 (UTC) FILETIME=[70033890:01CB123F] Subject: [PCN] I-D Action:draft-ietf-pcn-cl-edge-behaviour-04.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 19:16:33 -0000 I've updated the CL edge behaviour draft based on Michael's suggestions. The detailed changes from the -02 version (the one in the archives before this week) is as follows: 1) Added definitions of NM-rate, ThM-rate, and ETM-rate in the terminology section. Reordered but did not change the definition of CLE, except to update its forward reference. 2) s/unmarked/not-marked in the first paragraph of section 3.1. Followed through with same change in section 2.1. 3) Modified the egress node reporting requirements in accordance with yesterday/today's discussion. Basic requirement to report every interval, configurable option to suppress reports basic on lack of marking, configurable option for egress node to calculate and report CLE. 4) Both flow admission and flow termination are now independently configurable options at the decision point. 5) Modified the text regarding the calculation of CLE at the decision point to take account of the possibility it is in the report from the egress node. Named the admission decision threshold ("CLElimit") for further reference. 6) Change details of flow termination from MUST to SHOULD as suggested at the last meeting, to provide some room for discretion. 7) Focussed the missing report section (3.4.3) more tightly on the viewpoint of the decision point. Left recommendations for values of Tfail to the "Timers" section 3.5. Added text covering the possibility a report is subsequently received from the egress node concerned. 8) Realized Michael and I were disagreeing on names for times because I was failing to distinguish between timers and their limits. Created a table to show timer name, location, how many instances are needed, the limiting value, and action on expiry. Also made recommendations on limiting values in this section. 9) Made a detailed list of configurable parameters for each actor in the system in the applicable section 5.4 of the per-domain behaviour template. Tom Taylor From toby@moncaster.com Wed Jun 23 07:53:33 2010 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 CB7D93A68AC for ; Wed, 23 Jun 2010 07:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.141 X-Spam-Level: * X-Spam-Status: No, score=1.141 tagged_above=-999 required=5 tests=[AWL=0.790, BAYES_50=0.001, 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 VSE+OqkYMH-8 for ; Wed, 23 Jun 2010 07:53:29 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id 7FAC73A6A34 for ; Wed, 23 Jun 2010 07:53:24 -0700 (PDT) Received: from TobysHP (host86-170-50-165.range86-170.btcentralplus.com [86.170.50.165]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MTcE0-1OaLGI1JCq-00RAOn; Wed, 23 Jun 2010 16:53:26 +0200 From: "Toby Moncaster" To: "'Tom Taylor'" , "'pcn'" References: In-Reply-To: Date: Wed, 23 Jun 2010 15:53:26 +0100 Message-ID: <000d01cb12e3$d654f800$82fee800$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsSP3cQgwX8Yav9Sr+qVjFcl9WKrgAmfqIg Content-Language: en-gb X-Provags-ID: V01U2FsdGVkX19TflKHOFIxPVr4f6UtIgKysW7MFjRF8WjoaNf Bc78+WyCNaBjq1zIif//mtZxtBCAiL90MoaV8T4XuOPoIoeuyh 3Bhq3lB3mmeuCVinWF43/5JNhJpxz/Y Subject: Re: [PCN] I-D Action:draft-ietf-pcn-cl-edge-behaviour-04.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jun 2010 14:53:33 -0000 Tom, Overall this seems to make sense and I don't think I disagree with any of the actual technical stuff. A few detailed comments. I would quite like to see decision point capitalised to clarify that it is a defined term, and maybe even hyphenated to give Decision-point... 2. Bullet 2 in section 2 currently reads " the domain satisfies the conditions specified in the applicable encoding extension document;" This carries an inherent assumption that the encoding is defined in a document (implication being that document will be a formal IETF document), but this assumption isn't made clear in the first bullet. My suggested solution is to modify the first bullet so it reads: "encoding of PCN status within individual packets is based on [RFC5696], extended to provide a third PCN encoding state. Extensions for this purpose will be specified by the IETF. Possible extensions are documented in [ID.PCN3state] or alternatively [ID.PCN3in1];" End of Section 2. Would it be an idea to re-iterate the other MUST NOTS for the marking. E.g. any packet that has been threshold-marked (ThM) or excess-traffic-marked (ETM) MUST NOT have that marking cleared to NM 3.1. Para 2. This was slightly confusing first time I read it, because it seems in the wrong order. It also made it unclear that the decision point was receiving the reports as well as requesting them. I would be tempted to put it as: " The PCN ingress node enforces flow admission and termination decisions. When requested, it reports the rate of PCN traffic admitted to a given ingress-egress aggregate to the decision point. For details, see Section 3.3." Section 3.2. It is RECOMMENDED that the interval, Tcalc, between calculation Insert commas: ^ ^ In the last para (starting "In networks with multipath routing"), it might be worth expanding as to why you want to identify the particular flows so as to ensure people make the correct choice regarding this SHOULD 3.2.2. This seems to be back to front because it starts by referring forward, having looked at it, I think the solution is to swap sections 3.2.2 and 3.2.3... Otherwise it is very confusing. Para 2 of 3.2.2. If so configured, and if excess-traffic-marked packets Insert comma ^ This para is actually a bit confusing, so should refer to why the reporting of flow identifiers may be configured. Section 3.2.3. " Egress reports may be lost and they are also a demonstration of liveness to the decision point." No such word as liveness... This whole paragraph needs to be re-written to improve its English and make better sense 3.2.4. More or less clear, but could be made much clearer. IN particular we need to clarify that this is an option for the egress node: "The congestion level estimate (CLE) MUST be calculated in every measurement for every ingress-egress-aggregate. This calculation MAY be performed at the PCN-egress node. A configurable option MUST be provided to enable this. If this option is enabled, then the PCN-egress-node MUST calculate the CLE and include this value in every report it sends, along with the values for NM-rate, ThM-rate, and ETM-rate. The CLE is equal to the ratio: (ThM-Rate + ETM-Rate) / (NM-rate + ThM-rate + ETM-rate) if any PCN traffic was observed, or zero otherwise." 3.4. 1st sentence, add "...or both." 3.4.1. Clunky first sentence. Suggested replacement: " The decision point needs to know the current CLE for every ingress-egress-aggregate. This may be contained in the reports from the egress. If not then when the decision point receives a report from the egress node for a given ingress-egress-aggregate that contains non-zero rates, it calculates the CLE as described in Section 3.2.4" Should we add "...but this is NOT RECOMMENDED" to the end of the last sentence (after the MAY about policy)? 3.4.2. Sentence beginning " The decision point MUST then wait, both for the" Reverse the order of both and for (giving "...wait for both the") Sentence starting "if the difference calculated in the second step...". The whole sentence has too many clauses and is confusing. I suggest a complete re-order to give: "If the difference calculated in the second step is positive, the decision point SHOULD select sufficient flows to terminate until it determines that the PCN traffic admission rate will no longer be greater than the estimated sustainable aggregate rate. This should be based on its knowledge of the bandwidth required by individual flows gained from resource signalling, etc" last sentence of 3.4.2 is a bit clunky, but liveable with... 3.5. This is a nice clear section. I like things in tables :) The only question is about recommended Tfail values which seem to be wildly different depending whether report suppression is active or not. Are these figures based on anything or are they gut-feel figures for what seems right? I think that will do for now! Toby > -----Original Message----- > From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of > Tom Taylor > Sent: 22 June 2010 20:17 > To: pcn > Subject: [PCN] I-D Action:draft-ietf-pcn-cl-edge-behaviour-04.txt > > I've updated the CL edge behaviour draft based on Michael's > suggestions. The > detailed changes from the -02 version (the one in the archives before > this week) > is as follows: > > 1) Added definitions of NM-rate, ThM-rate, and ETM-rate in the > terminology > section. Reordered but did not change the definition of CLE, except to > update > its forward reference. > > 2) s/unmarked/not-marked in the first paragraph of section 3.1. > Followed through > with same change in section 2.1. > > 3) Modified the egress node reporting requirements in accordance with > yesterday/today's discussion. Basic requirement to report every > interval, > configurable option to suppress reports basic on lack of marking, > configurable > option for egress node to calculate and report CLE. > > 4) Both flow admission and flow termination are now independently > configurable > options at the decision point. > > 5) Modified the text regarding the calculation of CLE at the decision > point to > take account of the possibility it is in the report from the egress > node. Named > the admission decision threshold ("CLElimit") for further reference. > > 6) Change details of flow termination from MUST to SHOULD as suggested > at the > last meeting, to provide some room for discretion. > > 7) Focussed the missing report section (3.4.3) more tightly on the > viewpoint of > the decision point. Left recommendations for values of Tfail to the > "Timers" > section 3.5. Added text covering the possibility a report is > subsequently > received from the egress node concerned. > > 8) Realized Michael and I were disagreeing on names for times because I > was > failing to distinguish between timers and their limits. Created a table > to show > timer name, location, how many instances are needed, the limiting > value, and > action on expiry. Also made recommendations on limiting values in this > section. > > 9) Made a detailed list of configurable parameters for each actor in > the system > in the applicable section 5.4 of the per-domain behaviour template. > > Tom Taylor > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From rbriscoe@jungle.bt.co.uk Fri Jun 25 05:45:13 2010 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 B0AC03A6892 for ; Fri, 25 Jun 2010 05:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.851 X-Spam-Level: X-Spam-Status: No, score=0.851 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_50=0.001, 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 fRnWQLINf4uO for ; Fri, 25 Jun 2010 05:45:06 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 2B4D13A686B for ; Fri, 25 Jun 2010 05:45:05 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Jun 2010 13:45:14 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Jun 2010 13:45:13 +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 1277469912442; Fri, 25 Jun 2010 13:45:12 +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 o5PCjAXf023753; Fri, 25 Jun 2010 13:45:10 +0100 Message-Id: <201006251245.o5PCjAXf023753@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 25 Jun 2010 13:45:12 +0100 To: "BABIARZ, Jozef Z" , Daisuke SATOH , Toby Moncaster , Michael Menth , "CHAN, Kwok Ho" 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: 25 Jun 2010 12:45:14.0012 (UTC) FILETIME=[419A7DC0:01CB1464] Cc: PCN IETF list Subject: [PCN] plan for PCN encodings, now ecn-tunnel is in last call X-BeenThere: pcn@ietf.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, 25 Jun 2010 12:45:13 -0000 Joe, Daisuke, Toby, Michael, Kwok, I writing to you all as co-authors of the various PCN encoding drafts and RFCs, and to Kwok as author of the encoding comparison draft. I have started this conversation between you all rather than starting numerous side conversations between slightly different sets of co-authors. I have also included the PCN list as there are others with interest in the outcome (not least the chairs). I hope that's OK - otherwise please accept my apologies and feel free to switch to off-list mode. The IETF last call on ietf-tsvwg-ecn-tunnel will end on 6 Jul 10. Assuming it goes thru without substantive changes, I would like to suggest a plan for how to deal with all the experimental PCN encodings and then to try to update the drafts accordingly before the Maastricht deadline. * draft-ietf-pcn-3-in-1-encoding -> add applicability to sm{1} -> stds track * RFC5696 (baseline encoding) -> obsoleted by 3-in-1 encoding{2} * draft-ietf-pcn-3-state-encoding -> expt track or expire{3} * draft-ietf-pcn-psdm-encoding -> leave to expire? * draft-satoh-pcn-st-marking -> (expired) -> leave to expire? {Note 1}: I propose we edit 3-in-1 to make it clear that you don't have to use both severity levels just because you can. So it's OK to use 3-in-1 for single marking, you just don't use the extra codepoint. {Note 2}: To anyone not paying close attention to the PCN w-g, they will be (and are) confused by multiple encodings. I think it would be best to re-write 3-in-1 a little so it can obsolete the baseline, rather than keeping both on the stds track. {Note 3}: 3-state is the only encoding that explicitly supports e2e ECN, but e2e ECN can be supported with tunnelling across the PCN domain instead. IMO tunnelling across the domain is more likely to be used if e2e ECN is needed, so I would let 3-state expire. Then, in 3-in-1 we should explicitly say that PCN domain tunnelling MUST be used when incoming packets are alread ECT. Questions: Q1. Do any co-authors of psdm/st think either could still be useful even if ecn-tunnel becomes a proposed standard? Q2. Would the co-authors of 3-state prefer e2e ECN to be supported by tunnelling, rather than 3-state encoding? Q3. Are the co-authors of 3-in-1 willing to edit it to make it clear you don't have to use both severity levels (i.e. single marking with 3-in-1 is OK)? Q4. Is the w-g happy to obsolete RFC5696 (baseline) with 3-in-1 replacing it? Q5. Have I missed anything? Background on ecn-tunnel: ------------------------ finally got to IETF last call on 22-Jun-10. It previously received a favourable SecDir review: We created various experimental PCN encodings as work-rounds to ECN tunnelling not propagating congestion markings how we wished: - RFC3168 ingress breaks excess-rate marking and single marking; - all egress tunnels break two severity-level marking. Altho we cannot expect all tunnels in the Internet to immediately become compliant with this new spec (!), an operator wanting to deploy PCN can ask tunnel vendors to comply with it. It's at -08, but I have prepared an -09b draft to capture the queued up minor changes since -08, and removal of the comments, notes and appendices marked for removal before publication: For diffs from -08, either see the list within the doc, or the diffs here: Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From toby@moncaster.com Fri Jun 25 06:16:55 2010 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 BC74A3A6946 for ; Fri, 25 Jun 2010 06:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.467 X-Spam-Level: X-Spam-Status: No, score=0.467 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_50=0.001, 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 hvHm7e1Wl3bP for ; Fri, 25 Jun 2010 06:16:54 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by core3.amsl.com (Postfix) with ESMTP id 2799A3A6880 for ; Fri, 25 Jun 2010 06:16:53 -0700 (PDT) Received: from TobysHP (host86-170-50-165.range86-170.btcentralplus.com [86.170.50.165]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0M83Dl-1PNYep40OX-00vhPT; Fri, 25 Jun 2010 15:15:31 +0200 From: "Toby Moncaster" To: "'Bob Briscoe'" , "'BABIARZ, Jozef Z'" , "'Daisuke SATOH'" , "'Michael Menth'" , "'CHAN, Kwok Ho'" References: <201006251245.o5PCjAXf023753@bagheera.jungle.bt.co.uk> In-Reply-To: <201006251245.o5PCjAXf023753@bagheera.jungle.bt.co.uk> Date: Fri, 25 Jun 2010 14:15:30 +0100 Message-ID: <002501cb1468$7d0142a0$7703c7e0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcsUZEGYA2MAG3A0S5aVym7mOMvjswAAQiXg Content-Language: en-gb X-Provags-ID: V01U2FsdGVkX1/TffNcskoWBapBONolrLY+XFC3HuMLzdDkAUm rDvzfXO0MdxMDnrqTABmFfwUh6Y5ZHaYY0qQY2rmJYfR4KbbXj MnrY6ePdzDiHBusZMGsGJg4hWGuCi9F Cc: 'PCN IETF list' Subject: Re: [PCN] plan for PCN encodings, now ecn-tunnel is in last call X-BeenThere: pcn@ietf.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, 25 Jun 2010 13:16:55 -0000 Initial comment is this seems to run counter to the PCN W-G decision that we should actually experiment on the different experimental encodings to see which was best... But as long as the W-G agrees to the new approach that won't matter Some quick answers inline.... > -----Original Message----- > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > Sent: 25 June 2010 13:45 > To: BABIARZ, Jozef Z; Daisuke SATOH; Toby Moncaster; Michael Menth; > CHAN, Kwok Ho > Cc: PCN IETF list > Subject: plan for PCN encodings, now ecn-tunnel is in last call > > Joe, Daisuke, Toby, Michael, Kwok, > > I writing to you all as co-authors of the various PCN encoding drafts > and RFCs, and to Kwok as author of the encoding comparison draft. > > I have started this conversation between you all rather than starting > numerous side conversations between slightly different sets of > co-authors. I have also included the PCN list as there are others > with interest in the outcome (not least the chairs). I hope that's OK > - otherwise please accept my apologies and feel free to switch to > off-list mode. > > The IETF last call on ietf-tsvwg-ecn-tunnel will end on 6 Jul 10. > Assuming it goes thru without substantive changes, I would like to > suggest a plan for how to deal with all the experimental PCN > encodings and then to try to update the drafts accordingly before the > Maastricht deadline. > > * draft-ietf-pcn-3-in-1-encoding -> add applicability to sm{1} -> stds > track I can see the argument for STDs track, however there are some issues and it will be tough getting it through, especially if it becomes the only STDs track encoding. I think we need to take a straw poll to find out what the general view is on this > * RFC5696 (baseline encoding) -> obsoleted by 3-in-1 encoding{2} If we obsolete this, we need to add in some extra details from there into 3-in-1 > * draft-ietf-pcn-3-state-encoding -> expt track or expire{3} Experiment as it allows lots of extra functionality in its extended form. However if 3-in-1 is going to be the new STD then we need to make sure it allows for this sort of encoding... > * draft-ietf-pcn-psdm-encoding -> leave to expire? No strong views - it does fit nicely with the RSVP model for signalling... > * draft-satoh-pcn-st-marking -> (expired) -> leave to expire? Expire as I am still not convinced by it... > > {Note 1}: I propose we edit 3-in-1 to make it clear that you don't > have to use both severity levels just because you can. So it's OK to > use 3-in-1 for single marking, you just don't use the extra codepoint. if it is obsoleting baseline then it also needs to include all the extra stuff that is in there... > > {Note 2}: To anyone not paying close attention to the PCN w-g, they > will be (and are) confused by multiple encodings. I think it would be > best to re-write 3-in-1 a little so it can obsolete the baseline, > rather than keeping both on the stds track. Not keen on this. I would prefer to make 3-in-1 a STDs track extension to RFC5696. I can see the current state of affairs (with 4 possible extension encodings all competing) is confusing but having a baseline encoding and an extended encoding doesn't seem at all confusing to me... > > {Note 3}: 3-state is the only encoding that explicitly supports e2e > ECN, but e2e ECN can be supported with tunnelling across the PCN > domain instead. IMO tunnelling across the domain is more likely to be > used if e2e ECN is needed, so I would let 3-state expire. Then, in > 3-in-1 we should explicitly say that PCN domain tunnelling MUST be > used when incoming packets are alread ECT. 3-state gives the potential for a much richer encoding, not just tunnelling of ECN. Also there is the point that this is designed to allow the PCN domain to signal pre-congestion back to the responsive codec... > > Questions: > Q1. Do any co-authors of psdm/st think either could still be useful > even if ecn-tunnel becomes a proposed standard? As I said, it does make a neat fit with the RSVP signalling model. But I have no strong views > Q2. Would the co-authors of 3-state prefer e2e ECN to be supported by > tunnelling, rather than 3-state encoding? This question also needs to go out to people who wanted to include ECN functionality. In particular we need to look at the issue of how to expose PCN marking to the end-system in some later extension. > Q3. Are the co-authors of 3-in-1 willing to edit it to make it clear > you don't have to use both severity levels (i.e. single marking with > 3-in-1 is OK)? Yes, but exactly what else needs editing will depend on the decision regarding what status to give this. > Q4. Is the w-g happy to obsolete RFC5696 (baseline) with 3-in-1 > replacing it? Not really, as I say I prefer to make this an extension to baseline > Q5. Have I missed anything? > > Background on ecn-tunnel: > ------------------------ > finally got to IETF last call on 22-Jun- > 10. > tunnel/> > > It previously received a favourable SecDir review: > > > We created various experimental PCN encodings as work-rounds to ECN > tunnelling not propagating congestion markings how we wished: > - RFC3168 ingress breaks excess-rate marking and single marking; > - all egress tunnels break two severity-level marking. > Altho we cannot expect all tunnels in the Internet to immediately > become compliant with this new spec (!), an operator wanting to > deploy PCN can ask tunnel vendors to comply with it. > > It's at -08, but I have prepared an -09b draft to capture the queued > up minor changes since -08, and removal of the comments, notes and > appendices marked for removal before publication: > tsvwg-ecn-tunnel-09b.txt> > For diffs from -08, either see the list within the doc, or the diffs > here: > tsvwg-ecn-tunnel-09b-08.html> > > > Bob > > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design From Ruediger.Geib@telekom.de Fri Jun 25 06:48:36 2010 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 D38803A693A for ; Fri, 25 Jun 2010 06:48:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.649 X-Spam-Level: X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OLlm-qB6YCG for ; Fri, 25 Jun 2010 06:48:25 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id E7DD43A685A for ; Fri, 25 Jun 2010 06:48:24 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 25 Jun 2010 15:48:28 +0200 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Jun 2010 15:48:27 +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: Fri, 25 Jun 2010 15:48:26 +0200 Message-ID: <151C164FE2E066418D8D44D0801543A50426A7C4@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <201006251245.o5PCjAXf023753@bagheera.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] plan for PCN encodings, now ecn-tunnel is in last call Thread-Index: AcsUZEq3y0KLH3cuSZ2tqjgRXp0BLgAB4Cdw References: <201006251245.o5PCjAXf023753@bagheera.jungle.bt.co.uk> From: To: X-OriginalArrivalTime: 25 Jun 2010 13:48:27.0779 (UTC) FILETIME=[16DD6530:01CB146D] Cc: khchan@huawei.com, daisuke.satoh@ntt-at.co.jp, pcn@ietf.org Subject: Re: [PCN] plan for PCN encodings, now ecn-tunnel is in last call X-BeenThere: pcn@ietf.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, 25 Jun 2010 13:48:37 -0000 Bob, despite being no author I'd like to PSDM being maintained.=20 Threshold marking combined with probe packets to avoid=20 admission is simple an straightforward. I don't object if=20 that feature is moved from PSDM to another document of=20 the ones you mentioned below (and excuse if this happened=20 already). Is this linked to ECN tunneling?=20 The wording of 3 in 1 must allow for MPLS support of PCN with=20 just two TC codepoints. Then baseline may be obsoleted. Regards, Ruediger -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Bob Briscoe Sent: Friday, June 25, 2010 2:45 PM To: BABIARZ, Jozef Z; Daisuke SATOH; Toby Moncaster; Michael Menth; = CHAN, Kwok Ho Cc: PCN IETF list Subject: [PCN] plan for PCN encodings, now ecn-tunnel is in last call Joe, Daisuke, Toby, Michael, Kwok, I writing to you all as co-authors of the various PCN encoding drafts=20 and RFCs, and to Kwok as author of the encoding comparison draft. I have started this conversation between you all rather than starting=20 numerous side conversations between slightly different sets of=20 co-authors. I have also included the PCN list as there are others=20 with interest in the outcome (not least the chairs). I hope that's OK=20 - otherwise please accept my apologies and feel free to switch to=20 off-list mode. The IETF last call on ietf-tsvwg-ecn-tunnel will end on 6 Jul 10.=20 Assuming it goes thru without substantive changes, I would like to=20 suggest a plan for how to deal with all the experimental PCN=20 encodings and then to try to update the drafts accordingly before the=20 Maastricht deadline. * draft-ietf-pcn-3-in-1-encoding -> add applicability to sm{1} -> stds = track * RFC5696 (baseline encoding) -> obsoleted by 3-in-1 encoding{2} * draft-ietf-pcn-3-state-encoding -> expt track or expire{3} * draft-ietf-pcn-psdm-encoding -> leave to expire? * draft-satoh-pcn-st-marking -> (expired) -> leave to expire? {Note 1}: I propose we edit 3-in-1 to make it clear that you don't=20 have to use both severity levels just because you can. So it's OK to=20 use 3-in-1 for single marking, you just don't use the extra codepoint. {Note 2}: To anyone not paying close attention to the PCN w-g, they=20 will be (and are) confused by multiple encodings. I think it would be=20 best to re-write 3-in-1 a little so it can obsolete the baseline,=20 rather than keeping both on the stds track. {Note 3}: 3-state is the only encoding that explicitly supports e2e=20 ECN, but e2e ECN can be supported with tunnelling across the PCN=20 domain instead. IMO tunnelling across the domain is more likely to be=20 used if e2e ECN is needed, so I would let 3-state expire. Then, in=20 3-in-1 we should explicitly say that PCN domain tunnelling MUST be=20 used when incoming packets are alread ECT. Questions: Q1. Do any co-authors of psdm/st think either could still be useful=20 even if ecn-tunnel becomes a proposed standard? Q2. Would the co-authors of 3-state prefer e2e ECN to be supported by=20 tunnelling, rather than 3-state encoding? Q3. Are the co-authors of 3-in-1 willing to edit it to make it clear=20 you don't have to use both severity levels (i.e. single marking with=20 3-in-1 is OK)? Q4. Is the w-g happy to obsolete RFC5696 (baseline) with 3-in-1 = replacing it? Q5. Have I missed anything? Background on ecn-tunnel: ------------------------ finally got to IETF last call on = 22-Jun-10. = It previously received a favourable SecDir review: We created various experimental PCN encodings as work-rounds to ECN=20 tunnelling not propagating congestion markings how we wished: - RFC3168 ingress breaks excess-rate marking and single marking; - all egress tunnels break two severity-level marking. Altho we cannot expect all tunnels in the Internet to immediately=20 become compliant with this new spec (!), an operator wanting to=20 deploy PCN can ask tunnel vendors to comply with it. It's at -08, but I have prepared an -09b draft to capture the queued=20 up minor changes since -08, and removal of the comments, notes and=20 appendices marked for removal before publication: For diffs from -08, either see the list within the doc, or the diffs = here: Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design=20 _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From rbriscoe@jungle.bt.co.uk Fri Jun 25 11:13:11 2010 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 4CDDE28C180 for ; Fri, 25 Jun 2010 11:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.502 X-Spam-Level: X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[AWL=1.615, 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 blrhcqm2TfL1 for ; Fri, 25 Jun 2010 11:13:04 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 49DB628C175 for ; Fri, 25 Jun 2010 11:13:02 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Jun 2010 19:13:10 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Jun 2010 19:13:10 +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 1277489589702; Fri, 25 Jun 2010 19:13:09 +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 o5PID8h5027498; Fri, 25 Jun 2010 19:13:08 +0100 Message-Id: <201006251813.o5PID8h5027498@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 25 Jun 2010 19:13:10 +0100 To: From: Bob Briscoe In-Reply-To: <151C164FE2E066418D8D44D0801543A50426A7C4@S4DE8PSAAQA.mitte .t-com.de> References: <201006251245.o5PCjAXf023753@bagheera.jungle.bt.co.uk> <151C164FE2E066418D8D44D0801543A50426A7C4@S4DE8PSAAQA.mitte.t-com.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: 25 Jun 2010 18:13:10.0798 (UTC) FILETIME=[11E1C2E0:01CB1492] Cc: khchan@huawei.com, daisuke.satoh@ntt-at.co.jp, pcn@ietf.org Subject: Re: [PCN] plan for PCN encodings, now ecn-tunnel is in last call X-BeenThere: pcn@ietf.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, 25 Jun 2010 18:13:11 -0000 Ruediger, At 14:48 25/06/2010, Ruediger.Geib@telekom.de wrote: >Bob, > >despite being no author I'd like to PSDM being maintained. >Threshold marking combined with probe packets to avoid >admission is simple an straightforward. I don't object if >that feature is moved from PSDM to another document of >the ones you mentioned below (and excuse if this happened >already). Trouble is, I believe 3-in-1 and the encoding used by psdm are mutually incompatible. I think it should be possible to do the probing you want and use threshold marking with 3-in-1 rather than PSDM. I believe the motivation for PSDM was the other way round: if you use PSDM, you can only use one of the codepoints for probing, so probing became an integral part of PSDM. That doesn't preclude probing using another encoding. Michael might be able to confirm whether I'm correct here-it's late on a Friday and my brain is fried. >Is this linked to ECN tunneling? PSDM was designed to work-round the ECN-tunnelling issue. And ecn-tunnel side-steps that issue. So in that sense, it's linked to tunnelling. >The wording of 3 in 1 must allow for MPLS support of PCN with >just two TC codepoints. Then baseline may be obsoleted. 3-in-1 is an IP encoding, so it shouldn't constrain MPLS deployments. We could say that explicitly, but I think it's pretty clear already. RFC5129 (ECN in MPLS) says words about only mapping the ECN codepoints you need from IP into the MPLS CoS field and mapping the rest all to the the same MPLS CoS codepoint. HTH Bob >Regards, > >Ruediger > > > >-----Original Message----- >From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf >Of Bob Briscoe >Sent: Friday, June 25, 2010 2:45 PM >To: BABIARZ, Jozef Z; Daisuke SATOH; Toby Moncaster; Michael Menth; >CHAN, Kwok Ho >Cc: PCN IETF list >Subject: [PCN] plan for PCN encodings, now ecn-tunnel is in last call > >Joe, Daisuke, Toby, Michael, Kwok, > >I writing to you all as co-authors of the various PCN encoding drafts >and RFCs, and to Kwok as author of the encoding comparison draft. > >I have started this conversation between you all rather than starting >numerous side conversations between slightly different sets of >co-authors. I have also included the PCN list as there are others >with interest in the outcome (not least the chairs). I hope that's OK >- otherwise please accept my apologies and feel free to switch to >off-list mode. > >The IETF last call on ietf-tsvwg-ecn-tunnel will end on 6 Jul 10. >Assuming it goes thru without substantive changes, I would like to >suggest a plan for how to deal with all the experimental PCN >encodings and then to try to update the drafts accordingly before the >Maastricht deadline. > >* draft-ietf-pcn-3-in-1-encoding -> add applicability to sm{1} -> stds track >* RFC5696 (baseline encoding) -> obsoleted by 3-in-1 encoding{2} >* draft-ietf-pcn-3-state-encoding -> expt track or expire{3} >* draft-ietf-pcn-psdm-encoding -> leave to expire? >* draft-satoh-pcn-st-marking -> (expired) -> leave to expire? > >{Note 1}: I propose we edit 3-in-1 to make it clear that you don't >have to use both severity levels just because you can. So it's OK to >use 3-in-1 for single marking, you just don't use the extra codepoint. > >{Note 2}: To anyone not paying close attention to the PCN w-g, they >will be (and are) confused by multiple encodings. I think it would be >best to re-write 3-in-1 a little so it can obsolete the baseline, >rather than keeping both on the stds track. > >{Note 3}: 3-state is the only encoding that explicitly supports e2e >ECN, but e2e ECN can be supported with tunnelling across the PCN >domain instead. IMO tunnelling across the domain is more likely to be >used if e2e ECN is needed, so I would let 3-state expire. Then, in >3-in-1 we should explicitly say that PCN domain tunnelling MUST be >used when incoming packets are alread ECT. > >Questions: >Q1. Do any co-authors of psdm/st think either could still be useful >even if ecn-tunnel becomes a proposed standard? >Q2. Would the co-authors of 3-state prefer e2e ECN to be supported by >tunnelling, rather than 3-state encoding? >Q3. Are the co-authors of 3-in-1 willing to edit it to make it clear >you don't have to use both severity levels (i.e. single marking with >3-in-1 is OK)? >Q4. Is the w-g happy to obsolete RFC5696 (baseline) with 3-in-1 replacing it? >Q5. Have I missed anything? > >Background on ecn-tunnel: >------------------------ > finally got to IETF last call on 22-Jun-10. > > >It previously received a favourable SecDir review: > > >We created various experimental PCN encodings as work-rounds to ECN >tunnelling not propagating congestion markings how we wished: >- RFC3168 ingress breaks excess-rate marking and single marking; >- all egress tunnels break two severity-level marking. >Altho we cannot expect all tunnels in the Internet to immediately >become compliant with this new spec (!), an operator wanting to >deploy PCN can ask tunnel vendors to comply with it. > >It's at -08, but I have prepared an -09b draft to capture the queued >up minor changes since -08, and removal of the comments, notes and >appendices marked for removal before publication: > >For diffs from -08, either see the list within the doc, or the diffs here: > > > >Bob > > >________________________________________________________________ >Bob Briscoe, BT Innovate & Design > >_______________________________________________ >PCN mailing list >PCN@ietf.org >https://www.ietf.org/mailman/listinfo/pcn ________________________________________________________________ Bob Briscoe, BT Innovate & Design From rbriscoe@jungle.bt.co.uk Fri Jun 25 11:28:09 2010 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 23EF528C106 for ; Fri, 25 Jun 2010 11:28:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.596 X-Spam-Level: X-Spam-Status: No, score=0.596 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_50=0.001, 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 3ExkL+g+Bl3N for ; Fri, 25 Jun 2010 11:28:03 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 9EE8628C0EE for ; Fri, 25 Jun 2010 11:28:02 -0700 (PDT) Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Jun 2010 19:28:10 +0100 Received: from cbibipnt08.iuser.iroot.adidom.com ([147.149.100.81]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Jun 2010 19:28:10 +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 1277490489851; Fri, 25 Jun 2010 19:28:09 +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 o5PIS7Xt027674; Fri, 25 Jun 2010 19:28:07 +0100 Message-Id: <201006251828.o5PIS7Xt027674@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 25 Jun 2010 19:28:11 +0100 To: "Toby Moncaster" From: Bob Briscoe In-Reply-To: <002501cb1468$7d0142a0$7703c7e0$@com> References: <201006251245.o5PCjAXf023753@bagheera.jungle.bt.co.uk> <002501cb1468$7d0142a0$7703c7e0$@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: 25 Jun 2010 18:28:10.0364 (UTC) FILETIME=[2A10A3C0:01CB1494] Cc: 'PCN IETF list' Subject: Re: [PCN] plan for PCN encodings, now ecn-tunnel is in last call X-BeenThere: pcn@ietf.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, 25 Jun 2010 18:28:09 -0000 Toby, At 14:15 25/06/2010, Toby Moncaster wrote: >Initial comment is this seems to run counter to the PCN W-G decision that we >should actually experiment on the different experimental encodings to see >which was best... But as long as the W-G agrees to the new approach that >won't matter Yeah, I know but, now ecn-tunnel is nearly there, the world changes... >Some quick answers inline.... Responses marked [BB] inline (non-repsonse to the other points means I agree)... > > -----Original Message----- > > From: Bob Briscoe [mailto:rbriscoe@jungle.bt.co.uk] > > Sent: 25 June 2010 13:45 > > To: BABIARZ, Jozef Z; Daisuke SATOH; Toby Moncaster; Michael Menth; > > CHAN, Kwok Ho > > Cc: PCN IETF list > > Subject: plan for PCN encodings, now ecn-tunnel is in last call > > * draft-ietf-pcn-3-in-1-encoding -> add applicability to sm{1} -> stds > > track > >I can see the argument for STDs track, however there are some issues and it >will be tough getting it through, especially if it becomes the only STDs >track encoding. I think we need to take a straw poll to find out what the >general view is on this > > > * RFC5696 (baseline encoding) -> obsoleted by 3-in-1 encoding{2} > >If we obsolete this, we need to add in some extra details from there into >3-in-1 > > > * draft-ietf-pcn-3-state-encoding -> expt track or expire{3} > >Experiment as it allows lots of extra functionality in its extended form. [BB]: We need to be brutal if we can make the same functionality work with 3-in-1 >However if 3-in-1 is going to be the new STD then we need to make sure it >allows for this sort of encoding... > > > * draft-ietf-pcn-psdm-encoding -> leave to expire? > >No strong views - it does fit nicely with the RSVP model for signalling... > > > * draft-satoh-pcn-st-marking -> (expired) -> leave to expire? > >Expire as I am still not convinced by it... > > > > > {Note 1}: I propose we edit 3-in-1 to make it clear that you don't > > have to use both severity levels just because you can. So it's OK to > > use 3-in-1 for single marking, you just don't use the extra codepoint. > >if it is obsoleting baseline then it also needs to include all the extra >stuff that is in there... > > > > > > {Note 2}: To anyone not paying close attention to the PCN w-g, they > > will be (and are) confused by multiple encodings. I think it would be > > best to re-write 3-in-1 a little so it can obsolete the baseline, > > rather than keeping both on the stds track. > >Not keen on this. I would prefer to make 3-in-1 a STDs track extension to >RFC5696. I can see the current state of affairs (with 4 possible extension >encodings all competing) is confusing but having a baseline encoding and an >extended encoding doesn't seem at all confusing to me... [BB]: I'm trying to force the issue to see if we can do everything with one encoding now the tunnel issue has gone away. Otherwise, I agree it would not make much sense to have a stds track baseline and a stds track extension, if experimental alternatives to the extension were mutually incompatible. > > > > {Note 3}: 3-state is the only encoding that explicitly supports e2e > > ECN, but e2e ECN can be supported with tunnelling across the PCN > > domain instead. IMO tunnelling across the domain is more likely to be > > used if e2e ECN is needed, so I would let 3-state expire. Then, in > > 3-in-1 we should explicitly say that PCN domain tunnelling MUST be > > used when incoming packets are alread ECT. > >3-state gives the potential for a much richer encoding, not just tunnelling >of ECN. Also there is the point that this is designed to allow the PCN >domain to signal pre-congestion back to the responsive codec... [BB]: You can do that with tunnelling just as well. > > > > Questions: > > Q1. Do any co-authors of psdm/st think either could still be useful > > even if ecn-tunnel becomes a proposed standard? > >As I said, it does make a neat fit with the RSVP signalling model. But I >have no strong views > > > Q2. Would the co-authors of 3-state prefer e2e ECN to be supported by > > tunnelling, rather than 3-state encoding? > >This question also needs to go out to people who wanted to include ECN >functionality. In particular we need to look at the issue of how to expose >PCN marking to the end-system in some later extension. > > > Q3. Are the co-authors of 3-in-1 willing to edit it to make it clear > > you don't have to use both severity levels (i.e. single marking with > > 3-in-1 is OK)? > >Yes, but exactly what else needs editing will depend on the decision >regarding what status to give this. [BB]: Seen the other way round, exactly how we edit it will determine whether it should deserve consensus and the status of stds track. > > Q4. Is the w-g happy to obsolete RFC5696 (baseline) with 3-in-1 > > replacing it? > >Not really, as I say I prefer to make this an extension to baseline [BB]: As above - depends whether we can satisfy all the features of the others. Cheers Bob ________________________________________________________________ Bob Briscoe, BT Innovate & Design From tom111.taylor@bell.net Fri Jun 25 17:48:00 2010 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 26D9A3A682B for ; Fri, 25 Jun 2010 17:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.888 X-Spam-Level: X-Spam-Status: No, score=0.888 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4ofU9g5Fnea for ; Fri, 25 Jun 2010 17:47:59 -0700 (PDT) Received: from blu0-omc1-s26.blu0.hotmail.com (blu0-omc1-s26.blu0.hotmail.com [65.55.116.37]) by core3.amsl.com (Postfix) with ESMTP id BE85C3A6A00 for ; Fri, 25 Jun 2010 17:47:58 -0700 (PDT) Received: from BLU0-SMTP97 ([65.55.116.9]) by blu0-omc1-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Jun 2010 17:48:07 -0700 X-Originating-IP: [70.26.17.94] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.26.17.94]) by BLU0-SMTP97.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Jun 2010 17:48:07 -0700 Date: Fri, 25 Jun 2010 20:48:01 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Toby Moncaster References: <000d01cb12e3$d654f800$82fee800$@com> In-Reply-To: <000d01cb12e3$d654f800$82fee800$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jun 2010 00:48:07.0591 (UTC) FILETIME=[3E456B70:01CB14C9] Cc: 'pcn' Subject: Re: [PCN] I-D Action:draft-ietf-pcn-cl-edge-behaviour-04.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 00:48:00 -0000 Thanks for the review, Toby. Responses marked by [PTT]. Toby Moncaster wrote: > Tom, > > > Overall this seems to make sense and I don't think I disagree with any of > the actual technical stuff. > > A few detailed comments. > > I would quite like to see decision point capitalised to clarify that it is a > defined term, and maybe even hyphenated to give Decision-point... [PTT] Changed to Decision Point. XML2RFC is inserting blanks after hyphens, and I have to go through and clean up manually afterwards. I am reluctant to add another hyphenated term. > > 2. > Bullet 2 in section 2 currently reads " the domain satisfies the conditions > specified in the applicable encoding extension document;" > > This carries an inherent assumption that the encoding is defined in a > document (implication being that document will be a formal IETF document), > but this assumption isn't made clear in the first bullet. > > My suggested solution is to modify the first bullet so it reads: > > "encoding of PCN status within individual packets is based on > [RFC5696], extended to provide a third PCN encoding state. > Extensions for this purpose will be specified by the IETF. > Possible extensions are documented in [ID.PCN3state] or > alternatively [ID.PCN3in1];" > [PTT] Done. > > End of Section 2. Would it be an idea to re-iterate the other MUST NOTS for > the marking. E.g. any packet that has been threshold-marked (ThM) or > excess-traffic-marked (ETM) MUST NOT have that marking cleared to NM [PTT] I think you're the second person to suggest that, so I've given in. I felt that with the introductory text to the bullet saying "these are the only permitted transitions", I had said enough. > > 3.1. > Para 2. This was slightly confusing first time I read it, because it seems > in the wrong order. It also made it unclear that the decision point was > receiving the reports as well as requesting them. I would be tempted to put > it as: > > " The PCN ingress node enforces flow admission and termination decisions. > When requested, it reports the rate of PCN traffic admitted to a > given ingress-egress aggregate to the decision point. > For details, see Section 3.3." [PTT] You're right. Done. > > Section 3.2. > It is RECOMMENDED that the interval, Tcalc, between calculation > Insert commas: [PTT] OK ^ ^ > > In the last para (starting "In networks with multipath routing"), it might > be worth expanding as to why you want to identify the particular flows so as > to ensure people make the correct choice regarding this SHOULD > [PTT] Done > 3.2.2. > > This seems to be back to front because it starts by referring forward, > having looked at it, I think the solution is to swap sections 3.2.2 and > 3.2.3... Otherwise it is very confusing. [PTT] Done. > > Para 2 of 3.2.2. > If so configured, and if excess-traffic-marked packets > Insert comma ^ > > This para is actually a bit confusing, so should refer to why the reporting > of flow identifiers may be configured. [PTT] Reworked the wording and requirement a bit. Not sure if that meets your needs. > > Section 3.2.3. > > " Egress reports may be lost and they are also a demonstration of > liveness to the decision point." > > No such word as liveness... This whole paragraph needs to be re-written to > improve its English and make better sense [PTT] Rewritten. > > 3.2.4. > > More or less clear, but could be made much clearer. IN particular we need to > clarify that this is an option for the egress node: > > "The congestion level estimate (CLE) MUST be calculated in every measurement > for every ingress-egress-aggregate. This calculation MAY be performed at the > PCN-egress node. A configurable option MUST be provided to enable this. > If this option is enabled, then the PCN-egress-node MUST calculate the CLE > and include this value in every report it sends, along with the values for > NM-rate, ThM-rate, and ETM-rate. The CLE is equal to the ratio: > > (ThM-Rate + ETM-Rate) / (NM-rate + ThM-rate + ETM-rate) > > if any PCN traffic was observed, or zero otherwise." [PTT] A little push-back here. The whole of section 3.2 is about requirements on the egress node. Your first sentence is actually a requirement on the system, and therefore violates the separation of responsibilities between actors that is a basic priciple of the organization of section 3. That same principle is why I didn't pick up Michael's nicely-written text. > > 3.4. > 1st sentence, add "...or both." [PTT] Done > > 3.4.1. > Clunky first sentence. Suggested replacement: > > " The decision point needs to know the current CLE for every > ingress-egress-aggregate. This may be contained in the reports from the > egress. If not then when the decision point receives a report from the > egress node for a given ingress-egress-aggregate that contains non-zero > rates, it > calculates the CLE as described in Section 3.2.4" [PTT] Played with the wording a bit more. > > Should we add "...but this is NOT RECOMMENDED" to the end of the last > sentence (after the MAY about policy)? [PTT] This is the escape hatch for something like emergency calls or high priority customers. I don't think we're in a position to recommend anything. I did add the warning: ", but such policy intervention risks defeating the purpose of using PCN". > > 3.4.2. > Sentence beginning " The decision point MUST then wait, both for the" > Reverse the order of both and for (giving "...wait for both the") > > Sentence starting "if the difference calculated in the second step...". The > whole sentence has too many clauses and is confusing. I suggest a complete > re-order to give: > > "If the difference calculated in the second step is positive, the > decision point SHOULD select sufficient flows to terminate > until it determines that the PCN traffic > admission rate will no longer be greater than the estimated > sustainable aggregate rate. This should be based on its knowledge > of the bandwidth required by individual flows gained from > resource signalling, etc" [PTT] I wasn't happy with that myself. Played with the wording a bit more, hope you like it. > > last sentence of 3.4.2 is a bit clunky, but liveable with... > > 3.5. > > This is a nice clear section. I like things in tables :) The only question > is about recommended Tfail values which seem to be wildly different > depending whether report suppression is active or not. Are these figures > based on anything or are they gut-feel figures for what seems right? > [PTT] The general principle was to use at least 3 * the expected interval. I'm open to suggestions, since we're looking at something in the order of 300 ms for no report suppression and ten times that for report suppression. > > I think that will do for now! > > Toby > > >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >> Tom Taylor >> Sent: 22 June 2010 20:17 >> To: pcn >> Subject: [PCN] I-D Action:draft-ietf-pcn-cl-edge-behaviour-04.txt >> >> I've updated the CL edge behaviour draft based on Michael's >> suggestions. The >> detailed changes from the -02 version (the one in the archives before >> this week) >> is as follows: >> >> 1) Added definitions of NM-rate, ThM-rate, and ETM-rate in the >> terminology >> section. Reordered but did not change the definition of CLE, except to >> update >> its forward reference. >> >> 2) s/unmarked/not-marked in the first paragraph of section 3.1. >> Followed through >> with same change in section 2.1. >> >> 3) Modified the egress node reporting requirements in accordance with >> yesterday/today's discussion. Basic requirement to report every >> interval, >> configurable option to suppress reports basic on lack of marking, >> configurable >> option for egress node to calculate and report CLE. >> >> 4) Both flow admission and flow termination are now independently >> configurable >> options at the decision point. >> >> 5) Modified the text regarding the calculation of CLE at the decision >> point to >> take account of the possibility it is in the report from the egress >> node. Named >> the admission decision threshold ("CLElimit") for further reference. >> >> 6) Change details of flow termination from MUST to SHOULD as suggested >> at the >> last meeting, to provide some room for discretion. >> >> 7) Focussed the missing report section (3.4.3) more tightly on the >> viewpoint of >> the decision point. Left recommendations for values of Tfail to the >> "Timers" >> section 3.5. Added text covering the possibility a report is >> subsequently >> received from the egress node concerned. >> >> 8) Realized Michael and I were disagreeing on names for times because I >> was >> failing to distinguish between timers and their limits. Created a table >> to show >> timer name, location, how many instances are needed, the limiting >> value, and >> action on expiry. Also made recommendations on limiting values in this >> section. >> >> 9) Made a detailed list of configurable parameters for each actor in >> the system >> in the applicable section 5.4 of the per-domain behaviour template. >> >> Tom Taylor >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn > > > From root@core3.amsl.com Fri Jun 25 18:00:04 2010 Return-Path: X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 54A983A69C6; Fri, 25 Jun 2010 18:00:04 -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: <20100626010004.54A983A69C6@core3.amsl.com> Date: Fri, 25 Jun 2010 18:00:04 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-cl-edge-behaviour-05.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 01:00:04 -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-05.txt Pages : 18 Date : 2010-06-25 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 a form of measurement-based load control using three PCN marking states, not PCN-marked, threshold-marked, and excess-traffic-marked. This behaviour is known informally as the Controlled Load (CL) PCN edge behaviour. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-cl-edge-behaviour-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcn-cl-edge-behaviour-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-25175409.I-D@ietf.org> --NextPart-- From toby@moncaster.com Sat Jun 26 04:31:07 2010 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 539FC3A6817 for ; Sat, 26 Jun 2010 04:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.448 X-Spam-Level: X-Spam-Status: No, score=0.448 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_50=0.001, 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 E-MJEzMYLVWW for ; Sat, 26 Jun 2010 04:31:03 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id C66D23A6895 for ; Sat, 26 Jun 2010 04:30:48 -0700 (PDT) Received: from TobysHP (host86-170-50-165.range86-170.btcentralplus.com [86.170.50.165]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0M8JwA-1PO2EZ0Ugk-00w0Rj; Sat, 26 Jun 2010 13:30:53 +0200 From: "Toby Moncaster" To: "'Tom Taylor'" References: <000d01cb12e3$d654f800$82fee800$@com> In-Reply-To: Date: Sat, 26 Jun 2010 12:30:52 +0100 Message-ID: <001101cb1523$093136d0$1b93a470$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcsUyT8cbPAd9B3iSW2FBV5gGlsh5QAV/uEA Content-Language: en-gb X-Provags-ID: V01U2FsdGVkX18OnMSc2ub3kFHT7lPBt9zyS0cRC+2Lt7YRLLi 6xo/+mjqDerbY43KMz0EePFSTXdLdblE4lFJpldNYVAz6w8VGd F720CBLXyhKep3Rwajv209lVVO0b/Ba Cc: 'pcn' Subject: Re: [PCN] I-D Action:draft-ietf-pcn-cl-edge-behaviour-04.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2010 11:31:07 -0000 Thanks for that Tom. I like the new version much better and it is probably ready for WGLC in my view (especially if you accept the suggestion I make below...) Some inline comments marked {TM} Toby > -----Original Message----- > From: Tom Taylor [mailto:tom111.taylor@bell.net] > Sent: 26 June 2010 01:48 > To: Toby Moncaster > Cc: 'pcn' > Subject: Re: [PCN] I-D Action:draft-ietf-pcn-cl-edge-behaviour-04.txt > > Thanks for the review, Toby. Responses marked by [PTT]. > > Toby Moncaster wrote: > > Tom, > > > > > > Overall this seems to make sense and I don't think I disagree with > any of > > the actual technical stuff. > > > > A few detailed comments. > > > > I would quite like to see decision point capitalised to clarify that > it is a > > defined term, and maybe even hyphenated to give Decision-point... > > [PTT] Changed to Decision Point. XML2RFC is inserting blanks after > hyphens, and > I have to go through and clean up manually afterwards. I am reluctant > to add > another hyphenated term. > > > > 2. > > Bullet 2 in section 2 currently reads " the domain satisfies the > conditions > > specified in the applicable encoding extension document;" > > > > This carries an inherent assumption that the encoding is defined in a > > document (implication being that document will be a formal IETF > document), > > but this assumption isn't made clear in the first bullet. > > > > My suggested solution is to modify the first bullet so it reads: > > > > "encoding of PCN status within individual packets is based on > > [RFC5696], extended to provide a third PCN encoding state. > > Extensions for this purpose will be specified by the IETF. > > Possible extensions are documented in [ID.PCN3state] or > > alternatively [ID.PCN3in1];" > > > [PTT] Done. > > > > End of Section 2. Would it be an idea to re-iterate the other MUST > NOTS for > > the marking. E.g. any packet that has been threshold-marked (ThM) or > > excess-traffic-marked (ETM) MUST NOT have that marking cleared to NM > > [PTT] I think you're the second person to suggest that, so I've given > in. I felt > that with the introductory text to the bullet saying "these are the > only > permitted transitions", I had said enough. > > > > 3.1. > > Para 2. This was slightly confusing first time I read it, because it > seems > > in the wrong order. It also made it unclear that the decision point > was > > receiving the reports as well as requesting them. I would be tempted > to put > > it as: > > > > " The PCN ingress node enforces flow admission and termination > decisions. > > When requested, it reports the rate of PCN traffic admitted to a > > given ingress-egress aggregate to the decision point. > > For details, see Section 3.3." > > [PTT] You're right. Done. > > > > Section 3.2. > > It is RECOMMENDED that the interval, Tcalc, between calculation > > Insert commas: > > [PTT] OK > ^ ^ > > > > In the last para (starting "In networks with multipath routing"), it > might > > be worth expanding as to why you want to identify the particular > flows so as > > to ensure people make the correct choice regarding this SHOULD > > > [PTT] Done > > > 3.2.2. > > > > This seems to be back to front because it starts by referring > forward, > > having looked at it, I think the solution is to swap sections 3.2.2 > and > > 3.2.3... Otherwise it is very confusing. > > [PTT] Done. > > > > Para 2 of 3.2.2. > > If so configured, and if excess-traffic-marked packets > > Insert comma ^ > > > > This para is actually a bit confusing, so should refer to why the > reporting > > of flow identifiers may be configured. > > [PTT] Reworked the wording and requirement a bit. Not sure if that > meets your needs. {TM} new version is much clearer... > > > > Section 3.2.3. > > > > " Egress reports may be lost and they are also a demonstration of > > liveness to the decision point." > > > > No such word as liveness... This whole paragraph needs to be re- > written to > > improve its English and make better sense > > [PTT] Rewritten. {TM} The new version is much better! > > > > 3.2.4. > > > > More or less clear, but could be made much clearer. IN particular we > need to > > clarify that this is an option for the egress node: > > > > "The congestion level estimate (CLE) MUST be calculated in every > measurement > > for every ingress-egress-aggregate. This calculation MAY be performed > at the > > PCN-egress node. A configurable option MUST be provided to enable > this. > > If this option is enabled, then the PCN-egress-node MUST calculate > the CLE > > and include this value in every report it sends, along with the > values for > > NM-rate, ThM-rate, and ETM-rate. The CLE is equal to the ratio: > > > > (ThM-Rate + ETM-Rate) / (NM-rate + ThM-rate + ETM-rate) > > > > if any PCN traffic was observed, or zero otherwise." > > [PTT] A little push-back here. The whole of section 3.2 is about > requirements on > the egress node. Your first sentence is actually a requirement on the > system, > and therefore violates the separation of responsibilities between > actors that is > a basic priciple of the organization of section 3. That same principle > is why I > didn't pick up Michael's nicely-written text. {TM} OK, I can see that argument. It would be a little clearer (to me at least) if it read "Congestion level estimate (CLE) calculation and reporting MUST be provided as a configurable option at the PCN-egress-node. If this option is enabled then the PCN-egress-node MUST calculate the current value for CLE for each ingress-egress-aggregate in each measurement interval and include this in its report (along with the current values of NM-rate, ThM-rate and ETM-rate). The CLE is equal to the ratio: (ThM-Rate + ETM-Rate) / (NM-rate + ThM-rate + ETM-rate) if any traffic was observed, or zero otherwise." > > > > 3.4. > > 1st sentence, add "...or both." > > [PTT] Done > > > > 3.4.1. > > Clunky first sentence. Suggested replacement: > > > > " The decision point needs to know the current CLE for every > > ingress-egress-aggregate. This may be contained in the reports from > the > > egress. If not then when the decision point receives a report from > the > > egress node for a given ingress-egress-aggregate that contains non- > zero > > rates, it > > calculates the CLE as described in Section 3.2.4" > > [PTT] Played with the wording a bit more. > > > > Should we add "...but this is NOT RECOMMENDED" to the end of the last > > sentence (after the MAY about policy)? > > [PTT] This is the escape hatch for something like emergency calls or > high > priority customers. I don't think we're in a position to recommend > anything. > I did add the warning: ", but such policy intervention risks defeating > the purpose of using PCN". {TM} OK, that makes it clearer > > > > 3.4.2. > > Sentence beginning " The decision point MUST then wait, both for the" > > Reverse the order of both and for (giving "...wait for both the") > > > > Sentence starting "if the difference calculated in the second > step...". The > > whole sentence has too many clauses and is confusing. I suggest a > complete > > re-order to give: > > > > "If the difference calculated in the second step is positive, the > > decision point SHOULD select sufficient flows to terminate > > until it determines that the PCN traffic > > admission rate will no longer be greater than the estimated > > sustainable aggregate rate. This should be based on its knowledge > > of the bandwidth required by individual flows gained from > > resource signalling, etc" > > [PTT] I wasn't happy with that myself. Played with the wording a bit > more, hope > you like it. {TM} Much better, thanks... > > > > last sentence of 3.4.2 is a bit clunky, but liveable with... > > > > 3.5. > > > > This is a nice clear section. I like things in tables :) The only > question > > is about recommended Tfail values which seem to be wildly different > > depending whether report suppression is active or not. Are these > figures > > based on anything or are they gut-feel figures for what seems right? > > > [PTT] The general principle was to use at least 3 * the expected > interval. I'm > open to suggestions, since we're looking at something in the order of > 300 ms for > no report suppression and ten times that for report suppression. {TM} OK, leave it as it is, I have no views on this whatsoever... > > > > I think that will do for now! > > > > Toby > > > > > >> -----Original Message----- > >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf > Of > >> Tom Taylor > >> Sent: 22 June 2010 20:17 > >> To: pcn > >> Subject: [PCN] I-D Action:draft-ietf-pcn-cl-edge-behaviour-04.txt > >> > >> I've updated the CL edge behaviour draft based on Michael's > >> suggestions. The > >> detailed changes from the -02 version (the one in the archives > before > >> this week) > >> is as follows: > >> > >> 1) Added definitions of NM-rate, ThM-rate, and ETM-rate in the > >> terminology > >> section. Reordered but did not change the definition of CLE, except > to > >> update > >> its forward reference. > >> > >> 2) s/unmarked/not-marked in the first paragraph of section 3.1. > >> Followed through > >> with same change in section 2.1. > >> > >> 3) Modified the egress node reporting requirements in accordance > with > >> yesterday/today's discussion. Basic requirement to report every > >> interval, > >> configurable option to suppress reports basic on lack of marking, > >> configurable > >> option for egress node to calculate and report CLE. > >> > >> 4) Both flow admission and flow termination are now independently > >> configurable > >> options at the decision point. > >> > >> 5) Modified the text regarding the calculation of CLE at the > decision > >> point to > >> take account of the possibility it is in the report from the egress > >> node. Named > >> the admission decision threshold ("CLElimit") for further reference. > >> > >> 6) Change details of flow termination from MUST to SHOULD as > suggested > >> at the > >> last meeting, to provide some room for discretion. > >> > >> 7) Focussed the missing report section (3.4.3) more tightly on the > >> viewpoint of > >> the decision point. Left recommendations for values of Tfail to the > >> "Timers" > >> section 3.5. Added text covering the possibility a report is > >> subsequently > >> received from the egress node concerned. > >> > >> 8) Realized Michael and I were disagreeing on names for times > because I > >> was > >> failing to distinguish between timers and their limits. Created a > table > >> to show > >> timer name, location, how many instances are needed, the limiting > >> value, and > >> action on expiry. Also made recommendations on limiting values in > this > >> section. > >> > >> 9) Made a detailed list of configurable parameters for each actor in > >> the system > >> in the applicable section 5.4 of the per-domain behaviour template. > >> > >> Tom Taylor > >> _______________________________________________ > >> PCN mailing list > >> PCN@ietf.org > >> https://www.ietf.org/mailman/listinfo/pcn > > > > > > From root@core3.amsl.com Sun Jun 27 18:00:01 2010 Return-Path: X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 593A43A688C; Sun, 27 Jun 2010 18: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: <20100628010001.593A43A688C@core3.amsl.com> Date: Sun, 27 Jun 2010 18:00:01 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-cl-edge-behaviour-06.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, 28 Jun 2010 01: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 Boundary Node Behaviour for the Controlled Load (CL) Mode of Operation Author(s) : A. Charny, et al. Filename : draft-ietf-pcn-cl-edge-behaviour-06.txt Pages : 17 Date : 2010-06-27 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 a form of measurement-based load control using three PCN marking states, not PCN-marked, threshold-marked, and excess-traffic-marked. This behaviour is known informally as the Controlled Load (CL) PCN edge behaviour. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-cl-edge-behaviour-06.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-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-27175945.I-D@ietf.org> --NextPart-- From tom111.taylor@bell.net Sun Jun 27 19:18:54 2010 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 78BDE3A68C1 for ; Sun, 27 Jun 2010 19:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.883 X-Spam-Level: X-Spam-Status: No, score=0.883 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id au0MYxH97xzJ for ; Sun, 27 Jun 2010 19:18:53 -0700 (PDT) Received: from blu0-omc1-s38.blu0.hotmail.com (blu0-omc1-s38.blu0.hotmail.com [65.55.116.49]) by core3.amsl.com (Postfix) with ESMTP id A10073A6828 for ; Sun, 27 Jun 2010 19:18:53 -0700 (PDT) Received: from BLU0-SMTP83 ([65.55.116.7]) by blu0-omc1-s38.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 27 Jun 2010 19:19:03 -0700 X-Originating-IP: [70.26.17.94] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.26.17.94]) by BLU0-SMTP83.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 27 Jun 2010 19:19:03 -0700 Date: Sun, 27 Jun 2010 22:19:00 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: pcn Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jun 2010 02:19:03.0218 (UTC) FILETIME=[46E78920:01CB1668] 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, 28 Jun 2010 02:18:54 -0000 I updated the CL edge behaviour draft based on Toby's final suggestion and cleaned up the references to get rid of some idnits warnings. I also updated the SM draft to match. Toby, I have to apologize for not adding you to the CL Acknowledgements section yet. I'll do it when I submit the inevitable next version. You do appear in the SM Acknowledgements section. Thanks again for your careful review. Tom Taylor From root@core3.amsl.com Sun Jun 27 19:30:05 2010 Return-Path: X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B93263A6848; Sun, 27 Jun 2010 19:30:03 -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: <20100628023004.B93263A6848@core3.amsl.com> Date: Sun, 27 Jun 2010 19:30:03 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-sm-edge-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: Mon, 28 Jun 2010 02:30:05 -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-03.txt Pages : 15 Date : 2010-06-27 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 a form of measurement-based load control using two PCN marking states, not PCN- marked, and excess-traffic-marked. This behaviour is known informally as the Single Marking (SM) PCN edge behaviour. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-sm-edge-behaviour-03.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-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-27191534.I-D@ietf.org> --NextPart-- From menth@informatik.uni-wuerzburg.de Mon Jun 28 16:35:33 2010 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 BDC833A69D8 for ; Mon, 28 Jun 2010 16:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 CS+Wc+nyvoHj for ; Mon, 28 Jun 2010 16:35:32 -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 BFC313A687D for ; Mon, 28 Jun 2010 16:35:31 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 7DCBE21F98; Tue, 29 Jun 2010 01:34:55 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 78ED349042; Tue, 29 Jun 2010 01:34:55 +0200 (CEST) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from [192.168.1.2] (f051020011.adsl.alicedsl.de [78.51.20.11]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTPSA id 02EAE41F8A; Tue, 29 Jun 2010 01:34:54 +0200 (CEST) Message-ID: <4C29319F.7070200@informatik.uni-wuerzburg.de> Date: Tue, 29 Jun 2010 01:34:55 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Bob Briscoe References: <201006251245.o5PCjAXf023753@bagheera.jungle.bt.co.uk> In-Reply-To: <201006251245.o5PCjAXf023753@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "CHAN, Kwok Ho" , Daisuke SATOH , PCN IETF list Subject: Re: [PCN] plan for PCN encodings, now ecn-tunnel is in last call 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: Mon, 28 Jun 2010 23:35:33 -0000 Hi Bob and all, Bob Briscoe schrieb: > Joe, Daisuke, Toby, Michael, Kwok, > > I writing to you all as co-authors of the various PCN encoding drafts > and RFCs, and to Kwok as author of the encoding comparison draft. > > I have started this conversation between you all rather than starting > numerous side conversations between slightly different sets of > co-authors. I have also included the PCN list as there are others with > interest in the outcome (not least the chairs). I hope that's OK - > otherwise please accept my apologies and feel free to switch to > off-list mode. > > The IETF last call on ietf-tsvwg-ecn-tunnel will end on 6 Jul 10. > Assuming it goes thru without substantive changes, I would like to > suggest a plan for how to deal with all the experimental PCN encodings > and then to try to update the drafts accordingly before the Maastricht > deadline. > > * draft-ietf-pcn-3-in-1-encoding -> add applicability to sm{1} -> stds > track ok > * RFC5696 (baseline encoding) -> obsoleted by 3-in-1 encoding{2} On the one hand I like the idea to have only a single relevant encoding. On the other hand I am not 100% sure that baseline encoding is no longer needed as it may take some time until new tunnels will be deployed. I also thought that another advantage of baseline might be that it requires only two PCN states so that it requires fewer codepoints in the MPLS header. However, the same can be done with 3-in-1 encoding if only one marking scheme is used. After reading rfc 5129 it seems to me that pcn is considered only in the appendix and that only 3-in-1 is considered but baseline is not. Therefore, when defining a necessary adaptation from 3-in-1 to mpls shim, it is possible to define a translation for three and for two used pcn states in that document. Hm, has anybody understood me? Am I correct? > * draft-ietf-pcn-3-state-encoding -> expt track or expire{3} ok > * draft-ietf-pcn-psdm-encoding -> leave to expire? ok. I saw some positive comments about psdm. However, I think what people like is rather the implicit probing feather than the encoding itself. I'll provide a write-up to separate implicit probing (edge behavior for admission control) from the encoding issue and make clear that it equally works with baseline or 3-in-1 encoding. > * draft-satoh-pcn-st-marking -> (expired) -> leave to expire? ok > > {Note 1}: I propose we edit 3-in-1 to make it clear that you don't > have to use both severity levels just because you can. So it's OK to > use 3-in-1 for single marking, you just don't use the extra codepoint. ok And it should be made clear that baseline has no advantage over 3-in-1 when going to MPLS. > > {Note 2}: To anyone not paying close attention to the PCN w-g, they > will be (and are) confused by multiple encodings. I think it would be > best to re-write 3-in-1 a little so it can obsolete the baseline, > rather than keeping both on the stds track. Currently I see that only the tunneling issue is an advantage of baseline encoding over 3-in-1. If we can expect that new tunnels are supported when PCN is deployed, I think baseline can be well obsoleted by 3-in-1 encoding. > > {Note 3}: 3-state is the only encoding that explicitly supports e2e > ECN, but e2e ECN can be supported with tunnelling across the PCN > domain instead. IMO tunnelling across the domain is more likely to be > used if e2e ECN is needed, so I would let 3-state expire. Then, in > 3-in-1 we should explicitly say that PCN domain tunnelling MUST be > used when incoming packets are alread ECT. I do not think that 3-state is very useful: 1) it cannot fully support e2e ECN - it gives support only if packets are not re-marked in a PCN domain, therefore, it cannot substitute tunneling 2) providing combined ECN & PCN information to end hosts requires additional signalling to the egress node which is a lot of extra work that still needs to be done. If the egress node has this information, it can provide combined PCN & ECN information also without this type of encoding. Therefore, I can well live with the option of expiring 3-state encoding. > > Questions: > Q1. Do any co-authors of psdm/st think either could still be useful > even if ecn-tunnel becomes a proposed standard? Not in this form. What's useful is implicit probing as edge behavior and that's what people especially liked due to its simplicity. I'll provide a draft that retains this aspect. > Q2. Would the co-authors of 3-state prefer e2e ECN to be supported by > tunnelling, rather than 3-state encoding? I prefer tunneling as 3-state does not give support for e2e ECN as soon as packets are re-marked in the PCN domain. > Q3. Are the co-authors of 3-in-1 willing to edit it to make it clear > you don't have to use both severity levels (i.e. single marking with > 3-in-1 is OK)? > Q4. Is the w-g happy to obsolete RFC5696 (baseline) with 3-in-1 > replacing it? If we can be sure that new tunnels are available before PCN is deployed, obsoleting RFC5696 is a good option. Best wishes, Michael > Q5. Have I missed anything? > > Background on ecn-tunnel: > ------------------------ > finally got to IETF last call on 22-Jun-10. > > > It previously received a favourable SecDir review: > > > We created various experimental PCN encodings as work-rounds to ECN > tunnelling not propagating congestion markings how we wished: > - RFC3168 ingress breaks excess-rate marking and single marking; > - all egress tunnels break two severity-level marking. > Altho we cannot expect all tunnels in the Internet to immediately > become compliant with this new spec (!), an operator wanting to deploy > PCN can ask tunnel vendors to comply with it. > > It's at -08, but I have prepared an -09b draft to capture the queued > up minor changes since -08, and removal of the comments, notes and > appendices marked for removal before publication: > > > For diffs from -08, either see the list within the doc, or the diffs > here: > > > > > Bob > > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design -- PD Dr. habil. 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/31-86632 (new) mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From menth@informatik.uni-wuerzburg.de Mon Jun 28 16:39:55 2010 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 4F0093A68A7 for ; Mon, 28 Jun 2010 16:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 UQDRWTyR93KP for ; Mon, 28 Jun 2010 16:39:53 -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 815B43A67EE for ; Mon, 28 Jun 2010 16:39:53 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 9B5B37325C; Tue, 29 Jun 2010 01:40:03 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 916A855360; Tue, 29 Jun 2010 01:40:03 +0200 (CEST) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from [192.168.1.2] (f051020011.adsl.alicedsl.de [78.51.20.11]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTPSA id 15A8662A25; Tue, 29 Jun 2010 01:40:03 +0200 (CEST) Message-ID: <4C2932D4.9090209@informatik.uni-wuerzburg.de> Date: Tue, 29 Jun 2010 01:40:04 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Bob Briscoe References: <201006251245.o5PCjAXf023753@bagheera.jungle.bt.co.uk> <151C164FE2E066418D8D44D0801543A50426A7C4@S4DE8PSAAQA.mitte.t-com.de> <201006251813.o5PID8h5027498@bagheera.jungle.bt.co.uk> In-Reply-To: <201006251813.o5PID8h5027498@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: khchan@huawei.com, daisuke.satoh@ntt-at.co.jp, pcn@ietf.org Subject: Re: [PCN] plan for PCN encodings, now ecn-tunnel is in last call 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: Mon, 28 Jun 2010 23:39:55 -0000 Hi Bob, hi Ruediger, psdm was able to support both admission control based on threshold marking and flow termination based on excess marking with current tunnels. However, psdm required implicit probing as edge behavior for admission control as it cannot support CLE-based admission control. In contrast, implicit probing does not depend on psdm, it can be equally applied with baseline or 3-in-1. I'll provide a write-up for that. Best wishes, Michael Bob Briscoe schrieb: > Ruediger, > > At 14:48 25/06/2010, Ruediger.Geib@telekom.de wrote: >> Bob, >> >> despite being no author I'd like to PSDM being maintained. >> Threshold marking combined with probe packets to avoid >> admission is simple an straightforward. I don't object if >> that feature is moved from PSDM to another document of >> the ones you mentioned below (and excuse if this happened >> already). > > Trouble is, I believe 3-in-1 and the encoding used by psdm are > mutually incompatible. > > I think it should be possible to do the probing you want and use > threshold marking with 3-in-1 rather than PSDM. > > I believe the motivation for PSDM was the other way round: if you use > PSDM, you can only use one of the codepoints for probing, so probing > became an integral part of PSDM. That doesn't preclude probing using > another encoding. > > Michael might be able to confirm whether I'm correct here-it's late on > a Friday and my brain is fried. > >> Is this linked to ECN tunneling? > > PSDM was designed to work-round the ECN-tunnelling issue. And > ecn-tunnel side-steps that issue. So in that sense, it's linked to > tunnelling. > > >> The wording of 3 in 1 must allow for MPLS support of PCN with >> just two TC codepoints. Then baseline may be obsoleted. > > 3-in-1 is an IP encoding, so it shouldn't constrain MPLS deployments. > We could say that explicitly, but I think it's pretty clear already. > > RFC5129 (ECN in MPLS) says words about only mapping the ECN codepoints > you need from IP into the MPLS CoS field and mapping the rest all to > the the same MPLS CoS codepoint. > > HTH > > > Bob > > > >> Regards, >> >> Ruediger >> >> >> >> -----Original Message----- >> From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of >> Bob Briscoe >> Sent: Friday, June 25, 2010 2:45 PM >> To: BABIARZ, Jozef Z; Daisuke SATOH; Toby Moncaster; Michael Menth; >> CHAN, Kwok Ho >> Cc: PCN IETF list >> Subject: [PCN] plan for PCN encodings, now ecn-tunnel is in last call >> >> Joe, Daisuke, Toby, Michael, Kwok, >> >> I writing to you all as co-authors of the various PCN encoding drafts >> and RFCs, and to Kwok as author of the encoding comparison draft. >> >> I have started this conversation between you all rather than starting >> numerous side conversations between slightly different sets of >> co-authors. I have also included the PCN list as there are others >> with interest in the outcome (not least the chairs). I hope that's OK >> - otherwise please accept my apologies and feel free to switch to >> off-list mode. >> >> The IETF last call on ietf-tsvwg-ecn-tunnel will end on 6 Jul 10. >> Assuming it goes thru without substantive changes, I would like to >> suggest a plan for how to deal with all the experimental PCN >> encodings and then to try to update the drafts accordingly before the >> Maastricht deadline. >> >> * draft-ietf-pcn-3-in-1-encoding -> add applicability to sm{1} -> >> stds track >> * RFC5696 (baseline encoding) -> obsoleted by 3-in-1 encoding{2} >> * draft-ietf-pcn-3-state-encoding -> expt track or expire{3} >> * draft-ietf-pcn-psdm-encoding -> leave to expire? >> * draft-satoh-pcn-st-marking -> (expired) -> leave to expire? >> >> {Note 1}: I propose we edit 3-in-1 to make it clear that you don't >> have to use both severity levels just because you can. So it's OK to >> use 3-in-1 for single marking, you just don't use the extra codepoint. >> >> {Note 2}: To anyone not paying close attention to the PCN w-g, they >> will be (and are) confused by multiple encodings. I think it would be >> best to re-write 3-in-1 a little so it can obsolete the baseline, >> rather than keeping both on the stds track. >> >> {Note 3}: 3-state is the only encoding that explicitly supports e2e >> ECN, but e2e ECN can be supported with tunnelling across the PCN >> domain instead. IMO tunnelling across the domain is more likely to be >> used if e2e ECN is needed, so I would let 3-state expire. Then, in >> 3-in-1 we should explicitly say that PCN domain tunnelling MUST be >> used when incoming packets are alread ECT. >> >> Questions: >> Q1. Do any co-authors of psdm/st think either could still be useful >> even if ecn-tunnel becomes a proposed standard? >> Q2. Would the co-authors of 3-state prefer e2e ECN to be supported by >> tunnelling, rather than 3-state encoding? >> Q3. Are the co-authors of 3-in-1 willing to edit it to make it clear >> you don't have to use both severity levels (i.e. single marking with >> 3-in-1 is OK)? >> Q4. Is the w-g happy to obsolete RFC5696 (baseline) with 3-in-1 >> replacing it? >> Q5. Have I missed anything? >> >> Background on ecn-tunnel: >> ------------------------ >> finally got to IETF last call on >> 22-Jun-10. >> >> >> >> It previously received a favourable SecDir review: >> >> >> We created various experimental PCN encodings as work-rounds to ECN >> tunnelling not propagating congestion markings how we wished: >> - RFC3168 ingress breaks excess-rate marking and single marking; >> - all egress tunnels break two severity-level marking. >> Altho we cannot expect all tunnels in the Internet to immediately >> become compliant with this new spec (!), an operator wanting to >> deploy PCN can ask tunnel vendors to comply with it. >> >> It's at -08, but I have prepared an -09b draft to capture the queued >> up minor changes since -08, and removal of the comments, notes and >> appendices marked for removal before publication: >> >> >> For diffs from -08, either see the list within the doc, or the diffs >> here: >> >> >> >> >> Bob >> >> >> ________________________________________________________________ >> Bob Briscoe, BT Innovate & Design >> >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design -- PD Dr. habil. 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/31-86632 (new) mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From toby@moncaster.com Tue Jun 29 01:28:48 2010 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 CDE263A67D0 for ; Tue, 29 Jun 2010 01:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 soALAsI4Ho+F for ; Tue, 29 Jun 2010 01:28:47 -0700 (PDT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id 96C7C3A65A5 for ; Tue, 29 Jun 2010 01:28:47 -0700 (PDT) Received: from TobysHP (host86-145-203-64.range86-145.btcentralplus.com [86.145.203.64]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MCOnp-1OKPW02URl-0097AT; Tue, 29 Jun 2010 10:28:54 +0200 From: "Toby Moncaster" To: , "'Bob Briscoe'" References: <201006251245.o5PCjAXf023753@bagheera.jungle.bt.co.uk> <4C29319F.7070200@informatik.uni-wuerzburg.de> In-Reply-To: <4C29319F.7070200@informatik.uni-wuerzburg.de> Date: Tue, 29 Jun 2010 09:28:53 +0100 Message-ID: <000101cb1765$1c22ce90$54686bb0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsXGp697blxWBJxSCKBIqyGwybHsgASWV+w Content-Language: en-gb X-Provags-ID: V01U2FsdGVkX1+5czgwFTLiyJ+CktQbSZEmXjOZ5Xx8NBwkkX5 qfj2tvP07xJBf54EFxH+5ihkFY9J1A4vOrfni2UcGPfyvohzWh Xn1gWn3QQO7LTmZwY4FRFa3iuswH+be Cc: "'CHAN, Kwok Ho'" , 'Daisuke SATOH' , 'PCN IETF list' Subject: Re: [PCN] plan for PCN encodings, now ecn-tunnel is in last call X-BeenThere: pcn@ietf.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, 29 Jun 2010 08:28:49 -0000 I have trimmed the reply to the key points Michael was making > -----Original Message----- > From: Michael Menth [mailto:menth@informatik.uni-wuerzburg.de] > Sent: 29 June 2010 00:35 > To: Bob Briscoe > Cc: BABIARZ, Jozef Z; Daisuke SATOH; Toby Moncaster; CHAN, Kwok Ho; PCN > IETF list > Subject: Re: plan for PCN encodings, now ecn-tunnel is in last call > > Hi Bob and all, > > > * RFC5696 (baseline encoding) -> obsoleted by 3-in-1 encoding{2} > On the one hand I like the idea to have only a single relevant > encoding. > On the other hand I am not 100% sure that baseline encoding is no > longer > needed as it may take some time until new tunnels will be deployed. > > I also thought that another advantage of baseline might be that it > requires only two PCN states so that it requires fewer codepoints in > the > MPLS header. However, the same can be done with 3-in-1 encoding if only > one marking scheme is used. After reading rfc 5129 it seems to me that > pcn is considered only in the appendix and that only 3-in-1 is > considered but baseline is not. Therefore, when defining a necessary > adaptation from 3-in-1 to mpls shim, it is possible to define a > translation for three and for two used pcn states in that document. Hm, > has anybody understood me? Am I correct? That shows that baseline wasn't even invented as an option until after RFC5129 had been published... The really key point relates to the issue of when the new tunnels are deployed. I suspect Bob's argument might be that this would add another deployment incentive for those new tunnels, on the other hand things can take a good while to be deployed in the core... One solution would be to effectively merge the two by having a "legacy encoding" in 3-in-1 that is essentially baseline and applies whenever old-style tunnels are in operation... > > > > * draft-ietf-pcn-psdm-encoding -> leave to expire? > ok. I saw some positive comments about psdm. However, I think what > people like is rather the implicit probing feather than the encoding > itself. I'll provide a write-up to separate implicit probing (edge > behavior for admission control) from the encoding issue and make clear > that it equally works with baseline or 3-in-1 encoding. That sounds an excellent idea. I think you are right that it was the probing feature that attracted most people and as you rightly say, that can be used with other encodings. > > > > > {Note 2}: To anyone not paying close attention to the PCN w-g, they > > will be (and are) confused by multiple encodings. I think it would be > > best to re-write 3-in-1 a little so it can obsolete the baseline, > > rather than keeping both on the stds track. > Currently I see that only the tunneling issue is an advantage of > baseline encoding over 3-in-1. If we can expect that new tunnels are > supported when PCN is deployed, I think baseline can be well obsoleted > by 3-in-1 encoding. See my earlier comment about merging the two documents and providing a legacy encoding within 3-in-1 > > > > > {Note 3}: 3-state is the only encoding that explicitly supports e2e > > ECN, but e2e ECN can be supported with tunnelling across the PCN > > domain instead. IMO tunnelling across the domain is more likely to be > > used if e2e ECN is needed, so I would let 3-state expire. Then, in > > 3-in-1 we should explicitly say that PCN domain tunnelling MUST be > > used when incoming packets are alread ECT. > I do not think that 3-state is very useful: > 1) it cannot fully support e2e ECN - it gives support only if packets > are not re-marked in a PCN domain, therefore, it cannot substitute > tunneling > 2) providing combined ECN & PCN information to end hosts requires > additional signalling to the egress node which is a lot of extra work > that still needs to be done. If the egress node has this information, > it > can provide combined PCN & ECN information also without this type of > encoding. > Therefore, I can well live with the option of expiring 3-state > encoding. Reasonable points. Would like to get an explicit response from Ingemar and the others that were interested in E2E ECN support in PCN... Toby From daisuke.satoh@ntt-at.co.jp Tue Jun 29 01:30:51 2010 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 3B8393A6981 for ; Tue, 29 Jun 2010 01:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.51 X-Spam-Level: ** X-Spam-Status: No, score=2.51 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzLpZH4h2mUJ for ; Tue, 29 Jun 2010 01:30:50 -0700 (PDT) Received: from sg.ntt-at.co.jp (roma.ntt-at.co.jp [202.253.160.19]) by core3.amsl.com (Postfix) with SMTP id 956BE3A67D0 for ; Tue, 29 Jun 2010 01:30:49 -0700 (PDT) Received: (qmail 66891 invoked by alias); 29 Jun 2010 17:30:59 +0900 Received: from gwall1.bb.ntt-at.co.jp (192.168.5.201) by subgate.bb.ntt-at.co.jp with SMTP; 29 Jun 2010 17:30:59 +0900 Received: (from root@localhost) by gwall1.bb.ntt-at.co.jp (8.13.1/8.13.1) id o5T8UxFg024015; Tue, 29 Jun 2010 17:30:59 +0900 Received: from vcsrv1.bb.ntt-at.co.jp [192.168.2.9] by gwall1.bb.ntt-at.co.jp with ESMTP id TAA24014; Tue, 29 Jun 2010 17:30:59 +0900 Received: from vcsrv1.bb.ntt-at.co.jp (vcsrv1.bb.ntt-at.co.jp [127.0.0.1]) by vcsrv1.bb.ntt-at.co.jp (8.13.8/8.13.8) with ESMTP id o5T8Ux4n014948; Tue, 29 Jun 2010 17:30:59 +0900 Received: from pacific.bb.ntt-at.co.jp (pacific.bb.ntt-at.co.jp [192.168.2.16]) by vcsrv1.bb.ntt-at.co.jp (8.13.8/8.13.8) with ESMTP id o5T8Ux7a014945; Tue, 29 Jun 2010 17:30:59 +0900 Received: from atmail22.am.ntt-at.co.jp (atmail22.am.ntt-at.co.jp [192.168.5.162]) by pacific.bb.ntt-at.co.jp (8.13.1/cf/pacific) with ESMTP id o5T8UxiE059890; Tue, 29 Jun 2010 17:30:59 +0900 (JST) (envelope-from daisuke.satoh@ntt-at.co.jp) Received: from [192.168.23.66] (ip23-066.tec.ntt-at.co.jp [192.168.23.66]) by atmail22.am.ntt-at.co.jp (Postfix) with ESMTP id CD0F740F019; Tue, 29 Jun 2010 17:30:53 +0900 (JST) Date: Tue, 29 Jun 2010 17:30:53 +0900 From: SATOH Daisuke To: menth@informatik.uni-wuerzburg.de In-Reply-To: <4C29319F.7070200@informatik.uni-wuerzburg.de> References: <201006251245.o5PCjAXf023753@bagheera.jungle.bt.co.uk> <4C29319F.7070200@informatik.uni-wuerzburg.de> Message-Id: <20100629173053.D880.26AD349@ntt-at.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.51.07 [ja] Cc: "CHAN, Kwok Ho" , PCN IETF list Subject: Re: [PCN] plan for PCN encodings, now ecn-tunnel is in last call X-BeenThere: pcn@ietf.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, 29 Jun 2010 08:30:51 -0000 Dear Bob, Michael, and all On Tue, 29 Jun 2010 01:34:55 +0200 Michael Menth wrote: > Hi Bob and all, > > Bob Briscoe schrieb: > > Joe, Daisuke, Toby, Michael, Kwok, > > > > I writing to you all as co-authors of the various PCN encoding drafts > > and RFCs, and to Kwok as author of the encoding comparison draft. > > > > I have started this conversation between you all rather than starting > > numerous side conversations between slightly different sets of > > co-authors. I have also included the PCN list as there are others with > > interest in the outcome (not least the chairs). I hope that's OK - > > otherwise please accept my apologies and feel free to switch to > > off-list mode. > > > > The IETF last call on ietf-tsvwg-ecn-tunnel will end on 6 Jul 10. > > Assuming it goes thru without substantive changes, I would like to > > suggest a plan for how to deal with all the experimental PCN encodings > > and then to try to update the drafts accordingly before the Maastricht > > deadline. > > > > * draft-ietf-pcn-3-in-1-encoding -> add applicability to sm{1} -> stds > > track > ok OK > > > * RFC5696 (baseline encoding) -> obsoleted by 3-in-1 encoding{2} > On the one hand I like the idea to have only a single relevant encoding. > On the other hand I am not 100% sure that baseline encoding is no longer > needed as it may take some time until new tunnels will be deployed. > > I also thought that another advantage of baseline might be that it > requires only two PCN states so that it requires fewer codepoints in the > MPLS header. However, the same can be done with 3-in-1 encoding if only > one marking scheme is used. After reading rfc 5129 it seems to me that > pcn is considered only in the appendix and that only 3-in-1 is > considered but baseline is not. Therefore, when defining a necessary > adaptation from 3-in-1 to mpls shim, it is possible to define a > translation for three and for two used pcn states in that document. Hm, > has anybody understood me? Am I correct? > As Michael writes, adaptaion from 3-in-1 to mpls shim is necessary. > > * draft-ietf-pcn-3-state-encoding -> expt track or expire{3} > ok OK > > > * draft-ietf-pcn-psdm-encoding -> leave to expire? OK. > ok. I saw some positive comments about psdm. However, I think what > people like is rather the implicit probing feather than the encoding > itself. I'll provide a write-up to separate implicit probing (edge > behavior for admission control) from the encoding issue and make clear > that it equally works with baseline or 3-in-1 encoding. > > > * draft-satoh-pcn-st-marking -> (expired) -> leave to expire? > ok OK Best regards, Daisuke From menth@informatik.uni-wuerzburg.de Tue Jun 29 07:29:23 2010 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 5F7CC3A6A47 for ; Tue, 29 Jun 2010 07:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 zP9RBPo5PCK2 for ; Tue, 29 Jun 2010 07:29:21 -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 700A63A6A4D for ; Tue, 29 Jun 2010 07:29:20 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 93F8521AD3; Tue, 29 Jun 2010 16:29:30 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 8C92049042; Tue, 29 Jun 2010 16:29:30 +0200 (CEST) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from [132.187.12.151] (win3151.informatik.uni-wuerzburg.de [132.187.12.151]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTPSA id 635BC41F8E; Tue, 29 Jun 2010 16:29:30 +0200 (CEST) Message-ID: <4C2A034B.7090803@informatik.uni-wuerzburg.de> Date: Tue, 29 Jun 2010 16:29:31 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Bob Briscoe , Toby Moncaster , pcn Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: [PCN] Application of 3-in-1 to a single marking scheme 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: Tue, 29 Jun 2010 14:29:23 -0000 Hi Bob, Toby, and all, in 3-in-1 encoding we have the following mapping to ECN codepoints: not-ECT: not-PCN ECT(0): not-marked (NM) ECT(1): threshold-marked (ThM) CE: excess-traffic-marked (ETM) 3-in-1 encoding can also be used with only a single marking scheme so that packets are re-marked to either ETM or ThM. Here we have two fundamentally different encoding options: a) baseline style i) for excess-traffic-marking not-ECT: not-PCN ECT(0): not-marked (NM) CE: excess-traffic-marked (ETM) ii) for threshold-marking not-ECT: not-PCN ECT(0): not-marked (NM) CE: excess-traffic-marked (ETM) Here, only two codepoints are effectively used for pcn encoding (ECT(0) and CE). When interior nodes perform threshold-marking, they need to know whether the three-state 3-in-1 encoding is used or the two-state 3-in-1 encoding to re-mark packets correctly. Thus, interior nodes need to be configured with the exact encoding option (three-state, a.i or a.ii). The advantage of this encoding scheme is that it works well with old tunnels. b) "no-encoding-config" style i) for excess-traffic-marking not-ECT: not-PCN ECT(0): not-marked (NM) CE: excess-traffic-marked (ETM) ii) for threshold-marking not-ECT: not-PCN ECT(0): not-marked (NM) ECT(1): excess-traffic-marked (ETM) Here, three codepoints are effectively blocked for pcn encoding (ECT(0), ECT(1), and CE). With this encoding option, interior nodes just need to know that 3-in-1 encoding is used and do not need to be configured with any more information (such as three-state or b.i or b.ii). The drawback is that threshold-marking does not work with old-fashion tunnels. When going from PCN encoding from IP headers to shim headers in MPLS, a "no-config" style cannot be maintained as it blocks 3 pcn codepoints which is too expensive when only two of them are effectively used. Therefore, LSRs need to be configured anyway whether three-state encoding or two-state encoding using option i) or ii) is used. Is my analysis clear and do you share it? What should be the consequence for a two-state limitation of 3-in-1 encoding? Is a) or b) more clever for two-state pcn in IP? It probably boils down to the question whether legacy tunnels are more important than "no-encoding-config" for IP equipment. Best wishes, Michael -- PD Dr. habil. 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/31-86632 (new) mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From tom111.taylor@bell.net Tue Jun 29 07:48:12 2010 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 24A993A6842 for ; Tue, 29 Jun 2010 07:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.875 X-Spam-Level: X-Spam-Status: No, score=0.875 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWeMV4MkL0nL for ; Tue, 29 Jun 2010 07:48:11 -0700 (PDT) Received: from blu0-omc1-s38.blu0.hotmail.com (blu0-omc1-s38.blu0.hotmail.com [65.55.116.49]) by core3.amsl.com (Postfix) with ESMTP id 570F93A6807 for ; Tue, 29 Jun 2010 07:48:10 -0700 (PDT) Received: from BLU0-SMTP98 ([65.55.116.9]) by blu0-omc1-s38.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Jun 2010 07:48:20 -0700 X-Originating-IP: [70.26.17.94] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.26.17.94]) by BLU0-SMTP98.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Jun 2010 07:48:20 -0700 Date: Tue, 29 Jun 2010 10:48:18 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: pcn References: <201006251245.o5PCjAXf023753@bagheera.jungle.bt.co.uk> <4C29319F.7070200@informatik.uni-wuerzburg.de> In-Reply-To: <4C29319F.7070200@informatik.uni-wuerzburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jun 2010 14:48:21.0024 (UTC) FILETIME=[1E421200:01CB179A] Subject: Re: [PCN] plan for PCN encodings, now ecn-tunnel is in last call X-BeenThere: pcn@ietf.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, 29 Jun 2010 14:48:12 -0000 Does this mean we have to postpone WGLC on the edge behaviour drafts? Or can we factor in the changes at a later stage? Tom Taylor From rbriscoe@jungle.bt.co.uk Tue Jun 29 10:54:38 2010 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 329A43A68F6 for ; Tue, 29 Jun 2010 10:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.574 X-Spam-Level: X-Spam-Status: No, score=0.574 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_50=0.001, 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 WEsbdN-Nqm1W for ; Tue, 29 Jun 2010 10:54:32 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id C3C503A6C14 for ; Tue, 29 Jun 2010 10:54:31 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Jun 2010 18:54:41 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Jun 2010 18:54:41 +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 1277834079686; Tue, 29 Jun 2010 18:54:39 +0100 Received: from MUT.jungle.bt.co.uk ([10.215.130.87]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id o5THsb3s016433; Tue, 29 Jun 2010 18:54:37 +0100 Message-Id: <201006291754.o5THsb3s016433@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 29 Jun 2010 18:54:39 +0100 To: menth@informatik.uni-wuerzburg.de From: Bob Briscoe In-Reply-To: <4C2A034B.7090803@informatik.uni-wuerzburg.de> References: <4C2A034B.7090803@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: 29 Jun 2010 17:54:41.0318 (UTC) FILETIME=[263B8C60:01CB17B4] Cc: pcn Subject: Re: [PCN] Application of 3-in-1 to a single marking scheme X-BeenThere: pcn@ietf.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, 29 Jun 2010 17:54:38 -0000 Michael, I thought single-marking only ever uses the excess-traffic marking algo? Then marking algos can be hard-coded (ie no config needed) so ETM always marks CE and ThM (if used) always marks ECT(1). Is threshold marking ever used for single marking? Or is there any proposed scheme (that has been simulated and it works) where threshold marking alone is used? * If there is, then we need to cater for a)ii) and b)ii). * If there is not, but someone might want to try theshold marking alone in future, then that someone shouldn't expect to do something experimental without any configuration. Ie. they have to ask their router vendor to allow them to: - either config their routers to encode threshold markings as CE [a)ii)] - or upgrade their tunnels to comply with ecn-tunnel [b)ii)] Or am I missing something? Bob At 15:29 29/06/2010, Michael Menth wrote: >Hi Bob, Toby, and all, > >in 3-in-1 encoding we have the following mapping to ECN codepoints: > >not-ECT: not-PCN >ECT(0): not-marked (NM) >ECT(1): threshold-marked (ThM) >CE: excess-traffic-marked (ETM) > >3-in-1 encoding can also be used with only a single marking scheme >so that packets are re-marked to either ETM or ThM. Here we have two >fundamentally different encoding options: > >a) baseline style > >i) for excess-traffic-marking >not-ECT: not-PCN >ECT(0): not-marked (NM) >CE: excess-traffic-marked (ETM) > >ii) for threshold-marking >not-ECT: not-PCN >ECT(0): not-marked (NM) >CE: excess-traffic-marked (ETM) > >Here, only two codepoints are effectively used for pcn encoding >(ECT(0) and CE). When interior nodes perform threshold-marking, they >need to know whether the three-state 3-in-1 encoding is used or the >two-state 3-in-1 encoding to re-mark packets correctly. Thus, >interior nodes need to be configured with the exact encoding option >(three-state, a.i or a.ii). The advantage of this encoding scheme is >that it works well with old tunnels. > > >b) "no-encoding-config" style > >i) for excess-traffic-marking >not-ECT: not-PCN >ECT(0): not-marked (NM) >CE: excess-traffic-marked (ETM) > >ii) for threshold-marking >not-ECT: not-PCN >ECT(0): not-marked (NM) >ECT(1): excess-traffic-marked (ETM) > >Here, three codepoints are effectively blocked for pcn encoding >(ECT(0), ECT(1), and CE). With this encoding option, interior nodes >just need to know that 3-in-1 encoding is used and do not need to be >configured with any more information (such as three-state or b.i or >b.ii). The drawback is that threshold-marking does not work with >old-fashion tunnels. > > >When going from PCN encoding from IP headers to shim headers in >MPLS, a "no-config" style cannot be maintained as it blocks 3 pcn >codepoints which is too expensive when only two of them are >effectively used. Therefore, LSRs need to be configured anyway >whether three-state encoding or two-state encoding using option i) >or ii) is used. > > >Is my analysis clear and do you share it? What should be the >consequence for a two-state limitation of 3-in-1 encoding? Is a) or >b) more clever for two-state pcn in IP? It probably boils down to >the question whether legacy tunnels are more important than >"no-encoding-config" for IP equipment. > >Best wishes, > > Michael > >-- >PD Dr. habil. 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/31-86632 (new) >mailto:menth@informatik.uni-wuerzburg.de >http://www3.informatik.uni-wuerzburg.de/research/ngn ________________________________________________________________ Bob Briscoe, BT Innovate & Design From menth@informatik.uni-wuerzburg.de Tue Jun 29 12:00:56 2010 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 A288C3A6C19 for ; Tue, 29 Jun 2010 12:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 4niQZeH4tVrL for ; Tue, 29 Jun 2010 12:00:55 -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 19A483A6C42 for ; Tue, 29 Jun 2010 12:00:37 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 602D4735F3; Tue, 29 Jun 2010 21:00:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 5D23C55361; Tue, 29 Jun 2010 21:00:47 +0200 (CEST) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from [192.168.1.2] (f051124156.adsl.alicedsl.de [78.51.124.156]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTPSA id 0D05C62A25; Tue, 29 Jun 2010 21:00:47 +0200 (CEST) Message-ID: <4C2A42E0.8070106@informatik.uni-wuerzburg.de> Date: Tue, 29 Jun 2010 21:00:48 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Bob Briscoe References: <4C2A034B.7090803@informatik.uni-wuerzburg.de> <201006291754.o5THsb3s016433@bagheera.jungle.bt.co.uk> In-Reply-To: <201006291754.o5THsb3s016433@bagheera.jungle.bt.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn Subject: Re: [PCN] Application of 3-in-1 to a single marking scheme 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: Tue, 29 Jun 2010 19:00:56 -0000 Hi Bob, Bob Briscoe schrieb: > Michael, > > I thought single-marking only ever uses the excess-traffic marking algo? Depends which "Single Marking" you are talking about ;-) 1) There is the SM edge behavior which uses only excess-traffic-marking 2) There is the admission control aspect of the CL edge behavior which requires only threshold-marking. It was often discussed that this feature may be deployed also without flow termination especially in MPLS networks when a third pcn codepoint is just not available. I think that was often Ruediger's and Joe's point. For this case it makes sense to enable only threshold marking. > > Then marking algos can be hard-coded (ie no config needed) so ETM > always marks CE and ThM (if used) always marks ECT(1). > > Is threshold marking ever used for single marking? Or is there any > proposed scheme (that has been simulated and it works) where threshold > marking alone is used? Yes, see 2) above. Regards, Michael > > * If there is, then we need to cater for a)ii) and b)ii). > * If there is not, but someone might want to try theshold marking > alone in future, then that someone shouldn't expect to do something > experimental without any configuration. Ie. they have to ask their > router vendor to allow them to: > - either config their routers to encode threshold markings as CE > [a)ii)] > - or upgrade their tunnels to comply with ecn-tunnel [b)ii)] > > Or am I missing something? > > > Bob > > At 15:29 29/06/2010, Michael Menth wrote: >> Hi Bob, Toby, and all, >> >> in 3-in-1 encoding we have the following mapping to ECN codepoints: >> >> not-ECT: not-PCN >> ECT(0): not-marked (NM) >> ECT(1): threshold-marked (ThM) >> CE: excess-traffic-marked (ETM) >> >> 3-in-1 encoding can also be used with only a single marking scheme so >> that packets are re-marked to either ETM or ThM. Here we have two >> fundamentally different encoding options: >> >> a) baseline style >> >> i) for excess-traffic-marking >> not-ECT: not-PCN >> ECT(0): not-marked (NM) >> CE: excess-traffic-marked (ETM) >> >> ii) for threshold-marking >> not-ECT: not-PCN >> ECT(0): not-marked (NM) >> CE: excess-traffic-marked (ETM) >> >> Here, only two codepoints are effectively used for pcn encoding >> (ECT(0) and CE). When interior nodes perform threshold-marking, they >> need to know whether the three-state 3-in-1 encoding is used or the >> two-state 3-in-1 encoding to re-mark packets correctly. Thus, >> interior nodes need to be configured with the exact encoding option >> (three-state, a.i or a.ii). The advantage of this encoding scheme is >> that it works well with old tunnels. >> >> >> b) "no-encoding-config" style >> >> i) for excess-traffic-marking >> not-ECT: not-PCN >> ECT(0): not-marked (NM) >> CE: excess-traffic-marked (ETM) >> >> ii) for threshold-marking >> not-ECT: not-PCN >> ECT(0): not-marked (NM) >> ECT(1): excess-traffic-marked (ETM) >> >> Here, three codepoints are effectively blocked for pcn encoding >> (ECT(0), ECT(1), and CE). With this encoding option, interior nodes >> just need to know that 3-in-1 encoding is used and do not need to be >> configured with any more information (such as three-state or b.i or >> b.ii). The drawback is that threshold-marking does not work with >> old-fashion tunnels. >> >> >> When going from PCN encoding from IP headers to shim headers in MPLS, >> a "no-config" style cannot be maintained as it blocks 3 pcn >> codepoints which is too expensive when only two of them are >> effectively used. Therefore, LSRs need to be configured anyway >> whether three-state encoding or two-state encoding using option i) or >> ii) is used. >> >> >> Is my analysis clear and do you share it? What should be the >> consequence for a two-state limitation of 3-in-1 encoding? Is a) or >> b) more clever for two-state pcn in IP? It probably boils down to the >> question whether legacy tunnels are more important than >> "no-encoding-config" for IP equipment. >> >> Best wishes, >> >> Michael >> >> -- >> PD Dr. habil. 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/31-86632 (new) >> mailto:menth@informatik.uni-wuerzburg.de >> http://www3.informatik.uni-wuerzburg.de/research/ngn > > ________________________________________________________________ > Bob Briscoe, BT Innovate & Design -- PD Dr. habil. 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/31-86632 (new) mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From menth@informatik.uni-wuerzburg.de Tue Jun 29 14:21:02 2010 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 0A8773A6930 for ; Tue, 29 Jun 2010 14:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 97d9KxD0QNTt for ; Tue, 29 Jun 2010 14:20:59 -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 8FB003A67F3 for ; Tue, 29 Jun 2010 14:20:56 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 17065736B2; Tue, 29 Jun 2010 23:21:07 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 12FBC55361; Tue, 29 Jun 2010 23:21:07 +0200 (CEST) X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Received: from [192.168.1.2] (f051124156.adsl.alicedsl.de [78.51.124.156]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTPSA id B7F5C41F90; Tue, 29 Jun 2010 23:21:06 +0200 (CEST) Message-ID: <4C2A63C0.5010004@informatik.uni-wuerzburg.de> Date: Tue, 29 Jun 2010 23:21:04 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Bob Briscoe References: <4C2A034B.7090803@informatik.uni-wuerzburg.de> In-Reply-To: <4C2A034B.7090803@informatik.uni-wuerzburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn Subject: Re: [PCN] Application of 3-in-1 to a single marking scheme 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: Tue, 29 Jun 2010 21:21:02 -0000 Hi all, what I forgot to say: Solution a) is basically RFC5696+current 3-in-1 encoding while solution b) is only 3-in-1 encoding and and two explicit subsets of it. If we want to go with a), we could keep RFC5696, if we want to go with b), we should obsolete RFC5696. Opinions? Best wishes, Michael Michael Menth schrieb: > Hi Bob, Toby, and all, > > in 3-in-1 encoding we have the following mapping to ECN codepoints: > > not-ECT: not-PCN > ECT(0): not-marked (NM) > ECT(1): threshold-marked (ThM) > CE: excess-traffic-marked (ETM) > > 3-in-1 encoding can also be used with only a single marking scheme so > that packets are re-marked to either ETM or ThM. Here we have two > fundamentally different encoding options: > > a) baseline style > > i) for excess-traffic-marking > not-ECT: not-PCN > ECT(0): not-marked (NM) > CE: excess-traffic-marked (ETM) > > ii) for threshold-marking > not-ECT: not-PCN > ECT(0): not-marked (NM) > CE: excess-traffic-marked (ETM) > > Here, only two codepoints are effectively used for pcn encoding > (ECT(0) and CE). When interior nodes perform threshold-marking, they > need to know whether the three-state 3-in-1 encoding is used or the > two-state 3-in-1 encoding to re-mark packets correctly. Thus, interior > nodes need to be configured with the exact encoding option > (three-state, a.i or a.ii). The advantage of this encoding scheme is > that it works well with old tunnels. > > > b) "no-encoding-config" style > > i) for excess-traffic-marking > not-ECT: not-PCN > ECT(0): not-marked (NM) > CE: excess-traffic-marked (ETM) > > ii) for threshold-marking > not-ECT: not-PCN > ECT(0): not-marked (NM) > ECT(1): excess-traffic-marked (ETM) > > Here, three codepoints are effectively blocked for pcn encoding > (ECT(0), ECT(1), and CE). With this encoding option, interior nodes > just need to know that 3-in-1 encoding is used and do not need to be > configured with any more information (such as three-state or b.i or > b.ii). The drawback is that threshold-marking does not work with > old-fashion tunnels. > > > When going from PCN encoding from IP headers to shim headers in MPLS, > a "no-config" style cannot be maintained as it blocks 3 pcn codepoints > which is too expensive when only two of them are effectively used. > Therefore, LSRs need to be configured anyway whether three-state > encoding or two-state encoding using option i) or ii) is used. > > > Is my analysis clear and do you share it? What should be the > consequence for a two-state limitation of 3-in-1 encoding? Is a) or b) > more clever for two-state pcn in IP? It probably boils down to the > question whether legacy tunnels are more important than > "no-encoding-config" for IP equipment. > > Best wishes, > > Michael > -- PD Dr. habil. 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/31-86632 (new) mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From sob@harvard.edu Tue Jun 29 17:33:41 2010 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 32EBE3A68C7 for ; Tue, 29 Jun 2010 17:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.27 X-Spam-Level: X-Spam-Status: No, score=-1.27 tagged_above=-999 required=5 tests=[AWL=-0.160, 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 gYWV95UmxCzf for ; Tue, 29 Jun 2010 17:33:40 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id 2943D3A68D3 for ; Tue, 29 Jun 2010 17:33:40 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 4669D189698; Tue, 29 Jun 2010 20:33:50 -0400 (EDT) To: pcn@ietf.org Message-Id: <20100630003350.4669D189698@newdev.eecs.harvard.edu> Date: Tue, 29 Jun 2010 20:33:50 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: [PCN] FW: Third Call for Nomcom 2010-11 Volunteers X-BeenThere: pcn@ietf.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, 30 Jun 2010 00:33:41 -0000 From: "Romascanu, Dan (Dan)" Please send this third call for volunteers for NomComm to your WG lists. Participating in NomComm is an important contribution to the future of the IETF. Regards, Dan -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Thomas Walsh Sent: Wednesday, June 30, 2010 12:31 AM To: ietf@ietf.org Subject: FW: Third Call for Nomcom 2010-11 Volunteers Please volunteer if you are eligible. You must have attended 3 of the last 5 IETF meetings to be eligible. -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of NomCom Chair Sent: Monday, June 28, 2010 4:58 PM To: IETF Announcement list Subject: Third Call for Nomcom 2010-11 Volunteers Hi all, This is the Third call for Volunteers for the 2010-2011 Nomcom. We are now 2/3 of the way through the volunteer period so if you are considering volunteering please do so now as the time in which you may volunteer is beginning to run short. The call for volunteers remains open until 17:00 PDT (24:00 UTC) on July 8, 2010. I am pleased to report that we currently have 65 volunteers thus far whose qualifications have been confirmed by the secretariat. I have notified each of these volunteers by email. I will publish the current list of volunteers in a separate message. If you volunteered before 12:00 PDT (19:00 UTC) on June 28 to serve as a voting member and have not received a confirmation email from me, please re-submit and bring to my attention right away! We still need additional volunteers, please! If you have attended at least 3 of the last 5 IETF meetings you are eligible to volunteer. The 10 nominating committee members are selected randomly from a pool of volunteers. The details of the operation of Nomcom may be found in RFC 3777. The process on how to volunteer for Nomcom is in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2330/ The lists of open positions and people whose terms end in March 2011 and thus the positions for which the nominating committee is responsible are summarized in the initial announcement: https://datatracker.ietf.org/ann/nomcom/2330/ Please volunteer by sending an email before: 17:00 PDT (24:00 UTC) July 8, 2010 as follows: To: nomcom-chair@ietf.org Subject: Nomcom 2010-11 Volunteer Please include the following information in the body: // As you enter in the IETF Registration Form, // First/Given name followed by Last/Family Name // typically what goes in the Company field // in the IETF Registration Form // // For confirmation if selected Please expect an email response from me within 3 days stating whether or not you are qualified. If you don't receive a response, please re-send your email with the tag "Duplicate:" added to the subject line. Thank you and I hope to hear from you, Thomas Walsh Chair, Nomcom 2010-11 Email: nomcom-chair@ietf.org _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf