From toby.moncaster@bt.com Thu Apr 2 05:55:48 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 956D028C1E0 for ; Thu, 2 Apr 2009 05:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=-0.317, BAYES_05=-1.11, 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 F4PYYItsgxqn for ; Thu, 2 Apr 2009 05:55:47 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 89CBE3A6A48 for ; Thu, 2 Apr 2009 05:55:47 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 13:56:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Apr 2009 13:56:47 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: defining extensions to baseline encoding Thread-Index: AcmxiebaIoJkYiSrRrSSz1ntePBeIACBw+wy References: <49C6CF4E.7050004@informatik.uni-wuerzburg.de><151C164FE2E066418D8D44D0801543A5D8C682@S4DE8PSAAQA.mitte.t-com.de> <49D14CA6.9010908@rogers.com> From: To: X-OriginalArrivalTime: 02 Apr 2009 12:56:48.0009 (UTC) FILETIME=[7BC84790:01C9B392] Subject: [PCN] defining extensions to baseline encoding X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 12:55:48 -0000 =20 At last weeks IETF it was agreed that the basline encoding draft is = pretty much ready for WGLC. There was also a lot of discussion about the = edge behaviour documents out of which came a suggestion that Tom Taylor = should write a draft setting out guidance on writing an edge behaviour = document for PCN. This triggered a thought - currently in the baseline = encoding draft there is a section about rules any extension encodings = have to follow in order to comply with this baseline encoding. I was = wondering whether it would be sensible to split this into a separate = document so you would hav: 1) a pure standards document defining the baseline encoding 2) a document akin to a BCP (e.g. probably informational but carrying = more weight) describing how any extension encoding scheme shoudl be = written and giving guidance on all the things that it will have to take = into account (such as tunneling constraints, choice of DSCPs, valid and = invalid state transitions, etc) =20 The pros and cons are as follows. =20 Pros: we get a cleaner baseline document. We ensure that all extension = encodings are proprely defined and compatible with baseline. We get 2 = RFCs for the price of 1 Cons: its a bit of extra work. We would need to be very precise in = defining what makes an acceptable extension.=20 I would be happy to do the split and to write the guidance document. Any = thoughts on this? =20 Toby From toby.moncaster@bt.com Thu Apr 2 06:04:45 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F18F3A6ACA for ; Thu, 2 Apr 2009 06:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.14 X-Spam-Level: X-Spam-Status: No, score=-3.14 tagged_above=-999 required=5 tests=[AWL=0.459, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61RAfccsbdaC for ; Thu, 2 Apr 2009 06:04:44 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 2FF833A68C3 for ; Thu, 2 Apr 2009 06:03:17 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Apr 2009 14:04:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Apr 2009 14:04:17 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: advancing experimental encoding schemes Thread-Index: Acmzk4eAFhuMqN2qRNu+hmz2X7kyug== From: To: X-OriginalArrivalTime: 02 Apr 2009 13:04:18.0211 (UTC) FILETIME=[881FA730:01C9B393] Subject: [PCN] advancing experimental encoding schemes X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2009 13:04:45 -0000 Hi All, =20 At the IETF meeting on Friday I think it was agreed that the following = drafts relating to experimental extensions to the baseline encoding can = be accepted as WG docs: =20 http://tools.ietf.org/html/draft-moncaster-pcn-3-state-encoding http://tools.ietf.org/html/draft-briscoe-pcn-3-in-1-encoding http://tools.ietf.org/html/draft-menth-pcn-psdm-encoding =20 I am intending to resubmit the first one this week. =20 Toby From menth@informatik.uni-wuerzburg.de Fri Apr 3 04:10:02 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 653BB3A68DE for ; Fri, 3 Apr 2009 04:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGre-IBbcsM9 for ; Fri, 3 Apr 2009 04:10:01 -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 499E23A6B59 for ; Fri, 3 Apr 2009 04:10:01 -0700 (PDT) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 0DAB3A080F; Fri, 3 Apr 2009 13:11:03 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 01A62A0693; Fri, 3 Apr 2009 13:11:03 +0200 (CEST) Received: from [92.226.145.242] (g226145242.adsl.alicedsl.de [92.226.145.242]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id C3AD219915E; Fri, 3 Apr 2009 13:11:02 +0200 (CEST) Message-ID: <49D5EEC9.2080402@informatik.uni-wuerzburg.de> Date: Fri, 03 Apr 2009 13:11:05 +0200 From: Michael Menth Organization: University of Wuerzburg User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: pcn Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Subject: [PCN] Tutorial on PCN 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: Fri, 03 Apr 2009 11:10:02 -0000 Hi all, I would like to draw your attention to the tutorial on PCN that I will give with my colleague Frank Lehrieder at IEEE ICC in Dresden, Germany, on Sunday, June 14 2009. http://www.ieee-icc.org/tutorials.html#PCN We are happy to have you as participants. Regards, Michael -- Dr. Michael Menth, Assistant Professor University of Wuerzburg, Institute of Computer Science Am Hubland, D-97074 Wuerzburg, Germany, room B206 phone: (+49)-931/888-6644, fax: (+49)-931/888-6632 mailto:menth@informatik.uni-wuerzburg.de http://www3.informatik.uni-wuerzburg.de/research/ngn From toby.moncaster@bt.com Fri Apr 3 07:12:10 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE3623A6E39 for ; Fri, 3 Apr 2009 07:12:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.181 X-Spam-Level: X-Spam-Status: No, score=-3.181 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkR2N8fIzSE5 for ; Fri, 3 Apr 2009 07:12:09 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id A76373A679C for ; Fri, 3 Apr 2009 07:12:09 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.61]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 15:13:10 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Apr 2009 15:13:09 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on display of valid/invalid states in baseline Thread-Index: Acm0ZlDO3iRz+kFVQeSoAAkfHkNjWA== From: To: X-OriginalArrivalTime: 03 Apr 2009 14:13:10.0149 (UTC) FILETIME=[515D1B50:01C9B466] Subject: [PCN] Question on display of valid/invalid states in baseline X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 14:12:10 -0000 Hi All, =20 I'm just going through the very thorough comments sent in by Gorry = Fairhurst about the baseline encoding draft. One of his=20 comments is that the following table is unclear: =20 +-----------+-------------+-----------------+-----------------------+ | PCN node | Codepoint | Valid codepoint | Invalid codepoint out | | type | in | out | | +-----------+-------------+-----------------+-----------------------+ | ingress | Any | NM (or Not-PCN) | PM | | interior | NM | NM or PM | Not-PCN or EXP | | interior | EXP + | EXP or PM | Not-PCN | | interior | Not-PCN | Not-PCN | Any other codepoint | | interior | PM | PM | Any other codepoint | | egress | Any | 00 | Any other codepoint * | +-----------+-------------+-----------------+-----------------------+ + This SHOULD cause an alarm to be raised at a higher layer. The packet MUST be treated as if it were NM. * Except where the egress node knows that other marks may be safely exposed outside the PCN-domain (e.g. [PCN-3-enc-state = ]). Table 2: Valid and Invalid Codepoint Transitions for PCN-packets at PCN-nodes Would people find the following table to be clearer? You read down the = row for the codepoint in and across the column for the codepoint out. At the intersection you can find if that is a valid combination for each type = of node... =20 (In =3D Ingress, Mid =3D Interior, Out =3D Egress, None means that no = node is=20 allowed to do that transition): =20 +----------------------------------------------------+ | Codepoint Out | +--------------+-------------+------------+------------+------------+ | Codepoint in | Not PCN(00) | NM(10) | EXP(01) | PM(11) | +--------------+-------------+------------+------------+------------+ | Not PCN(00) | In Mid Out | In --- --- | -- None -- | -- None -- | +--------------+-------------+------------+------------+------------+ | NM(10) | In --- Out | In Mid --- | ---None--- | -- Mid --- | +--------------+-------------+------------+------------+------------+ | EXP(01)+ | In --- Out | -- None -- | -- Mid --- | -- Mid --- | +--------------+-------------+------------+------------+------------+ | PM(11) | In --- Out* | -- None -- | -- None -- | -- --- Out | +--------------+-------------+------------+------------+------------+ + This SHOULD cause an alarm to be raised at a higher layer. The packet MUST be treated as if it carried the NM codepoint. * Except where the egress node knows that other marks may be safely exposed outside the PCN-domain (e.g. [PCN-3-enc-state = ]). It is hard to know how to make this clearer unless one has a separate = table for each of the 3 types of nodes. Basically the=20 rules can be summarised as Ingress doesn't care what comes in but can = only send out not-PCN or NM; Exterior nodes can=20 only send out not-PCN (00); Interior nodes are more difficult: not-PCN = must stay as not-PCN, PM must stay as PM, NM or EXP can go out unchanged or can be changed to PM. =20 Toby From tom.taylor@rogers.com Fri Apr 3 07:53:15 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CAC83A6CA6 for ; Fri, 3 Apr 2009 07:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.427, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywmZiG7L60gU for ; Fri, 3 Apr 2009 07:53:14 -0700 (PDT) Received: from smtp116.rog.mail.re2.yahoo.com (smtp116.rog.mail.re2.yahoo.com [68.142.225.232]) by core3.amsl.com (Postfix) with SMTP id D4BDB3A6AFB for ; Fri, 3 Apr 2009 07:52:57 -0700 (PDT) Received: (qmail 75319 invoked from network); 3 Apr 2009 14:54:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Ikf8XL9rPiEPAsjUVjXL9w6QI0JZ7dCjhXWndooaITJAb07J8Nq41eX0TeEtt4jpgSJhfT3+912qOiQGtp2GLXn39uzZftTHRIabrcAaQYpU4Z9au9IIipoa+17IApHyAFAlh1zvb7z/ilETReaYqTI+VWGIJdJev278xJg5Tfo= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@72.140.46.24 with plain) by smtp116.rog.mail.re2.yahoo.com with SMTP; 3 Apr 2009 14:54:00 -0000 X-YMail-OSG: Po9lzDAVM1kwCDTAPbthOT9AD7V5MhJiR87aLloy2fsKTuHwHiKgr_ZjwGD0ZHu6RQ-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49D62307.4090308@rogers.com> Date: Fri, 03 Apr 2009 10:53:59 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: toby.moncaster@bt.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: pcn@ietf.org Subject: Re: [PCN] Question on display of valid/invalid states in baseline X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 14:53:15 -0000 Frankly, I'd suggest that the table only deal with the interior node case, and the ingress and egress transitions be described only in text as you have done. After all, they are pretty simple. toby.moncaster@bt.com wrote: > Hi All, > > I'm just going through the very thorough comments sent in by Gorry Fairhurst about the baseline encoding draft. One of his > comments is that the following table is unclear: > > +-----------+-------------+-----------------+-----------------------+ > | PCN node | Codepoint | Valid codepoint | Invalid codepoint out | > | type | in | out | | > +-----------+-------------+-----------------+-----------------------+ > | ingress | Any | NM (or Not-PCN) | PM | > | interior | NM | NM or PM | Not-PCN or EXP | > | interior | EXP + | EXP or PM | Not-PCN | > | interior | Not-PCN | Not-PCN | Any other codepoint | > | interior | PM | PM | Any other codepoint | > | egress | Any | 00 | Any other codepoint * | > +-----------+-------------+-----------------+-----------------------+ > + This SHOULD cause an alarm to be raised at a higher layer. The > packet MUST be treated as if it were NM. > * Except where the egress node knows that other marks may be safely > exposed outside the PCN-domain (e.g. [PCN-3-enc-state ]). > > Table 2: Valid and Invalid Codepoint Transitions for > PCN-packets at PCN-nodes > > Would people find the following table to be clearer? You read down the row > for the codepoint in and across the column for the codepoint out. At the > intersection you can find if that is a valid combination for each type of > node... > > (In = Ingress, Mid = Interior, Out = Egress, None means that no node is > allowed to do that transition): > > +----------------------------------------------------+ > | Codepoint Out | > +--------------+-------------+------------+------------+------------+ > | Codepoint in | Not PCN(00) | NM(10) | EXP(01) | PM(11) | > +--------------+-------------+------------+------------+------------+ > | Not PCN(00) | In Mid Out | In --- --- | -- None -- | -- None -- | > +--------------+-------------+------------+------------+------------+ > | NM(10) | In --- Out | In Mid --- | ---None--- | -- Mid --- | > +--------------+-------------+------------+------------+------------+ > | EXP(01)+ | In --- Out | -- None -- | -- Mid --- | -- Mid --- | > +--------------+-------------+------------+------------+------------+ > | PM(11) | In --- Out* | -- None -- | -- None -- | -- --- Out | > +--------------+-------------+------------+------------+------------+ > + This SHOULD cause an alarm to be raised at a higher layer. The > packet MUST be treated as if it carried the NM codepoint. > * Except where the egress node knows that other marks may be safely > exposed outside the PCN-domain (e.g. [PCN-3-enc-state ]). > > It is hard to know how to make this clearer unless one has a separate table for each of the 3 types of nodes. Basically the > rules can be summarised as Ingress doesn't care what comes in but can only send out not-PCN or NM; Exterior nodes can > only send out not-PCN (00); Interior nodes are more difficult: not-PCN must stay as not-PCN, PM must stay as PM, NM or EXP > can go out unchanged or can be changed to PM. > > Toby > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > > From philip.eardley@bt.com Fri Apr 3 08:12:40 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90F3E3A6862 for ; Fri, 3 Apr 2009 08:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.881 X-Spam-Level: X-Spam-Status: No, score=-2.881 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPfEivqD1h5H for ; Fri, 3 Apr 2009 08:12:39 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id BF3CA3A6A07 for ; Fri, 3 Apr 2009 08:12:38 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Apr 2009 16:13:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 3 Apr 2009 16:13:39 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD7AC4@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <49D62307.4090308@rogers.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Question on display of valid/invalid states in baseline Thread-Index: Acm0bBcy0A+1xXsQQrmPA8kN/uQubQAAmnKQ From: To: , X-OriginalArrivalTime: 03 Apr 2009 15:13:40.0987 (UTC) FILETIME=[C58304B0:01C9B46E] Cc: pcn@ietf.org Subject: Re: [PCN] Question on display of valid/invalid states in baseline X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 15:12:40 -0000 I agree - either 1 table or 3 tables. It's quite complicated with them all in the same table, as well as raising picky points [like the '+' alarm comment doesn't apply at the ingress]. The PM-PM box is missing a 'Mid' btw. { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Tom { Taylor { Sent: 03 April 2009 15:54 { To: Moncaster,T,Toby,CXR9 R { Cc: pcn@ietf.org { Subject: Re: [PCN] Question on display of valid/invalid states in baseline {=20 { Frankly, I'd suggest that the table only deal with the interior node case, { and { the ingress and egress transitions be described only in text as you have { done. { After all, they are pretty simple. {=20 { toby.moncaster@bt.com wrote: { > Hi All, { > { > I'm just going through the very thorough comments sent in by Gorry { Fairhurst about the baseline encoding draft. One of his { > comments is that the following table is unclear: { > { > +-----------+-------------+-----------------+-----------------------+ { > | PCN node | Codepoint | Valid codepoint | Invalid codepoint out | { > | type | in | out | | { > +-----------+-------------+-----------------+-----------------------+ { > | ingress | Any | NM (or Not-PCN) | PM | { > | interior | NM | NM or PM | Not-PCN or EXP | { > | interior | EXP + | EXP or PM | Not-PCN | { > | interior | Not-PCN | Not-PCN | Any other codepoint | { > | interior | PM | PM | Any other codepoint | { > | egress | Any | 00 | Any other codepoint * | { > +-----------+-------------+-----------------+-----------------------+ { > + This SHOULD cause an alarm to be raised at a higher layer. The { > packet MUST be treated as if it were NM. { > * Except where the egress node knows that other marks may be safely { > exposed outside the PCN-domain (e.g. [PCN-3-enc-state { ]). { > { > Table 2: Valid and Invalid Codepoint Transitions for { > PCN-packets at PCN-nodes { > { > Would people find the following table to be clearer? You read down the { row { > for the codepoint in and across the column for the codepoint out. At the { > intersection you can find if that is a valid combination for each type { of { > node... { > { > (In =3D Ingress, Mid =3D Interior, Out =3D Egress, None means that = no node is { > allowed to do that transition): { > { > +----------------------------------------------------+ { > | Codepoint Out | { > +--------------+-------------+------------+------------+------------+ { > | Codepoint in | Not PCN(00) | NM(10) | EXP(01) | PM(11) | { > +--------------+-------------+------------+------------+------------+ { > | Not PCN(00) | In Mid Out | In --- --- | -- None -- | -- None -- | { > +--------------+-------------+------------+------------+------------+ { > | NM(10) | In --- Out | In Mid --- | ---None--- | -- Mid --- | { > +--------------+-------------+------------+------------+------------+ { > | EXP(01)+ | In --- Out | -- None -- | -- Mid --- | -- Mid --- | { > +--------------+-------------+------------+------------+------------+ { > | PM(11) | In --- Out* | -- None -- | -- None -- | -- --- Out | { > +--------------+-------------+------------+------------+------------+ { > + This SHOULD cause an alarm to be raised at a higher layer. The { > packet MUST be treated as if it carried the NM codepoint. { > * Except where the egress node knows that other marks may be safely { > exposed outside the PCN-domain (e.g. [PCN-3-enc-state { ]). { > { > It is hard to know how to make this clearer unless one has a separate { table for each of the 3 types of nodes. Basically the { > rules can be summarised as Ingress doesn't care what comes in but can { only send out not-PCN or NM; Exterior nodes can { > only send out not-PCN (00); Interior nodes are more difficult: not-PCN { must stay as not-PCN, PM must stay as PM, NM or EXP { > can go out unchanged or can be changed to PM. { > { > Toby { > _______________________________________________ { > PCN mailing list { > PCN@ietf.org { > https://www.ietf.org/mailman/listinfo/pcn { > { > { _______________________________________________ { PCN mailing list { PCN@ietf.org { https://www.ietf.org/mailman/listinfo/pcn From philip.eardley@bt.com Mon Apr 6 02:26:42 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F7C63A6C03 for ; Mon, 6 Apr 2009 02:26:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.133 X-Spam-Level: X-Spam-Status: No, score=-1.133 tagged_above=-999 required=5 tests=[AWL=-1.635, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_ASCII0=1.5, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 66RHOR7-sv6G for ; Mon, 6 Apr 2009 02:26:39 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 27CCE3A6BEB for ; Mon, 6 Apr 2009 02:26:38 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Apr 2009 10:27:43 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9B699.EF959C52" Date: Mon, 6 Apr 2009 10:27:42 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD7AD2@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last call comment on draft-ietf-pcn-marking-behaviour-02 Thread-Index: Acm2me+mW7Rh3oxsT96Bv6G8XpG5ow== From: To: X-OriginalArrivalTime: 06 Apr 2009 09:27:43.0014 (UTC) FILETIME=[F008F460:01C9B699] Subject: [PCN] Last call comment on draft-ietf-pcn-marking-behaviour-02 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 09:26:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B699.EF959C52 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I guess the last call hasn't formally started yet, so here's an early comment. =20 Instead of "traffic conditioning" a better term to use would be "dropping" or "policing". Because in the diffserv docs, 'conditioning' is used to refer collectively to metering /marking /shaping /dropping.=20 =20 There is also one use of 'traffic conditioning' in the architecture doc [S4.2] which I'll alter. =20 Best wishes, phil =20 ------_=_NextPart_001_01C9B699.EF959C52 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I guess the last call hasn’t formally = started yet, so here’s an early comment.

 

Instead of “traffic conditioning” = a better term to use would be “dropping” or “policing”. = Because in the diffserv docs, ‘conditioning’ is used to refer = collectively to metering /marking /shaping /dropping.

 

There is also one use of ‘traffic = conditioning’ in the architecture doc [S4.2] which I’ll alter.

 

Best wishes,

phil

 

=00 ------_=_NextPart_001_01C9B699.EF959C52-- From sob@harvard.edu Mon Apr 6 05:44:43 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7816B3A6A45 for ; Mon, 6 Apr 2009 05:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7fxVQ8dJ95b for ; Mon, 6 Apr 2009 05:44:42 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id D0D2E3A6B31 for ; Mon, 6 Apr 2009 05:44:42 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 318EC156ABED; Mon, 6 Apr 2009 08:45:47 -0400 (EDT) To: pcn@ietf.org Message-Id: <20090406124547.318EC156ABED@newdev.eecs.harvard.edu> Date: Mon, 6 Apr 2009 08:45:47 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: [PCN] WGLC on draft-ietf-pcn-marking-behaviour-02 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 12:44:43 -0000 this starts a WGLC on draft-ietf-pcn-marking-behaviour-02 - comments to the list by April 20th please Scott From sob@harvard.edu Mon Apr 6 06:18:07 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 867663A6782 for ; Mon, 6 Apr 2009 06:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.58 X-Spam-Level: X-Spam-Status: No, score=-1.58 tagged_above=-999 required=5 tests=[AWL=-0.840, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwBVvImELpd1 for ; Mon, 6 Apr 2009 06:18:02 -0700 (PDT) Received: from newdev.eecs.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by core3.amsl.com (Postfix) with ESMTP id 0192528C18B for ; Mon, 6 Apr 2009 06:16:15 -0700 (PDT) Received: by newdev.eecs.harvard.edu (Postfix, from userid 501) id 0BAE7156ADC1; Mon, 6 Apr 2009 09:17:20 -0400 (EDT) To: pcn@ietf.org Message-Id: <20090406131720.0BAE7156ADC1@newdev.eecs.harvard.edu> Date: Mon, 6 Apr 2009 09:17:20 -0400 (EDT) From: sob@harvard.edu (Scott O. Bradner) Subject: [PCN] draft meeting minutes for pcn X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 13:18:07 -0000 comments to list asap thanks Scott ----- PCN Meeting Notes Friday morning Mar 27/09 Scott Bradner chairing minutes by Tom Taylor and Kwok Ho Chan Architecture Status -- Phillip Eardley ============================== draft-ietf-pcn-architecture Phillip Eardley: He is currently clearing IESG DISCUSS comments -- primarily editorial, clarifications Lars Eggart (as AD): three new ADs have to state their opinions. Outgoing AD comments no longer count -- incoming ADs will review and decide whether they hold that position. Because the changes have been substantial, new ADs will be encouraged to review from the start. Suggests Phillip talk to broadest commenter. Tom Taylor: pcn should have a common "elevator pitch" for PCN at the start of every WG draft (Abstract and Introduction). Kwok Ho Chan noted that there is material in the Problem Statement draft that was used to start the WG can that be reused for this purpose. Tom has action to draft. Marking Behaviour -- Phillip Eardley ============================ draft-ietf-pcn-marking-behaviour Phillip Eardley: Would like to go to WGLC. SATOH Daisuke has called for delay. SATOH Daisuke: Without a third code point, termination and admission are inaccurate. He said that he had ideas for improving accuracy, but needs more time (measured in weeks) to simulate them. Phillip Eardley: have to make a decision at some point. We already cut off another proposal that had asked for more time and had not come through within the period given. Lars Eggart: does Daisuke believe current approaches don't work at all or work less accurately than can be achieved? SATOH Daisuke: Only have Single Marking according to the intended standard. Phillip Eardley: operator has deployment choices. Daisuke is concentrating on a single case. Bob Briscoe: Daisuke's proposed marking behaviour would preclude migration to three-code-point marking. Giorgios Karagiannis: as target of last year's closure, he accepts that it is time to put something on the ground and experiment with improvements after we have experience. Lars Eggart: we don't intend to have multiple marking behaviours. Chair: reasonable to go to WGLC. This discussion can be part of the WGLC discussion. Baseline Encoding -- Phillip Eardley ============================ draft-ietf-pcn-baseline-encoding Tom Taylor: he put some of the encoding discussion into the behavior draft Phillip Eardley: Talking about "What's Next" slide. Code point transitions are specified in each encoding document. Tom noted that also summarized in the edge behaviour "core assumptions" sections. Re ECN tunneling draft: thoroughly rewritten -- more report later. Last call discussion: Gorry Fairhurst noted that lots of editorial nits, but OK technically. Chair: will take to WGLC after nits addressed. Edge behaviour drafts -- Tom Taylor (for Anna) ============================ Tom Taylor: Will be submitted as WG documents after next revision (in line with discussion results). Bob Briscoe: these drafts are informational drafts and they are informational on some experimental ideas Ken Carlberg: he have a draft on Emergency and that scares people, hence Ken's draft will pull out the notion of "Emergency". Tom Taylor: the decision point should be in the loop for flow terminations Tom has action to write up draft on "How to write an edge behaviour draft", incorporating by reference "Per domain behaviour" draft (reference to be obtained). CL and SM drafts should be updated to include per domain behaviour. Bob Briscoe: template draft should reference Kathie Nichols's PHB template RFC 3086 Three state encoding -- Phillip Eardley =============================== Phillip Eardley: Time to look at experimental extensions. Toby Moncaster: "Basic 3 state" and "Extended 3 state" encodings from the baseline draft presentation. "Extended" is used to carry ECN marking across the PCN domain. Bob Briscoe: "3 in 1" based on premise that tunnel behaviour is suitable. No tunnels, or tunnels end in your network or at its edge. PSDM has dual mode. Overwrites ECN. Proposal is that all three become WG documents. Giorgios Karagiannis: supports. Wants to work on HOSE model after basic set done, hence would need the "Affected Marking" codepoint. But this would be after the initial set done. Gorry: are the two DSCPs related or just arbitrary? Giorgios -- should be related, same PHB. Kwok Ho suggests AF. Lars Eggart: logically related obviously. But (general agreement) no need for a numerical relationship. Second DSCP would have to be reallocated, but evidence of successful experiment would be strong argument in favor. Bob Briscoe: are we aiming to have a few experimental proposals and then narrow down to one result, or just leave it to local use? Lars Eggart: if we go to multi-domain, experimental is going to be interesting because of potential clashes with other experiments. support in room that PSDM, Moncaster 3-state, and 3 in 1 become WG drafts, aiming at Experimental. Jabber comment (Steven Blake): Wiki available for public notification of PCN experiments. Further comment on use of Pool 1 vs. Pool 2, which will not be allocated until Pool 1 is exhausted. [Follow-up note to list] Lars Eggart: PCN should also start a wiki page on IETF site indicating which DSCPs are used for PCN experiments. Tunneling of ECN -- Bob Briscoe =============================== draft-ietf-tsvwg-ecn-tunnel-02.txt Bob Briscoe: Layered encapsulation. Intended to be Standards Track. Summary on charts. Proposal: At ingress, bring ECN tunneling in line with IPSec. At egress: use two wasted combinations of inner and outer codepoints. Absolutely no backward compatibility issues. Gorry: OK on merits. But assumes ECT(1) is more severe than ECT(0). Is this the intention? Seems consistent with others' suggestions. Kwok Ho: ECT(1) usage new? Gorry: ECN nonce doesn't have this concept, but original ECN did. Chair: basically this is a TSVWG discussion. Bob Briscoe: Discussion on TSVWG list: don't necessarily need to drop illegal combinations. Gorry: actually now distinguishing (0) and (1). Have to think through the implications. Kwok Ho Chan will review the draft. PCN Encoding Comparison - Kwok Ho Chan ====================================== Kwok Ho Chan: Charter work item. Tracks reasoning leading to current positions Question is whether this draft should be continued or closed? Chair suggestion: output as Informational now, can update later. Make it a Working Group draft. No further points. Finished at 10:45. From root@core3.amsl.com Tue Apr 7 07:45:02 2009 Return-Path: X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 19E713A698D; Tue, 7 Apr 2009 07:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090407144502.19E713A698D@core3.amsl.com> Date: Tue, 7 Apr 2009 07:45:02 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-baseline-encoding-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, 07 Apr 2009 14:45:02 -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 : Baseline Encoding and Transport of Pre-Congestion Information Author(s) : T. Moncaster, et al. Filename : draft-ietf-pcn-baseline-encoding-03.txt Pages : 12 Date : 2009-04-07 The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. The overall rate of the PCN-traffic is metered on every link in the PCN-domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. The level of marking allows the boundary nodes to make decisions about whether t o admit or block a new flow request, and (in abnormal circumstances) whether to terminate some of the existing flows, thereby protecting the QoS of previously admitted flows. This document specifies how such marks are to be encoded into the IP header by re-using the ECN codepoints within this controlled domain. The baseline encoding described here provides for only two PCN encoding states, unmarked and marked. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-baseline-encoding-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-baseline-encoding-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-07074127.I-D@ietf.org> --NextPart-- From toby.moncaster@bt.com Tue Apr 7 07:47:05 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 984AA28C19C for ; Tue, 7 Apr 2009 07:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7LU-aKnJdIi for ; Tue, 7 Apr 2009 07:47:04 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id D09BF28C1E4 for ; Tue, 7 Apr 2009 07:45:42 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Apr 2009 15:46:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Apr 2009 15:43:48 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-pcn-baseline-encoding-03 Thread-Index: Acm3jxulfMqMrmzOTiCng4Th5M7kqgAACcpw References: <20090407144128.033A03A6981@core3.amsl.com> From: To: X-OriginalArrivalTime: 07 Apr 2009 14:46:48.0467 (UTC) FILETIME=[AE06FE30:01C9B78F] Subject: [PCN] FW: New Version Notification for draft-ietf-pcn-baseline-encoding-03 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, 07 Apr 2009 14:47:05 -0000 This new draft attempts to address the majority of Gorry Fairhurst's = comments sent after the last meeting. There are a couple of comments = that I have either disagreed with or failed to understand which I will = adrress in a separate email later in the week. =20 I assume from the minutes of the meeting that this will now trigger the = charirs to start a WGLC for this document? =20 Toby Moncaster ________________________________ From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Tue 4/7/2009 15:41 To: Moncaster,T,Toby,CXR9 R Cc: Briscoe,RJ,Bob,CXR9 R; menth@informatik.uni-wuerzburg.de Subject: New Version Notification for = draft-ietf-pcn-baseline-encoding-03=20 A new version of I-D, draft-ietf-pcn-baseline-encoding-03.txt has been = successfuly submitted by T Moncaster and posted to the IETF repository. Filename: draft-ietf-pcn-baseline-encoding Revision: 03 Title: Baseline Encoding and Transport of Pre-Congestion = Information Creation_date: 2009-04-07 WG ID: pcn Number_of_pages: 12 Abstract: The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. The overall rate of the PCN-traffic is metered on every link in the PCN-domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. The level of marking allows the boundary nodes to make decisions about whether t o admit or block a new flow request, and (in abnormal circumstances) whether to terminate some of the existing flows, thereby protecting the QoS of previously admitted flows. This document specifies how such marks are to be encoded into the IP header by re-using the ECN codepoints within this controlled domain. The baseline encoding described here provides for only two PCN encoding states, unmarked and marked. = =20 The IETF Secretariat. From root@core3.amsl.com Tue Apr 7 09:30:01 2009 Return-Path: X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E678C3A688D; Tue, 7 Apr 2009 09:30: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: <20090407163001.E678C3A688D@core3.amsl.com> Date: Tue, 7 Apr 2009 09:30:01 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-architecture-11.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, 07 Apr 2009 16:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF. Title : Pre-Congestion Notification (PCN) Architecture Author(s) : P. Eardley Filename : draft-ietf-pcn-architecture-11.txt Pages : 61 Date : 2009-04-07 This document describes a general architecture for flow admission and termination based on pre-congestion information in order to protect the quality of service of established inelastic flows within a single Diffserv domain. Status A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcn-architecture-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-07092925.I-D@ietf.org> --NextPart-- From philip.eardley@bt.com Wed Apr 8 00:54:25 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C35C3A67E6 for ; Wed, 8 Apr 2009 00:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.151 X-Spam-Level: X-Spam-Status: No, score=-3.151 tagged_above=-999 required=5 tests=[AWL=0.448, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsKttliLXeWz for ; Wed, 8 Apr 2009 00:54:24 -0700 (PDT) Received: from smtp1.smtp.bt.com (smtp1.smtp.bt.com [217.32.164.137]) by core3.amsl.com (Postfix) with ESMTP id 8AB3A3A6D25 for ; Wed, 8 Apr 2009 00:54:24 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp1.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Apr 2009 08:55:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9B81F.67B9600E" Date: Wed, 8 Apr 2009 08:55:38 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD7AF3@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [PCN] I-D Action:draft-ietf-pcn-architecture-11.txt Thread-Index: Acm3nlCnA1EjCzViSm+aPBH6agIPxwAf9raA From: To: X-OriginalArrivalTime: 08 Apr 2009 07:55:30.0459 (UTC) FILETIME=[63338EB0:01C9B81F] Subject: [PCN] FW: I-D Action:draft-ietf-pcn-architecture-11.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, 08 Apr 2009 07:54:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9B81F.67B9600E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Another version, Changes to deal with IESG comments from routing area review: o Small clarifications to Introduction o the term "marking" now only used to refer only to setting the codepoint (not as a shorthand for 'metering and setting the codepoint') o Added Figure 4 (Schematic of PCN-interior-node functionality) (from [PCN08-2] o Appendix A brought back into the main body. o Other minor clarifications the second of these led to a few changes throughout the doc (in terminology, not content).=20 Reason: people with a Diffserv background use "marking" only to refer to 'setting a codepoint'; the use to mean both 'metering and setting the codepoint' was found confusing.=20 Best wishes phil -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org Sent: 07 April 2009 17:30 To: i-d-announce@ietf.org Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-architecture-11.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Congestion and Pre-Congestion Notification Working Group of the IETF. Title : Pre-Congestion Notification (PCN) Architecture Author(s) : P. Eardley Filename : draft-ietf-pcn-architecture-11.txt Pages : 61 Date : 2009-04-07 This document describes a general architecture for flow admission and termination based on pre-congestion information in order to protect the quality of service of established inelastic flows within a single Diffserv domain. Status A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-11.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_001_01C9B81F.67B9600E Content-Type: application/octet-stream; name="draft-ietf-pcn-architecture-11.URL" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-pcn-architecture-11.URL Content-Disposition: attachment; filename="draft-ietf-pcn-architecture-11.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLXBjbi1hcmNoaXRlY3R1cmUtMTEudHh0DQo= ------_=_NextPart_001_01C9B81F.67B9600E-- From philip.eardley@bt.com Wed Apr 8 01:34:48 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39A993A6B0D for ; Wed, 8 Apr 2009 01:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.86 X-Spam-Level: X-Spam-Status: No, score=-2.86 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQ2o43-126NJ for ; Wed, 8 Apr 2009 01:34:47 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 93AC73A6B06 for ; Wed, 8 Apr 2009 01:34:45 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Apr 2009 09:35:51 +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: Wed, 8 Apr 2009 09:35:59 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD7AF4@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <200903232352.n2NNqdSN022778@bagheera.jungle.bt.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-02.txt Thread-Index: AcmsEnTSZRSXuPGPTDmFv/CV0o24EAMEbOwQ From: To: X-OriginalArrivalTime: 08 Apr 2009 08:35:51.0430 (UTC) FILETIME=[06366A60:01C9B825] Cc: pcn@ietf.org Subject: Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-02.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, 08 Apr 2009 08:34:48 -0000 Thanks bob, agree with nearly all of them - a few follow-ups below phil { -----Original Message----- { From: Briscoe,RJ,Bob,XVR9 BRISCORJ R { Sent: 23 March 2009 23:53 { To: Eardley,PL,Philip,CXR9 R { Cc: pcn@ietf.org { Subject: Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-02.txt {=20 { Phil, {=20 { Review comments below. Nothing substantive, just editorial mostly. {=20 { Abstract: { s/standardises/specifies/ [I think the IESG objects to RFCs using the { 'standard' word] {=20 { 1. Intro { s/Other documents/Other documents introduced below/ {=20 { 1.1 Terminology { s/Competing-non-PCN-packet: a non PCN-packet that shares a link with/ { /Competing-non-PCN-packet: a non PCN-packet that shares a queue with/ {=20 { " [I-D.ietf-pcn-baseline-encoding] defines only two PCN { encoding states available (PCN-marked and not-marked); the { deployment MUST choose whether PCN-marked is interpreted as { excess-traffic-marked or threshold-marked; a consistent choice { MUST be made throughout a PCN-domain. { "This sentence is too detailed and normative for the terminology { section and would be better merged in with the other text about the { same subject in S.2.5. With the following additional changes: { s/the deployment MUST choose/in this case the deployment MUST choose/ [phil] agree this is too detailed for terminology & will delete. In addition, I think this part of S2.5 would be better in Appendix than main body (will follow-up about that shortly) {=20 { 2. Specified PCN-marking behaviour {=20 { s/This section specifies the PCN-marking behaviour. { /This section specifies the PCN-marking behaviours./ {=20 { 2.4. Excess traffic meter function {=20 { Move this para to the start of the section: { " A PCN-node MUST implement an Excess traffic Meter that has behaviour { functionally equivalent to the following. { " [phil] disagree with moving this to start of section. The section starts "A PCN-packet SHOULD NOT be metered (by this excess traffic meter function) in the following two cases: ...". I think it's better to keep the SHOULD NOT outside the MUST!=20 {=20 { References. {=20 { Suggest one or two references to original research on virtual queues, { to provide some legitimacy, rather than implying this is all just { invented out of thin air with no theoretical backing. E.g. the { original Courcoubetis paper in the context of ATM. {=20 {=20 { B.1. Competing-non-PCN-traffic {=20 { s/and there is voice-admit traffic in the PCN-domain./ { /and there is non-PCN voice-admit traffic in the PCN-domain./ {=20 { Somewhere, we need to explain that PCN & non-PCN voice-admit traffic { probably differ only in the ECN field, not the DSCP. Some networks { might schedule them in separate queues distinguished only by ECN { field, while others might schedule them together. [phil] this is basically already discussed in B.4. I'll add a refernce fwd.=20 {=20 { B.2 Scope {=20 { s/such considerations are out of scope of PCN./ { /such considerations are out of scope of this document./ {=20 { An RFC exists beyond the lifetime of a w-g, so the current scope of { the w-g is irrelevant in an RFC. {=20 { B.4 Traffic conditioning {=20 { s/wold/would/ {=20 { s/In brief, the reason is that this avoids over-termination, with the { CL/SM edge behaviour, in the event of/ { /In brief, the reason is that with the CL/SM edge behaviour this { avoids over-terminationin in the event of/ {=20 { B.5. Threshold metering {=20 { s/However the implementation is not standardised./ { /However the description is not intended to standardise implementation./ {=20 { " * leave TBthreshold.fill unaltered and indicate threshold-mark to { the Marking function. { " { [By you definition of functionally equivalent, this isn't. But I { think you need to relax the definition, rather than preclude this { implementation.] [phil] suggestion how to relax it? {=20 { B.6. Excess traffic metering { s/However the implementation is not standardised./ { /However the description is not intended to standardise implementation./ {=20 { s/substantially pre-congested and hence PCN-marking all packets.)/ { /substantially pre-congested and hence excess-rate-marking all { packets.)/ [phil] you mean threshold-marking {=20 { s/and the impact of not doing it is moderate/ { /and the impact of not doing it is undesirable but moderate/ {=20 { Bob {=20 { At 16:47 05/03/2009, philip.eardley@bt.com wrote: { >I updated the draft. { >http://www.ietf.org/internet-drafts/draft-ietf-pcn-marking-behaviour-02 . { >txt { > { >6.1. Changes to -02 from -01 { > { > Updates as follows: { > { > o added notes (end of S1.1 & 2.5) to clarify what "excess-traffic- { > marked" means when there is only one encoding for PCN-marking { > { > o added explanations for in Section B.4 and B.6 about why various { > things are SHOULD or SHOULD NOT rather than MUST or MUST NOT. { > { > o Deleted a couple of paragraphs about encoding states, as they are { > relevant to encoding documents rather than this document. { > { >I also corrected the editorial nits the Ruediger pointed out. { > { >There is the on-going suggestion from Daisuke (currently writing an { >email) - but apart from this issue I think that the document is done { >(there have been no changes to normative text since the -00 version of { >2nd Oct 2008). { > { >Thanks { >phil { > { >{ -----Original Message----- { >{ From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { >{ Internet-Drafts@ietf.org { >{ Sent: 05 March 2009 16:15 { >{ To: i-d-announce@ietf.org { >{ Cc: pcn@ietf.org { >{ Subject: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-02.txt { >{ { >{ A New Internet-Draft is available from the on-line Internet-Drafts { >{ directories. { >{ This draft is a work item of the Congestion and Pre-Congestion { >{ Notification Working Group of the IETF. { >{ { >{ { >{ Title : Marking behaviour of PCN-nodes { >{ Author(s) : P. Eardley { >{ Filename : draft-ietf-pcn-marking-behaviour-02.txt { >{ Pages : 20 { >{ Date : 2009-03-05 { >{ { >{ This document standardises the two marking behaviours of PCN-nodes: { >{ threshold marking and excess traffic marking. Threshold marking { >{ marks all PCN-packets if the PCN traffic rate is greater than a { >{ configured rate ("PCN-threshold-rate"). Excess traffic marking marks { >{ a proportion of PCN-packets, such that the amount marked equals the { >{ traffic rate in excess of a configured rate ("PCN-excess-rate"). { >{ Setting the configured rates below the physical link rates enables { >{ PCN-nodes to provide information to support admission control and { >{ flow termination in order to protect the quality of service of { >{ established inelastic flows. { >{ { >{ A URL for this Internet-Draft is: { >{ http://www.ietf.org/internet-drafts/draft-ietf-pcn-marking-behaviour- { >{ 02.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 {=20 { ________________________________________________________________ { Bob Briscoe, Networks Research Centre, BT Research From philip.eardley@bt.com Wed Apr 8 02:37:24 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECA463A6E53 for ; Wed, 8 Apr 2009 02:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.163 X-Spam-Level: X-Spam-Status: No, score=-3.163 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGr3DNMOEpWa for ; Wed, 8 Apr 2009 02:37:24 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 07FAA3A6E49 for ; Wed, 8 Apr 2009 02:37:23 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Apr 2009 10:38:29 +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: Wed, 8 Apr 2009 10:38:37 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD7AF6@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC04AD7AF4@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-02.txt Thread-Index: AcmsEnTSZRSXuPGPTDmFv/CV0o24EAMEbOwQAAJNnhA= From: To: , X-OriginalArrivalTime: 08 Apr 2009 09:38:30.0067 (UTC) FILETIME=[C688E830:01C9B82D] Cc: pcn@ietf.org Subject: Re: [PCN] I-D Action:draft-ietf-pcn-marking-behaviour-02.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, 08 Apr 2009 09:37:25 -0000 I realise I disagree with this one: { { 1.1 Terminology { { s/Competing-non-PCN-packet: a non PCN-packet that shares a link with/ { { /Competing-non-PCN-packet: a non PCN-packet that shares a queue { with/ suppose the PCN-pkts & competing-non-pcn-pkts used separate queues, but the same link [an alternative implementation to common queue - B.4 & as you mentioned later in your mail] so I think "link" is correct.=20 From philip.eardley@bt.com Wed Apr 8 03:10:15 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DE5A3A6E51 for ; Wed, 8 Apr 2009 03:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.171 X-Spam-Level: X-Spam-Status: No, score=-3.171 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id il3zsZ6OkVCh for ; Wed, 8 Apr 2009 03:10:14 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 16C843A6DE6 for ; Wed, 8 Apr 2009 03:10:13 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Apr 2009 11:11:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Apr 2009 11:11:27 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD7AF7@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <20090406124547.318EC156ABED@newdev.eecs.harvard.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] WGLC on draft-ietf-pcn-marking-behaviour-02 Thread-Index: Acm2taDGSirIewC0TEa7zAM6XjZ6dgBdRqEg From: To: , X-OriginalArrivalTime: 08 Apr 2009 10:11:20.0084 (UTC) FILETIME=[5CC1A540:01C9B832] Subject: Re: [PCN] WGLC on draft-ietf-pcn-marking-behaviour-02 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 10:10:15 -0000 Some LC comments. They're all clarifications, consistency etc Thanks phil Title: Change to "Metering and marking behaviour of PCN-nodes" Reason: architecture i-d uses "marking" to refer only to "setting the codepoint" (& not as shorthand for "metering & setting the codepoint") Abstract: Some tweaking needed for above point. Intro: Some tweaking needed for above point. (after the first half a page, the doc mostly is already ok in the way it uses the term "marking") Introduce the "common capsule" about PCN (first para of the architecture doc) Is the para about other PCN docs needed? "traffic condition" [made this comment already on ML] Instead of "traffic conditioning" a better term to use would be "dropping". Because in the diffserv docs, 'conditioning' is used to refer collectively to metering /marking /shaping /dropping. "meter operates on the aggregate of all PCN-pkts" - or: "operates on all" S2.2 traffic conditioning -> dropping S2.3 & 2.4 [Michael suggested this off list] the terminology "TBthreshold.fill" etc is quite cumbersome. I think I'll re-phrase to follow what eg RFC2211 does: T & E for the two token buckets [threshold & excess] Tr, Tb, Tt [& explain what these are] [rate, bucket depth, threshold level] Er, Eb S2.4: Delete " The PCN-excess-rate is greater than (or equal to) the PCN-threshold-rate." Doesn't seem appropriate to have this as a MUST. It's already mentioned in the informative appendix. 2.5 the last para ("Note:...") seems appropriate for the informative. appendix rather than the normative main sections. The very last sentence is however normative. Result: S2.5 has this para: A PCN-packet MUST be marked to reflect the metering results by setting its encoding state appropriately, as specified by the specific encoding scheme that applies in the PCN-domain. A consistent choice MUST be made throughout a PCN-domain. The appendix gains this para: In some deployment scenarios there may be only two PCN encoding states available (PCN-marked and not-marked). In such scenarios, the deployment chooses whether the Threshold meter function or the Excess traffic meter function triggers a packet to be PCN-marked; a consistent choice needs to be made throughout a PCN-domain. S7 Authors, Acks: Could be improved? Refs: The i-d "draft-ietf-pcn-blah" could be hidden in text [kept in xml] B.4 "CL/SM edge behaviour" - guess these needs a little explanation /ref of what CL & SM are? { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of { Scott O. Bradner { Sent: 06 April 2009 13:46 { To: pcn@ietf.org { Subject: [PCN] WGLC on draft-ietf-pcn-marking-behaviour-02 {=20 {=20 { this starts a WGLC on draft-ietf-pcn-marking-behaviour-02 - comments to { the list by April 20th please {=20 { Scott { _______________________________________________ { PCN mailing list { PCN@ietf.org { https://www.ietf.org/mailman/listinfo/pcn From root@core3.amsl.com Wed Apr 8 09:15:01 2009 Return-Path: X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6385628C0E5; Wed, 8 Apr 2009 09:15: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: <20090408161501.6385628C0E5@core3.amsl.com> Date: Wed, 8 Apr 2009 09:15:01 -0700 (PDT) Cc: pcn@ietf.org Subject: [PCN] I-D Action:draft-ietf-pcn-3-state-encoding-00.txt X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2009 16:15: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 : A PCN encoding using 2 DSCPs to provide 3 or more states Author(s) : T. Moncaster, et al. Filename : draft-ietf-pcn-3-state-encoding-00.txt Pages : 14 Date : 2009-04-08 Pre-congestion notification (PCN) is a mechanism designed to protect the Quality of Service of inelastic flows within a controlled domain. It does this by marking packets when traffic load on a link is approaching or has exceeded a threshold below the physical link rate. This experimental encoding scheme specifies how three encoding states can be carried in the IP header using a combination of two DSCPs and the ECN bits. The Basic scheme only allows for three encoding states. The Full scheme additionally provides limited end-to-end support for ECN. Status (to be removed by RFC Editor) This memo is posted as an Internet-Draft with an intent to eventually be published as an experimental RFC. The PCN Working Group will be asked to adopt this memo as a Working Group document describing one of several possible experimental PCN encoding schemes. The intention is that the title of this document will change to avoid confusion with the three state marking scheme. Changes from previous drafts >From draft-moncaster-pcn-3-state-encoding-01: o Changed to WG draft. Title changed from "A three state extended PCN encoding scheme" o Imposed new structure on document. This structure is intended to be followed by all extensions to the baseline PCN encoding scheme. o Extensive changes throughout to ensure consistency with the baseline PCN encoding scheme. >From 00 to 01: o Checked terminology for consistency with [I-D.ietf-pcn-baseline-encoding] o Minor editorial changes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-3-state-encoding-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-pcn-3-state-encoding-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-08091237.I-D@ietf.org> --NextPart-- From fausto.vieira@fe.up.pt Tue Apr 14 08:44:07 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 878783A6E12 for ; Tue, 14 Apr 2009 08:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.111 X-Spam-Level: * X-Spam-Status: No, score=1.111 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkdrJBYq8FSW for ; Tue, 14 Apr 2009 08:44:06 -0700 (PDT) Received: from smtp.fe.up.pt (smtp.fe.up.pt [193.136.28.30]) by core3.amsl.com (Postfix) with ESMTP id A61753A6936 for ; Tue, 14 Apr 2009 08:44:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by smtp.fe.up.pt (Postfix) with ESMTP id D5135EFACC for ; Tue, 14 Apr 2009 16:44:21 +0100 (WEST) Received: from smtp.fe.up.pt ([127.0.0.1]) by localhost (smtp1.fe.up.pt [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLTmpY9JoRgb for ; Tue, 14 Apr 2009 16:44:21 +0100 (WEST) Received: from [192.168.103.185] (unknown [192.168.56.20]) by smtp.fe.up.pt (Postfix) with ESMTP id BEC65EFABD for ; Tue, 14 Apr 2009 16:44:21 +0100 (WEST) Message-ID: <49E4AF9B.1090901@fe.up.pt> Date: Tue, 14 Apr 2009 16:45:31 +0100 From: Fausto Vieira User-Agent: Thunderbird 2.0.0.19 (X11/20081227) MIME-Version: 1.0 To: pcn@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: [PCN] Adaptive capacity systems X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 17:59:38 -0000 Dear PCN group, I recently became aware of this WG and I found it very interesting since I was previously working in similar topics. I was trying to check if PCN covered adaptive capacity systems and was unable to find such reference. If you search for a paper I wrote named "Adaptive RED for Cross-layer DVB-S2 systems", you see that I address the problem of adaptive capacity systems that apply Adaptive Coding and Modulation (ACM) and/or Power Control to vary the capacity according to the channel conditions. Basically all advanced wireless systems employ such techniques, in order to maximize bandwidth and/or limit Packet Error Rate (PER). I believe that PCN would be a perfect tool for standardizing a solution for inelastic flows for adaptive capacity systems that have slow bandwidth variations (slow fading channel impairments). However, from what I could find out, this is not foreseen and only catastrophic bandwidth redutions are foreseen. Looking forward for your comments, Fausto -- Fausto Vieira, PhD Instituto de Telecomunicações Faculdade de Engenharia da Universidade do Porto Rua Dr. Roberto Frias, s/n 4200-465 Porto PORTUGAL From Ruediger.Geib@telekom.de Tue Apr 14 23:51:06 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1244D3A6848 for ; Tue, 14 Apr 2009 23:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.857, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XsLi3oIh9L4 for ; Tue, 14 Apr 2009 23:51:05 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id F26453A6A32 for ; Tue, 14 Apr 2009 23:50:44 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 15 Apr 2009 08:51:45 +0200 Received: from S4DE8PSAAQA.mitte.t-com.de ([10.151.229.12]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Apr 2009 08:51:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Apr 2009 08:51:43 +0200 Message-ID: <151C164FE2E066418D8D44D0801543A5FA0123@S4DE8PSAAQA.mitte.t-com.de> In-Reply-To: <49E4AF9B.1090901@fe.up.pt> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Adaptive capacity systems Thread-Index: Acm9KvN+n2m3/xZrQNCfdF9ad1XMIAAaIE0Q References: <49E4AF9B.1090901@fe.up.pt> From: To: X-OriginalArrivalTime: 15 Apr 2009 06:51:44.0987 (UTC) FILETIME=[A3EF1AB0:01C9BD96] Cc: pcn@ietf.org Subject: Re: [PCN] Adaptive capacity systems 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, 15 Apr 2009 06:51:06 -0000 Hello Fausto, it is true, the main focus of the PCN WG up to now seems to be = expressing=20 a wish for PCN bandwidth reduction by "termination". If you read the = drafts,=20 you'll find however that what PCN delivers is an indication of a network = condition (admit, admission stop and termination). At least = theoretically,=20 PCN does not determine how to reduce bandwidth once "termination" is=20 indicated. I personally dislike the idea of terminating application sessions to = reduce=20 PCN bandwidth consumption. Negotiating different codecs or changing = bandwith=20 of an adaptive codec seems a better choice - for personal communication=20 services. I however couldn't figure out yet, how to deal with unicast=20 streaming, if my wish is to reduce PCN bandwidth consumption by = indicating=20 this network condition to the application layer. I do not regard load conditions resulting in "termination" as standard=20 operational conditions, these must be an exception no matter how the=20 bandwidth consumption is reduced. Regards, Rudiger Deutsche Telekom Netzproduktion GmbH=20 Zentrum Technik Einf=FChrung=20 Technik Internet Backbone, TE142-19 R=FCdiger Geib Heinrich Hertz Str. 3-7 64297 Darmstadt Tel.: 06151/6282747 Fax: 0251/7985109 Deutsche Telekom Netzproduktion GmbH=20 Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender)=20 Gesch=E4ftsf=FChrung: Friedrich Fu=DF (Vorsitzender), Albert Matheis, = Klaus Peren=20 Handelsregister: Amtsgericht Bonn HRB 14190=20 Sitz der Gesellschaft: Bonn=20 USt-IdNr.: DE 814645262 -----Original Message----- From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of = Fausto Vieira Sent: Tuesday, April 14, 2009 5:46 PM To: pcn@ietf.org Subject: [PCN] Adaptive capacity systems Dear PCN group, I recently became aware of this WG and I found it very interesting since I was previously working in similar topics. I was trying to check if PCN covered adaptive capacity systems and was unable to find such reference. If you search for a paper I wrote named "Adaptive RED for Cross-layer DVB-S2 systems", you see that I address the problem of adaptive capacity systems that apply Adaptive Coding and Modulation (ACM) and/or Power Control to vary the capacity according to the channel conditions. Basically all advanced wireless systems employ such techniques, in order to maximize bandwidth and/or limit Packet Error Rate (PER). I believe that PCN would be a perfect tool for standardizing a solution for inelastic flows for adaptive capacity systems that have slow bandwidth variations (slow fading channel impairments). However, from what I could find out, this is not foreseen and only catastrophic bandwidth redutions are foreseen. Looking forward for your comments, Fausto --=20 Fausto Vieira, PhD Instituto de Telecomunica=E7=F5es Faculdade de Engenharia da Universidade do Porto Rua Dr. Roberto Frias, s/n 4200-465 Porto PORTUGAL _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From philip.eardley@bt.com Thu Apr 16 04:48:07 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D6C43A6970 for ; Thu, 16 Apr 2009 04:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.852 X-Spam-Level: X-Spam-Status: No, score=-2.852 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5w51vZ-zfLqF for ; Thu, 16 Apr 2009 04:48:06 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 3E5B23A6940 for ; Thu, 16 Apr 2009 04:48:06 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.108]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 12:49:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Apr 2009 12:49:17 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD7B32@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC04AD7B27@E03MVB1-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] Adaptive capacity systems Thread-Index: Acm9KvPhNEQRiFaXQBWrLQKlU8wtoAAgHqNQADc0FbA= From: To: , X-OriginalArrivalTime: 16 Apr 2009 11:49:18.0554 (UTC) FILETIME=[5FE6FBA0:01C9BE89] Subject: Re: [PCN] Adaptive capacity systems X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 11:48:07 -0000 I read your paper. Your idea is interesting.=20 I think it would work in a PCN context - it would mean that PCN's = "configured rates" (threshold-rate & excess-traffic-rate) would be = adjusted according to the current radio conditions. Note that PCN's = virtual queue means that the real queue should suffer very low delay. On = reflection, I'm not sure whether the edge behaviours would need to be = changed (your paper is about RED adapting - wasn't sure if the = application also adapted, I think not?).=20 Best wishes phil { -----Original Message----- { From: Eardley,PL,Philip,CXR9 R { Sent: 15 April 2009 10:26 { To: 'Fausto Vieira' { Subject: RE: [PCN] Adaptive capacity systems {=20 { Hi fausto {=20 { The current charter of the WG is about standardising the = metering/marking { behaviour on the interior nodes = [http://tools.ietf.org/html/draft-ietf- { pcn-marking-behaviour - comments appreciated as it's in WGLC] { & standardising baseline encoding + experimental encoding extensions { & examples of using this for admission control & flow termination. {=20 { Beyond that, after re-chartering, it would certainly be interesting to = see { how to re-apply these functions for other uses (edge behaviours) {=20 { Best wishes { phil {=20 { { -----Original Message----- { { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf = Of { { Fausto Vieira { { Sent: 14 April 2009 16:46 { { To: pcn@ietf.org { { Subject: [PCN] Adaptive capacity systems { { { { Dear PCN group, { { { { I recently became aware of this WG and I found it very interesting = since { { I was previously working in similar topics. { { I was trying to check if PCN covered adaptive capacity systems and = was { { unable to find such reference. { { If you search for a paper I wrote named "Adaptive RED for = Cross-layer { { DVB-S2 systems", you see that I address the problem of adaptive = capacity { { systems that apply Adaptive Coding and Modulation (ACM) and/or Power { { Control to vary the capacity according to the channel conditions. { { Basically all advanced wireless systems employ such techniques, in = order { { to maximize bandwidth and/or limit Packet Error Rate (PER). { { I believe that PCN would be a perfect tool for standardizing a = solution { { for inelastic flows for adaptive capacity systems that have slow { { bandwidth variations (slow fading channel impairments). However, = from { { what I could find out, this is not foreseen and only catastrophic { { bandwidth redutions are foreseen. { { { { Looking forward for your comments, { { { { Fausto { { { { -- { { Fausto Vieira, PhD { { Instituto de Telecomunica=E7=F5es { { Faculdade de Engenharia da Universidade do Porto { { Rua Dr. Roberto Frias, s/n 4200-465 Porto PORTUGAL { { { { _______________________________________________ { { PCN mailing list { { PCN@ietf.org { { https://www.ietf.org/mailman/listinfo/pcn From wwwrun@core3.amsl.com Thu Apr 16 13:27:48 2009 Return-Path: X-Original-To: pcn@ietf.org Delivered-To: pcn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id B3C9D3A6978; Thu, 16 Apr 2009 13:27:48 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090416202748.B3C9D3A6978@core3.amsl.com> Date: Thu, 16 Apr 2009 13:27:48 -0700 (PDT) Cc: pcn mailing list , pcn chair , Internet Architecture Board , RFC Editor Subject: [PCN] Document Action: 'Pre-Congestion Notification (PCN) Architecture' to Informational RFC X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 20:27:48 -0000 The IESG has approved the following document: - 'Pre-Congestion Notification (PCN) Architecture ' as an Informational RFC This document is the product of the Congestion and Pre-Congestion Notification Working Group. The IESG contact persons are Lars Eggert and Magnus Westerlund. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-11.txt Technical Summary This document describes a general architecture for flow admission and Termination based on pre-congestion information in order to protect the quality of service of established inelastic flows within a single DiffServ domain. This document is a product of the PCN working group. Working Group Summary This document was the subject of good discussion in the working group and a good consensus was reached that this document describes the PCN architecture Document Quality This document was reviewed by the PCN working group in multiple meetings and by the Document Shepherd (Scott Bradner). Personnel Scott Bradner (sob@harvard.edu) is the Document Shepherd. Lars Eggert (lars.eggert@nokia.com) reviewed this document for the IESG. From tom.taylor@rogers.com Thu Apr 16 16:02:40 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13C2528C14E for ; Thu, 16 Apr 2009 16:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgomTvQsXWx6 for ; Thu, 16 Apr 2009 16:02:39 -0700 (PDT) Received: from smtp123.rog.mail.re2.yahoo.com (smtp123.rog.mail.re2.yahoo.com [206.190.53.28]) by core3.amsl.com (Postfix) with SMTP id 1D3C428C0EB for ; Thu, 16 Apr 2009 16:02:39 -0700 (PDT) Received: (qmail 81620 invoked from network); 16 Apr 2009 23:03:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=zgE2NtZ/5r35h57fnK9V/vxG8wqclVTbn2ufasx8cdI1O15cMIYUXSEtMXLpSoQkKcqWl/rFIHSiGlc20qaDxVo8Je5O+fEcgXJisJsTx1Vcs6Meu4PivK0R9WYP9KrUeF4BI+cLREdaoe2ud7paMASszZ8C/yNRZBgTsdzgPRc= ; Received: from unknown (HELO ?192.168.0.100?) (tom.taylor@72.140.46.24 with plain) by smtp123.rog.mail.re2.yahoo.com with SMTP; 16 Apr 2009 23:03:51 -0000 X-YMail-OSG: US3bI30VM1m6wnVva9MWh_QshAOJJsqS28vIQRILmVi2t3SVeucNkvyA1hvjHBo.Vg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49E7B958.8000800@rogers.com> Date: Thu, 16 Apr 2009 19:03:52 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: pcn References: <20090416202748.B3C9D3A6978@core3.amsl.com> In-Reply-To: <20090416202748.B3C9D3A6978@core3.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PCN] Document Action: 'Pre-Congestion Notification (PCN) Architecture' to Informational RFC X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 23:02:40 -0000 Congratulations, Phillip. The IESG wrote: > The IESG has approved the following document: > > - 'Pre-Congestion Notification (PCN) Architecture ' > as an Informational RFC > > This document is the product of the Congestion and Pre-Congestion > Notification Working Group. > > The IESG contact persons are Lars Eggert and Magnus Westerlund. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-pcn-architecture-11.txt > > Technical Summary > > This document describes a general architecture for flow admission and > Termination based on pre-congestion information in order to protect the > quality of service of established inelastic flows within a single > DiffServ domain. This document is a product of the PCN working group. > > Working Group Summary > > This document was the subject of good discussion in the working group > and a good consensus was reached that this document describes the PCN > architecture > > Document Quality > > This document was reviewed by the PCN working group in multiple > meetings and by the Document Shepherd (Scott Bradner). > > Personnel > > Scott Bradner (sob@harvard.edu) is the Document Shepherd. Lars Eggert > (lars.eggert@nokia.com) reviewed this document for the IESG. > > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > > From tom.taylor@rogers.com Fri Apr 24 15:38:06 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ED333A6BB9 for ; Fri, 24 Apr 2009 15:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_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 tDhfR5GZaW+r for ; Fri, 24 Apr 2009 15:38:05 -0700 (PDT) Received: from smtp101.rog.mail.re2.yahoo.com (smtp101.rog.mail.re2.yahoo.com [206.190.36.79]) by core3.amsl.com (Postfix) with SMTP id 419353A6B73 for ; Fri, 24 Apr 2009 15:38:05 -0700 (PDT) Received: (qmail 43930 invoked from network); 24 Apr 2009 22:39:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding; b=kwtnHCGgYChJ3Cy7VRvy26/k3FzzLzL3LAzJXdk2ax4j8Ks0cqCM75ebRzIkT7P4NVy2fcF3ph2+kCY7v2UzpY92xo0mXxrfeBiBXTN5iY9ysDP9LCQpeuqzT2508TPR2jSjHV/qjMsm6S9fIykr6wqNrjJo//m3jMqWZDeK/LE= ; Received: from unknown (HELO ?192.192.20.78?) (tom.taylor@123.65.217.65 with plain) by smtp101.rog.mail.re2.yahoo.com with SMTP; 24 Apr 2009 22:39:23 -0000 X-YMail-OSG: KiWTuHAVM1m3YO5nA.Biv6a4F4iI6OoLD5wAu74gezjjMQrS2F7tkTmKElocCyYSXg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49F23F9C.4030801@rogers.com> Date: Fri, 24 Apr 2009 18:39:24 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: pcn Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [PCN] PCN elevator speech X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 22:38:06 -0000 Here is the text that is proposed to begin all PCN-related documents. Phil actually did the work, with input from others. The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain, in a simple, scalable and robust fashion. Two mechanisms are used: admission control, to decide whether to admit or block a new flow request, and (in abnormal circumstances) flow termination to decide whether to terminate some of the existing flows. Together they protect the QoS of previously admitted flows. To achieve this, the overall rate of the PCN-traffic is metered on every link in the PCN-domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. These configured rates are below the rate of the link thus providing notification before any congestion occurs (hence "pre-congestion notification"). The level of marking allows the boundary nodes to make decisions about whether to admit or terminate. For a full description of the PCN architecure see [RFC xxxx (the architecture document)]. From tom.taylor@rogers.com Fri Apr 24 16:05:07 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4559B3A6B3F for ; Fri, 24 Apr 2009 16:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBzC1oV+mW-4 for ; Fri, 24 Apr 2009 16:05:06 -0700 (PDT) Received: from smtp104.rog.mail.re2.yahoo.com (smtp104.rog.mail.re2.yahoo.com [206.190.36.82]) by core3.amsl.com (Postfix) with SMTP id 534A93A6839 for ; Fri, 24 Apr 2009 16:05:06 -0700 (PDT) Received: (qmail 5745 invoked from network); 24 Apr 2009 23:06:24 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=CIM0ErZIgvJuiv21YRfG2+yyWrArcHnYlhKE8XxijGZlIcYs30kwiGH/NCaH4x2xkTdIr9MTUlTHKTw1xHI00sOgieJUet4tauHNKB9d5FvzA/uN67ROHHfJOAlDvTE08JdRc5Im6ibcWyKGJSIvQrFYXLXrzXsIO6mXQIN0iPg= ; Received: from unknown (HELO ?192.192.20.78?) (tom.taylor@123.65.217.65 with plain) by smtp104.rog.mail.re2.yahoo.com with SMTP; 24 Apr 2009 23:06:24 -0000 X-YMail-OSG: R75dpPQVM1lDFDpjvyvYeepjKbxVdNJd57jWyBKGFhCzXDwbf4WCfVilslAasHMwzg-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49F245F1.6080402@rogers.com> Date: Fri, 24 Apr 2009 19:06:25 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: pcn References: <49F23F9C.4030801@rogers.com> In-Reply-To: <49F23F9C.4030801@rogers.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PCN] PCN elevator speech X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 23:05:07 -0000 Having said this, I would beg the indulgence of the group to modify the second-last sentence slightly, so it reads: "The level of marking allows decisions to be made about whether to admit or terminate." Tom Taylor wrote: > Here is the text that is proposed to begin all PCN-related documents. > Phil actually did the work, with input from others. > > The objective of Pre-Congestion Notification (PCN) is to protect the > quality of service (QoS) of inelastic flows within a Diffserv domain, in > a simple, scalable and robust fashion. Two mechanisms are used: > admission control, to decide whether to admit or block a new flow > request, and (in abnormal circumstances) flow termination to decide > whether to terminate some of the existing flows. Together they protect > the QoS of previously admitted flows. To achieve this, the overall rate > of the PCN-traffic is metered on every link in the PCN-domain, and > PCN-packets are appropriately marked when certain configured rates are > exceeded. These configured rates are below the rate of the link thus > providing notification before any congestion occurs (hence > "pre-congestion notification"). The level of marking allows the boundary > nodes to make decisions about whether to admit or terminate. For a full > description of the PCN architecure see [RFC xxxx (the architecture > document)]. > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn > From fred@cisco.com Fri Apr 24 16:52:18 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BC7F3A6B3F for ; Fri, 24 Apr 2009 16:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.474 X-Spam-Level: X-Spam-Status: No, score=-106.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 z3b6u+KDKpaZ for ; Fri, 24 Apr 2009 16:52:17 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0E5983A6AFA for ; Fri, 24 Apr 2009 16:52:17 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,244,1238976000"; d="scan'208";a="176644235" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 24 Apr 2009 23:53:36 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3ONrakD006831; Fri, 24 Apr 2009 16:53:36 -0700 Received: from stealth-10-32-244-219.cisco.com (stealth-10-32-244-219.cisco.com [10.32.244.219]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3ONraD4005569; Fri, 24 Apr 2009 23:53:36 GMT Message-Id: <0AD29BC9-757C-4AEF-9F99-939BEF18A936@cisco.com> From: Fred Baker To: Tom Taylor In-Reply-To: <49F245F1.6080402@rogers.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 24 Apr 2009 16:53:33 -0700 References: <49F23F9C.4030801@rogers.com> <49F245F1.6080402@rogers.com> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3487; t=1240617216; x=1241481216; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[PCN]=20PCN=20elevator=20speech |Sender:=20; bh=CGD0aXI0LlHACRXiWSRskOUht7/8rgarlAmnFbSmwzw=; b=oNLnsvpB3aq4ikTZvHshj9McUh6hx/B1EFFHJzXV4gKjbHLFqNt+bUSN8P ZLOidk56vV9ZjtkSQCY1i4Po9aLLskdhIvO+OZdEktTBrF/VSGOiDcc6Zp+s R75cQBByeG; Authentication-Results: sj-dkim-3; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: pcn Subject: Re: [PCN] PCN elevator speech X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 23:52:18 -0000 I have an additional edit. Generally, one doesn't configure a link to run full-bore and then scale back to deal with the traffic it has. r\Rather, one configures a link to deal effectively with specific application classes. For example, one will generally have a class for real-time traffic or separate classes for voice and video, with a separate class for elastic applications. This results in the real time traffic being handled in a way that serves its needs (it is guaranteed at most a given latency on a link so that e2e delay variation doesn't exceed some threshold), allowing elastic traffic to do the things it is famous for doing without interrupting real-time services. As such, the reference to "the rate of the link" should refer to the "the rate allocated to a traffic class". If the class in fact occupies the whole link, the two statements are equivalent. If that observation gives heartburn, I would suggest "the rate of a traffic class, or where appropriate, a link". It would also be very nice if we could somehow provide an architecture in which we are not using one mechanism differently for two different purposes, but using one mechanism to serve one purpose interpreted differently by different use cases. We are willing to have pre- congestion notification for voice/video/etc, but are willing to build queues for data in some cases, and in other cases have had suggestions that folks could similarly manage RFC 3168-like ECN based on traffic rates in elastic classes. If we are building an architecture for ECN in general of which PCN and RFC 3168 are special cases, then that should be reflected in this proposed text. On Apr 24, 2009, at 4:06 PM, Tom Taylor wrote: > Having said this, I would beg the indulgence of the group to modify > the second-last sentence slightly, so it reads: > > "The level of marking allows decisions to be made about whether to > admit or terminate." > > Tom Taylor wrote: >> Here is the text that is proposed to begin all PCN-related >> documents. Phil actually did the work, with input from others. >> The objective of Pre-Congestion Notification (PCN) is to protect the >> quality of service (QoS) of inelastic flows within a Diffserv >> domain, in >> a simple, scalable and robust fashion. Two mechanisms are used: >> admission control, to decide whether to admit or block a new flow >> request, and (in abnormal circumstances) flow termination to decide >> whether to terminate some of the existing flows. Together they >> protect >> the QoS of previously admitted flows. To achieve this, the overall >> rate >> of the PCN-traffic is metered on every link in the PCN-domain, and >> PCN-packets are appropriately marked when certain configured rates >> are >> exceeded. These configured rates are below the rate of the link thus >> providing notification before any congestion occurs (hence >> "pre-congestion notification"). The level of marking allows the >> boundary >> nodes to make decisions about whether to admit or terminate. For a >> full description of the PCN architecure see [RFC xxxx (the >> architecture document)]. >> _______________________________________________ >> PCN mailing list >> PCN@ietf.org >> https://www.ietf.org/mailman/listinfo/pcn > _______________________________________________ > PCN mailing list > PCN@ietf.org > https://www.ietf.org/mailman/listinfo/pcn From toby.moncaster@bt.com Tue Apr 28 07:44:50 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 481A23A6D18 for ; Tue, 28 Apr 2009 07:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXVovbg+2G4E for ; Tue, 28 Apr 2009 07:44:49 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 400F53A6B21 for ; Tue, 28 Apr 2009 07:44:48 -0700 (PDT) Received: from E03MVZ1-UKDY.domain1.systemhost.net ([193.113.30.65]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 15:46:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 28 Apr 2009 15:43:04 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-ietf-pcn-baseline-encoding-03 Thread-Index: Acm3jxulfMqMrmzOTiCng4Th5M7kqgAACcpwBCAYHQ4= References: <20090407144128.033A03A6981@core3.amsl.com> From: To: , X-OriginalArrivalTime: 28 Apr 2009 14:46:09.0419 (UTC) FILETIME=[116D7DB0:01C9C810] Subject: Re: [PCN] FW: New Version Notification fordraft-ietf-pcn-baseline-encoding-03 X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 14:44:50 -0000 Just checking when the chairs are going to start a WGLC for this = document as was agreed in the last IETF meeting? I did the revisions = suggested by Gorry Fairhurst 3 weeks ago... =20 Toby Moncaster ________________________________ From: pcn-bounces@ietf.org on behalf of toby.moncaster@bt.com Sent: Tue 07/04/2009 15:43 To: pcn@ietf.org Subject: [PCN] FW: New Version Notification = fordraft-ietf-pcn-baseline-encoding-03 This new draft attempts to address the majority of Gorry Fairhurst's = comments sent after the last meeting. There are a couple of comments = that I have either disagreed with or failed to understand which I will = adrress in a separate email later in the week. I assume from the minutes of the meeting that this will now trigger the = charirs to start a WGLC for this document? Toby Moncaster ________________________________ From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Tue 4/7/2009 15:41 To: Moncaster,T,Toby,CXR9 R Cc: Briscoe,RJ,Bob,CXR9 R; menth@informatik.uni-wuerzburg.de Subject: New Version Notification for = draft-ietf-pcn-baseline-encoding-03 A new version of I-D, draft-ietf-pcn-baseline-encoding-03.txt has been = successfuly submitted by T Moncaster and posted to the IETF repository. Filename: draft-ietf-pcn-baseline-encoding Revision: 03 Title: Baseline Encoding and Transport of Pre-Congestion = Information Creation_date: 2009-04-07 WG ID: pcn Number_of_pages: 12 Abstract: The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. The overall rate of the PCN-traffic is metered on every link in the PCN-domain, and PCN-packets are appropriately marked when certain configured rates are exceeded. The level of marking allows the boundary nodes to make decisions about whether t o admit or block a new flow request, and (in abnormal circumstances) whether to terminate some of the existing flows, thereby protecting the QoS of previously admitted flows. This document specifies how such marks are to be encoded into the IP header by re-using the ECN codepoints within this controlled domain. The baseline encoding described here provides for only two PCN encoding states, unmarked and marked. = =20 The IETF Secretariat. _______________________________________________ PCN mailing list PCN@ietf.org https://www.ietf.org/mailman/listinfo/pcn From slblake@petri-meat.com Tue Apr 28 09:48:38 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2BD928C101 for ; Tue, 28 Apr 2009 09:48:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPiWtEwzwEJ9 for ; Tue, 28 Apr 2009 09:48:38 -0700 (PDT) Received: from elom.tchmachines.com (elom.tchmachines.com [208.76.80.198]) by core3.amsl.com (Postfix) with ESMTP id B6EBE28C209 for ; Tue, 28 Apr 2009 09:46:28 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=petri-meat.com) by elom.tchmachines.com with esmtpa (Exim 4.69) (envelope-from ) id 1LyqTC-0003RN-FU for pcn@ietf.org; Tue, 28 Apr 2009 12:47:46 -0400 MIME-Version: 1.0 Date: Tue, 28 Apr 2009 12:47:46 -0400 From: To: pcn@ietf.org Message-ID: X-Sender: slblake@petri-meat.com User-Agent: RoundCube Webmail/0.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - elom.tchmachines.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - petri-meat.com Subject: [PCN] WGLC for draft-ietf-pcn-baseline-encoding-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, 28 Apr 2009 16:48:38 -0000 The working group last call for draft-ietf-pcn-baseline-encoding-03.txt starts now, and will end in two weeks (Tuesday May 12). Please send comments to the list. http://tools.ietf.org/html/draft-ietf-pcn-baseline-encoding Regards, // Steve From philip.eardley@bt.com Wed Apr 29 08:22:42 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E0053A715A for ; Wed, 29 Apr 2009 08:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.162 X-Spam-Level: X-Spam-Status: No, score=-3.162 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNFzx-P4UOvV for ; Wed, 29 Apr 2009 08:22:41 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 3DB693A6CD1 for ; Wed, 29 Apr 2009 08:22:40 -0700 (PDT) Received: from E03MVB1-UKBR.domain1.systemhost.net ([193.113.197.107]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 16:24:01 +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: Wed, 29 Apr 2009 16:24:01 +0100 Message-ID: <4A916DBC72536E419A0BD955EDECEDEC04AD7B9E@E03MVB1-UKBR.domain1.systemhost.net> In-Reply-To: <0AD29BC9-757C-4AEF-9F99-939BEF18A936@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PCN] PCN elevator speech Thread-Index: AcnFN+zh+vmen8uBRoyHt8KVh0CQEwDpSG7w From: To: , X-OriginalArrivalTime: 29 Apr 2009 15:24:01.0550 (UTC) FILETIME=[8622EAE0:01C9C8DE] Cc: pcn@ietf.org Subject: Re: [PCN] PCN elevator speech X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 15:22:42 -0000 Fred I agree with the sentiment of your first point. But:- >>These configured rates are below the rate of the link thus providing notification before any congestion occurs (hence "pre-congestion notification").]=20 >> the point of this sentence was simply to say that PCN is providing notification before congestion occurs. In the main body of the doc, it simply says things like " PCN-admissible-rate: the rate of PCN-traffic on a link up to which PCN admission control should accept new PCN-flows." - so hopefully it's clear that as you say you can configure this value to be whatever you choose, ie what you want for this class of traffic and not the full capacity of the link.=20 on your second point, sorry if the following misunderstands. Is your idea to use PCN-marking on elastic traffic? I believe that the marking draft http://tools.ietf.org/html/draft-ietf-pcn-marking-behaviour-02 allows this. although i don't think anyone's done any experiments. I certainly hope that PCN marking will be useful in use cases beyond admission control [but these wider cases are outside the current pcn charter, and so not covered in the Architecture docm beyond a small mention in the Appendix about possible future work]. Best wishes phil { -----Original Message----- { From: pcn-bounces@ietf.org [mailto:pcn-bounces@ietf.org] On Behalf Of Fred { Baker { Sent: 25 April 2009 00:54 { To: Tom Taylor { Cc: pcn { Subject: Re: [PCN] PCN elevator speech {=20 { I have an additional edit. {=20 { Generally, one doesn't configure a link to run full-bore and then { scale back to deal with the traffic it has. r\Rather, one configures a { link to deal effectively with specific application classes. For { example, one will generally have a class for real-time traffic or { separate classes for voice and video, with a separate class for { elastic applications. This results in the real time traffic being { handled in a way that serves its needs (it is guaranteed at most a { given latency on a link so that e2e delay variation doesn't exceed { some threshold), allowing elastic traffic to do the things it is { famous for doing without interrupting real-time services. {=20 { As such, the reference to "the rate of the link" should refer to the { "the rate allocated to a traffic class". If the class in fact occupies { the whole link, the two statements are equivalent. If that observation { gives heartburn, I would suggest "the rate of a traffic class, or { where appropriate, a link". {=20 { It would also be very nice if we could somehow provide an architecture { in which we are not using one mechanism differently for two different { purposes, but using one mechanism to serve one purpose interpreted { differently by different use cases. We are willing to have pre- { congestion notification for voice/video/etc, but are willing to build { queues for data in some cases, and in other cases have had suggestions { that folks could similarly manage RFC 3168-like ECN based on traffic { rates in elastic classes. If we are building an architecture for ECN { in general of which PCN and RFC 3168 are special cases, then that { should be reflected in this proposed text. {=20 { On Apr 24, 2009, at 4:06 PM, Tom Taylor wrote: {=20 { > Having said this, I would beg the indulgence of the group to modify { > the second-last sentence slightly, so it reads: { > { > "The level of marking allows decisions to be made about whether to { > admit or terminate." { > { > Tom Taylor wrote: { >> Here is the text that is proposed to begin all PCN-related { >> documents. Phil actually did the work, with input from others. { >> The objective of Pre-Congestion Notification (PCN) is to protect the { >> quality of service (QoS) of inelastic flows within a Diffserv { >> domain, in { >> a simple, scalable and robust fashion. Two mechanisms are used: { >> admission control, to decide whether to admit or block a new flow { >> request, and (in abnormal circumstances) flow termination to decide { >> whether to terminate some of the existing flows. Together they { >> protect { >> the QoS of previously admitted flows. To achieve this, the overall { >> rate { >> of the PCN-traffic is metered on every link in the PCN-domain, and { >> PCN-packets are appropriately marked when certain configured rates { >> are { >> exceeded. These configured rates are below the rate of the link thus { >> providing notification before any congestion occurs (hence { >> "pre-congestion notification"). The level of marking allows the { >> boundary { >> nodes to make decisions about whether to admit or terminate. For a { >> full description of the PCN architecure see [RFC xxxx (the { >> architecture document)]. { >> _______________________________________________ { >> PCN mailing list { >> PCN@ietf.org { >> https://www.ietf.org/mailman/listinfo/pcn { > _______________________________________________ { > PCN mailing list { > PCN@ietf.org { > https://www.ietf.org/mailman/listinfo/pcn {=20 { _______________________________________________ { PCN mailing list { PCN@ietf.org { https://www.ietf.org/mailman/listinfo/pcn From fred@cisco.com Wed Apr 29 08:57:19 2009 Return-Path: X-Original-To: pcn@core3.amsl.com Delivered-To: pcn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 777163A6CBF for ; Wed, 29 Apr 2009 08:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.472 X-Spam-Level: X-Spam-Status: No, score=-106.472 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 OTEtOhejOj8c for ; Wed, 29 Apr 2009 08:57:18 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id B913B3A6C7E for ; Wed, 29 Apr 2009 08:57:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,266,1238976000"; d="scan'208";a="157687108" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 29 Apr 2009 15:58:41 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3TFwf6E010415; Wed, 29 Apr 2009 08:58:41 -0700 Received: from [10.2.10.146] (sjc-vpn2-1335.cisco.com [10.21.117.55]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3TFwfdf021418; Wed, 29 Apr 2009 15:58:41 GMT Message-Id: <6B323068-945D-4D07-A88A-527E8D97EA5A@cisco.com> From: Fred Baker To: "" In-Reply-To: <4A916DBC72536E419A0BD955EDECEDEC04AD7B9E@E03MVB1-UKBR.domain1.systemhost.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 29 Apr 2009 08:58:40 -0700 References: <4A916DBC72536E419A0BD955EDECEDEC04AD7B9E@E03MVB1-UKBR.domain1.systemhost.net> X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=466; t=1241020721; x=1241884721; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:=20Fred=20Baker=20 |Subject:=20Re=3A=20[PCN]=20PCN=20elevator=20speech |Sender:=20; bh=jttcNitVPWB2dRoCaAX1L5AVsNBdxKnWUKWEF+LwyIQ=; b=t1sSpcSJku+pphZL0tRHGwss83Hjt7nxnRQyFUDUWp01HvjrGi+/nJSBmY gd2cqK9WBBYgDp83EfDQsMsB+PeVmelg0nPkaMis/Y8SvRO5TiGvckcms1Wr ddbMeZvhTF; Authentication-Results: sj-dkim-2; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: pcn@ietf.org Subject: Re: [PCN] PCN elevator speech X-BeenThere: pcn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: PCN WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 15:57:19 -0000 On Apr 29, 2009, at 8:24 AM, wrote: > on your second point, sorry if the following misunderstands. Is your > idea to use PCN-marking on elastic traffic? My point is that PCN builds on ECN, applying them same model to a different class of traffic (real time traffic). What I would like to see is a model that one might call "congestion notification", of which PCN and ECN are both special cases.